Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
-Version: 2.0.0
-Last-modified: 2010-03-15
+Version: 2.1.0
+Last-modified: 2011-05-01
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
+URL: http://th-h.de/faq/dana-manual.txt
Erläuterungen zur Einrichtung neuer Gruppen in de.*
===================================================
-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 Danksagungen
+Inhalt
+------
+
+0. Einleitung
+ 0.1. Zielgruppe und Inhalt
+ 0.2. Das Einrichtungsverfahren im Überblick
+ 0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
+ 0.3.1. Vorbereitung
+ 0.3.2. Diskussionsphase
+ 0.3.3. Abstimmungsphase
+ 0.3.4. Umsetzung
+
+1. Vorüberlegungen
+ 1.1. Bedarf für eine neue Gruppe
+ 1.2. Status quo: bestehende Gruppen und frühere Vorschläge
+ 1.3. Mitinteressenten
+
+2. Einrichtungsvorschlag
+ 2.1. Auswahl des Gruppennamens
+ 2.1.1. Einordnung
+ 2.1.2. Namenswahl und technische Vorgaben
+ 2.2. Kurzbeschreibung
+ 2.3. Charta
+ 2.4. Status
+ 2.4.1. Pro und contra moderierte Gruppen
+ 2.4.2. Einrichtung moderierter Gruppen
+ 2.5. Sonderfälle
+
+3. Diskussionsphase
+ 3.1. Inhalt und Aufbau eines RfD
+ 3.1.1. Inhalt
+ 3.1.2. Formale Gestaltung
+ 3.2. Einreichung des RfD
+ 3.3. Diskussionsphase
+ 3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags
+
+4. Abstimmungsphase
+ 4.1. Voraussetzungen für die Durchführung einer Abstimmung
+ 4.2. Inhalt und Aufbau eines CfV
+ 4.3. Abstimmungsphase
+ 4.4. Auswertung und Ergebnis der Abstimmung
+
+5. Verfahrensabschluss und Umsetzung
+
+6. Quellen
+ 6.1. Grundlegende Informationen
+ 6.2. Weiterführende Hinweise
+ 6.3. Webseiten
+
+7. Maintainer und Kontakt
+ 7.1. Derzeitige Maintainer
+ 7.2. Frühere Fassungen
======================================================================
-1. Einleitung
+0. Einleitung
+=============
-1.1. Adressatenkreis
+0.1. Zielgruppe und Inhalt
+--------------------------
Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
-wollen. Er versucht, einen Teil der gerade für Neulinge auf diesem
-Gebiet häufig frustrierenden Standardargumentation in
-de.admin.news.groups vorwegzunehmen und die in den "REGELN FÜR DIE
-EINRICHTUNG UND ENTFERNUNG VON USENET-GRUPPEN" [1] niedergelegten Regeln
-zur Einrichtung neuer Gruppen zu erläutern.
-
- [1] Veröffentlich in de.admin.infos:
-| From: 3.14@piology.org (Boris 'pi' Piwinger)
-| Newsgroups: de.admin.infos,de.alt.admin
-| Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
-|
-| Archive-name: de-admin/einrichtung
-| Posting-frequency: weekly
-| Last-modified: 2005-08-06
-| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+lassen wollen und soll die in den "REGELN FÜR DIE EINRICHTUNG UND
+ENTFERNUNG VON USENET-GRUPPEN" [1] (kurz: Einrichtungsregeln)
+niedergelegten Regeln zur Einrichtung neuer Gruppen kommentieren und
+erläutern. Er gibt dabei notwendig den Blick der Autoren bzw.
+Maintainer auf die Verhältnisse in de(.admin.news).* und ihre
+Erfahrungen wieder.
+
+[1] Veröffentlicht in de.admin.infos:
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.alt.admin
+| Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
+|
+| Archive-name: de-admin/einrichtung
+| Posting-frequency: weekly
+| Last-modified: 2005-08-06
+| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+
+(Eine Liste aller in diesen Erläuterungen genannten Quellen findet
+sich noch einmal in Abschnitt 6.)
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
+Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln).
+Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die
+nachfolgende, mindestens einwöchige 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 de.* 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.
-
-----------------------------------------------------------------------
-
-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 notwendig
-ist. 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; die entsprechende Übersicht steht auch im
- World Wide Web unter <http://www.dana.de/status.html> zum Abruf
- bereit.
-
-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 (oder auch Tagline) 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.
+0.2. Das Einrichtungsverfahren im Überblick
+-------------------------------------------
+
+Newsgroups werden nicht auf einem zentralen Server angeboten, sondern
+dezentral auf vielen verschiedenen Newsservern geführt, die ihre
+Beiträge jeweils untereinander austauschen. Damit das funktionieren
+kann und jeder Benutzer dieselben Newsgroups zur Verfügung hat, müssen
+sich die Betreiber dieser Vielzahl von Newsservern nach Möglichkeit
+auf einen einheitlichen Bestand an Gruppen einigen. Das ist bei
+mehreren tausend Newsservern mit manchmal wenigen, manchmal aber auch
+Tausenden Benutzern durch Diskussionen im Einzelfall nicht praktikabel
+möglich. Daher werden für gepflegte Newsgroups-Hierarchien wie de.*
+Listen der Newsgroups geführt, die zur Hierarchie gehören; mit dieser
+Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand
+abgleichen.
+
+Für de.* wird die definitive Liste der bestehenden Newsgroups von der
+Moderation von de.admin.news.announce geführt, die jeden Monat auch
+eine entsprechende, digital signierte Steuernachricht (checkgroups)
+versendet, mit der die meisten Newsserverbetreiber ihren
+Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen.
+Für die Aufstellung dieser Liste sind vielerlei Möglichkeiten denkbar;
+in de.* entscheiden die Benutzer über ihren Inhalt. Änderungen am
+Gruppenbestand - Neueinrichtung, Löschung oder Umbenennung von Gruppen
+- werden in einem formalisierten Verfahren diskutiert und dann zur
+Abstimmung gestellt.
+
+Jedem Einrichtungsvorschlag sollte eine Überlegungsphase vorangehen,
+in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
+Status, Charta) einschließlich ihrer Einordnung in den bestehenden,
+hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
+mit anderen Interessenten diskutiert werden können. Am Ende dieser
+Vorüberlegungen steht dann zumeist ein erster Vorschlag, wie die neue
+Gruppe heißen soll, was ihre Inhalte sein werden und wie sie sich
+thematisch gegenüber bestehenden Gruppen abgrenzt. Mit der
+Veröffentlichung dieses Vorschlags in de.admin.news.announce als
+Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das
+Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion,
+die in de.admin.news.groups geführt wird, wird der Vorschlag auf
+inhaltliche Qualität und Akzeptanz abgeklopft und ggf. verändert oder
+verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der
+Vorschlag abstimmungsreif erscheint. Die Veröffentlichung eines
+Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die
+Diskussionsphase und leitet in die Abstimmungsphase über, an deren
+Ende sich zeigt, ob der Vorschlag zur Einrichtung der neuen Gruppe
+angenommen oder abgelehnt wurde. Dementsprechend wird die Gruppe dann
+in die Gruppenliste aufgenommen - oder auch nicht.
+
+Siehe auch:
+
++ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
+| From: bernd@tenuki.de (Bernd Gramlich)
+| Newsgroups: de.admin.infos
+| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
+|
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Last-modified: 2004-12-06
+| URL: http://www.tmt.de/~gramlich/dan-glossar.html
+| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
+
+
+0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
+----------------------------------------------------------
+
+Das Einrichtungsverfahren lässt sich in folgende Phasen unterteilen,
+die im Folgenden dann näher erläutert werden sollen:
+
+0.3.1. Vorbereitung
+
+* Ideenfindung
+* Information über den status quo, Bedarfsabschätzung
+* Suche nach anderen Interessierten, ggf. interne Diskussion
+* Ausformulierung eines förmlichen Einrichtungsvorschlag (RfD)
+* Einreichung des RfD bei der Moderation von de.admin.news.announce
+
+Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
+enden die Vorbereitungen; das Verfahren wird in die Statusübersicht
+der Moderation von de.admin.news.announce [2] aufgenommen und erhält
+einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prüft
+den RfD (und die weiteren Verfahrensbeiträge) auf Vereinbarkeit mit
+den Regeln, nimmt die nötigen Veröffentlichungen in
+de.admin.news.announce vor und steht dem Proponenten auch als
+Ansprechpartner (und in gewissem Umfang Berater) für sich im Verlauf
+des Verfahrens ergebende Fragen zur Verfügung.
+
+[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem
+ Betreff "dana-Status" wöchentlich in de.admin.news.announce
+ veröffentlicht und im WWW unter <http://www.dana.de/status.html>
+ abrufbar.
+
+0.3.2. Diskussionsphase
+
+* Beginn mit Veröffentlichung des 1. RfD in de.admin.news.announce,
+ de.admin.news.groups und weiteren betroffenen Newsgroups
+* öffentliche Diskussion des Vorschlags in de.admin.news.groups
+* Mindestdauer: 14 Tage
+* Einreichung beliebig vieler weiterer RfDs mit geänderten Vorschlägen
+
+Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
+der übrigen Teilnehmer zu ergründen; Änderungsvorschläge können
+gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
+RfD usw.) aufgenommen werden. Wenn alle Facetten erörtert, alle
+Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu
+drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag
+Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen möchte oder
+ob er den Vorschlag zurückzieht. Die zur Abstimmung gestellte Fassung
+muss mit dem letzten veröffentlichen RfD im Wesentlichen
+übereinstimmen.
+
+Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
+Rückzug des Vorschlags oder Verfall durch Nichtbetreiben über fünf
+Wochen) oder der Veröffentlichung des 1. CfVs.
+
+0.3.3. Abstimmungsphase
+
+* Beginn mit Veröffentlichung des 1. CfV in de.admin.news.announce und
+ den übrigen Gruppen
+* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
+ E-Mail bestätigt
+* Mindestdauer: 3 Wochen, Höchstdauer: 1 Monat (4 Wochen)
+* in der Regel Einreichung eines 2. CfV zur "Halbzeit"
+* Einreichung des Ergebnisses mit Namen und Stimmabgaben der
+ Abstimmenden
+* einwöchige Einspruchsfrist
+
+Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
+durchgeführt, der den 1. CfV zur Veröffentlichung einreicht, die
+Stimmen per E-Mail sammelt, bestätigt und auszählt und am Ende das
+Ergebnis der Abstimmung zur Veröffentlichung einreicht. Es muss sich
+dabei ausdrücklich nicht um dieselbe Person wie den Proponenten
+handeln; da die Durchführung und Auszählung einer Abstimmung einen
+gewissen technischen und organisatorischen Aufwand erfordert und auch
+Erfahrung im Umgang mit Zweifelsfällen - auch Manipulationsversuchen -
+wünschenswert ist, besteht die Möglichkeit, einen erfahrenen Usenet-
+Teilnehmer um die Übernahme der Abstimmungsleitung zu bitten. Einige
+Freiwillige haben sich zu diesem Zweck als "German Volunteer
+Votetakers" (GVV) zusammengeschlossen.
+
+Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und
+letztlich mit der Veröffentlichung des Ergebnisses. Daran schließt
+sich ein einwöchiger Einspruchszeitraum an, in dem Regelverstöße durch
+einen Einspruch bemängelt werden können. Nach Verstreichen dieses
+Zeitraums wird das Ergebnis der Abstimmung bestandskräftig.
+
+0.3.4. Umsetzung
+
+Wenn der Vorschlag in der Abstimmung angenommen wurde - wozu
+mindestens 60 Stimmen JA-Stimmen und zugleich eine Mehrheit von 2/3
+der abgegebenen gültigen Stimmen ohne die Enthaltungen, also
+mindestens doppelt so viele JA- wie NEIN-Stimmen erforderlich sind -,
+wird das Ergebnis im Anschluss durch die Moderation von
+de.admin.news.announce umgesetzt, indem eine Steuernachricht zur
+Einrichtung der betreffenden Gruppe versandt und diese in die
+kanonische Liste der in de.* vorhandenen Newsgroups aufgenommen wird.
+
+1. Vorüberlegungen
+==================
+
+1.1. Bedarf für eine neue Gruppe
+--------------------------------
+
+Ganz am Anfang der Überlegungen zur Einrichtung einer neuen Newsgroup
+stellt sich zunächst die Frage, ob die angedachte Gruppe denn auch
+tatsächlich benötigt wird und der Vorschlag Aussicht auf Erfolg hat.
+Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
+zukünftigen Nutzung der Gruppe zu rechnen ist, das Thema also im
+Usenet diskutiert werden wird und eine thematisch passende Gruppe
+entweder nicht vorhanden ist oder bereits so rege genutzt wird, dass
+sie überfüllt ist.
+
+Die zukünftige Nutzungsintensität der vorgeschlagenen Gruppe wird
+dabei regelmäßig anhand der derzeitigen Lage beurteilt:
+
+* Gibt es bereits Diskussionen zu dem Thema im Usenet?
+
+* Wenn ja: Ist die bisher dafür genutzte Gruppe überfüllt (so dass man
+ dieses Thema aus ihr abspalten sollte) oder gibt es bislang gar
+ keine Gruppe, in der man das Thema sinnvoll diskutieren kann?
+ Letzteres ist sehr selten, da de.* thematisch vollständig ist; die
+ meisten denkbaren Themen passen in eine oder mehrere bereits
+ bestehende Gruppen thematisch hinein.
+
+ Sind die derzeitigen Diskussionsteilnehmer bereit, zukünftig die neu
+ einzurichtende Gruppe zu benutzen (oder wünschen dies sogar)?
+
+* Wenn nein: Finden anderswo im Netz Diskussionen statt, bspw. in
+ anderen deutschsprachigen Usenet-Hierarchien, in Mailinglisten,
+ Webforen, Communities in sozialen Netzwerken?
+
+ Und sind die Diskutanten bereit, statt des bisher genutzten Mediums
+ oder zusätzlich zu diesem auch das Usenet als Diskussionsmedium zu
+ benutzen?
+
+* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
+ zukünftig einigermaßen intensiven Zuspruch erfahren wird?
+
+Die Erfahrung hat gezeigt, dass die empfundene oder tatsächliche
+gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts
+damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen
+und ob sie dies im Usenet tun möchten. Es mag sehr wichtige Themen
+geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht
+oder die anderswo diskutiert werden, ohne dass bei den Interessenten
+der Wunsch besteht, ihre Diskussionen im Usenet zu führen. Die
+mehrheitliche Ansicht geht überdies dahin, dass es nicht sinnvoll ist,
+für "Orchideenthemen" eigene Newsgroups einzurichten, die dann
+(weitgehend) ungenutzt bleiben; vielmehr wird es überwiegend als
+wünschenswert empfunden, lieber weniger thematisch breiter
+aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
+auf diese Weise den gegenseitigen Austausch beleben und fördern.
+
+Siehe auch:
+
++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
+ <http://th-h.de/infos/usenet/newgroup.php#vorschlag>
+
++ Missverstaendnisse in de.admin.news.groups
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
+|
+| Archive-name: de-admin/dang-faq
+| Posting-frequency: weekly
+| Last-modified: 2009-01-24
+| URL: http://www.kirchwitz.de/~amk/dai/dang-faq
+
+1.2. Status quo: bestehende Gruppen und frühere Vorschläge
+----------------------------------------------------------
+
+Die Frage nach dem Bedarf an einer neuen Gruppe führt zur Feststellung
+und Beurteilung des status quo: Welche thematisch verwandten Gruppen
+gibt es? Wo sind diese in der Struktur von de.* eingeordnet? Wie
+intensiv werden sie genutzt? Wie lässt sich das Thema der neuen Gruppe
+von den bestehenden themenverwandten Gruppen abgrenzen?
+
+Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob
+möglicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen
+wurde und wie Verlauf und Ergebnis der Diskussion (und ggf.
+Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal
+eine solche Gruppe, die dann später wieder aus der Gruppenliste
+entfernt wurde? Aus diesen Überlegungen ergeben sich Hinweise auf die
+Erfolgsaussichten des Vorschlags und möglicherweise auch Anregungen
+für seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
+Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
+wesentliche Änderungen in Inhalt oder Begründung erneut einzubringen.
+
+[3] Am bekanntesten dürfte das Angebot von Google Groups sein:
+ <http://groups.google.com/>
+
+ de.admin.news.announce bei Google Groups:
+ <http://groups.google.com/group/de.admin.news.announce/>
+
+ Erweiterte Suche: <http://groups.google.com/advanced_search>
+
+1.3. Mitinteressenten
+---------------------
+
+ "Gemeinsam sind wir stark."
+
+In der Diskussionsphase kommt es weniger auf die Anzahl der
+Befürworter als vielmehr auf deren Argumente an. Dennoch hilft es,
+einen Vorschlag nicht ganz alleine einzubringen, insbesondere dann,
+wenn man mit dem Procedere in de.admin.news.* noch nicht so vertraut
+ist. Soll der Vorschlag erfolgversprechend sein, wird es ja eine ganze
+Reihe von anderen Interessenten an der vorgeschlagenen neuen Gruppe
+geben. Deren Input ist schon bei der Formulierung des Vorschlags
+hilfreich; Brainstorming und Diskussion mehrerer führt oft zu besseren
+Ergebnissen als einsames Grübeln im stillen Kämmerlein.
+
+Auch in der Diskussion ist es förderlich, einen Vorschlag nicht
+alleine argumentativ zu stützen; nicht nur deshalb, weil eine Mehrzahl
+von Interessenten, die sich auch selbst in die Diskussion einbringt,
+überzeugender ein dauerhaftes Interesse signalisiert als ein
+Einzelner. Auch aus psychologischen Gründen ist es angenehmer, die
+eigene Position nicht alleine vertreten zu müssen.
+
+Eine Mitwirkung anderer Interessenten kann dabei auf vielfältige Weise
+erfolgen. Ein Vorschlag kann durch mehrere Proponenten eingebracht
+werden; die Mitwirkung kann sich aber auch auf Unterstützung bei
+inhaltlichen und Formulierungsfragen oder der formalen Abwicklung des
+Einrichtungsverfahrens oder Beiträge in der Diskussionsphase
+beschränken.
+
+2. Einrichtungsvorschlag
+========================
+
+Vor der Einrichtung einer neuen Newsgroup oder dem Beginn der
+Abstimmung über den entsprechenden Vorschlag müssen nach den
+Einrichtungsregeln Name und Attribute der vorgeschlagenen Gruppe
+feststehen:
+
+| Ein CfV kann nicht veröffentlicht werden, wenn einer der folgenden
+| Punkte noch unklar ist:
+|
+| o Name der Gruppe
+| o Kurzbeschreibung der Gruppe
+| o Charta der Gruppe
+| o Status der Gruppe (moderiert oder unmoderiert)
+| o der Name des Moderators im Falle einer moderierten Gruppe
+
+Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im
+luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt
+sich daher auch die Frage nach der Einordnung der neuen Gruppe in die
+bestehende Struktur der Hierarchie de.*, und in der Charta sollte
+nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern
+auch die Abgrenzung zu thematisch ähnlichen Gruppen ihren Platz
+finden.
+
+Sinnvoll ist es daher, sich zunächst Gedanken über das geplante Thema
+der Gruppe und dessen Abgrenzung zu bereits bestehenden Gruppen zu
+machen; daraus ergibt sich die Charta (2.3.). Danach sollte man sich
+überlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
+demnach heißen soll (2.1.); dann fehlt nur noch eine knackige
+Zusammenfassung für die Kurzbeschreibung (2.2.).
+
+Falls eine moderierte Newsgroup vorgeschlagen wird, müssen auch der
+oder die vorgesehenen Moderatoren feststehen; überdies sollte ein
+Konzept für die Moderation vorliegen und die technischen
+Voraussetzungen hinreichend geklärt sein.
+
+2.1. Auswahl des Gruppennamens
+------------------------------
+
+2.1.1. Einordnung
+
+Zunächst sollte die prospektive Gruppe sich in die bestehende
+Namenshierarchie in de.* einpassen. de.* besteht nämlich aus
+thematisch orientierten Teilhierarchien, die eine Baumstruktur mit
+immer feineren thematischen Verästelungen aufweisen. Diese Struktur
+ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollständig
+logisch stringent, und regelmäßig wird es nicht nur einen denkbaren
+Platz geben, an den eine neue Gruppe passen würde.
+
+Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz
+bemühen, den bestmöglichen Ort für die neue Gruppe zu finden. Dazu
+gehört sowohl die Einordnung in die - nach dem Themenschwerpunkt - am
+ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein
+sehr spezielles Thema sollte im Themenbaum nicht zu weit oben
+angesiedelt sein, ein sehr allgemeines Thema nicht zu tief.
+
+Mit Ausnahme von de.alt.*, das sich (nur) durch besondere
+Einrichtungsregeln auszeichnet und daher nicht Thema dieser
+Erläuterungen ist, bestehen in de.* folgende thematische
+Untergliederungen:
+
+* de.admin.*
+ Die Gruppen der de.admin-Unterhierarchie befassen sich thematisch
+ mit der Selbstverwaltung von de.* und organisatorischen (nicht
+ technischen) Fragen der Administration von Usenet-Systemen,
+ namentlich auch mit deren Missbrauch.
+
+* de.comm.*
+ Die Gruppen der de.comm-Unterhierarchie beschäftigen sich mit den
+ - im Usenet umfänglich vertretenen - Themenbereichen der
+ Kommunikation und Kommunikationstechnik und sind daher noch weiter
+ diversifiziert, im Wesentlichen in die Bereiche
+
+ * Anbieter:
+ de.comm.anbieter.* - Festnetz- und Mobiltelefonprovider und Tarife
+ de.comm.provider.* - Internetprovider und Onlinedienste
+
+ * Geräte (Hardware) und Technik:
+ de.comm.geraete.* - Festnetz- und Mobiltelefone und Telefonanlagen
+ de.comm.technik.* - Netztechnik (DSL, ISDN, Mobilfunknetze)
+ de.comm.internet.* - Infrastrukturaspekte des Internet
+ de.comm.protocols.* - Kommunikationsprotokolle
+
+ * Software:
+ de.comm.software.* - Browser, Mail-/Newsreader und -server etc.
+
+ und schließlich:
+ de.comm.infosystems.* - WWW samt Webseitenerstellung
+ de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...)
+
+* de.comp.*
+ Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik
+ ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme,
+ Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch
+ so dazugehört. Auch sie ist demnach umfangreich weiter
+ untergliedert, neben verschiedenen Einzelgruppen namentlich in
+
+ * Hardware:
+ de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks, Handhelds
+ de.comp.hardware.* - Rechner, Laufwerke, Monitore, Netzwerk
+
+ * Betriebssysteme, Anwendungsprogramme und andere Software
+ de.comp.os.* - Windows, Unix, Linux, OS/2,
+ de.comp.office-pakete.* - MS-Office, Staroffice
+ de.comp.text.* - Textverarbeitung
+ de.comp.datenbanken.* - Datenbanken
+ de.comp.lang.* - Programmiersprachen (C++, Java, Perl, PHP, ...)
+
+* de.rec.*
+ Die Unterhierarchie de.rec.* beschäftigt sich mit
+ Freizeitaktivitäten (recreational activities) aller Art und enthält
+ neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien zu den
+ Themen Musik hören und machen, Sport(arten), Spielen aller Art, am
+ Brett wie am Computer, Science Fiction und Fantasy, Fernseh(seri)en,
+ Filme und Heimkino und (Haus-)Tiere.
+
+* de.sci.*
+ Die Unterhierarchie de.sci.* ist für wissenschaftliche Themen
+ (sciences) vorgesehen und ist vorwiegend anhand der klassischen
+ wissenschaftlichen Themengebiete (Biologie, Chemie, Physik,
+ Mathematik, Medizin, etc. pp.) unterteilt. Teilweise sind aber
+ Themen gerade aus dem gesellschafts- oder sozialwissenschaftlichen
+ Bereich auch in de.soc.* angesiedelt.
+
+* de.soc.*
+ Die Unterhierarchie de.soc.* handelt von gesellschaftlichen Fragen
+ (social issues): Politik und Rechtswesen; Religionen und
+ Weltanschauungen; Kulturen und Subkulturen; Familie,
+ Gleichberechtigung, Senioren, Jugendarbeit, Schule und Studium;
+ Arbeit und Arbeitslosigkeit; Umwelt und Verkehr; Medien und
+ Wirtschaft; Datenschutz und Zensur.
+
+* de.talk.*
+ Die - sehr kleine - Unterhierarchie de.talk.* ist mehr für Smalltalk
+ und entspannten Plausch als Diskussion und Informationsaustausch
+ vorgesehen; viele der verbliebenen Gruppen würden aber ebenso gut
+ nach de.soc.* passen.
+
+* de.org.*
+ Die - gleichfalls kleine - Teilhierarchie de.org.* ist für
+ Organisationen und Vereine, deren Verlautbarungen und Diskussionen
+ um sie herum gedacht. Verblieben sind hier im Wesentlichen
+ Newsgroups zum CCC, zu Mensa und der SPD (bzw. politischen Parteien
+ allgemein).
+
+* de.etc.*
+ In der de.etc.*-Unterhierarchie sind sonstige Themen
+ zusammengefasst, die nicht in eine der anderen Unterhierarchien
+ passen. Dazu gehören das Bahnwesen, Autos und andere Fahrzeuge,
+ Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
+ Notfallrettung und Militärwesen oder auch die Haushaltsführung.
+
+* de.markt.*
+ In de.markt.*, dem Kleinanzeigenbereich des deutschsprachigen
+ Usenets, - und nur hier! - haben private, nicht-kommerzielle
+ Angebote und Gesuche Platz.
+
+Siehe auch:
+
++ Die Newsgruppen der de-Hierarchie
+| From: Daniel Roth <25.8@bluemail.ch>
+| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2011-03-07> Die Newsgruppen der de-Hierarchie
+|
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| Last-modified: 2011-03-07
+| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
+
+2.1.2. Namenswahl und technische Vorgaben
+
+Der "eigentliche" Name der Gruppe, insbesondere also der letzte
+Namensbestandteil, sollte so aussagekräftig und allgemeinverständlich,
+aber zugleich auch so kurz wie möglich gewählt werden. Kryptische oder
+mehrdeutige Abkürzungen sollte man möglichst nicht verwenden. Wenn
+diese gar nicht zu vermeiden sind, sollten sie in der
+Kurzbeschreibung, spätestens aber in der Charta erläutert werden.
+
+Für die Wahl des Gruppennamens sind zudem technisch geprägte
+Vorgaben [4] zu beachten, die sich auch im WWW unter
+<http://dana.de/newsgroup-namen.html> nachlesen lassen:
+
+* 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, dass 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 (-).
+
+* Insgesamt soll die Länge des Newsgruppennamens 71 Zeichen nicht
+ überschreiten.
+
+[4] Beschlossen im Jahr 2000:
+| From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
+| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
+| Date: 2000/07/18
+| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
+ <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
+
+2.2. Kurzbeschreibung
+---------------------
+
+Die Kurzbeschreibung (auch "Tagline" genannt) soll in Ergänzung zum
+Gruppennamen das Thema kurz umreißen. Im Gegensatz zur Charta, der
+ausführlichen thematischen Beschreibung des Gruppeninhalts, wird sie
+in der Regel zusammen mit dem Gruppennamen auf den Newsservern
+vorgehalten und kann in den gängigen Newsreadern angezeigt und ggf.
+auch durchsucht werden. Sie ist auch Bestandteil der regelmäßig
+versandten Steuernachrichten, die den aktuellen Gruppenbestand von
+de.* enthalten.
Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung
-ab: Sie muß kurz, knapp und für jeden verständlich sein. "Diskussion
+ab: Sie muss 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.
+überflüssige Formulierungen. Hingegen sollten möglichst Begriffe in
+der Kurzbeschreibung auftauchen, nach denen an der Gruppe
+interessierte Nutzer möglicherweise suchen werden. 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
+der Kurzbeschreibung beschränken. Daraus folgt, dass 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
+Beispiele für Kurzbeschreibungen finden sich in dem bereits genannten
+Text "Die Newsgruppen der de-Hierarchie".
+
+2.3. Charta
+-----------
+
+Die Charta ist die Beschreibung der Newsgroup und ihres vorgesehenen
+Themas schlechthin. Sie soll so kurz wie möglich und nur so
+ausführlich wie nötig umreißen, worum es in der Gruppe geht, welche
+Themen dort diskutiert werden sollen und welche ggf. nicht und welche
+besonderen Konventionen dort - unter Abweichung von den sonstigen
+Üblichkeiten im deutschsprachigen Usenet - gelten sollen.
+
+Es ist hilfreich, für das Thema der Gruppe einige Beispiele als nicht
+abschließende Aufzählung aufzunehmen; so lassen sich auch (weitere)
+Schlagworte unterbringen, nach denen möglicherweise gesucht wird.
+Dabei ist aber zu berücksichtigen, dass die Charta nur in
+entsprechenden Listen im Usenet und auch im WWW veröffentlicht wird,
+aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
+Newsreader zur Verfügung steht.
+
+Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
+diskutiert werden sollen, obwohl möglicherweise Name und
+Kurzbeschreibung bei flüchtiger Durchsicht zu dieser Annahme führen
+könnten, empfiehlt es sich, diese Facetten - oder Themen - in der
+Charta ausdrücklich auszuschließen. Genauso sollte innerhalb der
+Charta das Diskussionsthema von anderen, themenverwandten Gruppen
+abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings
+nicht tunlich, weil ansonsten bei jeder Umbenennung oder Löschung der
+betreffenden Gruppen eine Chartaänderung nötig würde.
+
+Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
+gelten sollen als sonst im Netz üblich sollte auch dies in der Charta
+vermerkt werden. Zu denken wäre bspw. an die (ausdrückliche) Akzeptanz
+anonymer Beiträge oder von Inseraten. Gleichfalls sollten vorgesehene
+ungewohnte technische Maßnahmen - zu denken wäre hier bspw. an die
+Eingangsbestätigung von Postings per E-Mail durch die sog. Reflektoren
+in den Testgruppen - durch die Charta legitimiert werden. In allen
+diesen Fällen sollte einerseits berücksichtigt werden, dass eine
+Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
+in der Regel ausdrücklich abgelehnt wird, sowohl wegen der unnötigen
+Verlängerung der Charta als auch, weil dies den Eindruck vermitteln
+könnte, die entsprechenden Regeln und Konventionen hätten nur dort
+Geltung, wo sie ausdrücklich in der Charta stehen. Andererseits darf
+man bei der Formulierung solcher abweichenden Üblichkeiten nicht aus
+den Augen verlieren, dass sowohl technische als auch soziale Vorgaben
+in der Regel gute Gründe haben und zudem als feststehende Gewohnheiten
+betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut
+begründeten Sonderfällen Aussicht auf Erfolg haben werden.
+
+Die Charta sollte so knapp wie möglich gehalten werden; weitergehende
+Erläuterungen und solche Regeln, die sich voraussichtlich häufiger
+ändern werden, gehören nicht in die Charta, sondern sollten Gegenstand
+einer (regelmäßig geposteten und nach Möglichkeit auch im WWW
+bereitgestellten) Einführung, eines Infopostings oder einer FAQ sein.
+So sollte bspw. die thematische Kennzeichnung von Unterthemen im
+Betreff von Postings durch sog. Tags ("[Reisebericht] Meine Tour durch
+Tadschikistan") in der Charta allenfalls generelle Erwähnung finden;
+die einzelnen angedachten Tags gehören dann in eine anderweitig
+bereitgestellte Erläuterung. Auch das Moderationskonzept einer
+moderierten Gruppe gehört schon aufgrund seiner Länge nicht in die
+Charta.
+
+Es empfiehlt sich, einige bestehende Chartas - insbesondere solcher
+Gruppen, die in den letzten 5-10 Jahren eingerichtet wurden - zu
+studieren, um ein Gefühl für die Abfassung einer guten Charta zu
+bekommen. Solche Beispiele finden sich in dem bereits genannten Text
+"Die Newsgruppen der de-Hierarchie".
+
+2.4. Status
+-----------
+
+Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status
+"moderiert" haben. Ersteres ist der Regelfall; alle Postings werden
+dann ohne weiteres in der Newsgroup veröffentlicht und weltweit
+verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall;
+stattdessen versendet der Newsserver, bei dem das Posting eingespeist
+wird, dieses per E-Mail an einen Moderator (oder in der Regel eine
+mehrköpfige Moderation). Diese entscheidet dann über die
+Veröffentlichung.
+
+2.4.1. Pro und contra moderierte Gruppen
+
+Moderierte Gruppen haben den Vorteil einer meist besseren
+Übersichtlichkeit und höheren inhaltlichen Qualität, weil Beiträge
+vorgefiltert werden können; ihr Nachteil ist die zwangsläufig
+entstehende Verzögerung durch die Weiterleitung jedes Beitrags an
+einen Moderator, der ihn bestätigen muss. Sie eignen sich daher vor
+allem für Ankündigungen oder FAQs. Ein Beispiel hierfür ist
+de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
+Abstimmungen veröffentlicht werden, so dass die Gruppe auch für
+diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen
+im einzelnen zu folgen, und eine vorherige Überprüfung der
+Veröffentlichungen sichergestellt ist. Ein anderes Beispiel stellen
+die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in
+denen nur FAQs und Infotexte veröffentlicht werden.
+
+Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
+Erhaltung einer höheren inhaltlichen Qualität dienen und ermöglicht
+vor allem den Ausschluss von bewussten Störern, begegnet im Gegenzug
+aber oft dem Vorwurf der Zensur, so unbegründet dieser im Einzelfall
+auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden
+Verzögerungen vor Veröffentlichung eines Beitrags den Fluss der
+Diskussion stören und an Veröffentlichung ihrer Beiträge in Echtzeit
+gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
+allem personelle Aufwand nicht zu unterschätzen; immerhin bedeutet die
+Moderation einer Diskussionsgruppe, dass auf Jahre hinaus eine
+Einzelperson oder Gruppe im Extremfall 24 Stunden am Tag und 7 Tage in
+der Woche erreichbar sein muss, um eingehende Beiträge so zeitnah wie
+möglich zu prüfen und freizugeben.
+
+2.4.2. Einrichtung moderierter Gruppen
+
+Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
+im Einrichtungsverfahren zusätzliche Angaben zur Moderation zu machen;
+dazu gehören der oder die vorgesehene(n) Moderator(en) und die
+Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
+für die Newsgroup zur Freigabe weitergeleitet werden sollen. Außerdem
+muss die Kurzbeschreibung entsprechend ergänzt werden. Schließlich
+sollte für die Durchführung der Moderation sinnvollerweise ein Konzept
+vorliegen und die technischen Voraussetzungen geschaffen und getestet
+sein.
+
+* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe
+ vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der
+ Veröffentlichung des Vorschlags seine entsprechende Bereitschaft
+ erklärt haben; in der Regel wird es sich empfehlen, ein mehrköpfiges
+ Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
+ auch im Falle eines mehrwöchigen Urlaubs oder gar eines dauerhaften
+ Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
+ interessiert sein mag - die Moderation handlungsfähig bleibt und
+ Beiträge weiterhin veröffentlicht werden können. Für moderierte
+ Diskussionsgruppen wird regelmäßig ein ausreichend großes Team
+ zwingend vorzusehen sein, damit Beiträge zumindest tagsüber zeitnah
+ veröffentlicht werden können.
+
+ Der oder die vorgesehene(n) Moderator(en) sollte ausreichende
+ Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um
+ Einreichungen bewerten zu können, von den zu erwartenden
+ Diskussionsteilnehmern akzeptiert werden und schließlich absehbar
+ für längere Zeit für diese Tätigkeit zur Verfügung stehen. Erfahrung
+ im Usenet und ggf. die notwendigen technischen Kenntnisse zur
+ Durchführung der Moderation sind hilfreich.
+
+* Wenn die (erste) Moderation personell feststeht, stellt sich als
+ nächstes die Frage, welche E-Mail-Adresse für Einreichungen
+ ("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit
+ in jedem Newsserver oder an einer zentralen Stelle (den Relays für
+ moderators.isc.org) in der Konfiguration vermerkt werden, sollte
+ sich also so selten wie möglich ändern; außerdem sollte die Adresse
+ zuverlässig erreichbar sein und ggf. die Möglichkeit für
+ ausreichende Spamfilterung bieten; langjährig aktive und regelmäßig
+ veröffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
+ Spam an.
+
+ Daneben sollte eine weitere Adresse veröffentlicht werden, über die
+ der Moderator oder die Moderation kontaktiert werden können, ohne
+ dass eine Veröffentlichung erfolgt, um bspw. für Anfragen erreichbar
+ sein.
+
+* Die Kurzbeschreibung der Gruppe (2.2.) muss im Falle einer moderierten
+ Gruppe zwingend mit der Submissionsadresse und dem Schlüsselwort
+ "(Moderated)" in exakt dieser Schreibweise enden, bspw. so:
+| de.gruppe.mod Moderierte Gruppe. <moderation@domain.example> (Moderated)
+
+* Falls die zu moderierende Gruppe keine Diskussionsgruppe ist,
+ sondern nur Ankündigungen, FAQs o.ä. enthalten soll, sollte eine
+ Gruppe bestimmt werden, in der diese Ankündigungen oder FAQs
+ anschließend ggf. diskutiert werden können und in die Antworten dann
+ per gesetztem Followup-To:-Header geleitet werden.
+
+* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach
+ welchen Kriterien Beiträge akzeptiert oder zurückgewiesen werden, ob
+ sie ggf. verändert veröffentlicht werden können und wie mit
+ Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
+ mehrköpfigen Moderation stellt dies eine einheitliche Handhabung
+ sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
+ werden und danach (regelmäßig) veröffentlicht werden.
+
+ Entsprechende Beispiele finden sich in bereits bestehenden
+ moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der
+ de-Hierarchie" enthält teilweise Verweise darauf.
+
+* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
+ Möglichkeit, einen per E-Mail übersandten Beitrag unter Beibehaltung
+ der wesentlichen Informationen auch im Header - aber unter Wegfall
+ mancher und Ergänzung anderer Headerzeilen - als Posting zu
+ veröffentlichen. Insbesondere dann, wenn mehr als eine Person -
+ parallel - an der Moderation beteiligt sein soll (was sich
+ mittlerweile als Regelfall etabliert haben dürfte), empfiehlt es
+ sich, das entsprechende Zusammenwirken auch technisch zu
+ unterstützen. In der Regel wird die Moderation einer Newsgroup also
+ die Installation entsprechender Software auf dem eigenen Rechner
+ oder sogar die Einrichtung auf einem übers Netz erreichbaren
+ Rechner, bspw. mit einem Webinterface, und deren Bedienung
+ erfordern.
+
+ Das muss nicht zwingend durch die Moderatoren selbst erfolgen; im
+ Zweifel werden aktive Netzteilnehmer bereit sein, eine solche
+ Installation zur Verfügung zu stellen. Die Auswahl und Erprobung der
+ vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
+ Kontaktaufnahmen sollten aber spätestens parallel zum laufenden
+ Einrichtungsverfahren erfolgen; Tests können bspw. in der Newsgroup
+ de.alt.test.moderated erfolgen.
+
+Siehe auch:
+
++ Unknown: NetNews Moderator's Handbook (1994, engl.)
+ <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
+ <http://pages.swcp.com/~dmckeon/mod-faq.html>
++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
+ <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
+ <http://www.big-8.org/wiki/Moderated_Newsgroups>
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+ <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
++ Informationen über de.alt.test.moderated
+| From: Thomas Hochstein <thh@inter.net>
+| Newsgroups: de.alt.test.moderated
+| Subject: Info: de.alt.test.moderated <2010-11-01>
|
+| Last-modified: 2010-11-01
+| Posting-frequency: monthly
+
+2.5. Sonderfälle
+----------------
+
+Die vorstehenden Erläuterungen decken den Regelfall der Einrichtung
+einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene
+Sonderfälle:
+
+* Aufteilung von Gruppen
+
+ Wenn eine bestehende Newsgroup aufgrund der regen Nutzung in mehrere
+ Gruppen unterteilt werden soll, entsteht daraus in der Regel eine
+ neue Teilhierachie (ein neuer Zweig am Baum der Struktur von de.*).
+ Die Einrichtungsregeln sehen für diesen Fall in Punkt 7 folgendes
+ vor:
+
+| .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie --
+| sei es durch Umwandlung einer bestehenden Gruppe oder durch
+| Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc
+| endende Gruppe eingerichtet. Der zur Gründung der Hierarchie
+| führende RfD hat hierzu die notwendigen Angaben bereitzustellen.
+| Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
+| findet hierüber eine normale Abstimmung statt.
+
+ Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe für
+ Ausrüstungsfragen ("de.rec.outdoors.ausruestung") abgespalten
+ werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
+ eingerichtet werden. Dies geschieht regelmäßig durch Umbenennung der
+ bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
+ also auch dazu Informationen enthalten.
+
+* Einrichtung einer neuen Teilhierarchie
+
+ Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
+ vorgeschlagen werden soll, sondern direkt mehrere, thematisch
+ zusammenhängende, also auf diese Weise eine neue Teilhierachie
+ entsteht.
+
+ Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
+ "de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
+ eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
+ aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
+ mit Ködern zu tun haben. Die entsprechenden Informationen - Name,
+ Kurzbeschreibung, Charta - müssen ebenfalls im Einrichtungsvorschlag
+ enthalten sein.
+
+* Einrichtung mehrerer Gruppen
+
+ In einem Einrichtungsvorschlag sollte nur dann die Einrichtung
+ mehrerer Gruppen zusammengefasst werden, wenn diese in einem inneren
+ Zusammenhang stehen, wenn bspw. eine bestehende Gruppe aufgeteilt
+ werden oder direkt eine komplette neue Teilhierarchie eingerichtet
+ werden soll. In diesem Fall muss der Einrichtungsvorschlag dann für
+ alle Gruppen die notwendigen Informationen bereitstellen.
+
+ Zu berücksichtigen ist, dass Vorschläge grundsätzlich nicht "en
+ bloc" zur Abstimmung gestellt werden können; vielmehr ist über jeden
+ Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
+ Teil 7 folgende Vorgaben:
+
+| Übertragbarkeit: Stimmen können nicht auf einen anderen
+| Abstimmungsvorschlag übertragen werden. Eine Stimme zählt nur für
+| GENAU DEN Vorschlag, für den sie abgegeben wurde. Insbesondere
+| darf eine Stimme für oder gegen eine Newsgruppe mit einem
+| bestimmten Namen NICHT als Stimme für oder gegen eine Newsgruppe
+| mit einem anderen Namen oder einer anderen Charta, einem anderen
+| unmoderiert/moderiert Status oder, falls moderiert, einem anderen
+| Moderator oder einer anderen Gruppe von Moderatoren gezählt
+| werden. Über jede Gruppe wird einzeln abgestimmt, Verknüpfungen
+| von Wahlen sind nicht möglich.
+
+* Diskussion mehrerer Alternativen
+
+ Ziel der Diskussion sollte es regelmäßig sein, am Ende der
+ Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
+ Das schließt nicht aus, in der Diskussion zunächst mehrere denkbare
+ Alternativen vorzuschlagen; die Diskussion sollte aber schließlich
+ zu einem mehrheitsfähigen Vorschlag führen. Ggf. kann dazu auch ein
+ unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
+ sich ausschließende Alternativen zur Abstimmung zu stellen sollte
+ nach Möglichkeit vermieden werden, weil die Abstimmung sonst
+ einerseits schnell sehr kompliziert wird und andererseits die Gefahr
+ besteht, dass entweder kein Vorschlag eine Mehrheit erhält (obwohl
+ die Mehrzahl der Abstimmenden durchaus generell für eine Einrichtung
+ der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
+ Vorschlägen angenommen wird, dass so niemand gewollt hat.
+
+ Die für die Abstimmung in diesem Fall zu beachtenden Regeln für
+ "kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
+ und lauten folgendermaßen:
+
+| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
+| höchstens eine eingerichtet werden soll ("kombiniertes Voting").
+| Dabei wird über die Einrichtung jeder einzelnen Gruppe gemäß den
+| obigen Regeln abgestimmt.
|
-| [Gruppenname] [Kurzbeschreibung]
+| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
+| zusätzlich ein Stichentscheid zwischen all diesen Gruppen statt.
+| Falls in den Einrichtungsfragen mehr als eine Gruppe angenommen
+| wird, so wird davon einzig diejenige eingerichtet, welche im
+| Stichentscheid das beste Verhältnis Zustimmung : Ablehnung aufweist.
+
+ Siehe dazu auch:
+
+ + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+| From: faq@wortrei.ch (Adrian Suter)
+| Newsgroups: de.admin.news.regeln,de.admin.infos
+| Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+|
+| Archive-name: de-admin/entscheidung
+| Posting-frequency: weekly
+| Last-modified: 2003-12-31
+| URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
+| URL: http://www.kirchwitz.de/~amk/dai/entscheidung
+
+3. Diskussionsphase
+===================
+
+Wenn alle Vorüberlegungen abgeschlossen sind, kann das "offizielle"
+Einrichtungsverfahren mit der Abfassung eines förmlichen
+Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der
+bei der Moderation von de.admin.news.announce eingereicht und von
+dieser dann nach Prüfung veröffentlicht wird.
+
+3.1. Inhalt und Aufbau eines RfD
+--------------------------------
+
+3.1.1. Inhalt
+
+Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter
+2. dargestellten notwendigen Informationen und einer Begründung des
+Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem
+Vorschlag und der Notwendigkeit für die bzw. dem Erfolg der
+vorgeschlagenen neuen Gruppe zu überzeugen.
+
+Üblicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
+und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
+Begründung, die den Hintergrund für den Vorschlag und die Überlegungen
+insbesondere zu den bereits oben unter 1. ("Vorüberlegungen")
+genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem
+Bedarf bietet es sich oft an, eine statistische Auswertung des bereits
+im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten
+Monaten vorzunehmen ("Trafficnachweis"). Außerdem enthält der RfD
+natürlich Namen und Mailadressen des- oder derjenigen, der/die den
+Vorschlag einreichen ("Proponent(en)"). Bei einer Mehrzahl von
+Personen bietet sich ggf. die Einrichtung eines Verteilers für die
+Kommunikation mit der Moderation von de.admin.news.announce und für
+eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an.
+
+Schließlich ist auch zu entscheiden, in welchen Gruppen der RfD
+veröffentlicht werden soll; das sind mindestens de.admin.news.announce
+und de.admin.news.groups, zusätzlich sollten aber auch die Gruppen
+aufgenommen werden, die durch das Verfahren vorhersehbar tangiert
+werden, also namentlich die Gruppe(n), die aufgeteilt werden soll(en),
+deren Themenbereiche durch die neue Gruppe eingeschränkt werden oder
+die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
+natürlich Gruppen, in denen bisher schon Diskussionen zu dem Thema
+stattfinden oder in denen man sich Interessen an der neuen Gruppe
+erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie
+möglich und nur so lang wie nötig sein sollte; dies schon deshalb,
+weil in übermäßig viele Gruppen verteilte Postings heutzutage
+möglicherweise als Spam ausgefiltert werden.
+
+Eine Veröffentlichung durch die Moderation von de.admin.news.announce
+kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im
+Einverständnis mit deren Moderation. In Gruppen außerhalb von de.*,
+auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
+Webforen o.ä. kann der Proponent nach Veröffentlichung des RfDs einen
+Hinweis auf diesen ("Pointer") veröffentlichen, der u.a. Newsgroups,
+Betreff und auch die Message-ID des RfDs enthalten sollte, damit
+Interessenten den Vorschlag und die Diskussion finden können.
+
+3.1.2. Formale Gestaltung
+
+Für die formale Gestaltung eines RfD gibt es keine verbindlichen
+Vorgaben; allenfalls haben sich Üblichkeiten entwickelt. Es empfiehlt
+sich auch hier, einige ältere RfD in de.admin.news.announce als Muster
+heranzuziehen. Das kann dann bspw. so aussehen:
+
+| 1. RfD (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
+oder
-| 1. Diskussionsaufruf
-| ====================
-|
-| zur Einrichtung der neuen Gruppe
-|
-| [Gruppenname] [Kurzbeschreibung] <moderator@domain.example> (Moderated)
-|
-| Diskussionen sollen in der Gruppe
-|
-| [Gruppenname] [Kurzbeschreibung]
-|
-| gefuehrt werden.
-|
-|
| Status
| ------
+|
+| Die Gruppe ist moderiert.
|
-| Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat
-| <moderator@domain.example> und Peter Roponent
-| <proponent@domain.example> vorgeschlagen.
+| Moderatoren sind Adam Berthold <adam@berthold.example> und
+| Charlotte Dominik <charlotte@dominik.example>.
+|
+| Die Submissionsadresse lautet <submissionen@domain.example>.
|
| Charta
| ------
|
| [Charta]
|
-| Die Postings in [Gruppenname] sind mit einer Headerzeile
-|
-| Followup-To: [Diskussionsgruppe]
-|
-| zu versehen.
+| Hintergrund / Begründung
+| ----------- ----------
|
+| [Begründung, ggf. untergliedert]
+|
+| Proponent(en)
+| -------------
|
-| 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.
-
-----------------------------------------------------------------------
+| [Name(n) und Mailadresse(n)]
+
+Unter <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
+einen "RfD-Generator" eingerichtet. Über ein Formular werden die
+notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige
+Fehler hin überprüft und daraus dann ein Text erzeugt, der als RfD
+eingereicht werden kann.
+
+3.2. Einreichung des RfD
+------------------------
+
+Der fertige RfD ist dann per E-Mail an <moderator@dana.de> an die
+Moderation von de.admin.news.announce einzureichen. Neben dem
+eigentlichen Text sollte dabei auch die Liste der Gruppen übermittelt
+werden, in denen der RfD veröffentlicht werden soll. Der RfD kann auch
+bereits einschließlich des Headers (mit Absender, Betreff,
+Gruppenliste etc.), bspw. als angehängte Textdatei, übermittelt
+werden.
-5. Nach der Veröffentlichung
+Üblicherweise wird die Moderation den Eingang des RfD bestätigen und
+ihn in den wöchentlich geposteten Status aufnehmen, der auch auf den
+Webseiten der Moderation veröffentlicht wird. Danach wird ein
+Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
+überprüft, ggf. Rücksprache mit dem oder den Proponenten nimmt und ihn
+schließlich in de.admin.news.announce und den übrigen Gruppen
+veröffentlicht.
+
+Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen
+sind oder Unsicherheit bestehen, können diese in der Regel mit dem
+Verfahrensbetreuer diskutiert und geklärt werden. Die
+Verfahrensbetreuer der Moderation von de.admin.news.announce haben
+üblicherweise bereits längerfristige Erfahrungen mit de.* und dem
+Einrichtungsverfahren gesammelt und können daher im Zweifel Tips und
+Hinweise geben oder beratend tätig werden.
+
+Siehe auch:
+
++ Moderationskonzept der derzeitigen Moderation von d.a.n.a
+| From: moderator@dana.de (Moderation von de.admin.news.announce)
+| Newsgroups: de.admin.news.announce,de.admin.news.misc
+| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
+ <http://dana.de/modkonzept.html>
+
+3.3. Diskussionsphase
+---------------------
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
-| ==================
+Proponenten sollten die Diskussion verfolgen und sich an ihr
+beteiligen, dabei auf Einwände und Kritik eingehen und ggf. ihre
+Begründung verfeinern.
+
+Häufig wird die Diskussion sinnvolle Ergänzungen zum ursprünglichen
+Vorschlag bringen, die in einen neuen, geänderten Vorschlag
+eingearbeitet werden können. Wenn dies der Fall ist, kann nach einiger
+Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur
+Veröffentlichung eingereicht werden, der den modifizierten Vorschlag
+und eine Begründung, warum welche Vorschläge aufgenommen oder
+verworfen wurden, enthält. Dieser zweite RfD erscheint als Antwort
+("Followup") auf den ersten.
+
+Besteht weiterer Diskussionsbedarf, können auch mehrere weitere RfDs
+veröffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
+unnötig verlängert oder verzögert werden; es ist aber auch nicht
+sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu
+veröffentlichen. Vielmehr sollte die Diskussion beobachtet und die
+sich herauskristallisierenden Verbesserungsvorschläge gesammelt
+werden; erst wenn sich ein Konsens abzeichnet oder sich jedenfalls die
+Diskussion beruhigt (oder im Kreis zu drehen beginnt), ist in der
+Regel der richtige Zeitpunkt gekommen, die bisherigen Vorschläge und
+Änderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
+stellen und dann auf dieser Basis einen geänderten Vorschlag als
+weiteren RfD zu veröffentlichen.
+
+Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
+möglichst konstruktiv geführt werden. Als Proponent sollte man sich
+jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer
+ausschließlich erfreulich sein wird; de.admin.news.groups ist auch
+insofern ein Spiegel des Usenets als es dort neben gutwilligen
+Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden
+Teilnehmern auch starrköpfige und unfreundliche. Auch dort gilt aber,
+dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.
+
+3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags
+-----------------------------------------------------------
+
+Am Ende der Diskussion sollte(n) der/die Proponent(en) sich darüber
+Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag
+voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall,
+kann das Verfahren zurückgezogen werden.
+
+Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
+der aus seiner/ihrer Sicht nunmehr endgültige Vorschlag feststellt,
+zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
+Vorschlag nur in der Form des letzten veröffentlichen RfDs zur
+Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss
+inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen
+übereinstimmen. Ggf. ist also vor dem Beginn der Abstimmung noch
+einmal ein weiterer RfD mit den letzten vorgesehenen Änderungen zu
+veröffentlichen.
+
+Nach Möglichkeit sollte am Ende der Diskussion nur noch ein einziger,
+einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls müssen aber
+für jede vorgeschlagene Gruppe Name, Kurzbeschreibung, Status und
+Charta (und bei moderierten Gruppen der Moderator und die
+Submissionsadresse) - notfalls in mehreren Varianten - feststehen.
+
+4. Abstimmungsphase
+===================
+
+Die Abstimmung über einen Vorschlag findet per E-Mail statt. Die
+abgegebenen Stimmen werden während des Abstimmungszeitraums an die E-
+Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie
+auszählt und am Ende ein Ergebnis der Abstimmung mit Namen, E-Mail-
+Adresse und Stimmabgabe aller Teilnehmer veröffentlicht. Die
+Durchführung der Abstimmung muss nicht zwingend durch den oder die
+Proponenten erfolgen; aufgrund der notwendigen technischen und
+organisatorischen Kenntnisse und Voraussetzungen empfiehlt es sich
+oft, die Durchführung einem erfahrenen Usenet-Teilnehmer oder den
+"German Volunteer Votetakers" (GVV) zu überlassen.
+
+4.1. Voraussetzungen für die Durchführung einer Abstimmung
+----------------------------------------------------------
+
+Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen
+gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld
+prüfen:
+
+* Für die Durchführung der Abstimmung 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 Missverständnisse
+ auftreten oder Wahlscheine in der sonstigen Post verloren gehen.
+ Wichtig ist insbesondere auch, dass der Account ungefiltert ist, also
+ keine Spamfilter oder Blacklists aktiv sind, die ggf. dazu führen,
+ dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
+ von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
+ Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
+ von Webhosting- oder Internetzugangsanbietern.
+
+ Siehe dazu auch:
+
+ + Zu Abstimmadressen und Filtermassnahmen
+| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
+| Organization: Moderation von de.admin.news.announce
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln
+| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
+| Date: Sat, 12 Mar 2011 23:15:00 +0100
+| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
+|
+| Filtermaßnahmen bei der Durchführung von Abstimmungen
+| =====================================================
+
+* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von
+ Hand zu bearbeiten, sondern dafür geeignete Software zu verwenden,
+ die Plausibilitätsprüfungen vornimmt, Bestätigungen per E-Mail
+ versenden kann und Auswertungen automatisch erstellt.
+
+ Die verbreitetste Softwarelösung dafür ist UseVote; mehr
+ Informationen dazu und eine Downloadmöglichkeit gibt es auf
+ <http://www.usevote.de>.
+
+* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
+ haben sich einige regelmäßige Teilnehmer in de.admin.news.* dazu
+ bereiterklärt, ungefilterte Abstimmungsaccounts einzurichten und die
+ eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse
+ des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.ä.
+ zu ermöglichen. Dazu zählen u.a.
+
+ - Ralph Angenendt <ihr.name@strg-alt-entf.org>
+ - Ralf Döblitz <doeblitz@doeblitz.net>
+ - Karsten Düsterloh <kd-usenet@tprac.de>
+ - Michael Grimm <trashcan@odo.in-berlin.de>
+ - Jürgen Ilse <ilse@usenet-verwaltung.de>
+ - Emil Schuster <emil@wieslauf.sub.de>
+
+ Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
+ Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
+ abzustimmen.
+
+* Daneben besteht auch die Möglichkeit, die Abstimmung gar nicht
+ selbst durchzuführen, sondern damit einen Dritten zu beauftragen,
+ der weitergehende technische Möglichkeiten oder größere Erfahrungen
+ mit der Durchführung von Abstimmungen hat. Überdies ist es zwar
+ zulässig und auch der von den Einrichtungsregeln ursprünglich
+ vorgesehene Regefall, dass der Proponent auch die Abstimmung
+ durchführt, manchmal ist es aber erwünscht, damit einen unabhängigen
+ Dritten zu beauftragen.
+
+ Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
+ erfahrene Votetaker haben sich überdies zu den "German Volunteer
+ Votetakers" (GVV) zusammengeschlossen und sind unter der Adresse
+ <gvv@dana.de> erreichbar. Jeder Proponent kann unter dieser Adresse
+ - rechtzeitig! - nachfragen, ob ein Mitglied der GVV bereit und in
+ der Lage ist, für ihn die Abstimmung durchzuführen. In den letzten
+ Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
+ Mitglieder der GVV durchgeführt.
+
+ Siehe dazu auch:
+
+ + GVV-FAQ
+| From: Thomas Hochstein <gvv@gvv.th-h.de>
+| Newsgroups: de.admin.infos,de.admin.news.groups
+| Subject: <2011-02-19> GVV-FAQ
+|
+| Archive-name: de-admin/gvv-faq
+| Posting-frequency: weekly
+| Last-modified: 2011-02-19
+| URL: http://gvv.th-h.de/faq.php
+| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq
+
+4.2. Inhalt und Aufbau eines CfV
+--------------------------------
+
+Auch für den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er
+muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name,
+Kurzbeschreibung, Charta, Status, ggf. Moderator) und die für die
+Teilnahme an der Abstimmung notwendigen Informationen, namentlich die
+Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
+den einzelnen Abstimmungspunkten, enthalten. Der Abstimmungszeitraum
+muss mindestens drei Wochen, darf aber höchstens vier Wochen betragen.
+
+Üblich ist es, auf Basis des letzten veröffentlichen RfD einen CfV zu
+entwerfen. Dabei kann der Begründungsteil gekürzt werden oder ganz
+entfallen und durch einen Verweis auf die geführte Diskussion -
+Message-IDs der RfDs - ersetzt werden. Hinzugefügt werden dann die
+Abstimmungsmodalitäten: Votetaker, Abstimmadresse, Abstimmungsende,
+ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
+Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele für
+Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unüblich.
+Bei einfachen Abstimmungen erweist sich eine solche Darstellung
+nämlich als überflüssig; bei komplexeren Abstimmungen hingegen würde
+die Darstellung aller möglichen Abstimmungsvarianten und der
+entsprechenden Ergebnisse solchermaßen unübersichtlich und aufwendig,
+dass regelmäßig darauf verzichtet wird. Wenn jedoch die einzelnen
+Abstimmungsmöglichkeiten dargestellt werden, dann müssen sowohl die
+Abstimmungsmöglichkeiten für wie auch die gegen einen Vorschlag
+dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu
+vermeiden.
+
+Beispiele für CfVs finden sich in de.admin.news.announce. Eine
+mögliche Gestaltung wäre folgende:
+
+| 1. CfV (Abstimmungsaufruf)
+| ==========================
|
| zur Einrichtung der neuen Gruppe
|
-| <Gruppenname> <Kurzbeschreibung>
-|
-| Status: Die Gruppe ist {moderiert|unmoderiert}.
-|
+| [Gruppenname] [Kurzbeschreibung]
+|
+| Status: Die Gruppe ist 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.
+| [Charta]
|
-| 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.
+| Hintergrund / Begründung
+| ----------- ----------
|
-| Es gelten die derzeitigen Wahlregeln, die in de.admin.infos
-| veröffentlicht sind.
+| [kurze Begründung, ggf. Verweis auf die Diskussion]
+|
+| Proponent(en)
+| -------------
|
-| Wie gewählt wird
-| ----------------
+| [Name(n) und Mailadresse(n)]
+|
+| Abstimmungsmodalitäten:
+| =======================
|
-| 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.
+| Votetaker : [Name und Mailadresse]
+| Abstimmadresse : [Mailadresse]
+| Abstimmungsende: Mit Ablauf des [Datum]
+| Wahlschein : Untenstehendes Formular ist zu verwenden. Möglich sind
+| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
+| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
+| der bei Beginn der Abstimmung gültigen Fassung, die in de.admin.infos
+| und unter <http://www.kirchwitz.de/~amk/dai/einrichtung> auch im WWW
+| veröffentlicht sind. Sie erläutern das Wahlverfahren detailliert und
+| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
|
-| Deine Entscheidung bedeutet dabei:
+| Gezählt werden nur per E-Mail bei der Abstimmadresse eingegangene
+| Stimmen. Diese werden einzeln per E-Mail bestätigt. Das Ergebnis wird
+| nach dem Ende der Wahl veröffentlicht. Namen, E-Mail-Adresse und
+| Inhalt der Stimmabgabe aller Abstimmenden werden im Ergebnis genannt.
+| Mit Rücksicht auf das deutsche Datenschutzrecht ist daher die
+| gesonderte Zustimmung zur Speicherung und Veröffentlichung der
+| abgegebenen Stimme entsprechend Hinweis im Wahlschein nötig.
|
-| JA - Ich bin für diesen Vorschlag.
-| NEIN - Ich bin gegen diesen Vorschlag.
-| ENTHALTUNG - Ich enthalte mich oder ich ziehe meine Stimme zurück
+| WAHLSCHEIN fuer Einrichtung von [Gruppenname]
|
-| Enthaltungen gelten nicht im Sinne einer gültig
-| abgegebenen Stimme; sie dienen vornehmlich dazu,
-| eine zuvor abgegebene Stimme zurückzuziehen.
+| Dein Realname, falls nicht im FROM-Header:
|
-| 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.
+| Wenn du keinen Real-Namen angibst, wird deine Stimme fuer
+| ungueltig erklaert werden.
|
-| 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).
+| Nr [Deine Stimme] Gruppe/Abstimmungsgegenstand
+| ========================================================================
+| #1 [ ] Einrichtung von [Gruppenname]
|
-| 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.
+| Zur Verarbeitung des Wahlscheines und insbesondere der
+| Veroeffentlichung des Ergebnisses ist deine Zustimmung zur Speicherung,
+| Auswertung und Veroeffentlichung deiner Stimmdaten (Name und
+| E-Mail-Adresse in Verbindung mit dem Stimmverhalten) im Rahmen dieses
+| Verfahrens erforderlich. Wenn du im Feld unterhalb dieses Absatzes "JA"
+| eintraegst, erklaerst du dich damit einverstanden. In allen anderen
+| Faellen wird der Wahlschein mit Ruecksicht auf das deutsche
+| Bundesdatenschutzgesetz verworfen und nicht gewertet.
|
-| 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.
+| #a [ ] Datenschutzklausel - Zustimmung: Ich bin mit der
+| Verarbeitung meiner Daten wie oben beschrieben
+| einverstanden
|
-| 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 nach dieser Zeile bitte loeschen =-=-=-=-=-=-=-=-
+
+Es empfiehlt sich, im Wahlschein eine Möglichkeit vorzusehen, den
+tatsächlichen Namen anzugeben, da möglicherweise im E-Mail-Programm
+ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist
+durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).
+
+Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
+an die Moderation von de.admin.news.announce einzureichen. Auch hier
+gehört die Liste der Gruppen dazu, in denen der RfD veröffentlicht
+werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
+kann bereits einschließlich des Headers (mit Absender,
+Betreff, Gruppenliste etc.), bspw. als angehängte Textdatei,
+übermittelt werden.
+
+Die Veröffentlichung des CfVs wird üblicherweise länger dauern als bei
+den RfD, weil der Abstimmungsaufruf durch die Moderation von
+de.admin.news.announce nach dem 4-Augen-Prinzip überprüft wird. Den
+zutreffenden Endtermin der Abstimmung, der sich aus dem Zeitpunkt der
+Veröffentlichung ergibt, setzt die Moderation dann selbst ein.
+
+4.3. Abstimmungsphase
+---------------------
+
+Während der drei- oder vierwöchigen Abstimmungsphase muss der
+Abstimmungsaccount durchgehend erreichbar sein. Jede abgegebene Stimme
+sollte - nach Möglichkeit einigermaßen zeitnah, am besten
+automatisiert - per E-Mail bestätigt werden; in dieser Bestätigung
+sollte angegeben sein, welche Stimme(n) und welcher Name sowie welche
+Mailadresse für den Abstimmenden registriert wurden. Für Zwecke der
+Abstimmung ist die Adresse im From: der E-Mail zu erfassen; an diese
+sollte auch die Bestätigung versandt werden, um sicherzustellen, dass
+diese Stimme auch tatsächlich vom angegebenen Absender stammte (und
+die Abstimmadresse replyfähig ist, d.h. E-Mail dort empfangen werden
+kann). Außerdem sollte in der Bestätigung angegeben sein, wie eine
+Stimme nachträglich geändert oder komplett zurückgezogen werden kann
+(wenn bspw. eine E-Mail-Adresse verwendet wurde, die nicht im Usenet
+veröffentlicht werden soll.)
+
+In der Mitte der Abstimmungsphase ist es üblich, einen 2. CfV zu
+veröffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
+Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die
+Stimmabgaben!) enthält; dabei kann auch bereits angegeben werden, ob
+Stimmen voraussichtlich als ungültig gewertet werden.
+
+Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
+endet die Abstimmung. Verspätete Stimmen werden nicht mehr gezählt.
+
+4.4. Auswertung und Ergebnis der Abstimmung
+-------------------------------------------
+
+Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgezählt.
+
+Dabei werden zunächst die JA- und NEIN-Stimmen sowie Enthaltungen
+gezählt. Wenn eine Person mehrere Stimmen abgegeben hat, gilt die
+zuletzt abgegebene Stimme. Bei Unklarheiten hinsichtlich des Inhalts
+der Stimmabgabe oder des Namens oder der Mailadresse sollte mit dem
+Abstimmenden Rücksprache gehalten werden. Das gleiche gilt, wenn
+mehrere Stimmen offenbar von derselben Person stammen (gleicher Name,
+unterschiedliche Mailadresse oder umgekehrt), um festzustellen, ob nur
+die letzte Stimme zu werten ist oder es sich doch um verschiedene
+Personen handelt.
+
+Stimmen, die nicht eindeutig sind, oder die in anderer Weise nicht den
+Einrichtungsregeln genügen (Angabe eines falschen oder nicht
+vollständigen Namens, nicht replyfähige Abstimmadresse), dürfen nicht
+gewertet werden. Der Votetaker sollte auch die Möglichkeit von
+Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
+Identitäten, Weitergabe des Wahlscheins außerhalb der Gruppen, in
+denen er veröffentlicht wurde, Beeinflussung der Abstimmung durch
+"Campaigning") im Auge behalten und entsprechende Überprüfungen
+vornehmen. Unklarheiten sollten mit den betroffenen
+Abstimmungsteilnehmern geklärt werden. Im Einzelfall kann auch die
+Meinung der Moderation zu einer umstrittenen Frage eingeholt werden;
+es empfiehlt sich, zumindest die Entscheidungen der Moderation aus
+vergangenen Jahren zu früheren Zweifelsfällen zu Rate zu ziehen.
+
+Bei der Auswertung sollte der Votetaker im eigenen Interesse die
+datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
+er unterliegt, berücksichtigen. Dies gilt insbesondere, sofern zur
+Speicherung, Verarbeitung und vor allem Veröffentlichung der
+personenbezogenen Daten der Abstimmungsteilnehmer ausdrückliche
+Einwilligungserklärungen erforderlich sind.
+
+Danach ist eine Ergebnisveröffentlichung ("Result") vorzubereiten.
+Üblich ist es, die Gesamtzahl der gültigen Stimmen und sodann für
+jeden Abstimmungspunkt die JA- und NEIN-Stimmen sowie die Enthaltungen
+und ungültigen Stimmabgaben zu nennen. Angenommen ist der Vorschlag,
+wenn mindestens 60 JA-Stimmen eingegangen sind und die Anzahl der JA-
+Stimmen mindestens doppelt so groß ist wie die Anzahl der NEIN-Stimmen
+(2/3-Mehrheit).
+
+Zwingend ist zudem die Veröffentlichung einer Liste aller Abstimmenden
+mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
+ungültige Stimmen sind anzugeben, bei letzteren unter Angabe einer
+stichwortartigen Begründung für die Nichtwertung. Dies ermöglicht es
+allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.
+
+In besonderen Fällen kann die Veröffentlichung von Name und/oder
+Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dürfte
+das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind,
+in denen aus bestimmten Gründen die Verwendung von Pseudonymen
+akzeptiert wird.
+
+5. Verfahrensabschluss und Umsetzung
+====================================
+
+Mit der Veröffentlichung des Results durch die Moderation von
+de.admin.news.announce beginnt eine einwöchige Einspruchsfrist, in der
+jeder Interessierte Einspruch mit der Begründung einlegen kann, dass
+bei der Durchführung der Abstimmung schwerwiegende Unregelmäßigkeiten
+gab. Das können bspw. technische Probleme mit der Abstimmadresse sein,
+die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker
+oder einer der bereits unter 4.4. angerissenen Manipulationsversuche.
+
+Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
+Abstimmung bestandskräftig; die Moderation von de.admin.news.announce
+wird dann die entsprechenden digital signierten Steuernachrichten
+versenden, die üblicherweise die automatische Einrichtung der neuen
+Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* führen, und
+die kanonische List der in de.* existierenden Newsgroups entsprechend
+ergänzen.
+
+Ansonsten wird die Moderation über eingegangene Einsprüche entscheiden
+und das Ergebnis der Abstimmung entweder entsprechend anpassen oder
+schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das
+veröffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch
+gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber
+keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in
+der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann,
+wenn über den Einspruch abschließend entschieden ist.
+
+Das Einrichtungsverfahren ist damit beendet.
+
+6. Quellen
+==========
+
+Alle in diesen Erläuterungen genannten Quellen sind hier noch einmal
+zusammengefasst und um weitere Hinweise ergänzt.
+
+6.1. Grundlegende Informationen
+-------------------------------
+
+Folgende Texte sollten einem Proponenten unbedingt bekannt sein:
+
++ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.alt.admin
+| Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
|
+| Archive-name: de-admin/einrichtung
+| Posting-frequency: weekly
+| Last-modified: 2005-08-06
+| URL: http://www.kirchwitz.de/~amk/dai/einrichtung
+
++ Missverstaendnisse in de.admin.news.groups
+| From: 3.14@piology.org (Boris 'pi' Piwinger)
+| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
|
-| -=-=-=-=-=-= Alles vor dieser Zeile löschen =-=-=-=-=-=-
+| Archive-name: de-admin/dang-faq
+| Posting-frequency: weekly
+| Last-modified: 2009-01-24
+| URL: http://www.kirchwitz.de/~amk/dai/dang-faq
+
++ Die Newsgruppen der de-Hierarchie (Gruppenliste)
+| From: Daniel Roth <25.8@bluemail.ch>
+| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
+| Subject: <2011-03-07> Die Newsgruppen der de-Hierarchie
|
-| Wahlschein fuer die {Einrichtung|Umbenennung|Entfernung} von
-| <Gruppenname>
+| Archive-name: de-newusers/de-newsgruppen
+| Posting-frequency: weekly
+| Last-modified: 2011-03-07
+| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen
+
+6.2. Weiterführende Hinweise
+----------------------------
+
+Folgende Texte sind allgemein oder für spezielle Fragen hilfreich oder
+von Interesse:
+
++ Moderationskonzept der derzeitigen Moderation von d.a.n.a
+| From: moderator@dana.de (Moderation von de.admin.news.announce)
+| Newsgroups: de.admin.news.announce,de.admin.news.misc
+| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
+ <http://dana.de/modkonzept.html>
+
++ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
+| From: bernd@tenuki.de (Bernd Gramlich)
+| Newsgroups: de.admin.infos
+| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
|
-| Dein Realname, falls nicht im From:-Header:
+| Archive-name: de-admin/dan-glossar
+| Posting-frequency: weekly
+| Last-modified: 2004-12-06
+| URL: http://www.tmt.de/~gramlich/dan-glossar.html
+| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar
+
++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
+ <http://th-h.de/infos/usenet/newgroup.php#vorschlag>
+
++ Erste Schritte zur Einrichtung neuer Gruppen
+ <http://www.babylonsounds.com/usenet/rfd_howto.html>
+
++ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
+| From: faq@wortrei.ch (Adrian Suter)
+| Newsgroups: de.admin.news.regeln,de.admin.infos
+| Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|
-| Wenn Du keinen Real-Namen veröffentlicht haben willst, wende Dich
-| mit einer Begründung an <e-mail@ad.res.se>
+| Archive-name: de-admin/entscheidung
+| Posting-frequency: weekly
+| Last-modified: 2003-12-31
+| URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
+| URL: http://www.kirchwitz.de/~amk/dai/entscheidung
+
++ Regeln fuer Newsgruppennamen
+| From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
+| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
+| Date: 2000/07/18
+| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
+ <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
+
++ GVV-FAQ
+| From: Thomas Hochstein <gvv@gvv.th-h.de>
+| Newsgroups: de.admin.infos,de.admin.news.groups
+| Subject: <2011-02-19> GVV-FAQ
|
-| [Deine Stimme] Abstimmungsgegenstand
-| ----------------------------------------------------------------------
-| [ ] Einrichtung von <Gruppenname>
+| Archive-name: de-admin/gvv-faq
+| Posting-frequency: weekly
+| Last-modified: 2011-02-19
+| URL: http://gvv.th-h.de/faq.php
+| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq
+
++ Filtermaßnahmen bei der Durchführung von Abstimmungen
+| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
+| Organization: Moderation von de.admin.news.announce
+| Newsgroups: de.admin.news.announce,de.admin.news.regeln
+| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
+| Date: Sat, 12 Mar 2011 23:15:00 +0100
+| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
+
++ Unknown: NetNews Moderator's Handbook (1994, engl.)
+ <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+
++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
+ <http://pages.swcp.com/~dmckeon/mod-faq.html>
+
++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
+ <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+
++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
+ <http://www.big-8.org/wiki/Moderated_Newsgroups>
+
++ Big-8 Moderation Board Wiki: Moderation Software (engl.)
+ <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
+
++ Informationen über de.alt.test.moderated
+| From: Thomas Hochstein <thh@inter.net>
+| Newsgroups: de.alt.test.moderated
+| Subject: Info: de.alt.test.moderated <2010-11-01>
|
-| -=-=-=-=-=-= Alles nach dieser Zeile löschen =-=-=-=-=-=-
-
+| Last-modified: 2010-11-01
+| Posting-frequency: monthly
-6.3. Technische Voraussetzungen für die Durchführung
+6.3. Webseiten
+--------------
-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. Wichtig ist insbesondere auch, daß der
-Account ungefiltert ist, also keine Spamfilter oder Blacklists aktiv
-sind, die ggf. dazu führen, daß legitime Abstimmungs-E-Mail nicht
-angenommen werden. Die meisten kostenlosen Angebote sind daher ebenso
-ungeeignet wie viele Standardaccounts von Webhostinganbietern.
+Folgende Webseiten sollten bekannt sein oder können bei der Durchführung des
+Einrichtungsverfahrens helfen:
-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.
++ Webseite der Moderation von de.admin.news.announce
+ <http://www.dana.de/status.html>
++ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
+ wöchentlich veröffentlicht in de.admin.news.announce
+ <http://www.dana.de/status.html>
-6.4. Unabhängige Wahlleiter
++ RfD-Generator
+ <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
-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.
++ Abstimmungssoftware UseVote
+ <http://www.usevote.de>
-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. Maintainer und Kontakt
+=========================
-----------------------------------------------------------------------
+7.1. Derzeitige Maintainer
+--------------------------
-7. Schlußbemerkungen
+Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
+ Michael Ottenbruch <dana-manual@ottenbruch.net>
-7.1. Literatur
+Das dana-Manual wurde im März/April 2011 vollständig überarbeitet und
+neu gefasst.
-Folgende Texte sollten dem Proponenten auf jeden Fall bekannt sein:
+Weitere Änderungen und Ergänzungen nehmen die Maintainer gerne
+entgegen. Vorschläge können per E-Mail an <dana-manual@usenet.th-h.de>
+gerichtet werden. Im Falle einer öffentlichen Diskussion solcher
+Vorschläge ist ein Hinweis an die Maintainer hilfreich.
- <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.
+Das dana-Manual ist auch in einem Git-Repository unter
+<http://code.th-h.de/?p=faqs/dana-manual.git> verfügbar und kann über
+die Weboberfläche eingesehen oder via "git clone" ausgecheckt werden.
+Bei Änderungsvorschlägen sind Git-Patches am einfachsten zu
+verarbeiten; natürlich nehmen die Maintainer aber auch jede andere
+Form von Anregungen entgegen.
- <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.
+7.2. Frühere Fassungen
+----------------------
- <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.
+Maintainer bis 2010: Thomas Roessler, Dirk Nimmich
- <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. Maintainer und Danksagungen
-
-Maintainer dieser FAQ: Michael Ottenbruch
- Thomas Hochstein
-
-Maintainer bis 2010: Thomas Roessler, nach einem Entwurf von Dirk Nimmich
-
-Zu diesem Text und seiner Entstehung haben beigetragen:
+Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
+haben außerdem beigetragen:
- Lutz Donnerhacke
- Kristian Köhntopp
- Rolf Krahl
-- Dirk Nimmich
- Martin Recke
-- Thomas Roessler
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth
+
+Herzlichen Dank!
projects / faqs / dana-manual.git / blobdiff