Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
-Last-modified: 2001-04-29
-URL: http://www.afaik.de/usenet/faq/dana-manual/
+Version: 2.0.0
+Last-modified: 2010-03-15
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 $
- ____________________________________________________________
+ Erläuterungen zur Einrichtung neuer Gruppen in de.*
+ ===================================================
- Inhaltsverzeichnis
+Inhaltsverzeichnis
+------------------
- 1. Einleitung
+1. Einleitung
- 1.1 Adressatenkreis
- 1.2 Was ist ein RfD?
+ 1.1 Adressatenkreis
+ 1.2 Was ist ein RfD?
- 2. Vor dem RfD
+2. Vor dem RfD
- 3. Formulierung eines 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
+ 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
+
+======================================================================
+
+1. Einleitung
+
+1.1. Adressatenkreis
+
+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
+
+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 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.
+
+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. 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.
+
+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] <moderator@domain.example> (Moderated)
+|
+| Diskussionen sollen in der Gruppe
+|
+| [Gruppenname] [Kurzbeschreibung]
+|
+| gefuehrt werden.
+|
+|
+| Status
+| ------
+|
+| Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat
+| <moderator@domain.example> und Peter Roponent
+| <proponent@domain.example> 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. 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.
+
+
+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. Maintainer und Danksagungen
+
+Maintainer dieser FAQ: Michael Ottenbruch
+ Thomas Hochstein
- ______________________________________________________________________
-
- 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.
+Maintainer bis 2010: Thomas Roessler, nach einem Entwurf von Dirk Nimmich
- 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.
+Zu diesem Text und seiner Entstehung haben beigetragen:
- 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>
+- Lutz Donnerhacke
+- Kristian Köhntopp
+- Rolf Krahl
+- Dirk Nimmich
+- Martin Recke
+- Thomas Roessler
+- Heiko Schlichting
+- Adrian Suter
+- Hans-Christoph Wirth
projects / faqs / dana-manual.git / blobdiff