Archive-name: de-newusers/dana-manual Posting-frequency: weekly 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 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 ====================================================================== 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 notwendi 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 zum Abruf bereit. 4. Gab es kürzlich einen ähnlichen Vorschlag? Viele regelmäßige Leser von de.admin.news.groups reagieren mit Unwillen, wenn Vorschläge, über die gerade erst in epischer Breite diskutiert und abgestimmt wurde, wieder vorgebracht werden. Es wird allgemein empfohlen, vor der Wiedervorlage eines abgelehnten Vorschlages eine Denkpause von mindestens sechs Monaten einzulegen. Ist man nach der Überprüfung dieser Punkte der Ansicht, daß eine neue Gruppe im allgemeinen Interesse liegt, sollte man sich nach Verbündeten umsehen: Es schadet nicht, wenn ein Vorschlag während der Diskussion von einer ganzen Reihe von Leuten, die an dem vorgeschlagenen Thema Interesse haben und später in der Gruppe posten würden, unterstützt wird. ---------------------------------------------------------------------- 3. Formulierung eines RfD 3.1. Aufbau Ein RfD für die Neueinrichtung einer Gruppe besteht aus einem Namensvorschlag für die Gruppe, dem Status der Gruppe (moderiert oder unmoderiert), einer zugehörigen Kurzbeschreibung und einer Charta. Als Grundlage für die Diskussion sollte ferner der Hintergrund des Vorschlags erläutert werden. In dieser Erläuterung sollte man insbesondere auf die oben genannten Punkte eingehen; andernfalls muß man damit rechnen, daß sie als "Standardfragen" in der Diskussion wieder auftauchen. Ein RfD sollte üblicherweise nur einen einzelnen Gruppenvorschlag behandeln - es verwirrt nur, wenn eine Gruppe über das Fortpflanzungsverhalten der Pflastersteine unter Berücksichtigung des besonderen Einflusses des Sonnenlichts im gleichen Thread diskutiert wird wie eine Gruppe, die dem Diskurs über die gesellschaftlichen Auswirkungen des Fernsehens dient. Eine Ausnahme von dieser Regel stellt die schon oben angesprochene Aufspaltung von Gruppen dar: Hier sollte man Sammel-RfDs und -CfVs veranstalten. Eine Sammelabstimmung ist so zu verfassen, daß jede Entscheidung auch einzeln zur Abstimmung kommen könnte. Eine Ausnahme gibt es bei der Aufteilung einer Gruppe: Die Umbenennung einer Gruppe in Gruppe.misc bei Annahme mindestens einer Untergruppe kann automatisch erfolgen. 3.2. Wahl des Gruppennamens Der Name besteht aus mehreren durch Punkte getrennten Segmenten. Die einzelnen Segmente dürfen nicht länger als 30 Zeichen werden und müssen mindestens je einen Buchstaben enthalten. Zu beachten ist dabei, daß sich unterschiedliche Segmentnamen auf gleicher Ebene schon vor dem 15. Zeichen unterscheiden müssen. Erlaubte Zeichen innerhalb eines Segments sind die Kleinbuchstaben (a-z), die arabischen Ziffern (0-9) sowie das Plus- (+) und das Minus-Zeichen (-). Der Name sollte so aussagekräftig wie möglich sein und sich dabei in die bestehende Namenshierarchie einpassen: de.alt ist eine Unterhierarchie, in der eigene Regeln gelten. Die Einrichtung von Gruppen in dieser Unterhierarchie wird hier nicht behandelt. de.admin beschäftigt sich mit der administrativen Seite des Usenet, also im wesentlichen mit dem Mail- und Newsaustausch im Netz und der Fortentwicklung der de-Newsgroups. de.comm dient der Diskussion über Kommunikation und Kommunikationstechnik. Diese Unterhierarchie hat eine noch weiter differenzierte Struktur: de.comm.anbieter.* ist Themen rund um Sprachtelekommunikationsanbietern zugedacht, während de.comm.provider.* die Anbieter von Internet und Internetdiensten meint; de.comm.geraete.* dient der Diskussion über die zur Kommunikation benötigten Geräte, de.comm.technik.* der über die dahinterliegende Technik; de.comm.infosystems.* behandelt Informationssysteme wie das World Wide Web (WWW), WAIS oder Hyper-G; de.comm.internet.* ist mit einigen Aspekten des Internets befaßt; de.comm.protocols.* beschäftigt sich mit Kommunikationsprotokollen und de.comm.software.* mit Kommunikationssoftware. de.comp dreht sich um Computer und alles, was damit zu tun hat. Auch diese Unterhierarchie ist weitergehend gegliedert: In de.comp.os.* wird über Betriebssysteme gesprochen, Hardware diskutiert man in de.comp.sys.* (Komplettsysteme) bzw. de.comp.hardware.* (Einzelteile), und Programmiersprachen als solche werden in de.comp.lang.* debattiert. Daneben gibt es noch de.comp.datenbanken.* für Datenbankmanagementsysteme, de.comp.office-pakete.* für integrierte Büroanwendungen und de.comp.text.* zum Diskutieren über Textformate und Texterzeuger. de.markt ist der Kleinanzeigenbereich des deutschsprachigen Usenet: Hier werden nicht-kommerzielle Angebote und Gesuche ausgetauscht. de.org dient verschiedenen "Organisationen" als Diskussionsforum. In de.admin.news.groups ist allerdings die Auffassung recht weit verbreitet, daß neue Gruppen nach Möglichkeit in themenspezifischen Unterhierarchien eingerichtet werden sollten (wie beispielsweise de.org.politik.spd). de.rec beschäftigt sich mit Freizeitaktivitäten aller Art. Unterhierarchien sind de.rec.spiele (Spiele aller Art), de.rec.music (Musik), de.rec.sport (Sport), de.rec.sf (Science Fiction), de.rec.tiere (die lieben Haustiere). Auch hier vertreten einige Teilnehmer von de.admin.news.groups die Ansicht, daß neue Gruppen möglichst nicht mehr direkt unter de.rec.* eingerichtet werden sollten, um die Übersichtlichkeit nicht zu gefährden. de.sci ist den Wissenschaften gewidmet, wobei bei der Einrichtung neuer Gruppen in dieser Hierarchie immer wieder Streit aufkommt, was denn überhaupt eine Wissenschaft sei. In der Praxis scheint sich bisher die Meinung durchgesetzt zu haben, daß die Lehrpläne von Universitäten im deutschsprachigen Raum einen ganz guten Überblick bieten. Direkt unterhalb von de.sci werden üblicherweise ganze Fachbereiche untergebracht. Einzelne Spezialgebiete haben dort nichts zu suchen; sie sollten als Untergruppen dem entsprechenden Fach zugeordnet werden (Beispiel: de.sci.medizin.allergie). de.soc handelt von gesellschaftlichen Dingen. de.talk dient dem gemütlichen Plausch über mehr oder minder Weltbewegendes. Von purem Unsinn (de.talk.bizarre) bis hin zu des Menschen wichtigster Nebensache (de.talk.liebesakt) ist alles vertreten. de.etc schließlich stellt das Auffangbecken dar, wenn ein Thema nicht in eine der anderen Unterhierarchien paßt. Man sollte außerdem versuchen, im Gruppennamen möglichst keine kryptischen oder mehrdeutigen Abkürzungen zu verwenden. Wenn diese gar nicht zu vermeiden sind, sollte man sie in der Kurzbeschreibung, spätestens aber in der Charta auflösen. 3.3. Die Kurzbeschreibung Die Kurzbeschreibung (oder auch Tagline) ist zum einen in den regelmäßigen Postings zu finden, die den Systemadministratoren helfen, die Auswahl der auf ihren Systemen bereitgehaltenen Gruppen auf dem neuesten Stand zu halten. Andererseits zeigen viele Newsprogramme diese Kurzbeschreibung auch an, um den Leser an das Thema der Gruppe zu erinnern und somit von Fehlpostings abzuhalten. Sie ist (neben dem Namen) häufig das erste, was ein potentieller Leser von einer Gruppe zu Gesicht bekommt. 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] (Moderated) | | Diskussionen sollen in der Gruppe | | [Gruppenname] [Kurzbeschreibung] | | gefuehrt werden. | | | Status | ------ | | Die Gruppe ist moderiert. Als Moderatoren werden Martina Oderat | und Peter Roponent | 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 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 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 | | | | Status: Die Gruppe ist {moderiert|unmoderiert}. | | 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 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 (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 (). | | | -=-=-=-=-=-= Alles vor dieser Zeile löschen =-=-=-=-=-=- | | Wahlschein fuer die {Einrichtung|Umbenennung|Entfernung} von | | | Dein Realname, falls nicht im From:-Header: | | Wenn Du keinen Real-Namen veröffentlicht haben willst, wende Dich | mit einer Begründung an | | [Deine Stimme] Abstimmungsgegenstand | ---------------------------------------------------------------------- | [ ] Einrichtung von | | -=-=-=-=-=-= 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 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: 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. 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. 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. 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 . RfD Request for Discussion, Aufruf zur Diskussion. Leitet die Diskussion um eine Entscheidung ein bzw. bringt sie wieder in Gang. 7.3. Maintainer und Danksagungen Maintainer dieser FAQ: Michael Ottenbruch Thomas Hochstein Maintainer bis 2010: Thomas Roessler, nach einem Entwurf von Dirk Nimmich Zu diesem Text und seiner Entstehung haben beigetragen: - Lutz Donnerhacke - Kristian Köhntopp - Rolf Krahl - Dirk Nimmich - Martin Recke - Thomas Roessler - Heiko Schlichting - Adrian Suter - Hans-Christoph Wirth