<2001-04-29> Erlaeuterungen zur Einrichtung neuer Gruppen in de.*
Dirk Nimmich
Posting-frequency: weekly
Last-modified: 2001-04-29
URL: http://www.afaik.de/usenet/faq/dana-manual/
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
Erl�uterungen zur Einrichtung neuer Gruppen in der �de-Hierarchie�
Von Thomas Roessler. Nach einem Entwurf von Dirk Nimmich
$Revision: 1.33 $
____________________________________________________________
Inhaltsverzeichnis
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
3.7.3 Der RfD-Generator
4. Einsenden des RfD an die Moderation
5. Nach der Ver�ffentlichung
6. Die Abstimmung
6.1 Inhalt eines CfV
6.2 Ein Muster-CfV
6.3 Technische Voraussetzungen f�r die Durchf�hrung
6.4 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 Usenet-Gruppen in "de.*"� (Archive-Name: de-
newusers/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 bedarf es zur Annahme einer Gruppe einer
Zweidrittelmehrheit. Die aktuellen Wahlregeln werden regelm��ig u. a.
in de.admin.infos 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.
4. Gab es k�rzlich einen �hnlichen Vorschlag? Viele regelm��ige Leser
von de.admin.news.groups reagieren mit Unwillen, wenn Vorschl�ge,
�ber die gerade erst in epischer Breite diskutiert und abgestimmt
wurde, wieder vorgebracht werden. Es wird allgemein empfohlen, vor
der Wiedervorlage eines abgelehnten Vorschlages eine Denkpause von
mindestens sechs Monaten einzulegen.
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 30 Zeichen werden und
m�ssen mindestens je einen Buchstaben enthalten. Zu beachten ist
dabei, da� sich unterschiedliche Segmentnamen auf gleicher Ebene
schon vor dem 15. Zeichen unterscheiden m�ssen. Erlaubte Zeichen
innerhalb eines Segments sind die Kleinbuchstaben (a-z), die
arabischen Ziffern (0-9) sowie das Plus- (+) und das Minus-Zeichen
(-).
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.anbieter.* ist Themen
rund um Sprachtelekommunikationsanbietern zugedacht, w�hrend
de.comm.provider.* die Anbieter von Internet und
Internetdiensten meint; de.comm.geraete.* dient der Diskussion
�ber die zur Kommunikation ben�tigten Ger�te, de.comm.technik.*
der �ber die dahinterliegende Technik; 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.protocols.* besch�ftigt sich 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.* (Komplettsysteme) bzw.
de.comp.hardware.* (Einzelteile), und Programmiersprachen als
solche werden in de.comp.lang.* debattiert. Daneben gibt es
noch de.comp.datenbanken.* f�r Datenbankmanagementsysteme,
de.comp.office-pakete.* f�r integrierte B�roanwendungen und
de.comp.text.* zum Diskutieren �ber Textformate und
Texterzeuger.
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.spiele (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.allergie).
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.liebesakt) 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 die Kurzbeschreibung 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
Satzendezeichen (Punkt, Frage- oder Ausrufezeichen).
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 eine Moderation geschickt, die
sie dann ver�ffentlicht.
Moderierte Gruppen eignen sich vor allem f�r Ank�ndigungen. Beispiele
hierf�r sind 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 etwa 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
Freizeitbesch�ftigungen abseits der Zivilisation sowie der damit
verbundenen Themen wie Ausr�stung, gesetzliche Bestimmungen,
Erlebnisberichte, Freiluftk�che und dergleichen. Nicht Thema der
Gruppe ist das klassische Campen mit Gardinen im Hauszelt.
3.6. Die Begr�ndung
Hier hat man Gelegenheit, die Netz�ffentlichkeit 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 Moderatoren 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]
3.7.3. Der RfD-Generator
Unter dem URL <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi'
Piwinger ein Formular abgelegt, das die genannten RfD-Bestandteile
abfragt, die Eingaben auf einige Fehler hin �berpr�ft und daraus dann
einen Text erzeugt, der sich an den Muster-RfDs orientiert.
4. Einsenden des RfD an die Moderation
Die Moderation von de.admin.news.announce ist unter der Adresse
<mode...@dana.de> zu erreichen; ihr 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.
Die Moderation 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 sie den Artikel
in den genannten Gruppen.
5. Nach der Ver�ffentlichung
Nachdem die Moderation 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. Dieser zweite RfD
erscheint als Followup auf den ersten und hat wie dieser ein Followup-
To auf de.admin.news.groups gesetzt. Besteht weiterer
Diskussionsbedarf, k�nnen auch mehrere weitere RfDs ver�ffentlicht
werden; auch diese erscheinen dann in dem Thread, der durch den ersten
RfD er�ffnet wurde, und zwar jeweils als Followup auf den
vorangegangenen RfD.
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.
Alle CfVs sollen in den Gruppen, in denen auch der letzte RfD gepostet
wurde, erscheinen und werden als Followups in demselben Thread
ver�ffentlicht, der durch den ersten RfD ausgel�st wurde.
6.2. Ein Muster-CfV
1. Aufruf zur Wahl
==================
zur Einrichtung der neuen Gruppe
<Gruppenname> <Kurzbeschreibung>
Status: Die Gruppe ist {moderiert|unmoderiert}.
Charta
------
<Charta>
Modalit�ten
-----------
Sinn einer Usenet-Abstimmung ist es festzustellen, wer eine
vorgeschlagene Gruppe tats�chlich nutzen m�chte. Uninteressierte
Personen zur Teilnahme an der Abstimmung aufzufordern, schadet diesem
Ziel. Bitte verbreite diesen CfV nicht weiter. Verweise die Leute
stattdessen auf den offiziellen CfV, der in de.admin.news.announce
gepostet wurde. Die Verbreitung von vorausgef�llten oder anderweitig
ver�nderten CfV wird allgemein als Wahlf�lschung angesehen. Im
Zweifel wende Dich an den Wahlleiter.
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.admin.infos
ver�ffentlicht 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 annullieren, 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 Deines Realnamens 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
----------------------------------------------------------------------
[ ] Einrichtung von <Gruppenname>
-=-=-=-=-=-= Alles nach dieser Zeile l�schen =-=-=-=-=-=-
6.3. 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.4. 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.
Dazu fragt man bei den GVV unter der Adresse <g...@dana.de> an, wer
bereit ist, den CfV zu �bernehmen. Dem Freiwilligen, der sich dann
meldet, schickt man den soweit wie m�glich fertigen CfV (d. h., ohne
die Abstimmadresse und ohne Frist f�r die Stimmabgabe). Der GVV wird
die fehlenden Angaben erg�nzen, den Wahlschein auf Maschinenlesbarkeit
pr�fen und sonst wahrscheinlich nichts �ndern, sondern den CfV direkt
bei der Moderation einreichen. Mit dem weiteren Ablauf hat man dann
nichts mehr zu tun.
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 w�chentlich in de.admin.infos
gepostet.
<Datum> Die Newsgruppen der de.*-Hierarchie
Hier findet sich eine Beschreibung der bereits eingerichteten
Newsgroups in de.* (ohne de.alt.*). Das Posting findet sich
allw�chentlich in de.newusers.infos.
<Datum> Die Newsgruppen der de.alt.*-Hierarchie
Darin sind die bestehenden Newsgruppen der de.alt-Hierarchie
aufgef�hrt und beschrieben. Auch dieser Text kann der Newsgroup
de.newusers.infos entnommen werden.
<Datum> Missverstaendnisse in de.admin.news.groups
Dieser Text beschreibt typische Argumentationen in
de.admin.news.groups. Er wird nach de.admin.infos gepostet.
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:
Dirk Nimmich
Michael Ottenbruch
Boris `pi' Piwinger
Alexander Stielau
Adrian Suter
Oliver B. Warzecha
Eine aktuelle Liste kann man unter
<http://www.dana.de/mod/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>
Rolf Krahl <rolf....@gmx.net>
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>
Adrian Suter <adrian...@schweiz.org>
Hans-Christoph Wirth <ha...@dianoia.mayn.de>