+Archive-name: de-newusers/dana-manual
+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 <mentoren@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] <mode@ra.tor> (Moderated)
+
+ Diskussionen sollen in der Gruppe
+
+ [Gruppenname] [Kurzbeschreibung]
+
+ gefuehrt werden.
+
+
+ Status
+ ------
+
+ Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat
+ <m.ode@rator.de> und Peter Roponent <p.ropo@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
+ <moderator@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 <email@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-mail@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-mail@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 <gvv@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 <gvv@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 <mentoren@dana.de> geschickt werden.
+
+
+ 7.4. Danksagungen
+
+ Zu diesem Text und seiner Entstehung haben beigetragen:
+
+ Lutz Donnerhacke <lutz@as-node.jena.thur.de>
+ Kristian Köhntopp <kristian@koehntopp.de>
+ Rolf Krahl <rolf.krahl@gmx.net>
+ Dirk Nimmich <nimmich@uni-muenster.de>
+ Martin Recke <mr94@husemann.in-berlin.de>
+ Thomas Roessler <roessler@sobolev.rhein.de>
+ Heiko Schlichting <heiko@fu-berlin.de>
+ Adrian Suter <adrian.suter@schweiz.org>
+ Hans-Christoph Wirth <hansi@dianoia.mayn.de>
projects / faqs / dana-manual.git / commitdiff
