<1997-05-05> Erlaeuterungen zur Einrichtung neuer Gruppen in de.*
Thomas Roessler
Archive-Name: de-newusers/dana-manual
Version: $Revision: 1.12 $
URL: http://www.rhein.de/~roessler/manual.html
Posting-Frequency: monthly
-----BEGIN PGP SIGNED MESSAGE-----
Erläuterungen zur Einrichtung neuer Gruppen in der »de-Hier
archie«
Nach einem Entwurf von Dirk Nimmich
$Revision: 1.12 $
____________________________________________________________
Table of Contents:
1. Einleitung
1.1. Adressatenkreis
1.2. Was ist ein RfD?
2. Vor dem RfD
3. Formulierung eines RfD
3.1. Aufbau
3.2. Wahl des Gruppennamens
3.3. Die Kurzbeschreibung
3.4. Der Status
3.5. Die Charta
3.6. Die Begründung
3.7. Muster
3.7.1. RfD für eine unmoderierte Gruppe
3.7.2. RfD für eine moderierte Gruppe
4. Einsenden des RfD an die Moderation
5. Nach der Veröffentlichung
6. Die Abstimmung
6.1. Inhalt eines CfV
6.2. Technische Voraussetzungen für die Durchführung
6.3. Unabhängige Wahlleiter
7. Schlußbemerkungen
7.1. Literatur
7.2. Glossar
7.3. Die Mentoren
7.4. Danksagungen
______________________________________________________________________
1. Einleitung
1.1. Adressatenkreis
Dieser Text richtet sich an diejenigen, die eine Newsgroup in der »de-
Hierarchie« einrichten wollen. Er versucht, einen Teil der gerade für
»Neulinge« häufig frustrierenden Standardargumentation in
de.admin.news.groups vorwegzunehmen und die in dem Posting
»Einrichtung von Newsgroups in "de.*"« (Archive-Name: de-
newsgroups/einrichtung) niedergelegten Richtlinien zur Einrichtung
neuer Gruppen zu erläutern.
Jedem Unerfahrenen, der eine Wahl in der »de-Hierarchie« durchführen
will, sei empfohlen, sich vorher mit einer möglichst weit gediehenen
Beschreibung seines Vorschlags an <ment...@dana.de> zu richten. Unter
dieser Adresse ist eine Gruppe von Freiwilligen zu erreichen, die
bereit sind, den Proponenten bei der Abfassung des endgültigen RfDs zu
beraten und während des weiteren Procederes zu begleiten.
Natürlich gibt es keinerlei Zwang, auf dieses Angebot einzugehen; es
handelt sich lediglich um eine Möglichkeit, sich Anregungen und
Anmerkungen zu seinem Vorschlag einzuholen, bevor man sich damit an
die Öffentlichkeit wendet.
Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der
Unterhierarchie de.alt: Dort wird eine Gruppe in de.alt.admin
vorgeschlagen. Ergab die dortige Diskussion keinen gar zu heftigen
Gegenwind, wird die Gruppe eingerichtet.
1.2. Was ist ein RfD?
Ein RfD (kurz für »Request for Discussion«) ist der formale Aufruf zur
Diskussion, der am Anfang jedes Verfahrens zur Einrichtung,
Umbenennung etc. einer Gruppe in der »de-Hierarchie« steht. Er wird
in de.admin.news.announce veröffentlicht und dient als Grundlage der
nachfolgenden Diskussion in de.admin.news.groups, während der er auf
inhaltliche Qualität und Akzeptanz abgeklopft und verfeinert wird. Am
Ende dieser Diskussion steht üblicherweise der Aufruf zu einer
Abstimmung (»Call for Votes« oder kurz »CfV« genannt), in der die
Akzeptanz des Vorschlags festgestellt wird.
Vom Ausgang dieser Abstimmung hängt die Annahme des Vorschlags ab.
Nach den Regeln, die regelmäßig u. a. in de.admin.news.announce
gepostet werden, bedarf es zur Annahme einer Gruppe einer
Zweidrittelmehrheit. Die aktuellen Wahlregeln werden regelmäßig u. a.
in de.admin.news.announce unter dem Subject »Einrichtung von Usenet-
Gruppen in de.*« gepostet.
2. Vor dem RfD
Bevor man mit der Arbeit an einem RfD beginnt, sollte man sich selbst
immer die Frage stellen, ob die gewünschte Änderung wirklich benötigt
wird; bei der Neueinrichtung einer Gruppe sollte man insbesondere auf
die folgenden Punkte achten:
1. Existiert bereits eine deutschsprachige Gruppe zum Thema? Es ist
nicht sinnvoll, eine zweite Gruppe zur Diskussion ein und desselben
Themas einzurichten; ein entsprechender Vorschlag würde
zwangsläufig scheitern. Existiert andererseits eine Gruppe, in der
das gewünschte Thema diskutiert wird, ist diese Gruppe aber
überfüllt, so ist es unter Umständen sinnvoll, diese Gruppe in
mehrere Gruppen aufzuspalten.
2. Besteht im Netz Interesse am Thema? Öffentliche Selbstgespräche
sind auf Dauer ermüdend. Im eigenen Interesse sollte man zunächst
versuchen festzustellen, ob das gewünschte Thema überhaupt im Netz
diskutiert wird. Gibt es in verschiedenen Gruppen wiederkehrende
Diskussionen, die sich auf das gewünschte Thema beziehen? Gibt es
Mailinglisten, die sich mit dem Thema auseinandersetzen?
3. Existiert schon ein Vorschlag? Es ist wenig sinnvoll, eine weitere
Diskussion zu beginnen, wenn die Einrichtung einer Gruppe zum
gewünschten Thema bereits im Gespräch ist. Anstatt einen formellen
Vorschlag einzureichen, sollte man sich in de.admin.news.groups
aktiv an der laufenden Diskussion beteiligen. In der Gruppe
de.admin.news.announce wird regelmäßig der Status der laufenden
Verfahren veröffentlicht.
Ist man nach der Überprüfung dieser Punkte der Ansicht, daß eine neue
Gruppe im allgemeinen Interesse liegt, sollte man sich nach
Verbündeten umsehen: Es schadet nicht, wenn ein Vorschlag während der
Diskussion von einer ganzen Reihe von Leuten, die an dem
vorgeschlagenen Thema Interesse haben und später in der Gruppe posten
würden, unterstützt wird.
3. Formulierung eines RfD
3.1. Aufbau
Ein RfD für die Neueinrichtung einer Gruppe besteht aus einem
Namensvorschlag für die Gruppe, dem Status der Gruppe (moderiert oder
unmoderiert), einer zugehörigen Kurzbeschreibung und einer Charta.
Als Grundlage für die Diskussion sollte ferner der Hintergrund des
Vorschlags erläutert werden. In dieser Erläuterung sollte man
insbesondere auf die oben genannten Punkte eingehen; andernfalls muß
man damit rechnen, daß sie als »Standardfragen« in der Diskussion
wieder auftauchen.
Ein RfD sollte üblicherweise nur einen einzelnen Gruppenvorschlag
behandeln - es verwirrt nur, wenn eine Gruppe über das
Fortpflanzungsverhalten der Pflastersteine unter Berücksichtigung des
besonderen Einflusses des Sonnenlichts im gleichen Thread diskutiert
wird wie eine Gruppe, die dem Diskurs über die gesellschaftlichen
Auswirkungen des Fernsehens dient. Eine Ausnahme von dieser Regel
stellt die schon oben angesprochene Aufspaltung von Gruppen dar: Hier
sollte man Sammel-RfDs und -CfVs veranstalten. Eine Sammelabstimmung
ist so zu verfassen, daß jede Entscheidung auch einzeln zur Abstimmung
kommen könnte. Eine Ausnahme gibt es bei der Aufteilung einer Gruppe:
Die Umbenennung einer Gruppe in Gruppe.misc bei Annahme mindestens
einer Untergruppe kann automatisch erfolgen.
3.2. Wahl des Gruppennamens
Der Name besteht aus mehreren durch Punkte getrennten Segmenten. Die
einzelnen Segmente dürfen nicht länger als 14 Zeichen werden und
müssen mindestens je einen Buchstaben enthalten. Erlaubte Zeichen
innerhalb eines Segments sind die Kleinbuchstaben (a-z), die
arabischen Ziffern (0-9) sowie das Plus-Zeichen (+), das Minus-Zeichen
(-) und der Unterstrich (_); letzterer ist aber unüblich (um genau zu
sein: es gibt zur Zeit keine einzige Newsgroup in de.*, die einen
Unterstrich enthält).
Der Name sollte so aussagekräftig wie möglich sein und sich dabei in
die bestehende Namenshierarchie einpassen:
de.alt
ist eine Unterhierarchie, in der eigene Regeln gelten. Die
Einrichtung von Gruppen in dieser Unterhierarchie wird hier
nicht behandelt.
de.admin
beschäftigt sich mit der administrativen Seite des Usenet, also
im wesentlichen mit dem Mail- und Newsaustausch im Netz und der
Fortentwicklung der de-Newsgroups.
de.comm
dient der Diskussion über Kommunikation und
Kommunikationstechnik. Diese Unterhierarchie hat eine noch
weiter differenzierte Struktur: de.comm.infosystems.* behandelt
Informationssysteme wie das World Wide Web (WWW), WAIS oder
Hyper-G; de.comm.internet.* ist mit einigen Aspekten des
Internets befaßt; de.comm.isdn.* beschäftigt sich mit der Welt
des digitalen Telefonierens; de.comm.protocols.* mit
Kommunikationsprotokollen und de.comm.software.* mit
Kommunikationssoftware.
de.comp
dreht sich um Computer und alles, was damit zu tun hat. Auch
diese Unterhierarchie ist weitergehend gegliedert: In
de.comp.os.* wird über Betriebssysteme gesprochen, Hardware
diskutiert man in de.comp.sys.*, und Programmiersprachen als
solche werden in de.comp.lang.* debattiert.
de.markt
ist der Kleinanzeigenbereich des deutschsprachigen Usenet: Hier
werden nicht-kommerzielle Angebote und Gesuche ausgetauscht.
de.org
dient verschiedenen »Organisationen« als Diskussionsforum. In
de.admin.news.groups ist allerdings die Auffassung recht weit
verbreitet, daß neue Gruppen nach Möglichkeit in
themenspezifischen Unterhierarchien eingerichtet werden sollten
(wie beispielsweise de.org.politik.spd).
de.rec
beschäftigt sich mit Freizeitaktivitäten aller Art.
Unterhierarchien sind de.rec.games (Spiele aller Art),
de.rec.music (Musik), de.rec.sport (Sport), de.rec.sf (Science
Fiction), de.rec.tiere (die lieben Haustiere). Auch hier
vertreten einige Teilnehmer von de.admin.news.groups die
Ansicht, daß neue Gruppen möglichst nicht mehr direkt unter
de.rec.* eingerichtet werden sollten, um die Übersichtlichkeit
nicht zu gefährden.
de.sci
ist den Wissenschaften gewidmet, wobei bei der Einrichtung neuer
Gruppen in dieser Hierarchie immer wieder Streit aufkommt, was
denn überhaupt eine Wissenschaft sei. In der Praxis scheint
sich bisher die Meinung durchgesetzt zu haben, daß die Lehrpläne
von Universitäten im deutschsprachigen Raum einen ganz guten
Überblick bieten. Direkt unterhalb von de.sci werden
üblicherweise ganze Fachbereiche untergebracht. Einzelne
Spezialgebiete haben dort nichts zu suchen; sie sollten als
Untergruppen dem entsprechenden Fach zugeordnet werden
(Beispiel: de.sci.medizin.logopaedie).
de.soc
handelt von gesellschaftlichen Dingen.
de.talk
dient dem gemütlichen Plausch über mehr oder minder
Weltbewegendes. Von purem Unsinn (de.talk.bizarre) bis hin zu
des Menschen wichtigster Nebensache (de.talk.sex) ist alles
vertreten.
de.etc
schließlich stellt das Auffangbecken dar, wenn ein Thema nicht
in eine der anderen Unterhierarchien paßt.
Man sollte außerdem versuchen, im Gruppennamen möglichst keine
kryptischen oder mehrdeutigen Abkürzungen zu verwenden. Wenn diese gar
nicht zu vermeiden sind, sollte man sie in der Kurzbeschreibung,
spätestens aber in der Charta auflösen.
3.3. Die Kurzbeschreibung
Die Kurzbeschreibung ist zum einen in den regelmäßigen Postings zu
finden, die den Systemadministratoren helfen, die Auswahl der auf
ihren Systemen bereitgehaltenen Gruppen auf dem neuesten Stand zu
halten. Andererseits zeigen viele Newsprogramme diese
Kurzbeschreibung auch an, um den Leser an das Thema der Gruppe zu
erinnern und somit von Fehlpostings abzuhalten. Sie ist (neben dem
Namen) häufig das erste, was ein potentieller Leser von einer Gruppe
zu Gesicht bekommt.
Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
ab: Sie muß kurz, knapp und für jeden verständlich sein. »Diskussion
über« oder »Informationen von« sind zum Beispiel notorisch
überflüssige Formulierungen. Da die Kurzbeschreibung in Gruppenlisten
auftaucht (auch in solchen, die von Newsreadern angezeigt werden), die
meist auf 80 Spalten breiten Terminals gelesen werden, ergibt sich
eine Beschränkung für die Länge der Kurzbeschreibung: Gruppenname, ein
8er-Tabulator und Kurzbeschreibung sollten in weniger als 80 Zeichen
passen. Als Richtwert gilt für gewöhnlich eine Maximallänge von 60
Zeichen.
Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze
Kurzbeschreibung anzeigen, wird er sich üblicherweise auf den Anfang
der Kurzbeschreibung beschränken. Daraus folgt, daß die wichtigsten
Punkte in einer Kurzbeschreibung an deren Anfang stehen sollten. Um
Komplikationen zu vermeiden, sollten Kurzbeschreibungen keine Umlaute
und sonstige Sonderzeichen enthalten; der Zeichenvorrat ist »US-
ASCII«. Per Konvention endet jede Kurzbeschreibung mit einem Punkt.
3.4. Der Status
Man unterscheidet zwischen moderierten und unmoderierten Gruppen.
Artikel für eine unmoderierte Gruppe werden vom Newsreader dem lokalen
Server übergeben, der sie mittels der üblichen Mechanismen an seine
»Nachbarn« weiterleitet. Artikel für eine moderierte Gruppe werden
zunächst zur Bestätigung per Mail an einen Moderator geschickt, der
sie dann veröffentlicht.
Moderierte Gruppen eignen sich vor allem für Ankündigungen. Beispiele
hierfür sind zum Beispiel de.admin.news.announce, die sich auf die
Aufrufe zu Diskussion und Abstimmung beschränkt und damit auch für
diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
im einzelnen zu folgen, oder de.rec.orakel, in der sich allwöchentlich
eine Auswahl der besten Fragen und Antworten des Internet-Orakels
findet.
Ein weiterer Grund für eine moderierte Gruppe kann sein, daß (bei
einem wissenschaftlichen Thema zum Beispiel) ein gewisses
Mindestniveau der Diskussion gewahrt werden soll. Als Beispiele seien
hier nur die internationalen sci.*.research-Gruppen genannt.
Ist man zu dem Ergebnis gekommen, daß man eine moderierte Gruppe
einrichten will, sollte man sich über die folgenden Punkte klar
werden:
1. Wer soll moderieren? Es ist für gewöhnlich sinnvoll, bereits vor
der Veröffentlichung des Vorschlags mindestens einen Kandidaten für
die Moderation zu haben. Diesen sollte man im RfD nennen.
2. Wohin mit den Followups? Viele moderierte Gruppen dienen als
Ankündigungsgruppen - de.admin.news.announce ist wieder nur ein
Beispiel. Über die Ankündigungen wird üblicherweise auch
diskutiert. Dies kann entweder in einer speziellen Gruppe
geschehen (für de.admin.news.announce ist das normalerweise
de.admin.news.groups) oder in einer allgemeineren Diskussionsgruppe
(Postings in de.rec.orakel haben üblicherweise ein Followup-To:
de.talk.jokes.d im Header). Existiert noch keine unmoderierte
Gruppe, in der die Diskussionen stattfinden können, sollte man
gegebenenfalls im gleichen RfD die Einrichtung einer solchen zur
Diskussion stellen.
3.5. Die Charta
Die Charta ist die Beschreibung der Newsgroup schlechthin. Hier wird
in ein bis zwei Absätzen in Form vollständiger Sätze erklärt, womit
eine Newsgroup sich beschäftigt, welche Themen erwünscht sind, welche
Themen nicht erwünscht sind, welche besonderen Konventionen gelten,
etc.
Beispiel für eine gelungene Charta ist diejenige von de.rec.outdoors:
Die Gruppe dient der Diskussion aller Arten von
Freizeitbeschaeftigungen abseits der Zivilisation sowie der damit
verbundenen Themen wie Ausruestung, gesetzliche Bestimmungen,
Erlebnisberichte, Freiluftkueche und dergleichen. Nicht Thema der
Gruppe ist das klassische Campen mit Gardinen im Hauszelt.
3.6. Die Begründung
Hier hat man Gelegenheit, den Leser davon zu überzeugen, daß die
vorgeschlagene Newsgroup sinnvoll ist und nicht nur Leser, sondern
auch Autoren finden wird. Man sollte begründen, warum man selbst die
Gruppe für sinnvoll hält, und seine Überlegungen zur Einordnung der
Gruppe in die de-Hierarchie darlegen. Man sollte darauf eingehen, wo
bereits über das Thema diskutiert wird - andere Newsgroups,
Mailinglisten, die überlaufen, und dergleichen.
Wird der Vorschlag von einer größeren Gruppe von Nutzern unterstützt
(soll beispielsweise eine überquellende Diskussionsliste in eine
Newsgroup umgewandelt werden), sollte man das hier erwähnen.
3.7. Muster
In diesem Abschnitt finden sich Muster für die formale Gestaltung von
RfDs für moderierte und unmoderierte Gruppen.
3.7.1. RfD für eine unmoderierte Gruppe
1. Diskussionsaufruf
====================
zur Einrichtung der neuen Gruppe
[Gruppenname] [Kurzbeschreibung]
Status: Die Gruppe ist unmoderiert.
Charta
------
[Charta]
Hintergrund
-----------
[Begruendung]
3.7.2. RfD für eine moderierte Gruppe
1. Diskussionsaufruf
====================
zur Einrichtung der neuen Gruppe
[Gruppenname] [Kurzbeschreibung] <mo...@ra.tor> (Moderated)
Diskussionen sollen in der Gruppe
[Gruppenname] [Kurzbeschreibung]
gefuehrt werden.
Status
------
Die Gruppe ist moderiert. Als Moderator werden Martina Oderat
<m....@rator.de> und Peter Roponent <p.r...@nent.de> vorgeschlagen.
Charta
------
[Charta]
Die Postings in [Gruppenname] sind mit einer Headerzeile
Followup-To: [Diskussionsgruppe]
zu versehen.
Hintergrund
-----------
[Begruendung]
4. Einsenden des RfD an die Moderation
Der Moderator von de.admin.news.announce ist unter der Adresse
<mode...@dana.de> zu erreichen; ihm schickt man den fertigen RfD
samt der Liste der Gruppen zu, in denen er veröffentlicht werden soll.
Dazu gehören immer de.admin.news.announce und de.admin.news.groups.
Hinzu kommen für gewöhnlich dem Vorschlag thematisch naheliegende
Gruppen, deren Leserschaft an der Diskussion über die Einrichtung der
geplanten Gruppe ein natürliches Interesse haben.
Der Moderator wird den RfD anhand der hier beschriebenen Punkte
überprüfen und beim Autor per Mail Rückfragen stellen, um ggfs.
Mißverständnisse auszuräumen. Ist alles klar, postet er den Artikel
in den genannten Gruppen.
5. Nach der Veröffentlichung
Nachdem der Moderator den RfD veröffentlicht hat, findet in
de.admin.news.groups die Diskussion über den Vorschlag statt. Die
Antragsteller sollten die Diskussion verfolgen und auf Einwände und
Kritik eingehen, ihre Begründung verfeinern. Häufig wird die
Diskussion sinnvolle Ergänzungen zum ursprünglichen Vorschlag bringen,
die man in einen neuen Vorschlag einarbeiten kann.
Hat die Diskussion zu weitgehenden Änderungen am Vorschlag geführt,
sollte man etwa zwei Wochen nach dem ersten Diskussionsaufruf einen
zweiten RfD in den gleichen Gruppen veröffentlichen, der den
modifizierten Vorschlag und eine Begründung, warum man welche
Vorschläge aufgenommen oder verworfen hat, enthält.
6. Die Abstimmung
6.1. Inhalt eines CfV
Ist die Diskussion in de.admin.news.groups so weit fortgeschritten,
daß der Proponent der Meinung ist, mit seinem Vorschlag weitgehend
Zustimmung zu erhalten, geht es darum, die Abstimmung über diesen
Vorschlag in die Wege zu leiten. Formell wird diese Abstimmung durch
einen CfV eingeleitet, der sich im großen und ganzen an dem letzten
RfD als Abstimmungsgegenstand orientieren soll. Zusätzlich enthält ein
CfV noch Informationen über die Wahlfrist und die Adresse oder
Adressen, an die die Wahlscheine geschickt werden sollen, sowie einen
Wahlschein und Beispiele für Abstimmöglichkeiten.
Die Frist zur Abgabe der Stimme beträgt in der Regel drei bis vier
Wochen, gerechnet von der Veröffentlichung in de.admin.news.announce.
In der Mitte der Frist sollte ein zweiter CfV veröffentlicht werden,
in dem die Personen, die ihre Stimme bereits abgegeben haben, zur
Kontrolle mit ihrer E-Mail-Adresse (ohne das Votum) aufgelistet
werden.
Ein Muster-CfV:
1. Aufruf zur Wahl
==================
zur Einrichtung der neuen Gruppe
<Gruppenname> <Kurzbeschreibung>
Status: Die Gruppe ist {moderiert|unmoderiert}.
Charta
------
<Charta>
Modalitäten
-----------
Die Stimmen müssen bis zum <Datum> eingehen. Ausschlaggebend
ist hierbei das *Eintreffen* der Stimme, nicht das Absendedatum!
Bitte benutze den Wahlschein, der am Ende dieses CfV angebracht
ist. Wahlberechtigt ist jede natürliche Person, die in der Lage
ist, E-Mail an die Abstimmungsadresse zu schicken.
Es gelten die derzeitigen Wahlregeln, die in de.newusers,
de.newusers.questions, de.admin.news.groups und de.alt.admin
veroeffentlicht sind.
Wie gewählt wird
----------------
Trage in die Felder des Wahlscheins unten Deine Stimme (JA, NEIN
oder ENTHALTUNG) ein und schicke den Wahlschein dann an den
Vote-Account <em...@adres.se> (Reply-To:-Header ist gesetzt.) Es
werden nur Stimmen berücksichtigt, die per Mail an diesen Account
gerichtet sind. Öffentliche Stimmabgaben (Postings) sind ungültige
Stimmen und werden nicht berücksichtigt.
Deine Entscheidung bedeutet dabei:
JA - Ich bin für diesen Vorschlag.
NEIN - Ich bin gegen diesen Vorschlag.
ENTHALTUNG - Ich enthalte mich oder ich ziehe meine Stimme zurück
Enthaltungen gelten nicht im Sinne einer gültig
abgegebenen Stimme; sie dienen vornehmlich dazu,
eine zuvor abgegebene Stimme zurückzuziehen.
Der Wahlleiter wird auf Deine Stimme mit einer persönlichen
Bestätigung via E-Mail reagieren. Wenn Du innerhalb von ein paar
Tagen nichts hörst, versuche es noch einmal.
Solltest Du Deine Meinung ändern, so wähle einfach
neu. Willst Du dabei Deine Stimme annulieren, so entscheide
ENTHALTUNG. Gehen mehrere Stimmen ein, gilt die jeweils zuletzt
abgeschickte (Date:-Eintrag der Mail).
Bitte beachte, daß die Stimme Deinen echten Namen enthalten
muß, kein Pseudonym. Sollte Dein Newsreader den Namen nicht
automatisch im From:-Header eintragen, trage ihn bitte nochmal im
Wahlzettel ein. Andernfalls ist Deine Stimme ungültig.
In der Mitte der Wahlperiode wird ein zweiter CfV gepostet, der
eine Auflistung aller Personen enthält, von denen bis zu diesem
Zeitpunkt eine gültige Stimme eingegangen ist.
Die Ergebnisse der Wahl werden nach Ablauf der Wahlfrist
öffentlich gepostet, wobei jede einzelne Stimme, zur Kontrolle
für alle, aufgelistet wird. Solltest Du begründete Bedenken gegen
die Veröffentlichung Deiner Stimme haben, melde Dich bitte beim
Wahlleiter (<e-m...@ad.res.se>).
-=-=-=-=-=-= Alles vor dieser Zeile löschen =-=-=-=-=-=-
Wahlschein fuer die {Einrichtung|Umbenennung|Entfernung} von
<Gruppenname>
Dein Realname, falls nicht im From:-Header:
Wenn Du keinen Real-Namen veröffentlicht haben willst, wende Dich
mit einer Begründung an <e-m...@ad.res.se>
[ Deine Stimme ] Abstimmungsgegenstand
----------------------------------------------------------------------
[ JA NEIN ENTHALTUNG ] Einrichtung von <Gruppenname>
-=-=-=-=-=-= Alles nach dieser Zeile löschen =-=-=-=-=-=-
6.2. Technische Voraussetzungen für die Durchführung
Für die Abstimmung selbst benötigt man einen E-Mail-Account, der die
Wahlscheine entgegennimmt. Dieser sollte nach Möglichkeit nicht mit
der »normalen« E-Mail-Adresse des Abstimmungsleiters identisch sein,
damit keine Mißverständnisse auftreten oder Wahlscheine in der
sonstigen Post verloren gehen.
Jede abgegebene Stimme soll - nach Möglichkeit automatisch - bestätigt
werden. Aus der Nachricht sollte außerdem hervorgehen, wie die Stimme
gezählt wurde, damit der Absender eine falsch gezählte Stimme wieder
ändern oder diese widerrufen kann, wenn er vor Ablauf der Wahlfrist
seine Meinung ändert.
Es wird außerdem empfohlen, den Account zur Entgegennahme der
Wahlscheine zur Reduzierung der Antwortlaufzeiten auf einem Internet-
Host einzurichten.
6.3. Unabhängige Wahlleiter
Wer sich nicht die Mühe machen will, nicht die Möglichkeiten dazu hat,
die Wahl abzuhalten, oder der Meinung ist, die Wahl besser durch
Unabhängige durchführen zu lassen, kann sich auch an die German
Volunteer Votetakers (GVV) wenden. Diese führen dann die Abstimmung
einschließlich zweitem CfV und Veröffentlichung des Ergebnisses durch.
Die GVV sind unter der Adresse <g...@dana.de> zu erreichen.
7. Schlußbemerkungen
7.1. Literatur
Folgende Texte sollten dem Proponenten auf jeden Fall bekannt sein:
<Datum> Einrichtung von USENET-Gruppen in de.*
Dieser Text beschreibt die Richtlinien für die Einrichtung einer
Newsgroup in der de.*-Hierarchie, insbesondere die üblichen
Abstimmungsmodalitäten. Er wird monatlich in de.newusers,
de.newusers.questions, de.admin.news.groups und de.alt.admin
gepostet.
<Datum> Die Newsgroups der de.*-Hierarchie
Hier findet sich eine Beschreibung der bereits eingerichteten
Newsgroups in de.* (ohne de.alt.*). Das Posting findet sich
allmonatlich in de.newusers, de.newusers.questions,
de.admin.news.groups und de.alt.admin.
<Datum> Die Newsgroups der de.alt.*-Hierarchie
Darin sind die bestehenden Newsgruppen der de.alt-Hierarchie
aufgeführt und beschrieben. Auch dieser Text kann den Newsgroups
de.newusers, de.newusers.questions, de.admin.news.groups und
de.alt.admin entnommen werden.
7.2. Glossar
CfV
Call for Votes, Aufruf zur Wahl. Leitet die Abstimmung über eine
Entscheidung ein bzw. dient zur Erinnerung an diese Abstimmung.
dana
Akronym für de.admin.news.announce
GVV
German Volunteer Votetakers, Freiwillige Abstimmungsleiter; zu
erreichen unter der E-Mail-Adresse <g...@dana.de>.
RfD
Request for Discussion, Aufruf zur Diskussion. Leitet die
Diskussion um eine Entscheidung ein bzw. bringt sie wieder in
Gang.
7.3. Die Mentoren
Die Liste der derzeit aktiven Mentoren, die sich bereit erklärt haben,
anderen bei der Erstellung von RfDs und CfVs zu helfen und bei der
Durchführung von Wahlverfahren zu beraten:
Arno Eigenwillig
Dirk Nimmich
Boris `pi' Piwinger
Martin Recke
Thomas Roessler
Oliver B. Warzecha
Eine aktuelle Liste kann man unter
<http://home.pages.de/~roessler/mentoren.html> im WWW finden.
Anfragen sollten aber an die Sammeladresse <ment...@dana.de>
geschickt werden.
7.4. Danksagungen
Zu diesem Text und seiner Entstehung haben beigetragen:
Lutz Donnerhacke <lu...@as-node.jena.thur.de>
Kristian Köhntopp <kris...@koehntopp.de>
Dirk Nimmich <nim...@uni-muenster.de>
Martin Recke <mr...@husemann.in-berlin.de>
Thomas Roessler <roes...@sobolev.rhein.de>
Heiko Schlichting <he...@fu-berlin.de>
Hans-Christoph Wirth <ha...@dianoia.mayn.de>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQC1AwUBMx7egT4lAO9ZMjjhAQHpdQT+O9RmVfiDa8auMF9Z/zsjUye7r/ldayHm
PWvNY/nsdfw8tgHsheR20N2VHfbT3u9/iGmmgCR724zFttXmHfBAj3Cyoc6PF9qB
2wIEeBg7o7uWfh5IbNcizJM/UwiwkjX9/ekMUWrUm/DfmgQ53bAH3x/27g1LoF7+
KyKzsNx9hqXuTlHbOxds71EBCZXiMEQ4YRypcqLzjTywk2dHrEtzmQ==
=dhob
-----END PGP SIGNATURE-----