X-Git-Url: https://code.th-h.de/?p=faqs%2Fdana-manual.git;a=blobdiff_plain;f=dana-manual;h=465e4e397f25e01f9d8b896ac9d0b8e63cff3f45;hp=68f31b05a18abf66a89c5842c91a33e3c88ef3cf;hb=a653d2daf8b4cb2dfbee13ee09d59a9ad3ec580e;hpb=41cc15b81072c6c0a8cc04ffaa9773820a0b1179;ds=sidebyside diff --git a/dana-manual b/dana-manual index 68f31b0..465e4e3 100644 --- a/dana-manual +++ b/dana-manual @@ -1,738 +1,2071 @@ 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.2.4 +Last-modified: (unreleased) 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 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 +URL: https://th-h.de/archives/faqs/dana-manual.txt + + Erläuterungen zur Einrichtung neuer Gruppen in de.* + =================================================== + +Inhalt +------ + +0. Einleitung + 0.1. Zielgruppe und Inhalt + 0.2. Das Einrichtungsverfahren im Überblick + 0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens + 0.3.1. Vorbereitung + 0.3.2. Diskussionsphase + 0.3.3. Abstimmungsphase + 0.3.4. Umsetzung + +1. Vorüberlegungen + 1.1. Bedarf für eine neue Gruppe + 1.2. Status quo: bestehende Gruppen und frühere Vorschläge + 1.3. Mitinteressenten + +2. Einrichtungsvorschlag + 2.1. Auswahl des Gruppennamens + 2.1.1. Einordnung + 2.1.2. Namenswahl und technische Vorgaben + 2.2. Kurzbeschreibung + 2.3. Charta + 2.4. Status + 2.4.1. Pro und contra moderierte Gruppen + 2.4.2. Einrichtung moderierter Gruppen + 2.5. Sonderfälle + +3. Diskussionsphase + 3.1. Inhalt und Aufbau eines RfD + 3.1.1. Inhalt + 3.1.2. Formale Gestaltung + 3.2. Einreichung des RfD + 3.3. Diskussionsphase + 3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags + +4. Abstimmungsphase + 4.1. Voraussetzungen für die Durchführung einer Abstimmung + 4.2. Inhalt und Aufbau eines CfV + 4.3. Sonderfall: CfV mit persönlichem Wahlschein + 4.4. Abstimmungsphase + 4.5. Auswertung und Ergebnis der Abstimmung + +5. Verfahrensabschluss und Umsetzung + +6. Sonderfall: Vereinfachtes Verfahren (VV) + +7. Löschungen, Umbenennungen, Status- und Regeländerungen u.ä. + 7.1. Gruppenlöschungen + 7.2. Umbenennungen + 7.3. Änderungen von Charta und/oder Kurzbeschreibung + 7.4. Statusänderungen + 7.5. Regeländerungen und Personenwahlen + +8. Quellen + 8.1. Grundlegende Informationen + 8.2. Weiterführende Hinweise + 8.3. Webseiten + +9. Maintainer und Kontakt + 9.1. Derzeitige Maintainer + 9.2. Frühere Fassungen + +====================================================================== + +0. Einleitung +============= + +0.1. Zielgruppe und Inhalt +-------------------------- + +Dieser Text richtet sich an diejenigen, die eine Newsgroup in der +internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten +lassen wollen und soll die in den "REGELN FÜR DIE EINRICHTUNG UND +ENTFERNUNG VON USENET-GRUPPEN" [1] (kurz: Einrichtungsregeln) +niedergelegten Regeln zur Einrichtung neuer Gruppen kommentieren und +erläutern. Er gibt dabei notwendig den Blick der Autoren bzw. +Maintainer auf die Verhältnisse in de(.admin.news).* und ihre +Erfahrungen wieder. + +[1] Veröffentlicht in de.admin.infos: +| From: 3.14@piology.org (Boris 'pi' Piwinger) +| Newsgroups: de.admin.infos,de.alt.admin +| Subject: <2012-01-09> Einrichtung von Usenet-Gruppen in "de.*" +| +| Archive-name: de-admin/einrichtung +| Posting-frequency: weekly +| Last-modified: 2012-01-09 +| URL: http://www.kirchwitz.de/~amk/dai/einrichtung + +(Eine Liste aller in diesen Erläuterungen genannten Quellen findet +sich noch einmal in Abschnitt 8.) + +Dieser Text bezieht sich nicht auf die Einrichtung von Gruppen in der +Unterhierarchie de.alt.* (vgl. Anhang A zu den Einrichtungsregeln). +Dort wird eine Gruppe in de.alt.admin vorgeschlagen. Ergibt die +nachfolgende, mindestens einwöchige Diskussion keinen gar zu heftigen +Gegenwind, wird die Gruppe eingerichtet. + +0.2. Das Einrichtungsverfahren im Überblick +------------------------------------------- + +Newsgroups werden nicht auf einem zentralen Server angeboten, sondern +dezentral auf vielen verschiedenen Newsservern geführt, die ihre +Beiträge jeweils untereinander austauschen. Damit das funktionieren +kann und jeder Benutzer dieselben Newsgroups zur Verfügung hat, müssen +sich die Betreiber dieser Vielzahl von Newsservern nach Möglichkeit +auf einen einheitlichen Bestand an Gruppen einigen. Das ist bei +mehreren tausend Newsservern mit manchmal wenigen, manchmal aber auch +Tausenden Benutzern durch Diskussionen im Einzelfall nicht praktikabel +möglich. Daher werden für gepflegte Newsgroups-Hierarchien wie de.* +Listen der Newsgroups geführt, die zur Hierarchie gehören; mit dieser +Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand +abgleichen. + +Für de.* wird die kanonische Liste der bestehenden Newsgroups von der +Moderation von de.admin.news.announce geführt, die jeden Monat auch +eine entsprechende, digital signierte Steuernachricht (checkgroups) +versendet, mit der die meisten Newsserverbetreiber ihren +Gruppenbestand automatisch ohne manuellen Eingriff abgleichen lassen. +Für die Aufstellung dieser Liste sind vielerlei Möglichkeiten denkbar; +in de.* entscheiden die Benutzer über ihren Inhalt. Änderungen am +Gruppenbestand - Neueinrichtung, Löschung oder Umbenennung von Gruppen +- werden in einem formalisierten Verfahren diskutiert und dann zur +Abstimmung gestellt. + +Jedem Einrichtungsvorschlag sollte eine Überlegungsphase vorangehen, +in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung, +Status, Charta) einschließlich ihrer Einordnung in den bestehenden, +hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch +mit anderen Interessenten diskutiert werden können. Am Ende dieser +Vorüberlegungen steht dann zumeist ein erster Vorschlag, wie die neue +Gruppe heißen soll, was ihre Inhalte sein werden und wie sie sich +thematisch gegenüber bestehenden Gruppen abgrenzt. Mit der +Veröffentlichung dieses Vorschlags in de.admin.news.announce als +Diskussionsaufruf ("Request for Discussion", kurz "RfD") beginnt das +Einrichtungsverfahren mit der Diskussionsphase. In dieser Diskussion, +die in de.admin.news.groups geführt wird, wird der Vorschlag auf +inhaltliche Qualität und Akzeptanz abgeklopft und ggf. verändert oder +verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der +Vorschlag abstimmungsreif erscheint. Die Veröffentlichung eines +Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die +Diskussionsphase und leitet in die Abstimmungsphase über, an deren +Ende sich zeigt, ob der Vorschlag zur Einrichtung der neuen Gruppe +angenommen oder abgelehnt wurde. Dementsprechend wird die Gruppe dann +in die Gruppenliste aufgenommen - oder auch nicht. + +Siehe auch: + ++ Wichtige Begriffe in de.admin.news.* (dan-Glossar) +| From: thh@inter.net (Thomas Hochstein) +| Newsgroups: de.admin.infos +| Subject: <2017-07-29> Wichtige Begriffe in de.admin.news.* +| +| Archive-name: de-admin/dan-glossar +| Posting-frequency: weekly +| Version: 1.5.2 +| Last-modified: 2017-07-29 +| URL: https://th-h.de/archives/faqs/dan-glossar.txt +| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar + + +0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens +---------------------------------------------------------- + +Das Einrichtungsverfahren lässt sich in folgende Phasen unterteilen, +die im Folgenden dann näher erläutert werden sollen: + +0.3.1. Vorbereitung + +* Ideenfindung +* Information über den status quo, Bedarfsabschätzung +* Suche nach anderen Interessierten, ggf. interne Diskussion +* Ausformulierung eines förmlichen Einrichtungsvorschlag (RfD) +* Einreichung des RfD bei der Moderation von de.admin.news.announce + +Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent") +enden die Vorbereitungen; das Verfahren wird in die Statusübersicht +der Moderation von de.admin.news.announce [2] aufgenommen und erhält +einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer prüft +den RfD (und die weiteren Verfahrensbeiträge) auf Vereinbarkeit mit +den Regeln, nimmt die nötigen Veröffentlichungen in +de.admin.news.announce vor und steht dem Proponenten auch als +Ansprechpartner (und in gewissem Umfang Berater) für sich im Verlauf +des Verfahrens ergebende Fragen zur Verfügung. + +[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem + Betreff "dana-Status" wöchentlich in de.admin.news.announce + veröffentlicht und im WWW unter + abrufbar. + +0.3.2. Diskussionsphase + +* Beginn mit Veröffentlichung des 1. RfD in de.admin.news.announce, + de.admin.news.groups und weiteren betroffenen Newsgroups +* öffentliche Diskussion des Vorschlags in de.admin.news.groups +* Mindestdauer: 14 Tage +* Einreichung beliebig vieler weiterer RfDs mit geänderten Vorschlägen + +Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung +der übrigen Teilnehmer zu ergründen; Änderungsvorschläge können +gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3. +RfD usw.) aufgenommen werden. Wenn alle Facetten erörtert, alle +Argumente ausgetauscht sind oder die Diskussion sich im Kreis zu +drehen beginnt, muss der Proponent sich entscheiden, ob sein Vorschlag +Aussicht auf Erfolg hat und er ihn zur Abstimmung stellen möchte oder +ob er den Vorschlag zurückzieht. Die zur Abstimmung gestellte Fassung +muss mit dem letzten veröffentlichen RfD im Wesentlichen +übereinstimmen. + +Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch +Rückzug des Vorschlags oder Verfall durch Nichtbetreiben über fünf +Wochen) oder der Veröffentlichung des 1. CfVs. + +0.3.3. Abstimmungsphase + +* Beginn mit Veröffentlichung des 1. CfV in de.admin.news.announce und + den übrigen Gruppen +* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per + E-Mail bestätigt +* Mindestdauer: 3 Wochen, Höchstdauer: 1 Monat (~ 4 Wochen) +* in der Regel Einreichung eines 2. CfV zur "Halbzeit" +* Einreichung des Ergebnisses mit Namen und Stimmabgaben der + Abstimmenden +* einwöchige Einspruchsfrist + +Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker") +durchgeführt, der die CfVs zur Veröffentlichung einreicht, die +Stimmen per E-Mail sammelt, bestätigt und auszählt und am Ende das +Ergebnis der Abstimmung zur Veröffentlichung einreicht. Diese Aufgabe +kann der Proponent übernehmen, er muss es aber nicht; da die +Durchführung und Auszählung einer Abstimmung einen gewissen +technischen und organisatorischen Aufwand erfordert und auch Erfahrung +im Umgang mit Zweifelsfällen - auch Manipulationsversuchen - +wünschenswert ist, besteht die Möglichkeit, einen erfahrenen +Usenet-Teilnehmer um die Übernahme der Abstimmungsleitung zu bitten. +Einige Freiwillige haben sich zu diesem Zweck als "German Volunteer +Votetakers" (GVV) zusammengeschlossen. + +Die Abstimmungsphase endet mit dem Ablauf des Abstimmungszeitraums und +letztlich mit der Veröffentlichung des Ergebnisses. Daran schließt +sich ein einwöchiger Einspruchszeitraum an, in dem Regelverstöße durch +einen Einspruch bemängelt werden können. Nach Verstreichen dieses +Zeitraums wird das Ergebnis der Abstimmung bestandskräftig. + +0.3.4. Umsetzung + +Wenn der Vorschlag in der Abstimmung angenommen wurde - wozu +mindestens 50 Stimmen JA-Stimmen und zugleich eine Mehrheit von 2/3 +der abgegebenen gültigen Stimmen ohne die Enthaltungen, also +mindestens doppelt so viele JA- wie NEIN-Stimmen erforderlich sind -, +wird das Ergebnis im Anschluss durch die Moderation von +de.admin.news.announce umgesetzt, indem eine Steuernachricht zur +Einrichtung der betreffenden Gruppe versandt und diese in die +kanonische Liste der in de.* vorhandenen Newsgroups aufgenommen wird. + +1. Vorüberlegungen +================== + +1.1. Bedarf für eine neue Gruppe +-------------------------------- + +Ganz am Anfang der Überlegungen zur Einrichtung einer neuen Newsgroup +stellt sich zunächst die Frage, ob die angedachte Gruppe denn auch +tatsächlich benötigt wird und der Vorschlag Aussicht auf Erfolg hat. +Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden +zukünftigen Nutzung der Gruppe zu rechnen ist, das Thema also im +Usenet diskutiert werden wird und eine thematisch passende Gruppe +entweder nicht vorhanden ist oder bereits so rege genutzt wird, dass +sie überfüllt ist. + +Die zukünftige Nutzungsintensität der vorgeschlagenen Gruppe wird +dabei regelmäßig anhand der derzeitigen Lage beurteilt: + +* Gibt es bereits Diskussionen zu dem Thema im Usenet? + +* Wenn ja: Ist die bisher dafür genutzte Gruppe überfüllt (so dass man + dieses Thema aus ihr abspalten sollte) oder gibt es bislang gar + keine Gruppe, in der man das Thema sinnvoll diskutieren kann? + Letzteres ist sehr selten, da de.* thematisch vollständig ist; die + meisten denkbaren Themen passen in eine oder mehrere bereits + bestehende Gruppen thematisch hinein. + + Sind die derzeitigen Diskussionsteilnehmer bereit, zukünftig die neu + einzurichtende Gruppe zu benutzen (oder wünschen dies sogar)? + +* Wenn nein: Finden anderswo im Netz Diskussionen statt, bspw. in + anderen deutschsprachigen Usenet-Hierarchien, in Mailinglisten, + Webforen, Communities in sozialen Netzwerken? + + Und sind die Diskutanten bereit, statt des bisher genutzten Mediums + oder zusätzlich zu diesem auch das Usenet als Diskussionsmedium zu + benutzen? + +* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe + zukünftig einigermaßen intensiven Zuspruch erfahren wird? + +Die Erfahrung hat gezeigt, dass die empfundene oder tatsächliche +gesellschaftliche oder anderweitige Wichtigkeit eines Themas nichts +damit zu tun hat, ob und wie intensiv Menschen es diskutieren wollen +und ob sie dies im Usenet tun möchten. Es mag sehr wichtige Themen +geben, zu denen aber dennoch entweder kein Diskussionsbedarf besteht +oder die anderswo diskutiert werden, ohne dass bei den Interessenten +der Wunsch besteht, ihre Diskussionen im Usenet zu führen. Die +mehrheitliche Ansicht geht überdies dahin, dass es nicht sinnvoll ist, +für "Orchideenthemen" eigene Newsgroups einzurichten, die dann +(weitgehend) ungenutzt bleiben; vielmehr wird es überwiegend als +wünschenswert empfunden, lieber weniger thematisch breiter +aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und +auf diese Weise den gegenseitigen Austausch beleben und fördern. + +Siehe auch: + ++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen? + + ++ Missverstaendnisse in de.admin.news.groups +| From: 3.14@piology.org (Boris 'pi' Piwinger) +| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin +| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups +| +| Archive-name: de-admin/dang-faq +| Posting-frequency: weekly +| Last-modified: 2009-01-24 +| URL: http://www.kirchwitz.de/~amk/dai/dang-faq + +1.2. Status quo: bestehende Gruppen und frühere Vorschläge +---------------------------------------------------------- + +Die Frage nach dem Bedarf an einer neuen Gruppe führt zur Feststellung +und Beurteilung des status quo: Welche thematisch verwandten Gruppen +gibt es? Wo sind diese in der Struktur von de.* eingeordnet? Wie +intensiv werden sie genutzt? Wie lässt sich das Thema der neuen Gruppe +von den bestehenden themenverwandten Gruppen abgrenzen? + +Es empfiehlt sich auch, in Archiven [3] nachzuforschen, ob +möglicherweise eine vergleichbare Gruppe bereits einmal vorgeschlagen +wurde und wie Verlauf und Ergebnis der Diskussion (und ggf. +Abstimmung) sich darstellen. Vielleicht gab es auch bereits einmal +eine solche Gruppe, die dann später wieder aus der Gruppenliste +entfernt wurde? Aus diesen Überlegungen ergeben sich Hinweise auf die +Erfolgsaussichten des Vorschlags und möglicherweise auch Anregungen +für seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten +Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne +wesentliche Änderungen in Inhalt oder Begründung erneut einzubringen. + +[3] Am bekanntesten dürfte das Angebot von Google Groups sein: + + + de.admin.news.announce bei Google Groups: + + +1.3. Mitinteressenten +--------------------- + + "Gemeinsam sind wir stark." + +In der Diskussionsphase kommt es weniger auf die Anzahl der +Befürworter als vielmehr auf deren Argumente an. Dennoch hilft es, +einen Vorschlag nicht ganz alleine einzubringen, insbesondere dann, +wenn man mit dem Procedere in de.admin.news.* noch nicht so vertraut +ist. Soll der Vorschlag erfolgversprechend sein, wird es ja eine ganze +Reihe von anderen Interessenten an der vorgeschlagenen neuen Gruppe +geben. Deren Input ist schon bei der Formulierung des Vorschlags +hilfreich; Brainstorming und Diskussion mehrerer führt oft zu besseren +Ergebnissen als einsames Grübeln im stillen Kämmerlein. + +Auch in der Diskussion ist es förderlich, einen Vorschlag nicht +alleine argumentativ zu stützen; nicht nur deshalb, weil eine Mehrzahl +von Interessenten, die sich auch selbst in die Diskussion einbringt, +überzeugender ein dauerhaftes Interesse signalisiert als ein +Einzelner. Auch aus psychologischen Gründen ist es angenehmer, die +eigene Position nicht alleine vertreten zu müssen. + +Eine Mitwirkung anderer Interessenten kann dabei auf vielfältige Weise +erfolgen. Ein Vorschlag kann durch mehrere Proponenten eingebracht +werden; die Mitwirkung kann sich aber auch auf Unterstützung bei +inhaltlichen und Formulierungsfragen oder der formalen Abwicklung des +Einrichtungsverfahrens oder Beiträge in der Diskussionsphase +beschränken. + +2. Einrichtungsvorschlag +======================== + +Vor der Einrichtung einer neuen Newsgroup oder dem Beginn der +Abstimmung über den entsprechenden Vorschlag müssen nach den +Einrichtungsregeln Name und Attribute der vorgeschlagenen Gruppe +feststehen: + +| Ein CfV kann nicht veröffentlicht werden, wenn einer der folgenden +| Punkte noch unklar ist: +| +| o Name der Gruppe +| o Kurzbeschreibung der Gruppe +| o Charta der Gruppe +| o Status der Gruppe (moderiert oder unmoderiert) +| o der Name des Moderators im Falle einer moderierten Gruppe + +Newsgroups innerhalb einer gepflegten Hierarchie existieren nicht im +luftleeren Raum. Im Zusammenhang mit der Auswahl des Namens stellt +sich daher auch die Frage nach der Einordnung der neuen Gruppe in die +bestehende Struktur der Hierarchie de.*, und in der Charta sollte +nicht nur die Beschreibung des vorgesehenen Themenkreises, sondern +auch die Abgrenzung zu thematisch ähnlichen Gruppen ihren Platz +finden. + +Sinnvoll ist es daher, sich zunächst Gedanken über das geplante Thema +der Gruppe und dessen Abgrenzung zu bereits bestehenden Gruppen zu +machen; daraus ergibt sich die Charta (2.3.). Danach sollte man sich +überlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie +demnach heißen soll (2.1.); dann fehlt nur noch eine knackige +Zusammenfassung für die Kurzbeschreibung (2.2.). + +Falls eine moderierte Newsgroup vorgeschlagen wird, müssen auch der +oder die vorgesehenen Moderatoren feststehen; überdies sollte ein +Konzept für die Moderation vorliegen und die technischen +Voraussetzungen hinreichend geklärt sein. + +2.1. Auswahl des Gruppennamens +------------------------------ + +2.1.1. Einordnung + +Zunächst sollte die prospektive Gruppe sich in die bestehende +Namenshierarchie in de.* einpassen. de.* besteht nämlich aus +thematisch orientierten Teilhierarchien, die eine Baumstruktur mit +immer feineren thematischen Verästelungen aufweisen. Diese Struktur +ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollständig +logisch stringent, und regelmäßig wird es nicht nur einen denkbaren +Platz geben, an den eine neue Gruppe passen würde. + +Man sollte sich bei seinem Namensvorschlag aber nichtsdestotrotz +bemühen, den bestmöglichen Ort für die neue Gruppe zu finden. Dazu +gehört sowohl die Einordnung in die - nach dem Themenschwerpunkt - am +ehesten passende Unterhierachie und die Wahl der richtigen Ebene. Ein +sehr spezielles Thema sollte im Themenbaum nicht zu weit oben +angesiedelt sein, ein sehr allgemeines Thema nicht zu tief. + +Mit Ausnahme von de.alt.*, das sich (nur) durch besondere +Einrichtungsregeln auszeichnet und daher nicht Thema dieser +Erläuterungen ist, bestehen in de.* folgende thematische +Untergliederungen: + +* de.admin.* + Die Gruppen der de.admin-Unterhierarchie befassen sich thematisch + mit der Selbstverwaltung von de.* und organisatorischen (nicht + technischen) Fragen der Administration von Usenet-Systemen, + namentlich auch mit deren Missbrauch. + +* de.comm.* + Die Gruppen der de.comm-Unterhierarchie beschäftigen sich mit den + - im Usenet umfänglich vertretenen - Themenbereichen der + Kommunikation und Kommunikationstechnik und sind daher noch weiter + diversifiziert, im Wesentlichen in die Bereiche + + * Anbieter: + de.comm.provider.* - Telefonie- und Internetanbieter sowie Onlinedienste + + * Geräte (Hardware) und Technik: + de.comm.geraete.* - Festnetz- und Mobiltelefone und Telefonanlagen + de.comm.technik.* - Netztechnik (DSL, ISDN, Mobilfunknetze) + de.comm.internet.* - Infrastrukturaspekte des Internet + de.comm.protocols.* - Kommunikationsprotokolle + + * Software: + de.comm.software.* - Browser, Mail-/Newsreader und -server etc. + + und schließlich: + de.comm.infosystems.* - WWW samt Webseitenerstellung + de.comm.funk.* - Funk (Amateurfunk, CB-Funk, Vereine, ...) + +* de.comp.* + Diese Unterhierarchie deckt den Rest der Themen zur Computertechnik + ab: Hardware (Computer wie Peripherie), Software (Betriebssysteme, + Anwendungsprogramme, etc.), Programmiersprachen und was sonst noch + so dazugehört. Auch sie ist demnach umfangreich weiter + untergliedert, neben verschiedenen Einzelgruppen namentlich in + + * Hardware: + de.comp.sys.* - Komplettsysteme (Mac, ...), Notebooks, Handhelds + de.comp.hardware.* - Rechner, Laufwerke, Monitore, Netzwerk + + * Betriebssysteme, Anwendungsprogramme und andere Software: + de.comp.os.* - Windows, Unix, Linux, OS/2, + de.comp.office-pakete.* - MS-Office, Staroffice + de.comp.text.* - Textverarbeitung + de.comp.datenbanken.* - Datenbanken + de.comp.lang.* - Programmiersprachen (C++, Java, Perl, PHP, ...) + +* de.rec.* + Die Unterhierarchie de.rec.* beschäftigt sich mit + Freizeitaktivitäten ("recreational activities") aller Art und + enthält neben einer Vielzahl von Einzelgruppen u.a. Unterhierarchien + zu den Themen Musik hören und machen, Sport(arten), Spielen aller + Art, am Brett wie am Computer, Science Fiction und Fantasy, + Fernseh(seri)en, Filme und Heimkino und (Haus-)Tiere. + +* de.sci.* + Die Unterhierarchie de.sci.* ist für wissenschaftliche Themen + ("sciences") vorgesehen und ist vorwiegend anhand der klassischen + wissenschaftlichen Themengebiete (Biologie, Chemie, Physik, + Mathematik, Medizin, etc. pp.) unterteilt. Teilweise sind aber + Themen gerade aus dem gesellschafts- oder sozialwissenschaftlichen + Bereich auch in de.soc.* angesiedelt. + +* de.soc.* + Die Unterhierarchie de.soc.* handelt von gesellschaftlichen Fragen + ("social issues"): Politik und Rechtswesen; Religionen und + Weltanschauungen; Kulturen und Subkulturen; Familie, + Gleichberechtigung, Senioren, Jugendarbeit, Schule und Studium; + Arbeit und Arbeitslosigkeit; Umwelt und Verkehr; Medien und + Wirtschaft; Datenschutz und Zensur. + +* de.talk.* + Die - sehr kleine - Unterhierarchie de.talk.* ist mehr für Smalltalk + und entspannten Plausch als Diskussion und Informationsaustausch + vorgesehen; viele der verbliebenen Gruppen würden aber ebenso gut + nach de.soc.* passen. + +* de.org.* + Die - gleichfalls kleine - Teilhierarchie de.org.* ist für + Organisationen und Vereine, deren Verlautbarungen und Diskussionen + um sie herum gedacht. Verblieben sind hier im Wesentlichen + Newsgroups zum CCC, zu Mensa und der SPD (bzw. politischen Parteien + allgemein). + +* de.etc.* + In der de.etc.*-Unterhierarchie sind sonstige Themen + zusammengefasst, die nicht in eine der anderen Unterhierarchien + passen. Dazu gehören das Bahnwesen, Autos und andere Fahrzeuge, + Finanzen und Banking, (kreatives) Schreiben und Sprache, Post, + Notfallrettung und Militärwesen oder auch die Haushaltsführung. + +* de.markt.* + In de.markt.*, dem Kleinanzeigenbereich des deutschsprachigen + Usenets, - und nur hier! - haben private, nicht-kommerzielle + Angebote und Gesuche Platz. + +Siehe auch: + ++ Die Newsgruppen der de-Hierarchie +| From: Daniel Roth <25.8@bluemail.ch> +| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin +| Subject: Die Newsgruppen der de-Hierarchie +| +| Archive-name: de-newusers/de-newsgruppen +| Posting-frequency: weekly +| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen + +2.1.2. Namenswahl und technische Vorgaben + +Der "eigentliche" Name der Gruppe, insbesondere also der letzte +Namensbestandteil, sollte so aussagekräftig und allgemeinverständlich, +aber zugleich auch so kurz wie möglich gewählt werden. Kryptische oder +mehrdeutige Abkürzungen sollte man möglichst nicht verwenden. Wenn +diese gar nicht zu vermeiden sind, sollten sie in der +Kurzbeschreibung, spätestens aber in der Charta erläutert werden. + +Für die Wahl des Gruppennamens sind zudem technisch geprägte +Vorgaben [4] zu beachten, die sich auch im WWW unter + 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 - (-). - - 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] (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. - - 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 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. 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 - im WWW finden. Anfragen - sollten aber an die Sammeladresse geschickt werden. - + dabei, dass sich unterschiedliche Segmentnamen auf gleicher Ebene + schon vor dem 15. Zeichen unterscheiden müssen. + +* Erlaubte Zeichen innerhalb eines Segments sind die Kleinbuchstaben + (a-z), die arabischen Ziffern (0-9) sowie das Plus- (+) und das + Minus-Zeichen (-). + +* Insgesamt soll die Länge des Gruppennamens 71 Zeichen nicht + überschreiten. + +[4] Beschlossen im Jahr 2000: +| From: "Christian Schulz - GVV" +| 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: + + +2.2. Kurzbeschreibung +--------------------- + +Die Kurzbeschreibung soll in Ergänzung zum Gruppennamen das Thema kurz +umreißen. Im Gegensatz zur Charta, der ausführlichen thematischen +Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit +dem Gruppennamen auf den Newsservern vorgehalten und kann in den +gängigen Newsreadern angezeigt und ggf. auch durchsucht werden; +Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline" +genannt. Diese Tagline ist auch Bestandteil der regelmäßig versandten +Steuernachrichten, die den aktuellen Gruppenbestand von de.* +enthalten. + +Daraus leiten sich mehrere Bedingungen an eine gute Kurzbeschreibung +ab: Sie muss kurz, knapp und für jeden verständlich sein. "Diskussion +über" oder "Informationen von" sind zum Beispiel notorisch +überflüssige Formulierungen. Hingegen sollten möglichst Begriffe in +der Kurzbeschreibung auftauchen, nach denen an der Gruppe +interessierte Nutzer möglicherweise suchen werden. Da die +Kurzbeschreibung in Gruppenlisten auftaucht (auch in solchen, die von +Newsreadern angezeigt werden), die meist auf 80 Spalten breiten +Terminals gelesen werden, ergibt sich eine Beschränkung für die Länge +der Kurzbeschreibung: Gruppenname, ein 8er-Tabulator und +Kurzbeschreibung sollten in weniger als 80 Zeichen passen. Als +Richtwert gilt für die Kurzbeschreibung gewöhnlich eine Maximallänge +von 60 Zeichen. + +Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze +Kurzbeschreibung anzeigen, wird er sich üblicherweise auf den Anfang +der Kurzbeschreibung beschränken. Daraus folgt, dass die wichtigsten +Punkte in einer Kurzbeschreibung an deren Anfang stehen sollten. Um +Komplikationen zu vermeiden, sollten Kurzbeschreibungen keine Umlaute +und sonstige Sonderzeichen enthalten; der Zeichenvorrat ist +"US-ASCII". Per Konvention endet jede Kurzbeschreibung mit einem +Satzendezeichen (Punkt, Frage- oder Ausrufezeichen). + +Beispiele für Kurzbeschreibungen finden sich in dem bereits genannten +Text "Die Newsgruppen der de-Hierarchie". + +2.3. Charta +----------- + +Die Charta ist die Beschreibung der Newsgroup und ihres vorgesehenen +Themas schlechthin. Sie soll so kurz wie möglich und nur so +ausführlich wie nötig umreißen, worum es in der Gruppe geht, welche +Themen dort diskutiert werden sollen und welche ggf. nicht und welche +besonderen Konventionen dort - unter Abweichung von den sonstigen +Üblichkeiten im deutschsprachigen Usenet - gelten sollen. + +Es ist hilfreich, für das Thema der Gruppe einige Beispiele als nicht +abschließende Aufzählung aufzunehmen; so lassen sich auch (weitere) +Schlagworte unterbringen, nach denen möglicherweise gesucht wird. +Dabei ist aber zu berücksichtigen, dass die Charta nur in +entsprechenden Listen im Usenet und auch im WWW veröffentlicht wird, +aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im +Newsreader zur Verfügung steht. + +Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht +diskutiert werden sollen, obwohl möglicherweise Name und +Kurzbeschreibung bei flüchtiger Durchsicht zu dieser Annahme führen +könnten, empfiehlt es sich, diese Facetten - oder Themen - in der +Charta ausdrücklich auszuschließen. Genauso sollte innerhalb der +Charta das Diskussionsthema von anderen, themenverwandten Gruppen +abgegrenzt werden; diese Gruppen namentlich zu nennen ist allerdings +nicht tunlich, weil ansonsten bei jeder Umbenennung oder Löschung der +betreffenden Gruppen eine Chartaänderung nötig würde (siehe 7.3.). + +Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen +gelten sollen als sonst im Netz üblich sollte auch dies in der Charta +vermerkt werden. Zu denken wäre bspw. an die (ausdrückliche) Akzeptanz +anonymer Beiträge oder von Inseraten. Gleichfalls sollten vorgesehene +ungewohnte technische Maßnahmen - zu denken wäre hier bspw. an die +Eingangsbestätigung von Postings per E-Mail durch die sog. Reflektoren +in den Testgruppen - durch die Charta legitimiert werden. In allen +diesen Fällen sollte einerseits berücksichtigt werden, dass eine +Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta +in der Regel ausdrücklich abgelehnt wird, sowohl wegen der unnötigen +Verlängerung der Charta als auch, weil dies den Eindruck vermitteln +könnte, die entsprechenden Regeln und Konventionen hätten nur dort +Geltung, wo sie ausdrücklich in der Charta stehen. Andererseits darf +man bei der Formulierung solcher abweichenden Üblichkeiten nicht aus +den Augen verlieren, dass sowohl technische als auch soziale Vorgaben +in der Regel gute Gründe haben und zudem als feststehende Gewohnheiten +betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut +begründeten Sonderfällen Aussicht auf Erfolg haben werden. + +Die Charta sollte so knapp wie möglich gehalten werden; weitergehende +Erläuterungen und solche Regeln, die sich voraussichtlich häufiger +ändern werden, gehören nicht in die Charta, sondern sollten Gegenstand +einer (regelmäßig geposteten und nach Möglichkeit auch im WWW +bereitgestellten) Einführung, eines Infopostings oder einer FAQ sein. +So sollte bspw. die thematische Kennzeichnung von Unterthemen im +Betreff von Postings durch sog. Tags ("[Reisebericht] Meine Tour durch +Tadschikistan") in der Charta allenfalls generelle Erwähnung finden; +die einzelnen angedachten Tags gehören dann in eine anderweitig +bereitgestellte Erläuterung. Auch das Moderationskonzept einer +moderierten Gruppe gehört schon aufgrund seiner Länge nicht in die +Charta. + +Es empfiehlt sich, einige bestehende Chartas - insbesondere solcher +Gruppen, die in den letzten 5-10 Jahren eingerichtet wurden - zu +studieren, um ein Gefühl für die Abfassung einer guten Charta zu +bekommen. Solche Beispiele finden sich in dem bereits genannten Text +"Die Newsgruppen der de-Hierarchie". + +2.4. Status +----------- + +Eine Newsgroup kann entweder den Status "unmoderiert" oder den Status +"moderiert" haben. Ersteres ist der Regelfall; alle Postings werden +dann ohne weiteres in der Newsgroup veröffentlicht und weltweit +verbreitet. Bei einer moderierten Gruppe ist dies nicht der Fall; +stattdessen versendet der Newsserver, bei dem das Posting eingespeist +wird, dieses per E-Mail an einen Moderator (oder in der Regel eine +mehrköpfige Moderation). Diese entscheidet dann über die +Veröffentlichung. + +2.4.1. Pro und contra moderierte Gruppen + +Moderierte Gruppen haben den Vorteil einer meist besseren +Übersichtlichkeit und höheren inhaltlichen Qualität, weil Beiträge +vorgefiltert werden können; ihr Nachteil ist die zwangsläufig +entstehende Verzögerung durch die Weiterleitung jedes Beitrags an +einen Moderator, der ihn bestätigen muss. Sie eignen sich daher vor +allem für Ankündigungen oder FAQs. Ein Beispiel hierfür ist +de.admin.news.announce, wo nur Aufrufe zu Diskussionen und +Abstimmungen veröffentlicht werden, so dass die Gruppe auch für +diejenigen lesbar bleibt, die nicht die Zeit haben, den Diskussionen +im einzelnen zu folgen, und eine vorherige Überprüfung der +Veröffentlichungen sichergestellt ist. Ein anderes Beispiel stellen +die Gruppen de.newusers.infos, de.admin.infos und de.answers dar, in +denen nur FAQs und Infotexte veröffentlicht werden. + +Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der +Erhaltung einer höheren inhaltlichen Qualität dienen und ermöglicht +vor allem den Ausschluss von bewussten Störern, begegnet im Gegenzug +aber oft dem Vorwurf der Zensur, so unbegründet dieser im Einzelfall +auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden +Verzögerungen vor Veröffentlichung eines Beitrags den Fluss der +Diskussion stören und an Veröffentlichung ihrer Beiträge in Echtzeit +gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor +allem personelle Aufwand nicht zu unterschätzen; immerhin bedeutet die +Moderation einer Diskussionsgruppe, dass auf Jahre hinaus eine +Einzelperson oder Gruppe im Extremfall 24 Stunden am Tag und 7 Tage in +der Woche erreichbar sein muss, um eingehende Beiträge so zeitnah wie +möglich zu prüfen und freizugeben. + +2.4.2. Einrichtung moderierter Gruppen + +Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind +im Einrichtungsverfahren zusätzliche Angaben zur Moderation zu machen; +dazu gehören der oder die vorgesehene(n) Moderator(en) und die +Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen +für die Newsgroup zur Freigabe weitergeleitet werden sollen. Außerdem +muss die Kurzbeschreibung entsprechend ergänzt werden. Schließlich +sollte für die Durchführung der Moderation sinnvollerweise ein Konzept +vorliegen und die technischen Voraussetzungen geschaffen und getestet +sein. + +* Als erstes stellt sich die Frage, wer zur Moderation der Gruppe + vorgesehen ist. Mindestens ein Kandidat sollte bereits bei der + Veröffentlichung des Vorschlags seine entsprechende Bereitschaft + erklärt haben; in der Regel wird es sich empfehlen, ein mehrköpfiges + Team oder zumindest einen oder mehrere Vertreter zu benennen, damit + auch im Falle eines mehrwöchigen Urlaubs oder gar eines dauerhaften + Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr + interessiert sein mag - die Moderation handlungsfähig bleibt und + Beiträge weiterhin veröffentlicht werden können. Für moderierte + Diskussionsgruppen wird regelmäßig ein ausreichend großes Team + zwingend vorzusehen sein, damit Beiträge zumindest tagsüber zeitnah + veröffentlicht werden können. + + Der oder die vorgesehene(n) Moderator(en) sollte ausreichende + Kenntnisse zum geplanten Thema der moderierten Gruppe haben, um + Einreichungen bewerten zu können, von den zu erwartenden + Diskussionsteilnehmern akzeptiert werden und schließlich absehbar + für längere Zeit für diese Tätigkeit zur Verfügung stehen. Erfahrung + im Usenet und ggf. die notwendigen technischen Kenntnisse zur + Durchführung der Moderation sind hilfreich. + +* Wenn die (erste) Moderation personell feststeht, stellt sich als + nächstes die Frage, welche E-Mail-Adresse für Einreichungen + ("Submissionen") vorgesehen ist. Diese Adresse muss entweder weltweit + in jedem Newsserver oder an einer zentralen Stelle (den Relays für + moderators.isc.org) in der Konfiguration vermerkt werden, sollte + sich also so selten wie möglich ändern; außerdem sollte die Adresse + zuverlässig erreichbar sein und ggf. die Möglichkeit für + ausreichende Spamfilterung bieten; langjährig aktive und regelmäßig + veröffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an + Spam an. + + Daneben sollte eine weitere Adresse veröffentlicht werden, über die + der Moderator oder die Moderation kontaktiert werden können, ohne + dass eine Veröffentlichung erfolgt, um bspw. für Anfragen erreichbar + sein. + +* Die Kurzbeschreibung der Gruppe (2.2.) muss im Falle einer moderierten + Gruppe zwingend mit der Submissionsadresse und dem Schlüsselwort + "(Moderated)" in exakt dieser Schreibweise enden, bspw. so: +| de.gruppe.mod Moderierte Gruppe. (Moderated) + +* Falls die zu moderierende Gruppe keine Diskussionsgruppe ist, + sondern nur Ankündigungen, FAQs o.ä. enthalten soll, sollte eine + Gruppe bestimmt werden, in der diese Ankündigungen oder FAQs + anschließend ggf. diskutiert werden können und in die Antworten dann + per gesetztem Followup-To:-Header geleitet werden. + +* Die Moderation einer Gruppe sollte sich ein Konzept geben, nach + welchen Kriterien Beiträge akzeptiert oder zurückgewiesen werden, ob + sie ggf. verändert veröffentlicht werden können und wie mit + Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer + mehrköpfigen Moderation stellt dies eine einheitliche Handhabung + sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt + werden und danach (regelmäßig) veröffentlicht werden. + + Entsprechende Beispiele finden sich in bereits bestehenden + moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der + de-Hierarchie" enthält teilweise Verweise darauf. + +* Die Moderation einer Newsgroup erfordert in technischer Sicht eine + Möglichkeit, einen per E-Mail übersandten Beitrag unter Beibehaltung + der wesentlichen Informationen auch im Header - aber unter Wegfall + mancher und Ergänzung anderer Headerzeilen - als Posting zu + veröffentlichen. Insbesondere dann, wenn mehr als eine Person - + parallel - an der Moderation beteiligt sein soll (was sich + mittlerweile als Regelfall etabliert haben dürfte), empfiehlt es + sich, das entsprechende Zusammenwirken auch technisch zu + unterstützen. In der Regel wird die Moderation einer Newsgroup also + die Installation entsprechender Software auf dem eigenen Rechner + oder sogar die Einrichtung auf einem übers Netz erreichbaren + Rechner, bspw. mit einem Webinterface, und deren Bedienung + erfordern. + + Das muss nicht zwingend durch die Moderatoren selbst erfolgen; im + Zweifel werden aktive Netzteilnehmer bereit sein, eine solche + Installation zur Verfügung zu stellen. Die Auswahl und Erprobung der + vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und + Kontaktaufnahmen sollten aber spätestens parallel zum laufenden + Einrichtungsverfahren erfolgen; Tests können bspw. in der Newsgroup + de.alt.test.moderated erfolgen. + +Siehe auch: + ++ Unknown: NetNews Moderator's Handbook (1994, engl.) + ++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.) + ++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.) + ++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.) + ++ Big-8 Moderation Board Wiki: Moderation Software (engl.) + ++ Informationen über de.alt.test.moderated +| From: Thomas Hochstein +| Newsgroups: de.alt.test.moderated +| Subject: Info: de.alt.test.moderated <2011-03-03> +| +| Last-modified: 2011-03-03 +| Posting-frequency: monthly + +2.5. Sonderfälle +---------------- + +Die vorstehenden Erläuterungen decken den Regelfall der Einrichtung +einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene +Sonderfälle: + +* Aufteilung von Gruppen + + Wenn eine bestehende Newsgroup aufgrund der regen Nutzung in mehrere + Gruppen unterteilt werden soll, entsteht daraus in der Regel eine + neue Teilhierachie (ein neuer Zweig am Baum der Struktur von de.*). + Die Einrichtungsregeln sehen für diesen Fall in Punkt 7 folgendes + vor: + +| .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie -- +| sei es durch Umwandlung einer bestehenden Gruppe oder durch +| Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc +| endende Gruppe eingerichtet. Der zur Gründung der Hierarchie +| führende RfD hat hierzu die notwendigen Angaben bereitzustellen. +| Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so +| findet hierüber eine normale Abstimmung statt. + + Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe für + Ausrüstungsfragen ("de.rec.outdoors.ausruestung") abgespalten + werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc" + eingerichtet werden. Dies geschieht regelmäßig durch Umbenennung der + bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss + also auch dazu Informationen enthalten. + +* Einrichtung einer neuen Teilhierarchie + + Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe + vorgeschlagen werden soll, sondern direkt mehrere, thematisch + zusammenhängende, also auf diese Weise eine neue Teilhierachie + entsteht. + + Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und + "de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch + eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen + aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch + mit Ködern zu tun haben. Die entsprechenden Informationen - Name, + Kurzbeschreibung, Charta - müssen ebenfalls im Einrichtungsvorschlag + enthalten sein. + +* Einrichtung mehrerer Gruppen + + In einem Einrichtungsvorschlag sollte nur dann die Einrichtung + mehrerer Gruppen zusammengefasst werden, wenn diese in einem inneren + Zusammenhang stehen, wenn bspw. eine bestehende Gruppe aufgeteilt + werden oder direkt eine komplette neue Teilhierarchie eingerichtet + werden soll. In diesem Fall muss der Einrichtungsvorschlag dann für + alle Gruppen die notwendigen Informationen bereitstellen. + + Zu berücksichtigen ist, dass Vorschläge grundsätzlich nicht "en + bloc" zur Abstimmung gestellt werden können; vielmehr ist über jeden + Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in + Teil 7 folgende Vorgaben: + +| Übertragbarkeit: Stimmen können nicht auf einen anderen +| Abstimmungsvorschlag übertragen werden. Eine Stimme zählt nur für +| GENAU DEN Vorschlag, für den sie abgegeben wurde. Insbesondere +| darf eine Stimme für oder gegen eine Newsgruppe mit einem +| bestimmten Namen NICHT als Stimme für oder gegen eine Newsgruppe +| mit einem anderen Namen oder einer anderen Charta, einem anderen +| unmoderiert/moderiert Status oder, falls moderiert, einem anderen +| Moderator oder einer anderen Gruppe von Moderatoren gezählt +| werden. Über jede Gruppe wird einzeln abgestimmt, Verknüpfungen +| von Wahlen sind nicht möglich. + +* Diskussion mehrerer Alternativen + + Ziel der Diskussion sollte es regelmäßig sein, am Ende der + Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen. + Das schließt nicht aus, in der Diskussion zunächst mehrere denkbare + Alternativen vorzuschlagen; die Diskussion sollte aber schließlich + zu einem mehrheitsfähigen Vorschlag führen. Ggf. kann dazu auch ein + unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere + sich ausschließende Alternativen zur Abstimmung zu stellen sollte + nach Möglichkeit vermieden werden, weil die Abstimmung sonst + einerseits schnell sehr kompliziert wird und andererseits die Gefahr + besteht, dass entweder kein Vorschlag eine Mehrheit erhält (obwohl + die Mehrzahl der Abstimmenden durchaus generell für eine Einrichtung + der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von + Vorschlägen angenommen wird, das so niemand gewollt hat. + + Die für die Abstimmung in diesem Fall zu beachtenden Regeln für + "kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln + und lauten folgendermaßen: + +| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen +| höchstens eine eingerichtet werden soll ("kombiniertes Voting"). +| Dabei wird über die Einrichtung jeder einzelnen Gruppe gemäß den +| obigen Regeln abgestimmt. +| +| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet +| zusätzlich ein Stichentscheid zwischen all diesen Gruppen statt. +| Falls in den Einrichtungsfragen mehr als eine Gruppe angenommen +| wird, so wird davon einzig diejenige eingerichtet, welche im +| Stichentscheid das beste Verhältnis Zustimmung : Ablehnung aufweist. + + Siehe dazu auch: + + + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten +| From: Ralf Döblitz +| Newsgroups: de.admin.news.regeln,de.admin.infos +| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten +| +| Archive-name: de-admin/entscheidung +| Posting-frequency: weekly +| Last-modified: 2013-06-09 +| URL: http://www.kirchwitz.de/~amk/dai/entscheidung + +3. Diskussionsphase +=================== + +Wenn alle Vorüberlegungen abgeschlossen sind, kann das "offizielle" +Einrichtungsverfahren mit der Abfassung eines förmlichen +Diskussionsvorschlags (RfD, "Request for Discussion") beginnen, der +bei der Moderation von de.admin.news.announce eingereicht und von +dieser dann nach Prüfung veröffentlicht wird. + +3.1. Inhalt und Aufbau eines RfD +-------------------------------- + +3.1.1. Inhalt + +Inhaltlich besteht ein RfD aus der Bereitstellung der vorstehend unter +2. dargestellten notwendigen Informationen und einer Begründung des +Einrichtungsvorschlags, die geeignet ist, die Mitlesenden von dem +Vorschlag und der Notwendigkeit für die bzw. dem Erfolg der +vorgeschlagenen neuen Gruppe zu überzeugen. + +Üblicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status +und der Charta der vorgeschlagenen Gruppe. Darauf folgt die +Begründung, die den Hintergrund für den Vorschlag und die Überlegungen +insbesondere zu den bereits oben unter 1. ("Vorüberlegungen") +genannten Punkten enthalten sollte. Im Hinblick auf die Frage nach dem +Bedarf bietet es sich oft an, eine statistische Auswertung des bereits +im Usenet oder anderswo bestehenden Diskussionsumfangs aus den letzten +Monaten vorzunehmen ("Trafficnachweis"). Außerdem enthält der RfD +natürlich Namen und Mailadressen des- oder derjenigen, der/die den +Vorschlag einreichen ("Proponent(en)"). Bei einer Mehrzahl von +Personen bietet sich ggf. die Einrichtung eines Verteilers für die +Kommunikation mit der Moderation von de.admin.news.announce und für +eventuelle Nachfragen per E-Mail im Verlauf der Diskussion an. + +Schließlich ist auch zu entscheiden, in welchen Gruppen der RfD +veröffentlicht werden soll; das sind mindestens de.admin.news.announce +und de.admin.news.groups, zusätzlich sollten aber auch die Gruppen +aufgenommen werden, die durch das Verfahren vorhersehbar tangiert +werden, also namentlich die Gruppe(n), die aufgeteilt werden soll(en), +deren Themenbereiche durch die neue Gruppe eingeschränkt werden oder +die sonst thematisch verwandt sind. Insbesondere relevant sind dabei +natürlich Gruppen, in denen bisher schon Diskussionen zu dem Thema +stattfinden oder in denen man sich Interessen an der neuen Gruppe +erhofft. Dabei gilt auch hier, dass die Gruppenliste so kurz wie +möglich und nur so lang wie nötig sein sollte; dies schon deshalb, +weil in übermäßig viele Gruppen verteilte Postings heutzutage +möglicherweise als Spam ausgefiltert werden. + +Eine Veröffentlichung durch die Moderation von de.admin.news.announce +kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im +Einverständnis mit deren Moderation. In Gruppen außerhalb von de.*, +auch in anderen deutschsprachigen Hierarchien, in Mailinglisten, +Webforen o.ä. kann der Proponent nach Veröffentlichung des RfDs einen +Hinweis auf diesen ("Pointer") veröffentlichen, der u.a. Newsgroups, +Betreff und auch die Message-ID des RfDs enthalten sollte, damit +Interessenten den Vorschlag und die Diskussion finden können. + +3.1.2. Formale Gestaltung + +Für die formale Gestaltung eines RfD gibt es keine verbindlichen +Vorgaben; allenfalls haben sich Üblichkeiten entwickelt. Es empfiehlt +sich auch hier, einige ältere RfD in de.admin.news.announce als Muster +heranzuziehen. Das kann dann bspw. so aussehen: + +| 1. RfD (Diskussionsaufruf) +| ========================== +| +| zur Einrichtung der neuen Gruppe +| +| [Gruppenname] [Kurzbeschreibung] +| +| Status: Die Gruppe ist unmoderiert. + +oder + +| Status +| ------ +| +| Die Gruppe ist moderiert. +| +| Moderatoren sind Adam Berthold und +| Charlotte Dominik . +| +| Die Submissionsadresse lautet . +| +| Charta +| ------ +| +| [Charta] +| +| Hintergrund / Begründung +| ----------- ---------- +| +| [Begründung, ggf. untergliedert] +| +| Proponent(en) +| ------------- +| +| [Name(n) und Mailadresse(n)] + +Unter hat Boris 'pi' Piwinger +einen "RfD-Generator" eingerichtet. Über ein Formular werden die +notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige +Fehler hin überprüft und daraus dann ein Text erzeugt, der als RfD +eingereicht werden kann. + +3.2. Einreichung des RfD +------------------------ + +Der fertige RfD ist dann per E-Mail an an die +Moderation von de.admin.news.announce einzureichen. Neben dem +eigentlichen Text sollte dabei auch die Liste der Gruppen übermittelt +werden, in denen der RfD veröffentlicht werden soll. Der RfD kann auch +bereits einschließlich des Headers (mit Absender, Betreff, +Gruppenliste etc.), bspw. als angehängte Textdatei, übermittelt +werden. + +Üblicherweise wird die Moderation den Eingang des RfD bestätigen und +ihn in den wöchentlich geposteten Status aufnehmen, der auch auf den +Webseiten der Moderation veröffentlicht wird. Danach wird ein +Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD +überprüft, ggf. Rücksprache mit dem oder den Proponenten nimmt und ihn +schließlich in de.admin.news.announce und den übrigen Gruppen +veröffentlicht. + +Wenn hinsichtlich der Inhalte oder Formalien des RfD noch Fragen offen +sind oder Unsicherheit bestehen, können diese in der Regel mit dem +Verfahrensbetreuer diskutiert und geklärt werden. Die +Verfahrensbetreuer der Moderation von de.admin.news.announce haben +üblicherweise bereits längerfristige Erfahrungen mit de.* und dem +Einrichtungsverfahren gesammelt und können daher im Zweifel Tips und +Hinweise geben oder beratend tätig werden. + +Siehe auch: + ++ Moderationskonzept der derzeitigen Moderation von d.a.n.a +| From: moderator@dana.de (Moderation von de.admin.news.announce) +| Newsgroups: de.admin.news.announce,de.admin.news.misc +| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation + + +3.3. Diskussionsphase +--------------------- + +Nachdem die Moderation den RfD veröffentlicht hat, findet in +de.admin.news.groups die Diskussion über den Vorschlag statt. Die +Proponenten sollten die Diskussion verfolgen und sich an ihr +beteiligen, dabei auf Einwände und Kritik eingehen und ggf. ihre +Begründung verfeinern. + +Häufig wird die Diskussion sinnvolle Ergänzungen zum ursprünglichen +Vorschlag bringen, die in einen neuen, geänderten Vorschlag +eingearbeitet werden können. Wenn dies der Fall ist, kann nach einiger +Zeit - bspw. zwei Wochen nach dem 1. RfD - ein weiterer RfD zur +Veröffentlichung eingereicht werden, der den modifizierten Vorschlag +und eine Begründung, warum welche Vorschläge aufgenommen oder +verworfen wurden, enthält. Dieser zweite RfD erscheint als Antwort +("Followup") auf den ersten. + +Besteht weiterer Diskussionsbedarf, können auch mehrere weitere RfDs +veröffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht +unnötig verlängert oder verzögert werden; es ist aber auch nicht +sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu +veröffentlichen. Vielmehr sollte die Diskussion beobachtet und die +sich herauskristallisierenden Verbesserungsvorschläge gesammelt +werden; erst wenn sich ein Konsens abzeichnet oder sich jedenfalls die +Diskussion beruhigt (oder im Kreis zu drehen beginnt), ist in der +Regel der richtige Zeitpunkt gekommen, die bisherigen Vorschläge und +Änderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu +stellen und dann auf dieser Basis einen geänderten Vorschlag als +weiteren RfD zu veröffentlichen. + +Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten +möglichst konstruktiv geführt werden. Als Proponent sollte man sich +jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer +ausschließlich erfreulich sein wird; de.admin.news.groups ist auch +insofern ein Spiegel des Usenets als es dort neben gutwilligen +Teilnehmern auch Unruhestifter gibt und neben netten, zuvorkommenden +Teilnehmern auch starrköpfige und unfreundliche. Auch dort gilt aber, +dass aus der Diskussion das wird, was die Diskutanten aus ihr machen. + +3.4. Überleitung zur Abstimmung oder Rückzug des Vorschlags +----------------------------------------------------------- + +Am Ende der Diskussion sollte(n) der/die Proponent(en) sich darüber +Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag +voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall, +kann das Verfahren zurückgezogen werden. + +Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten +der aus seiner/ihrer Sicht nunmehr endgültige Vorschlag feststellt, +zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der +Vorschlag nur in der Form des letzten veröffentlichen RfDs zur +Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss +inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen +übereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der +Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen +Änderungen zu veröffentlichen. + +Nach Möglichkeit sollte am Ende der Diskussion nur noch ein einziger, +einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls müssen aber +für jede vorgeschlagene Gruppe Name, Kurzbeschreibung, Status und +Charta (und bei moderierten Gruppen der Moderator und die +Submissionsadresse) - notfalls in mehreren Varianten - feststehen. + +4. Abstimmungsphase +=================== + +Die Abstimmung über einen Vorschlag findet per E-Mail statt. Die +abgegebenen Stimmen werden während des Abstimmungszeitraums an die +E-Mail-Adresse des Abstimmungsleiters ("Votetaker") versandt, der sie +auszählt und am Ende ein Ergebnis der Abstimmung mit Namen, +E-Mail-Adresse und Stimmabgabe aller Teilnehmer veröffentlicht. Die +Durchführung der Abstimmung muss nicht zwingend durch den oder die +Proponenten erfolgen; aufgrund der notwendigen technischen und +organisatorischen Kenntnisse und Voraussetzungen empfiehlt es sich +oft, die Durchführung einem erfahrenen Usenet-Teilnehmer oder den +"German Volunteer Votetakers" (GVV) zu überlassen. + +4.1. Voraussetzungen für die Durchführung einer Abstimmung +---------------------------------------------------------- + +Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen +gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld +prüfen: + +* Für die Durchführung der Abstimmung benötigt man einen + E-Mail-Account, der die Wahlscheine entgegennimmt. Dieser sollte + nach Möglichkeit nicht mit der "normalen" E-Mail-Adresse des + Abstimmungsleiters identisch sein, damit keine Missverständnisse + auftreten oder Wahlscheine in der sonstigen Post verloren gehen. + Wichtig ist insbesondere auch, dass der Account ungefiltert ist, also + keine Spamfilter oder Blacklists aktiv sind, die ggf. dazu führen, + dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung + von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen + Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts + von Webhosting- oder Internetzugangsanbietern. + + Siehe dazu auch: + + + Zu Abstimmadressen und Filtermassnahmen +| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci) +| Organization: Moderation von de.admin.news.announce +| Newsgroups: de.admin.news.announce,de.admin.news.regeln +| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen +| Date: Sat, 12 Mar 2011 23:15:00 +0100 +| Message-ID: +| +| Filtermaßnahmen bei der Durchführung von Abstimmungen +| ===================================================== + +* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von + Hand zu bearbeiten, sondern dafür geeignete Software zu verwenden, + die Plausibilitätsprüfungen vornimmt, Bestätigungen per E-Mail + versenden kann und Auswertungen automatisch erstellt. + + Die verbreitetste Softwarelösung dafür ist UseVote; mehr + Informationen dazu und eine Downloadmöglichkeit gibt es auf + . + +* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind, + haben sich einige regelmäßige Teilnehmer in de.admin.news.* dazu + bereiterklärt, ungefilterte Abstimmungsaccounts einzurichten und die + eingehenden Abstimmungsmails entweder an eine andere Mail-Adresse + des Votetakers weiterzuleiten oder den Abruf via POP3 oder IMAP o.ä. + zu ermöglichen. Dazu zählen u.a. + + - Ralph Angenendt + - Ralf Döblitz + - Karsten Düsterloh + - Michael Grimm + - Emil Schuster + + Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten + Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise + abzustimmen. + +* Daneben besteht auch die Möglichkeit, die Abstimmung gar nicht + selbst durchzuführen, sondern damit einen Dritten zu beauftragen, + der weitergehende technische Möglichkeiten oder größere Erfahrungen + mit der Durchführung von Abstimmungen hat. Überdies ist es zwar + zulässig und auch der von den Einrichtungsregeln ursprünglich + vorgesehene Regelfall, dass der Proponent auch die Abstimmung + durchführt, manchmal ist es aber erwünscht, damit einen unabhängigen + Dritten zu beauftragen. + + Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige + erfahrene Votetaker haben sich überdies zu den "German Volunteer + Votetakers" (GVV) zusammengeschlossen und sind unter der Adresse + erreichbar. Jeder Proponent kann unter dieser Adresse + - rechtzeitig! - nachfragen, ob ein Mitglied der GVV bereit und in + der Lage ist, für ihn die Abstimmung durchzuführen. In den letzten + Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch + Mitglieder der GVV durchgeführt. + + Siehe dazu auch: + + + GVV-FAQ +| From: Thomas Hochstein +| Newsgroups: de.admin.infos,de.admin.news.groups +| Subject: <2017-05-01> GVV-FAQ +| +| Archive-name: de-admin/gvv-faq +| Posting-frequency: weekly +| Last-modified: 2017-05-01 +| URL: https://votetakers.de/faq.php +| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq + +4.2. Inhalt und Aufbau eines CfV +-------------------------------- + +Auch für den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er +muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name, +Kurzbeschreibung, Charta, Status, ggf. Moderator) und die für die +Teilnahme an der Abstimmung notwendigen Informationen, namentlich die +Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit +den einzelnen Abstimmungspunkten, enthalten. + +Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber +höchstens einen Monat betragen. Üblicherweise wird diese Frist nicht +ausgeschöpft, sondern stattdessen eine Abstimmungsdauer von vier +Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit", +nach der ein 2. CfV veröffentlicht werden soll, mit "zwei Wochen" +leichter bestimmbar ist. Zum anderen ist es üblich, Abstimmungen +um Mitternacht enden zu lassen. Daher könnten sich bei einer +Abstimmungsdauer von einem Monat und Veröffentlichung des 1. CfV bspw. +um 16:30 Uhr unnötige Diskussionen ergeben, ob damit nicht die +Höchstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht) +überschritten wird. + +Schließlich muss der CfV mit dem letzten RfD im wesentlichen +übereinstimmen, wie Teil 6 der Einrichtungsregeln festhält: + +| Nach der Diskussionsperiode kann ein Abstimmungsaufruf -- engl. +| "Call for Votes" oder kurz CfV -- bei der Moderation eingereicht +| werden. Dieser muss mit dem letzten RfD im wesentlichen +| übereinstimmen. + +Zweck dieser Regel ist es, zu verhindern, dass etwas anderes zur +Abstimmung gestellt wurde als zuvor Gegenstand der Diskussion war. +"Wesentlich" in diesem Sinne sind daher alle Eigenschaften der +einzurichtenden Gruppe sowie die Abstimmungsmodalitäten; an diesen +dürfen keine über die Behebung von Schreibfehlern o.ä. hinausgehenden +Änderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung +gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor +diskutierte. Eine Änderung der Begründung - soweit sie überhaupt im +CfV wiederholt wird - ist hingegen regelmäßig unproblematisch. + +Üblich ist es, auf Basis des letzten veröffentlichen RfD einen CfV zu +entwerfen. Dabei kann der Begründungsteil gekürzt werden oder ganz +entfallen und durch einen Verweis auf die geführte Diskussion - +Message-IDs der RfDs - ersetzt werden. Hinzugefügt werden dann die +Abstimmungsmodalitäten: Votetaker, Abstimmadresse, Abstimmungsende, +ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme, +Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele für +Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut unüblich. +Bei einfachen Abstimmungen erweist sich eine solche Darstellung +nämlich als überflüssig; bei komplexeren Abstimmungen hingegen würde +die Darstellung aller möglichen Abstimmungsvarianten und der +entsprechenden Ergebnisse solchermaßen unübersichtlich und aufwendig, +dass regelmäßig darauf verzichtet wird. Wenn jedoch die einzelnen +Abstimmungsmöglichkeiten dargestellt werden, dann müssen sowohl die +Abstimmungsmöglichkeiten für wie auch die gegen einen Vorschlag +dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu +vermeiden. + +Beispiele für CfVs finden sich in de.admin.news.announce. Eine +mögliche Gestaltung wäre folgende: + +| 1. CfV (Abstimmungsaufruf) +| ========================== +| +| zur Einrichtung der neuen Gruppe +| +| [Gruppenname] [Kurzbeschreibung] +| +| Status: Die Gruppe ist unmoderiert. +| +| Charta +| ------ +| +| [Charta] +| +| Hintergrund / Begründung +| ----------- ---------- +| +| [kurze Begründung, ggf. Verweis auf die Diskussion] +| +| Proponent(en) +| ------------- +| +| [Name(n) und Mailadresse(n)] +| +| Abstimmungsmodalitäten +| ---------------------- +| +| Votetaker : [Name und Mailadresse] +| Abstimmadresse : [Mailadresse] +| Abstimmungsende: Mit Ablauf des [Datum] +| Wahlschein : Untenstehendes Formular ist zu verwenden. Möglich sind +| bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG. +| +| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in +| der bei Beginn der Abstimmung gültigen Fassung, die in de.admin.infos +| und unter auch im WWW +| veröffentlicht sind. Sie erläutern das Wahlverfahren detailliert und +| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden. +| +| Gezählt werden nur per E-Mail bei der Abstimmadresse eingegangene +| Stimmen. Diese werden einzeln per E-Mail bestätigt. Das Ergebnis wird +| nach dem Ende der Wahl veröffentlicht. Namen, E-Mail-Adresse und +| Inhalt der Stimmabgabe aller Abstimmenden werden im Ergebnis genannt. +| Mit Rücksicht auf das deutsche Datenschutzrecht ist daher die +| gesonderte Zustimmung zur Speicherung und Veröffentlichung der +| abgegebenen Stimme entsprechend Hinweis im Wahlschein nötig. +| +| =-=-=-=-=-=-=-=- Alles vor dieser Zeile bitte loeschen =-=-=-=-=-=-=-=- +| +| WAHLSCHEIN fuer Einrichtung von [Gruppenname] +| +| Dein Realname, falls nicht im FROM-Header: +| +| Wenn du keinen Real-Namen angibst, wird deine Stimme fuer +| ungueltig erklaert werden. +| +| Nr [Deine Stimme] Gruppe/Abstimmungsgegenstand +| ======================================================================== +| #1 [ ] Einrichtung von [Gruppenname] +| +| Zur Verarbeitung des Wahlscheines und insbesondere der +| Veroeffentlichung des Ergebnisses ist deine Zustimmung zur Speicherung, +| Auswertung und Veroeffentlichung deiner Stimmdaten (Name und +| E-Mail-Adresse in Verbindung mit dem Stimmverhalten) im Rahmen dieses +| Verfahrens erforderlich. Wenn du im Feld unterhalb dieses Absatzes "JA" +| eintraegst, erklaerst du dich damit einverstanden. In allen anderen +| Faellen wird der Wahlschein mit Ruecksicht auf das deutsche +| Bundesdatenschutzgesetz verworfen und nicht gewertet. +| +| #a [ ] Datenschutzklausel - Zustimmung: Ich bin mit der +| Verarbeitung meiner Daten wie oben beschrieben +| einverstanden +| +| =-=-=-=-=-=-=-=- Alles nach dieser Zeile bitte loeschen =-=-=-=-=-=-=-=- + +Es empfiehlt sich, im Wahlschein eine Möglichkeit vorzusehen, den +tatsächlichen Namen anzugeben, da möglicherweise im E-Mail-Programm +ein Pseudonym konfiguriert ist. Der Wahlschein im obigen Beispiel ist +durch die Abstimmungssoftware Usevote generiert (siehe 4.1.). + +Der fertige CfV ist dann wie gewohnt per E-Mail an +an die Moderation von de.admin.news.announce einzureichen. Auch hier +gehört die Liste der Gruppen dazu, in denen der RfD veröffentlicht +werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV +kann bereits einschließlich des Headers (mit Absender, +Betreff, Gruppenliste etc.), bspw. als angehängte Textdatei, +übermittelt werden. + +Die Veröffentlichung des CfVs wird üblicherweise länger dauern als bei +den RfD, weil der Abstimmungsaufruf durch die Moderation von +de.admin.news.announce nach dem 4-Augen-Prinzip überprüft wird. Daher +kann - und sollte - der 1. CfV ruhig möglichst frühzeitig eingereicht +werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem +Zeitpunkt der Veröffentlichung ergibt, setzt die Moderation dann +selbst ein. + +4.3. Sonderfall: CfV mit persönlichem Wahlschein +------------------------------------------------ + +Ergänzend zu der üblichen Form der Abstimmung, bei der bereits der CfV +einen Wahlschein enthält, sehen die Einrichtungsregeln in ihrem Teil +6a auch die Möglichkeit einer Abstimmung unter Verwendung persönlicher +Wahlscheine vor. + +Diese 1998/1999 eingeführte Verfahrensweise [5] soll die Manipulation +von Abstimmungen erschweren, indem sie das normale +Abstimmungsverfahren durch ein Zwei-Schritt-Verfahren ersetzt: der +Abstimmungswillige muss zunächst einen persönlichen Wahlschein beim +Votetaker anfordern, der ein kodiertes, eindeutig dem +Abstimmungswilligen zuzuordnendes Merkmal erhält und sodann diesen +persönlichen - und an seine E-Mail-Adresse gekoppelten - Wahlschein +ausgefüllt zurücksenden. Andere Wahlscheine oder die Verwendung einer +anderen E-Mail-Adresse werden nicht akzeptiert. + +Diese Vorgehensweise soll u.a. verhindern, dass vorausgefüllte +Wahlscheine verbreitet werden, die durch beliebige Netzteilnehmer ohne +Kenntnis des Verfahrens (oder gar ohne Kenntnis von der Existenz des +Usenets) dann an die Abstimmungsadresse versandt werden. Als +Nebeneffekt wird damit die zur selben Zeit festgeschriebene Forderung, +dass die zur Abstimmung verwendete Adresse gültig sein, d.h. E-Mails +entgegennehmen muss, überprüfbar - denn nur wer eine gültige Adresse +als Absender verwendet, kann den Wahlschein erhalten, und nur so - und +mit dieser Adresse - kann er an der Abstimmung teilnehmen. + +Da allerdings weiterhin andere Manipulationsmöglichkeiten verbleiben +und der Aufwand für die Durchführung dieses Verfahrens vergleichsweise +hoch ist, wird ein Verfahren nach Teil 6a der Regeln nur selten +durchgeführt. + +In der Abstimmungssoftware Usevote (siehe 4.1.) ist die Durchführung +solcher Verfahren implementiert. + +[5] Der Vorschlag und die entsprechende Begründung lassen sich im + Archiv von Google Groups unter + + nachlesen. + +4.4. Abstimmungsphase +--------------------- + +Während der drei- oder vierwöchigen (maximal aber einmonatigen) +Abstimmungsphase muss der Abstimmungsaccount durchgehend erreichbar +sein. Jede abgegebene Stimme sollte - nach Möglichkeit einigermaßen +zeitnah, am besten automatisiert - per E-Mail bestätigt werden; in +dieser Bestätigung sollte angegeben sein, welche Stimme(n) und welcher +Name sowie welche Mailadresse für den Abstimmenden registriert wurden. +Für Zwecke der Abstimmung ist die Adresse im From: der E-Mail zu +erfassen; an diese sollte auch die Bestätigung versandt werden, um +sicherzustellen, dass diese Stimme auch tatsächlich vom angegebenen +Absender stammte (und die Abstimmadresse replyfähig ist, d.h. E-Mail +dort empfangen werden kann). Außerdem sollte in der Bestätigung +angegeben sein, wie eine Stimme nachträglich geändert oder komplett +zurückgezogen werden kann (wenn bspw. eine E-Mail-Adresse verwendet +wurde, die nicht im Usenet veröffentlicht werden soll.) + +In der Mitte der Abstimmungsphase ist es üblich, einen 2. CfV zu +veröffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine +Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die +Stimmabgaben!) enthält; dabei kann auch bereits angegeben werden, ob +Stimmen voraussichtlich als ungültig gewertet werden. Weil auch der 2. +CfV im Rahmen der üblichen Bearbeitungszeiten regelmäßig nicht sofort, +sondern erst nach einigen (Stunden oder) Tagen veröffentlicht werden +wird, schadet es nicht, den Zeitpunkt anzugeben, zu dem die Liste der +Abstimmenden erstellt wurde, und auch den 2. CfV bereits ein oder zwei +Tage vor dem geplanten Veröffentlichungszeitraum einzureichen. + +Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht) +endet die Abstimmung. Verspätete Stimmen werden nicht mehr gezählt. + +4.5. Auswertung und Ergebnis der Abstimmung +------------------------------------------- + +Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgezählt. + +Dabei werden zunächst die JA- und NEIN-Stimmen sowie Enthaltungen +gezählt. Wenn eine Person mehrere Stimmen abgegeben hat, gilt die +zuletzt abgegebene Stimme. Bei Unklarheiten hinsichtlich des Inhalts +der Stimmabgabe oder des Namens oder der Mailadresse sollte mit dem +Abstimmenden Rücksprache gehalten werden. Das gleiche gilt, wenn +mehrere Stimmen offenbar von derselben Person stammen (gleicher Name, +unterschiedliche Mailadresse oder umgekehrt), um festzustellen, ob nur +die letzte Stimme zu werten ist oder es sich doch um verschiedene +Personen handelt. + +Stimmen, die nicht eindeutig sind, oder die in anderer Weise nicht den +Einrichtungsregeln genügen (Angabe eines falschen oder nicht +vollständigen Namens, nicht replyfähige Abstimmadresse), dürfen nicht +gewertet werden. Der Votetaker sollte auch die Möglichkeit von +Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen +Identitäten, Weitergabe des Wahlscheins außerhalb der Gruppen, in +denen er veröffentlicht wurde, Beeinflussung der Abstimmung durch +"Campaigning") im Auge behalten und entsprechende Überprüfungen +vornehmen. Unklarheiten sollten mit den betroffenen +Abstimmungsteilnehmern geklärt werden. Im Einzelfall kann auch die +Meinung der Moderation zu einer umstrittenen Frage eingeholt werden; +es empfiehlt sich, zumindest die Entscheidungen der Moderation aus +vergangenen Jahren zu früheren Zweifelsfällen zu Rate zu ziehen. Diese +sind, soweit sie eine Bedeutung über den konkret entschiedenen +Einzelfall hinaus haben und nicht später revidiert wurden, unter + auch im Web veröffentlicht. + +Bei der Auswertung sollte der Votetaker im eigenen Interesse die +datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen +er unterliegt, berücksichtigen. Dies gilt insbesondere, sofern zur +Speicherung, Verarbeitung und vor allem Veröffentlichung der +personenbezogenen Daten der Abstimmungsteilnehmer ausdrückliche +Einwilligungserklärungen erforderlich sind. + +Danach ist eine Ergebnisveröffentlichung ("Result") vorzubereiten. +Üblich ist es, die Gesamtzahl der gültigen Stimmen und sodann für +jeden Abstimmungspunkt die Anzahl der JA- und NEIN-Stimmen, der +Enthaltungen und ungültigen Stimmabgaben zu nennen. Angenommen ist der +Vorschlag, wenn mindestens 50 JA-Stimmen eingegangen sind und die +Anzahl der JA-Stimmen mindestens doppelt so groß ist wie die Anzahl +der NEIN-Stimmen (2/3-Mehrheit). + +Zwingend ist zudem die Veröffentlichung einer Liste aller Abstimmenden +mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und +ungültige Stimmen sind anzugeben, bei letzteren unter Angabe einer +stichwortartigen Begründung für die Nichtwertung. Dies ermöglicht es +allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen. + +In besonderen Fällen kann die Veröffentlichung von Name und/oder +Adresse eines Abstimmungsteilnehmers unterbleiben. Insbesondere dürfte +das relevant sein, wenn Gruppen von einer Abstimmung betroffen sind, +in denen aus bestimmten Gründen die Verwendung von Pseudonymen +akzeptiert wird. + +5. Verfahrensabschluss und Umsetzung +==================================== + +Mit der Veröffentlichung des Results durch die Moderation von +de.admin.news.announce beginnt eine einwöchige Einspruchsfrist, in der +jeder Interessierte Einspruch mit der Begründung einlegen kann, dass +bei der Durchführung der Abstimmung schwerwiegende Unregelmäßigkeiten +gab. Das können bspw. technische Probleme mit der Abstimmadresse sein, +die Nichtwertung oder falsche Wertung von Stimmen durch den Votetaker +oder einer der bereits unter 4.5. angerissenen Manipulationsversuche. + +Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der +Abstimmung bestandskräftig; die Moderation von de.admin.news.announce +wird dann die entsprechenden digital signierten Steuernachrichten +versenden, die üblicherweise die automatische Einrichtung der neuen +Gruppe(n) auf allen Newsservern nach sich ziehen, die de.* führen, und +die kanonische List der in de.* existierenden Newsgroups entsprechend +ergänzen. + +Ansonsten wird die Moderation über eingegangene Einsprüche entscheiden +und das Ergebnis der Abstimmung entweder entsprechend anpassen oder +schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das +veröffentlichte Ergebnis nicht tangiert (weil bspw. nur Einspruch +gegen die Wertung einer einzelnen Stimme eingelegt wurde, das aber +keinen Einfluss auf das Ergebnis haben kann), erfolgt die Umsetzung in +der Regel bereits mit Ablauf der Einspruchsfrist, ansonsten erst dann, +wenn über den Einspruch abschließend entschieden ist. + +Das Einrichtungsverfahren ist damit beendet. + +6. Sonderfall: Vereinfachtes Verfahren (VV) +=========================================== + +Nicht jeder marginale Änderungsvorschlag muss zwingend das vorstehend +geschilderte umfangreiche Verfahren nach sich ziehen. Für kleinere +Änderungen sehen die Einrichtungsregeln in ihrem Teil 10 ein sog. +"Vereinfachtes Verfahren" (kurz "VV") vor, bei dem Diskussions- und +Abstimmungsphase zugunsten einer Widerspruchslösung entfallen. + +Bei einem VV wird der entsprechende Änderungsvorschlag, der dieselben +Anforderungen wie ein RfD erfüllen muss (siehe 3.1.), zur +Veröffentlichung in de.admin.news.announce bei +eingereicht. Dieser Vorschlag im vereinfachten Verfahren muss darüber +hinaus ausdrücklich darauf hinweisen, dass die vorgeschlagene Änderung +ohne weiteres vorgenommen wird, wenn ihr nicht binnen einer +gleichfalls anzugebenden Frist, die mindestens zwei Wochen betragen +muss, per E-Mail an die Moderation von de.admin.news.announce (deren +E-Mail-Adresse anzugeben ist) widersprochen wird. + +Nach Abschluss der Widerspruchsfrist stellt die Moderation von +de.admin.news.announce entweder fest, dass kein Widerspruch +eingegangen ist und der Vorschlag angenommen wurde, oder +veröffentlicht Namen und E-Mail-Adresse der Widerspruchsführer. Im +letzteren Fall ist das VV gescheitert und kann durch den Proponenten +als normales Verfahren mit dem 1. RfD fortgeführt oder aufgegeben +werden. + +Wenn der Änderungsvorschlag angenommen wurde, wird er durch die +Moderation von de.admin.news.announce umgesetzt (siehe 5.). + +7. Löschungen, Umbenennungen, Status- und Regeländerungen u.ä. +============================================================== + +Bereits die Einleitung ("Übersicht") der Einrichtungsregeln weist +darauf hin, dass der gepostete Text zwar den Betreff "Einrichtung von +Usenet-Gruppen in de.*" trägt und sich die Ausführungen auch (im +wesentlichen nur) mit der Einrichtung neuer Gruppen beschäftigen, sie +aber für alle Änderungen am Gruppenbestand analog gelten und auch für +andere Entscheidungen - und Personenwahlen - entsprechend angewendet +werden können (und regelmäßig auch angewendet werden): + +| Diese Spielregeln gelten für die Einrichtung oder Entfernung einer +| Gruppe sowie Änderung ihrer Attribute. Die Attribute einer Gruppe +| sind: Gruppenname, Kurzbeschreibung, Charta und Status (moderiert/ +| unmoderiert) sowie bei moderierten Gruppen die Moderatoren. +| +| Es spricht nichts dagegen, auch andere hierarchieweit wirkende +| Entscheidungen nach analogen, nur im Detail abweichenden, Regeln +| herbeizuführen. +| +| Zur Moderatoren-Nachfolge in bestehenden moderierten Gruppen sind +| diese Spielregeln weder zwingend noch die einzigen Regeln. + +Die Einrichtungsregeln stammen im Ursprung aus der Zeit der Gründung +und Expansion der Hierarchie de.*, so dass sie sich im wesentlichen +mit einer koordinierten Vorgehensweise bei der Einrichtung neuer +Gruppen beschäftigen. Je größer die Hierarchie wurde (und je stärker +die Nutzerzahlen wieder zurückgingen), desto häufiger wurden dann +Änderungs- und Löschungsverfahren, aber auch Regeländerungen. + +Grundsätzlich ist die Vorgehensweise in diesen Fällen den +Einrichtungsverfahren vergleichbar, insbesondere die +Begründungsansätze sind aber freilich andere. + +7.1. Gruppenlöschungen +---------------------- + +Gruppenlöschungen sind das Gegenteil von Neueinrichtungen und kommen +dementsprechend auch aus den umgekehrten Gründen wie diese in +Betracht. Sie werden zumeist dann vorgeschlagen, wenn eine Gruppe +nicht mehr oder praktisch nicht mehr genutzt wird und dementsprechend +leersteht. So wie eine neue Gruppe oft durch Aufspaltung einer +bestehenden, sehr rege genutzten Gruppe in mehrere Untergruppen +entsteht, sollen so umgekehrt die fast leeren Untergruppen wieder zu +einer gemeinsamen Obergruppe zusammengeführt werden. Ziel ist es +letztlich bei Einrichtungen wie bei Löschungen von Gruppen, eine +thematische Aufteilung zu erreichen, die gerade so fein ist, dass +Gruppen zu intensiv diskutierten Themen nicht überfüllt sind und +Gruppen zu selten diskutierten Themen nicht leer stehen. + +* Insofern wird die Begründung eines Löschungsvorschlags in der Regel + primär auf eine statistische Auswertung über einen längeren Zeitraum + (mindestens 12 Monate, im Zweifel aber auch länger) gestützt, um zu + belegen, dass die Gruppe kaum mehr genutzt wird. Zur Erstellung + solcher Statistiken kann das Projekt "de.* in Graphen" [6] hilfreich + sein. Zahlen sind aber nicht alles; jedenfalls so lange die Anzahl + der Postings pro Jahr (!) nicht in den niedrigen zweistelligen + Bereich abrutscht, können niedrige Nutzungszahlen nur ein Hinweis + auf eine tote oder sterbende Gruppe sein. Entscheidender ist dann + oft, wie auf Postings - Fragen oder Diskussionsanregungen - reagiert + wird. Kommen auf Fragen zeitnah kompetente Antworten? Werden zur + Diskussion gestellte Argumente kompetent diskutiert? Wenn ja, dann + gibt es in der Gruppe zumindest noch eine aktive Community, die zwar + selbst kaum mehr Fragen oder Diskussionsthemen hat, aber auf solche + Anlässe reagiert und die Gruppe wieder mit Leben füllt. Das spricht + eher gegen eine Löschung der Gruppe. + + [6] + +* Ein weiterer wichtiger Punkt ist die Benennung einer - oder mehrerer - + Ausweichgruppe(n), in denen das Thema oder die Themenkomplexe der + zur Löschung vorgeschlagenen Gruppe zukünftig diskutiert werden + sollen. Wenn die Gruppe in einem größeren thematischen Zusammenhang + steht, ist es in der Regel einfach, eine solche Ausweichgruppe zu + benennen, was dann wiederum für eine niedrigere Schwelle zur + Löschung spricht, denn so werden einzelne, mittlerweile weniger + intensiv diskutierte Unterbereiche eines größeren Themas wieder + thematisch zusammengefasst. + + Ein Beispiel dafür wäre die Teilhierarchie + de.comp.office-pakete.ms-office.*, die aus den Gruppen + + - de.comp.office-pakete.ms-office.excel + - de.comp.office-pakete.ms-office.outlook + - de.comp.office-pakete.ms-office.powerpoint + - de.comp.office-pakete.ms-office.word + - de.comp.office-pakete.ms-office.misc + + besteht. Sollte sich herausstellen, dass zwar zu Word und Excel + intensiv diskutiert wird, es aber kaum Fragen zu Powerpoint gibt, + würde eine Löschung der Gruppe + de.comp.office-pakete.ms-office.powerpoint bedeuten, dass das Thema + "Powerpoint" nunmehr in de.comp.office-pakete.ms-office.misc diskutiert + werden kann, zusammen mit anderen, seltener (genutzten und) diskutierten + Komponenten von Microsoft Office wie bspw. OneNote. + + Manche Gruppen aber fassen ein weit gespanntes Thema zusammen, für + das ansonsten keine vergleichbare Gruppe besteht, sondern allenfalls + ein bunter Strauß verschiedenster Gruppen zu einzelnen Facetten des + Themas; manche Gruppen sind auch die einzigen oder letzten, die sich + (noch) mit einem solchen Thema befassen. In solchen Fällen ist eine + besonders kritische Prüfung erforderlich, ob sich die Gruppe nicht + wieder beleben lässt, weil dann die Gefahr besteht, dass ermangels + Alternativen das Thema völlig aus dem Usenet verschwindet. Solche + Gruppen sollten daher nur zur Löschung vorgeschlagen werden, wenn + das Thema letztlich bereits aus dem Usenet verschwunden *ist*. + +* Wenn die letzte Gruppe einer Teilhierarchie gelöscht wird, stellt + sich zudem noch die Frage, ob die *.misc-Gruppe der Hierachie + umbenannt werden soll (vgl. 2.5.: "Einrichtung einer neuen + Teilhierarchie"). + + So besteht die Teilhierarchie de.comm.protocols.* aus den beiden + Gruppen + + - de.comm.protocols.tcp-ip + - de.comm.protocols.misc + + Würde man die Gruppe de.comm.protocols.tcp-ip löschen, könnte man + die verbleibende Gruppe de.comm.protocols.misc nunmehr (wieder) in + de.comm.protocols umbenennen, um so den Namen zu verkürzen und die + Struktur besser erkennbar zu machen. Gegen eine solche Umbenennung + spricht, dass Umbenennungen technisch nicht möglich sind, sondern + nur durch eine Löschung der bestehenden Gruppe und die + Neueinrichtung der Gruppe mit dem geänderten Namen umgesetzt werden + können (siehe 7.2.). + +7.2. Umbenennungen +------------------ + +Umbenennungen von Gruppen erfolgen in der Regel nur im Zusammenhang +mit anderen Änderungen am Gruppenbestand. Dass eine Gruppe ohne +weiteren Anlass bloß an eine andere Stelle im Hierarchiebaum (siehe +2.1.1.) verschoben wird, ist sehr selten. + +Das liegt u.a. daran, dass technisch eine Umbenennung einer Gruppe +nicht möglich ist. Was man organisatorisch als "Umbenennung" +bezeichnet, ist technisch schlicht die (zusätzliche) Einrichtung der +Gruppe mit dem neuen Namen, gefolgt ungefähr eine Woche später von der +Löschung der Gruppe mit dem alten Namen. Dies führt dazu, dass alle +bestehenden Diskussionen auf den Newsservern mit der alten Gruppe +zusammen verschwinden und zudem Nutzer, die nur unregelmäßig in die +Gruppe hineinschauen, sie dann plötzlich nicht mehr finden können. +Eine solche Umbenennung will also wohlüberlegt sein. + +7.3. Änderungen von Charta und/oder Kurzbeschreibung +---------------------------------------------------- + +Neben dem Namen können auch alle anderen Attribute einer Gruppe (für +deren Beschreibung siehe 2.) geändert werden, namentlich die Charta +und die Kurzbeschreibung. Auch dies erfolgt nur selten isoliert; +meistens ist eine vorgeschlagene Chartaänderung die Folge einer +Reorganisation, also der Einrichtung oder Löschung anderer Gruppen, so +dass klarstellende Änderungen hinsichtlich des Themenbereichs einer +bestehenden Gruppe notwendig werden oder auch die Namen der gelöschten +oder sonstwie geänderten Newsgroups aus der Charta entfernt werden +müssen. Manchmal ergibt sich aber der Bedarf nach einer Abgrenzung +oder Erweiterung der Charta einer Gruppe auch so, wenn sich bspw. der +thematische Fokus verschiebt. + +Eine Charta- oder Kurzbeschreibungsänderung ist dabei im wesentlichen +kein technischer Vorgang. Geänderte Kurzbeschreibungen werden ggf. +durch eine Steuernachricht umgesetzt (siehe 5.); da Chartas ohnehin +nicht auf Newsservern gespeichert werden und daher auch nicht im +Newsreader angezeigt werden können (siehe 2.3.), sondern nur +organisatorische Metainformationen darstellen, werden Chartaänderungen +auch nur durch eine entsprechende Information per Posting in +de.admin.news.announce und der betroffenen Gruppe "umgesetzt". + +7.4. Statusänderungen +--------------------- + +Die Umstellung einer bestehenden unmoderierten Newsgroup auf +"moderiert" bzw. einer vormals moderierten Newsgroup auf den Status +"unmoderiert" ist nicht unproblematisch. Auch dies hat technische +Gründe; nicht immer erfolgen technische Umstellungen durch +Steuernachrichten wirklich überall auf jedem Newsserver oder gar +überall zur gleichen Zeit. Dies kann dazu führen, dass die Gruppe auf +manchen Servern noch als moderiert geführt wird, auf anderen aber +schon als unmoderiert (oder umgekehrt). + +Soll eine bisher unmoderierte Gruppe zukünftig moderiert sein, führt +dies dazu, dass Postings über Newsserver, auf denen die Gruppe noch +als unmoderiert angelegt ist, nur auf anderen solchen Newsservern +erscheinen; auf Newsservern, die die Gruppe schon als "moderiert" +führen, werden diese Postings schlicht verworfen. Wenn umgekehrt eine +bisher moderierte Gruppe zukünftig unmoderiert sein soll, werden +Newsserver, die diese Umstellung (noch) nicht vollzogen werden, +weiterhin eingereichte Postings per E-Mail an die (nicht mehr +bestehende) Moderation weiterleiten, so dass auch dann Beiträge +verloren gehen. + +Diese technischen Probleme müssen bereits in der Diskussionsphase +berücksichtigt werden und erfordern - in der Regel von denjenigen, die +den Vorschlag vorbringen - zusätzlichen Aufwand, um die Situation im +Auge zu behalten und ggf. die Betreiber von Newsservern an die +notwendige Umstellung zu erinnern. + +Ansonsten gelten die unter 2.4. dargestellten zusätzlichen Erwägungen +für die Einrichtung moderierter Gruppen entsprechend. + +7.5. Regeländerungen und Personenwahlen +--------------------------------------- + +Neben Änderungen am Gruppenbestand können - und werden - die +Einrichtungsregeln analog auch für andere Entscheiungen (bspw. die +Änderung der Einrichtungsregeln selbst) herangezogen. + +Sie gelten - teilweise modifiziert - auch für Personenwahlen, bspw. +für die Neuwahl der Moderation von de.admin.news.announce [7] oder die +von der amtierenden Moderation in regelmäßigen Abständen +durchgeführten Nachwahlen [8]. In gleicher Weise wäre es auch möglich, +jede andere Moderation einer moderierten Newsgroup - ggf. gegen ihren +Willen - auszutauschen. Ansonsten ist anerkannt, dass jede Moderation +einer moderierten Gruppe Mitglieder ausschließen oder neue Mitglieder +aufnehmen und auch die Moderation komplett an andere Personen +übergeben kann. Diese Entscheidung kann dann nur durch ein +Neuwahlverfahren - analog der Einrichtungsregeln - übersteuert werden. + +[7] Festgehalten ist dies in den "Moderatorenwahlregeln", die + gleichfalls in de.admin.infos veröffentlicht sind: +| From: ole-fg@gmx.de (Olaf Schneider), adrian.suter@schweiz.org (Adrian Suter) +| Newsgroups: de.admin.infos,de.admin.news.misc +| Subject: <1998-05-18> Neuwahl der de.admin.news.announce-Moderation +| +| Archive-name: de-admin/dana-neuwahl +| Posting-frequency: weekly +| Last-modified: 1998-05-18 +| URL: http://www.kirchwitz.de/~amk/dai/dana-neuwahl + +[8] Diese beruhen auf freiwilliger Übung der derzeit amtierenden + Moderation von de.admin.news.announce und sind daher (nur) in + deren Moderationskonzept (dort Abschnitt 4) festgehalten, das + regelmäßig in de.admin.news.announce veröffentlicht wird: +| From: moderator@dana.de (Moderation von de.admin.news.announce) +| Newsgroups: de.admin.news.announce,de.admin.news.misc +| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation + und auch auf den Webseiten der Moderation unter + abgerufen werden kann. + +8. Quellen +========== + +Alle in diesen Erläuterungen genannten Quellen sind hier noch einmal +zusammengefasst und um weitere Hinweise ergänzt. + +8.1. Grundlegende Informationen +------------------------------- + +Folgende Texte sollten einem Proponenten unbedingt bekannt sein: + ++ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln) +| From: 3.14@piology.org (Boris 'pi' Piwinger) +| Newsgroups: de.admin.infos,de.alt.admin +| Subject: <2012-01-09> Einrichtung von Usenet-Gruppen in "de.*" +| +| Archive-name: de-admin/einrichtung +| Posting-frequency: weekly +| Last-modified: 2012-01-09 +| URL: http://www.kirchwitz.de/~amk/dai/einrichtung + ++ Missverstaendnisse in de.admin.news.groups +| From: 3.14@piology.org (Boris 'pi' Piwinger) +| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin +| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups +| +| Archive-name: de-admin/dang-faq +| Posting-frequency: weekly +| Last-modified: 2009-01-24 +| URL: http://www.kirchwitz.de/~amk/dai/dang-faq + ++ Die Newsgruppen der de-Hierarchie (Gruppenliste) +| From: Daniel Roth <25.8@bluemail.ch> +| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin +| Subject: Die Newsgruppen der de-Hierarchie +| +| Archive-name: de-newusers/de-newsgruppen +| Posting-frequency: weekly +| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen + +8.2. Weiterführende Hinweise +---------------------------- + +Folgende Texte sind allgemein oder für spezielle Fragen hilfreich oder +von Interesse: + ++ Moderationskonzept der derzeitigen Moderation von d.a.n.a +| From: moderator@dana.de (Moderation von de.admin.news.announce) +| Newsgroups: de.admin.news.announce,de.admin.news.misc +| Subject: <2016-10-12> Moderationskonzept der derzeitigen Moderation + + ++ Wichtige Begriffe in de.admin.news.* (dan-Glossar) +| From: thh@inter.net (Thomas Hochstein) +| Newsgroups: de.admin.infos +| Subject: <2017-07-29> Wichtige Begriffe in de.admin.news.* +| +| Archive-name: de-admin/dan-glossar +| Posting-frequency: weekly +| Version: 1.5.2 +| Last-modified: 2017-07-29 +| URL: https://th-h.de/archives/faqs/dan-glossar.txt +| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar + ++ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen? + + ++ Erste Schritte zur Einrichtung neuer Gruppen + + ++ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten +| From: Ralf Döblitz +| Newsgroups: de.admin.news.regeln,de.admin.infos +| Subject: <2013-06-09> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten +| +| Archive-name: de-admin/entscheidung +| Posting-frequency: weekly +| Last-modified: 2013-06-09 +| URL: http://www.kirchwitz.de/~amk/dai/entscheidung + ++ Regeln fuer Newsgruppennamen +| From: "Christian Schulz - GVV" +| 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: + + ++ GVV-FAQ +| From: Thomas Hochstein +| Newsgroups: de.admin.infos,de.admin.news.groups +| Subject: <2017-05-01> GVV-FAQ +| +| Archive-name: de-admin/gvv-faq +| Posting-frequency: weekly +| Last-modified: 2017-05-01 +| URL: https://votetakers.de/faq.php +| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq + ++ Filtermaßnahmen bei der Durchführung von Abstimmungen +| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci) +| Organization: Moderation von de.admin.news.announce +| Newsgroups: de.admin.news.announce,de.admin.news.regeln +| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen +| Date: Sat, 12 Mar 2011 23:15:00 +0100 +| Message-ID: + ++ Unknown: NetNews Moderator's Handbook (1994, engl.) + + ++ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.) + + ++ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.) + + ++ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.) + + ++ Big-8 Moderation Board Wiki: Moderation Software (engl.) + + ++ Informationen über de.alt.test.moderated +| From: Thomas Hochstein +| Newsgroups: de.alt.test.moderated +| Subject: Info: de.alt.test.moderated <2011-03-03> +| +| Last-modified: 2011-03-03 +| Posting-frequency: monthly + ++ Entscheidungen der Moderation von de.admin.news.announce + + +8.3. Webseiten +-------------- + +Folgende Webseiten sollten bekannt sein oder können bei der Durchführung des +Einrichtungsverfahrens helfen: + ++ Webseite der Moderation von de.admin.news.announce + + ++ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status) + wöchentlich veröffentlicht in de.admin.news.announce + + ++ RfD-Generator + + ++ GVV-Statusübersicht + + ++ Abstimmungssoftware UseVote + + ++ de.* in Graphen + + +9. Maintainer und Kontakt +========================= + +9.1. Derzeitige Maintainer +-------------------------- + +Maintainer dieser FAQ: Thomas Hochstein + Michael Ottenbruch + +Das dana-Manual wurde im März/April 2011 vollständig überarbeitet und +neu gefasst. + +Weitere Änderungen und Ergänzungen nehmen die Maintainer gerne +entgegen. Vorschläge können per E-Mail an +gerichtet werden. Im Falle einer öffentlichen Diskussion solcher +Vorschläge ist ein Hinweis an die Maintainer hilfreich. + +Das dana-Manual ist auch in einem Git-Repository unter + verfügbar und kann über +die Weboberfläche eingesehen oder via "git clone" ausgecheckt werden. +Bei Änderungsvorschlägen sind Git-Patches am einfachsten zu +verarbeiten; natürlich nehmen die Maintainer aber auch jede andere +Form von Anregungen entgegen. + +Für Hinweise, Anregungen und Verbesserungsvorschläge sei insbesondere +- Stephan Manske +- 0liver Seyfert +gedankt. + +9.2. Frühere Fassungen +---------------------- + +Maintainer bis 2010: Thomas Roessler, Dirk Nimmich - 7.4. Danksagungen +Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung +haben außerdem beigetragen: - Zu diesem Text und seiner Entstehung haben beigetragen: +- Lutz Donnerhacke +- Kristian Köhntopp +- Rolf Krahl +- Martin Recke +- Heiko Schlichting +- Adrian Suter +- Hans-Christoph Wirth - Lutz Donnerhacke - Kristian Köhntopp - Rolf Krahl - Dirk Nimmich - Martin Recke - Thomas Roessler - Heiko Schlichting - Adrian Suter - Hans-Christoph Wirth +Herzlichen Dank! +-- +Id: $Format:%t %d %ai %an$