Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
-Version: 2.0.0
-Last-modified: 2010-03-15
+Version: 2.1.1
+Last-modified: (unreleased)
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
-
-Für die Wahl des Gruppennamens sind zunächst technisch geprägte
-Vorgaben [2] 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, 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 (-). Insgesamt soll die
-Länge des Newsgruppennamens 71 Zeichen nicht überschreiten.
-
- [2] 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>
-
-Der Name sollte ungeachtet dessen 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. Teilweise lassen sich neben den Gruppennamen auch
-die Kurzbeschreibungen vom Nutzer auf bestimmte Begriffe hin
-durchsuchen.
+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 Gruppennamens 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. Hingegen sollten möglichst Begriffe in
der Kurzbeschreibung auftauchen, nach denen an der Gruppe
-interessierte 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.
+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.
+|
+| Moderatoren sind Adam Berthold <adam@berthold.example> und
+| Charlotte Dominik <charlotte@dominik.example>.
|
-| Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat
-| <moderator@domain.example> und Peter Roponent
-| <proponent@domain.example> vorgeschlagen.
+| Die Submissionsadresse lautet <submissionen@domain.example>.
|
| Charta
| ------
|
| [Charta]
|
-| Die Postings in [Gruppenname] sind mit einer Headerzeile
-|
-| Followup-To: [Diskussionsgruppe]
+| Hintergrund / Begründung
+| ----------- ----------
|
-| zu versehen.
+| [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>
+ - 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 =-=-=-=-=-=-
-
-
-6.3. Technische Voraussetzungen für die Durchführung
-
-Für die Abstimmung selbst benötigt man einen E-Mail-Account, der die
-Wahlscheine entgegennimmt. Dieser sollte nach Möglichkeit nicht mit
-der "normalen" E-Mail-Adresse des Abstimmungsleiters identisch sein,
-damit keine Mißverständnisse auftreten oder Wahlscheine in der
-sonstigen Post verloren gehen. 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.
-
-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.
+| Last-modified: 2010-11-01
+| Posting-frequency: monthly
+6.3. Webseiten
+--------------
-6.4. Unabhängige Wahlleiter
+Folgende Webseiten sollten bekannt sein oder können bei der Durchführung des
+Einrichtungsverfahrens helfen:
-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.
++ Webseite der Moderation von de.admin.news.announce
+ <http://www.dana.de/status.html>
-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.
++ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
+ wöchentlich veröffentlicht in de.admin.news.announce
+ <http://www.dana.de/status.html>
-----------------------------------------------------------------------
++ RfD-Generator
+ <http://piology.org/cgi-bin/rfd.pl> hat Boris 'pi' Piwinger
-7. Schlußbemerkungen
++ Abstimmungssoftware UseVote
+ <http://www.usevote.de>
-7.1. Literatur
+7. Maintainer und Kontakt
+=========================
-Folgende Texte sollten dem Proponenten auf jeden Fall bekannt sein:
+7.1. Derzeitige Maintainer
+--------------------------
- <Datum> Einrichtung von Usenet-Gruppen in "de.*"
- Dieser Text beschreibt die Richtlinien für die Einrichtung einer
- Newsgroup in der de.*-Hierarchie, insbesondere die üblichen
- Abstimmungsmodalitäten. Er wird wöchentlich in de.admin.infos
- gepostet.
-
- <Datum> Die Newsgruppen der de.*-Hierarchie
- Hier findet sich eine Beschreibung der bereits eingerichteten
- Newsgroups in de.* (einschließlich de.alt.*). Das Posting findet
- sich allwöchentlich in de.newusers.infos.
-
- <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>.
+Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
+ Michael Ottenbruch <dana-manual@ottenbruch.net>
- RfD
- Request for Discussion, Aufruf zur Diskussion. Leitet die
- Diskussion um eine Entscheidung ein bzw. bringt sie wieder in
- Gang.
+Das dana-Manual wurde im März/April 2011 vollständig überarbeitet und
+neu gefasst.
+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.
-7.3. Maintainer und Danksagungen
+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.
-Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
- Michael Ottenbruch <dana-manual@ottenbruch.net>
+7.2. Frühere Fassungen
+----------------------
Maintainer bis 2010: Thomas Roessler, Dirk Nimmich
-Zu diesem Text und seiner Entstehung haben außerdem beigetragen:
+Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung
+haben außerdem beigetragen:
- Lutz Donnerhacke
- Kristian Köhntopp
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth
+
+Herzlichen Dank!
projects / faqs / dana-manual.git / blobdiff