2072 lines
93 KiB
Plaintext
2072 lines
93 KiB
Plaintext
Archive-name: de-newusers/dana-manual
|
|
Posting-frequency: weekly
|
|
Version: 2.2.4
|
|
Last-modified: (unreleased)
|
|
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
|
|
URL: http://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: http://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 <http://www.dana.de/status.html>
|
|
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?
|
|
<http://th-h.de/net/usenet/admin/newgroup/#vorschlag>
|
|
|
|
+ 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:
|
|
<https://groups.google.com/>
|
|
|
|
de.admin.news.announce bei Google Groups:
|
|
<https://groups.google.com/forum/#!forum/de.admin.news.announce>
|
|
|
|
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: <Datum> 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
|
|
<http://dana.de/newsgroup-namen.html> nachlesen lassen:
|
|
|
|
* Der Name besteht aus mehreren durch Punkte getrennten Segmenten.
|
|
|
|
* Die einzelnen Segmente dürfen nicht länger als 30 Zeichen werden und
|
|
müssen mindestens je einen Buchstaben enthalten. Zu beachten ist
|
|
dabei, 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" <gvv@spinfo.uni-koeln.de>
|
|
| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
|
|
| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
|
|
| Date: 2000/07/18
|
|
| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
|
|
<http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
|
|
|
|
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. <moderation@domain.example> (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.)
|
|
<http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
|
|
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
|
|
<http://pages.swcp.com/~dmckeon/mod-faq.html>
|
|
+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
|
|
<http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
|
|
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
|
|
<http://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups>
|
|
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
|
|
<http://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
|
|
+ Informationen über de.alt.test.moderated
|
|
| From: Thomas Hochstein <thh@inter.net>
|
|
| 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 <faq@netzverwaltung.net>
|
|
| 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 <adam@berthold.example> und
|
|
| Charlotte Dominik <charlotte@dominik.example>.
|
|
|
|
|
| Die Submissionsadresse lautet <submissionen@domain.example>.
|
|
|
|
|
| Charta
|
|
| ------
|
|
|
|
|
| [Charta]
|
|
|
|
|
| Hintergrund / Begründung
|
|
| ----------- ----------
|
|
|
|
|
| [Begründung, ggf. untergliedert]
|
|
|
|
|
| Proponent(en)
|
|
| -------------
|
|
|
|
|
| [Name(n) und Mailadresse(n)]
|
|
|
|
Unter <http://piology.org/cgi-bin/rfd.pl> 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 <moderator@dana.de> 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
|
|
<http://dana.de/modkonzept.html>
|
|
|
|
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: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
|
|
|
|
| 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
|
|
<http://www.usevote.de/>.
|
|
|
|
* 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 <ihr.name@strg-alt-entf.org>
|
|
- Ralf Döblitz <doeblitz@doeblitz.net>
|
|
- Karsten Düsterloh <kd-usenet@tprac.de>
|
|
- Michael Grimm <trashcan@odo.in-berlin.de>
|
|
- Emil Schuster <emil@wieslauf.sub.de>
|
|
|
|
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
|
|
<gvv@dana.de> 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 <thh@votetaker.de>
|
|
| 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: http://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 <http://www.kirchwitz.de/~amk/dai/einrichtung> 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 <moderator@dana.de>
|
|
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
|
|
<http://groups.google.com/group/de.admin.news.announce/browse_frm/thread/fd056d977d6a5240>
|
|
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
|
|
<http://www.dana.de/archiv.html> 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 <moderator@dana.de>
|
|
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] <http://usenet.dex.de/>
|
|
|
|
* 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
|
|
<http://dana.de/modkonzept.html> 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: <Datum> 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
|
|
<http://dana.de/modkonzept.html>
|
|
|
|
+ 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: http://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?
|
|
<http://th-h.de/net/usenet/admin/newgroup/#vorschlag>
|
|
|
|
+ Erste Schritte zur Einrichtung neuer Gruppen
|
|
<http://web.archive.org/web/20070105012315/http://usenet.babylonsounds.com/rfd_howto.html>
|
|
|
|
+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|
|
| From: Ralf Döblitz <faq@netzverwaltung.net>
|
|
| 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" <gvv@spinfo.uni-koeln.de>
|
|
| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
|
|
| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
|
|
| Date: 2000/07/18
|
|
| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
|
|
<http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>
|
|
|
|
+ GVV-FAQ
|
|
| From: Thomas Hochstein <thh@votetaker.de>
|
|
| 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: http://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: <Admin-Filtermassnahmen-20110312-2@dana.de>
|
|
|
|
+ Unknown: NetNews Moderator's Handbook (1994, engl.)
|
|
<http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
|
|
|
|
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
|
|
<http://pages.swcp.com/~dmckeon/mod-faq.html>
|
|
|
|
+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
|
|
<http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
|
|
|
|
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
|
|
<http://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups>
|
|
|
|
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
|
|
<http://web.archive.org/web/20120310123625/www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
|
|
|
|
+ Informationen über de.alt.test.moderated
|
|
| From: Thomas Hochstein <thh@inter.net>
|
|
| 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
|
|
<http://www.dana.de/archiv.html>
|
|
|
|
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
|
|
<http://www.dana.de/>
|
|
|
|
+ "Aktueller Stand der Diskussionen und Abstimmungen" (dana-Status)
|
|
wöchentlich veröffentlicht in de.admin.news.announce
|
|
<http://www.dana.de/status.html>
|
|
|
|
+ RfD-Generator
|
|
<http://piology.org/cgi-bin/rfd.pl>
|
|
|
|
+ GVV-Statusübersicht
|
|
<http://votetakers.de/status.php>
|
|
|
|
+ Abstimmungssoftware UseVote
|
|
<http://www.usevote.de/>
|
|
|
|
+ de.* in Graphen
|
|
<http://usenet.dex.de/>
|
|
|
|
9. Maintainer und Kontakt
|
|
=========================
|
|
|
|
9.1. Derzeitige Maintainer
|
|
--------------------------
|
|
|
|
Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
|
|
Michael Ottenbruch <dana-manual@ottenbruch.net>
|
|
|
|
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 <dana-manual@usenet.th-h.de>
|
|
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
|
|
<https://code.th-h.de/?p=faqs/dana-manual.git> 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$
|