Initial check-in.
authorThomas Hochstein <thh@inter.net>
Mon, 15 Mar 2010 21:23:57 +0000 (22:23 +0100)
committerThomas Hochstein <thh@inter.net>
Mon, 15 Mar 2010 21:23:57 +0000 (22:23 +0100)
Signed-off-by: Thomas Hochstein <thh@inter.net>
dana-manual [new file with mode: 0644]

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