Archive-name: de-newusers/dana-manual Posting-frequency: weekly Version: 2.2.8 Last-modified: (unreleased) URL: https://www.kirchwitz.de/~amk/dai/dana-manual 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, Änderung 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: thh@thh.name (Thomas Hochstein) | Newsgroups: de.admin.infos,de.alt.admin | Subject: <2021-12-13> Einrichtung, Aenderung und Entfernung von Usenet-Gruppen in de.* | | Archive-name: de-admin/einrichtung | Posting-frequency: weekly | Last-modified: 2021-12-13 | URL: http://www.kirchwitz.de/~amk/dai/einrichtung | URL: https://th-h.de/archives/faqs/einrichtung.txt (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@thh.name (Thomas Hochstein) | Newsgroups: de.admin.infos | Subject: <2020-08-24> Wichtige Begriffe in de.admin.news.* | | Archive-name: de-admin/dan-glossar | Posting-frequency: weekly | Version: 1.5.7 | Last-modified: 2021-12-16 | 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 15 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: Thomas Hochstein | 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, 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 <2020-08-23> | | Posting-frequency: monthly | Last-modified: 2020-08-23 | URL: https://th-h.de/net/usenet/faqs/datm-info/ 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.misc,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: <2021-06-29> 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: <2021-12-13> GVV-FAQ | | Archive-name: de-admin/gvv-faq | Posting-frequency: weekly | Last-modified: 2021-12-13 | 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 15 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: <2021-06-29> 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: thh@thh.name (Thomas Hochstein) | Newsgroups: de.admin.infos,de.alt.admin | Subject: <2021-12-13> Einrichtung, Aenderung und Entfernung von Usenet-Gruppen in de.* | | Archive-name: de-admin/einrichtung | Posting-frequency: weekly | Last-modified: 2021-12-13 | URL: http://www.kirchwitz.de/~amk/dai/einrichtung | URL: https://th-h.de/archives/faqs/einrichtung.txt + 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: Thomas Hochstein | 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: <2021-06-29> Moderationskonzept der derzeitigen Moderation + Wichtige Begriffe in de.admin.news.* (dan-Glossar) | From: thh@thh.name (Thomas Hochstein) | Newsgroups: de.admin.infos | Subject: <2020-08-24> Wichtige Begriffe in de.admin.news.* | | Archive-name: de-admin/dan-glossar | Posting-frequency: weekly | Version: 1.5.7 | Last-modified: 2021-12-16 | 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.misc,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: <2021-12-13> GVV-FAQ | | Archive-name: de-admin/gvv-faq | Posting-frequency: weekly | Last-modified: 2021-12-13 | 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 <2020-08-23> | | Posting-frequency: monthly | Last-modified: 2020-08-23 | URL: https://th-h.de/net/usenet/faqs/datm-info/ + 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 Zu der ursprünglichen Fassung dieses Textes und seiner Entstehung haben außerdem beigetragen: - Lutz Donnerhacke - Kristian Köhntopp - Rolf Krahl - Martin Recke - Heiko Schlichting - Adrian Suter - Hans-Christoph Wirth Herzlichen Dank! -- Id: $Format:%t %d %ai %an$