Path: senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!news.imp.ch!fu-berlin.de!stardust.hactar.de!.POSTED!gateway.krell.zikzak.de!not-for-mail
From: [email protected] (Thomas Hochstein / Michael Ottenbruch)
Newsgroups: de.admin.infos,de.answers,news.answers
Subject: <2018-01-27> Erlaeuterungen zur Einrichtung neuer Gruppen in de.*
Supersedes: <de-admin-infos/dana-manual/[email protected]>
Followup-To: de.admin.news.regeln
Date: 31 Jan 2018 23:00:03 -0000
Organization: Moderation von de.admin.infos
Lines: 2075
Sender: [email protected]
Approved: [email protected],[email protected]
Expires: Wed, 02 May 2018 23:00:02 +0000
Message-ID: <de-admin-infos/dana-manual/[email protected]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Summary: A newuser's guide on how to create new newsgroups in the German-language Usenet hierarchy de.*. In German.
X-PGP-Sig: 2.6.3in Subject,Message-ID,Date,From,Newsgroups,Approved,Supersedes
       iQCVAwUBWnJKc/d1G0T+jcJhAQGDTgP/egR0TY95oyJhFZcqSaYFdeRWotFzxEmm
       Te6TSRkIuWulWDAsaYueHDpGKIPTT15VAPYnjfCk0L1HkDAcnzpzVh5F1RZtZvMw
       rFJ6RONyYix93JniS2oUshU7FHOKKSYlyNF3JFVJxcav1pwcoOoNn5wi4W3lIgNt
       ob8z3tNvsNg=
       =tDMk
Xref: senator-bedfellow.mit.edu de.admin.infos:9389 de.answers:23326 news.answers:338909

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.2.4
Last-modified: 2018-01-27
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
URL: https://th-h.de/archives/faqs/dana-manual.txt

         Erl�uterungen zur Einrichtung neuer Gruppen in de.*
         ===================================================

Inhalt
------

0. Einleitung
  0.1. Zielgruppe und Inhalt
  0.2. Das Einrichtungsverfahren im �berblick
  0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
       0.3.1. Vorbereitung
       0.3.2. Diskussionsphase
       0.3.3. Abstimmungsphase
       0.3.4. Umsetzung

1. Vor�berlegungen
  1.1. Bedarf f�r eine neue Gruppe
  1.2. Status quo: bestehende Gruppen und fr�here Vorschl�ge
  1.3. Mitinteressenten

2. Einrichtungsvorschlag
  2.1. Auswahl des Gruppennamens
       2.1.1. Einordnung
       2.1.2. Namenswahl und technische Vorgaben
  2.2. Kurzbeschreibung
  2.3. Charta
  2.4. Status
       2.4.1. Pro und contra moderierte Gruppen
       2.4.2. Einrichtung moderierter Gruppen
  2.5. Sonderf�lle

3. Diskussionsphase
  3.1. Inhalt und Aufbau eines RfD
       3.1.1. Inhalt
       3.1.2. Formale Gestaltung
  3.2. Einreichung des RfD
  3.3. Diskussionsphase
  3.4. �berleitung zur Abstimmung oder R�ckzug des Vorschlags

4. Abstimmungsphase
  4.1. Voraussetzungen f�r die Durchf�hrung einer Abstimmung
  4.2. Inhalt und Aufbau eines CfV
  4.3. Sonderfall: CfV mit pers�nlichem Wahlschein
  4.4. Abstimmungsphase
  4.5. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Sonderfall: Vereinfachtes Verfahren (VV)

7. L�schungen, Umbenennungen, Status- und Regel�nderungen u.�.
  7.1. Gruppenl�schungen
  7.2. Umbenennungen
  7.3. �nderungen von Charta und/oder Kurzbeschreibung
  7.4. Status�nderungen
  7.5. Regel�nderungen und Personenwahlen

8. Quellen
  8.1. Grundlegende Informationen
  8.2. Weiterf�hrende Hinweise
  8.3. Webseiten

9. Maintainer und Kontakt
  9.1. Derzeitige Maintainer
  9.2. Fr�here Fassungen

======================================================================

0. Einleitung
=============

0.1. Zielgruppe und Inhalt
--------------------------

Dieser Text richtet sich an diejenigen, die eine Newsgroup in der
internationalen deutschsprachigen Usenet-Hierarchie de.* einrichten
lassen wollen und soll die in den "REGELN F�R DIE EINRICHTUNG 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: [email protected] (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: [email protected] (Thomas Hochstein)
| Newsgroups: de.admin.infos
| Subject: <2018-01-27> Wichtige Begriffe in de.admin.news.*
|
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Version: 1.5.3
| Last-modified: 2018-01-27
| URL: https://th-h.de/archives/faqs/dan-glossar.txt
| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar


0.3. Ablauf und einzelne Phasen des Einrichtungsverfahrens
----------------------------------------------------------

Das Einrichtungsverfahren l�sst sich in folgende Phasen unterteilen,
die im Folgenden dann n�her erl�utert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information �ber den status quo, Bedarfsabsch�tzung
* Suche nach anderen Interessierten, ggf. interne Diskussion
* Ausformulierung eines f�rmlichen Einrichtungsvorschlag (RfD)
* Einreichung des RfD bei der Moderation von de.admin.news.announce

Mit der Einreichung des RfD durch den Vorschlagenden ("Proponent")
enden die Vorbereitungen; das Verfahren wird in die Status�bersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erh�lt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer pr�ft
den RfD (und die weiteren Verfahrensbeitr�ge) auf Vereinbarkeit mit
den Regeln, nimmt die n�tigen Ver�ffentlichungen in
de.admin.news.announce vor und steht dem Proponenten auch als
Ansprechpartner (und in gewissem Umfang Berater) f�r sich im Verlauf
des Verfahrens ergebende Fragen zur Verf�gung.

[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem
   Betreff "dana-Status" w�chentlich in de.admin.news.announce
   ver�ffentlicht und im WWW unter <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?
 <https://th-h.de/net/usenet/admin/newgroup/#vorschlag>

+ Missverstaendnisse in de.admin.news.groups
| From: [email protected] (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: Thomas Hochstein <[email protected]>
| 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" <[email protected]>
|   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: <[email protected]>
   <https://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. <[email protected]> (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.)
 <https://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.)
 <https://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
 <http://www.big-8.org/articles/m/o/d/Moderated_Newsgroups.html>
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
 <http://www.big-8.org/articles/m/o/d/Moderated_Newsgroups.html#Moderation_Software>
+ Informationen �ber de.alt.test.moderated
| From: Thomas Hochstein <[email protected]>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2018-01-09>
|
| Posting-frequency: monthly
| Last-modified: 2018-01-09
| URL: https://th-h.de/net/usenet/faqs/datm-info/


2.5. Sonderf�lle
----------------

Die vorstehenden Erl�uterungen decken den Regelfall der Einrichtung
einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene
Sonderf�lle:

* Aufteilung von Gruppen

 Wenn eine bestehende Newsgroup aufgrund der regen Nutzung in mehrere
 Gruppen unterteilt werden soll, entsteht daraus in der Regel eine
 neue Teilhierachie (ein neuer Zweig am Baum der Struktur von de.*).
 Die Einrichtungsregeln sehen f�r diesen Fall in Punkt 7 folgendes
 vor:

| .misc-Gruppen: Bei der Einrichtung einer neuen Unterhierarchie --
|   sei es durch Umwandlung einer bestehenden Gruppe oder durch
|   Neuschaffung -- wird ohne gesonderte Abstimmung eine auf .misc
|   endende Gruppe eingerichtet. Der zur Gr�ndung der Hierarchie
|   f�hrende RfD hat hierzu die notwendigen Angaben bereitzustellen.
|   Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
|   findet hier�ber eine normale Abstimmung statt.

 Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe f�r
 Ausr�stungsfragen ("de.rec.outdoors.ausruestung") abgespalten
 werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
 eingerichtet werden. Dies geschieht regelm��ig durch Umbenennung der
 bestehenden Gruppe "de.rec.outdoors". Der Einrichtungsvorschlag muss
 also auch dazu Informationen enthalten.

* Einrichtung einer neuen Teilhierarchie

 Das gleiche gilt, wenn nicht nur eine einzelne neue Gruppe
 vorgeschlagen werden soll, sondern direkt mehrere, thematisch
 zusammenh�ngende, also auf diese Weise eine neue Teilhierachie
 entsteht.

 Wenn bspw. die neuen Gruppen "de.rec.fischen.angel" und
 "de.rec.fischen.koeder" vorgeschlagen werden, entsteht automatisch
 eine weitere Gruppe "de.rec.fischen.misc", die alle sonstigen Themen
 aus dem Bereich "Fischen" aufnehmen kann, die weder mit Angeln noch
 mit K�dern zu tun haben. Die entsprechenden Informationen - Name,
 Kurzbeschreibung, Charta - m�ssen ebenfalls im Einrichtungsvorschlag
 enthalten sein.

* Einrichtung mehrerer Gruppen

 In einem Einrichtungsvorschlag sollte nur dann die Einrichtung
 mehrerer Gruppen zusammengefasst werden, wenn diese in einem inneren
 Zusammenhang stehen, wenn bspw. eine bestehende Gruppe aufgeteilt
 werden oder direkt eine komplette neue Teilhierarchie eingerichtet
 werden soll. In diesem Fall muss der Einrichtungsvorschlag dann f�r
 alle Gruppen die notwendigen Informationen bereitstellen.

 Zu ber�cksichtigen ist, dass Vorschl�ge grunds�tzlich nicht "en
 bloc" zur Abstimmung gestellt werden k�nnen; vielmehr ist �ber jeden
 Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
 Teil 7 folgende Vorgaben:

| �bertragbarkeit: Stimmen k�nnen nicht auf einen anderen
|   Abstimmungsvorschlag �bertragen werden. Eine Stimme z�hlt nur f�r
|   GENAU DEN Vorschlag, f�r den sie abgegeben wurde. Insbesondere
|   darf eine Stimme f�r oder gegen eine Newsgruppe mit einem
|   bestimmten Namen NICHT als Stimme f�r oder gegen eine Newsgruppe
|   mit einem anderen Namen oder einer anderen Charta, einem anderen
|   unmoderiert/moderiert Status oder, falls moderiert, einem anderen
|   Moderator oder einer anderen Gruppe von Moderatoren gez�hlt
|   werden. �ber jede Gruppe wird einzeln abgestimmt, Verkn�pfungen
|   von Wahlen sind nicht m�glich.

* Diskussion mehrerer Alternativen

 Ziel der Diskussion sollte es regelm��ig sein, am Ende der
 Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
 Das schlie�t nicht aus, in der Diskussion zun�chst mehrere denkbare
 Alternativen vorzuschlagen; die Diskussion sollte aber schlie�lich
 zu einem mehrheitsf�higen Vorschlag f�hren. Ggf. kann dazu auch ein
 unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
 sich ausschlie�ende Alternativen zur Abstimmung zu stellen sollte
 nach M�glichkeit vermieden werden, weil die Abstimmung sonst
 einerseits schnell sehr kompliziert wird und andererseits die Gefahr
 besteht, dass entweder kein Vorschlag eine Mehrheit erh�lt (obwohl
 die Mehrzahl der Abstimmenden durchaus generell f�r eine Einrichtung
 der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
 Vorschl�gen angenommen wird, das so niemand gewollt hat.

 Die f�r die Abstimmung in diesem Fall zu beachtenden Regeln f�r
 "kombinierte Votings" finden sich in Teil 9 der Einrichtungsregeln
 und lauten folgenderma�en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h�chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird �ber die Einrichtung jeder einzelnen Gruppe gem�� den
| obigen Regeln abgestimmt.
|
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zus�tzlich ein Stichentscheid zwischen all diesen Gruppen statt.
| Falls in den Einrichtungsfragen mehr als eine Gruppe angenommen
| wird, so wird davon einzig diejenige eingerichtet, welche im
| Stichentscheid das beste Verh�ltnis Zustimmung : Ablehnung aufweist.

 Siehe dazu auch:

 + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|   From: Ralf D�blitz <[email protected]>
|   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 <[email protected]> und
| Charlotte Dominik <[email protected]>.
|
| Die Submissionsadresse lautet <[email protected]>.
|
| 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 <[email protected]> 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: [email protected] (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: [email protected] (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: <[email protected]>
|
|   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 <[email protected]>
 - Ralf D�blitz <[email protected]>
 - Karsten D�sterloh <[email protected]>
 - Michael Grimm <[email protected]>
 - Emil Schuster <[email protected]>

 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
 <[email protected]> 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 <[email protected]>
|   Newsgroups: de.admin.infos,de.admin.news.groups
|   Subject: <2017-08-19> GVV-FAQ
|
|   Archive-name: de-admin/gvv-faq
|   Posting-frequency: weekly
|   Last-modified: 2017-08-19
|   URL: https://votetakers.de/faq.php
|   URL: http://www.kirchwitz.de/~amk/dai/gvv-faq

4.2. Inhalt und Aufbau eines CfV
--------------------------------

Auch f�r den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er
muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name,
Kurzbeschreibung, Charta, Status, ggf. Moderator) und die f�r die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die
Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten.

Der Abstimmungszeitraum muss mindestens drei Wochen, darf aber
h�chstens einen Monat betragen. �blicherweise wird diese Frist nicht
ausgesch�pft, sondern stattdessen eine Abstimmungsdauer von vier
Wochen angesetzt. Das hat zum einen den Vorteil, dass die "Halbzeit",
nach der ein 2. CfV ver�ffentlicht werden soll, mit "zwei Wochen"
leichter bestimmbar ist. Zum anderen ist es �blich, Abstimmungen
um Mitternacht enden zu lassen. Daher k�nnten sich bei einer
Abstimmungsdauer von einem Monat und Ver�ffentlichung des 1. CfV bspw.
um 16:30 Uhr unn�tige Diskussionen ergeben, ob damit nicht die
H�chstfrist von einem Monat um siebeneinhalb Stunden (bis Mitternacht)
�berschritten wird.

Schlie�lich muss der CfV mit dem letzten RfD im wesentlichen
�bereinstimmen, wie Teil 6 der Einrichtungsregeln festh�lt:

| Nach der Diskussionsperiode kann ein Abstimmungsaufruf -- engl.
| "Call for Votes" oder kurz CfV -- bei der Moderation eingereicht
| werden. Dieser muss mit dem letzten RfD im wesentlichen
| �bereinstimmen.

Zweck dieser Regel ist es, zu verhindern, dass etwas anderes zur
Abstimmung gestellt wurde als zuvor Gegenstand der Diskussion war.
"Wesentlich" in diesem Sinne sind daher alle Eigenschaften der
einzurichtenden Gruppe sowie die Abstimmungsmodalit�ten; an diesen
d�rfen keine �ber die Behebung von Schreibfehlern o.�. hinausgehenden
�nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor
diskutierte. Eine �nderung der Begr�ndung - soweit sie �berhaupt im
CfV wiederholt wird - ist hingegen regelm��ig unproblematisch.

�blich ist es, auf Basis des letzten ver�ffentlichen RfD einen CfV zu
entwerfen. Dabei kann der Begr�ndungsteil gek�rzt werden oder ganz
entfallen und durch einen Verweis auf die gef�hrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugef�gt werden dann die
Abstimmungsmodalit�ten: Votetaker, Abstimmadresse, Abstimmungsende,
ggf. Kurzhinweise zum Vorgehen bei der Abstimmungsteilnahme,
Wahlschein. Zwar empfehlen die Einrichtungsregeln, Beispiele f�r
Stimmabgaben in den CfV aufzunehmen; dies ist jedoch absolut un�blich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
n�mlich als �berfl�ssig; bei komplexeren Abstimmungen hingegen w�rde
die Darstellung aller m�glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma�en un�bersichtlich und aufwendig,
dass regelm��ig darauf verzichtet wird. Wenn jedoch die einzelnen
Abstimmungsm�glichkeiten dargestellt werden, dann m�ssen sowohl die
Abstimmungsm�glichkeiten f�r wie auch die gegen einen Vorschlag
dargestellt werden, um eine Beeinflussung der Abstimmungsteilnehmer zu
vermeiden.

Beispiele f�r CfVs finden sich in de.admin.news.announce. Eine
m�gliche Gestaltung w�re folgende:

|             1. CfV (Abstimmungsaufruf)
|             ==========================
|
| zur Einrichtung der neuen Gruppe
|
| [Gruppenname]   [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
|
| [Charta]
|
| Hintergrund / Begr�ndung
| -----------   ----------
|
| [kurze Begr�ndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
|
| [Name(n) und Mailadresse(n)]
|
| Abstimmungsmodalit�ten
| ----------------------
|
| Votetaker      : [Name und Mailadresse]
| Abstimmadresse : [Mailadresse]
| Abstimmungsende: Mit Ablauf des [Datum]
| Wahlschein     : Untenstehendes Formular ist zu verwenden. M�glich sind
|                  bei jedem Abstimmungspunkt JA, NEIN und ENTHALTUNG.
|
| Es gelten die Regeln zur "Einrichtung von Usenet-Gruppen in de.*" in
| der bei Beginn der Abstimmung g�ltigen Fassung, die in de.admin.infos
| und unter <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 <[email protected]>
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
   <https://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 <[email protected]>
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: [email protected] (Olaf Schneider), [email protected] (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: [email protected] (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: [email protected] (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: [email protected] (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
|
| Archive-name: de-admin/dang-faq
| Posting-frequency: weekly
| Last-modified: 2009-01-24
| URL: http://www.kirchwitz.de/~amk/dai/dang-faq

+ Die Newsgruppen der de-Hierarchie (Gruppenliste)
| From: Thomas Hochstein <[email protected]>
| 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: [email protected] (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: [email protected] (Thomas Hochstein)
| Newsgroups: de.admin.infos
| Subject: <2018-01-27> Wichtige Begriffe in de.admin.news.*
|
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Version: 1.5.3
| Last-modified: 2018-01-27
| URL: https://th-h.de/archives/faqs/dan-glossar.txt
| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar

+ Wann kann ich mit Erfolg eine neue Newsgroup vorschlagen?
 <https://th-h.de/net/usenet/admin/newgroup/#vorschlag>

+ Erste Schritte zur Einrichtung neuer Gruppen
 <https://web.archive.org/web/20070105012315/http://usenet.babylonsounds.com/rfd_howto.html>

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: Ralf D�blitz <[email protected]>
| 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" <[email protected]>
| 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: <[email protected]>
 <https://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>

+ GVV-FAQ
| From: Thomas Hochstein <[email protected]>
| Newsgroups: de.admin.infos,de.admin.news.groups
| Subject: <2017-08-19> GVV-FAQ
|
| Archive-name: de-admin/gvv-faq
| Posting-frequency: weekly
| Last-modified: 2017-08-19
| URL: https://votetakers.de/faq.php
| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq

+ Filterma�nahmen bei der Durchf�hrung von Abstimmungen
| From: [email protected] (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: <[email protected]>

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
 <https://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.)
 <https://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>

+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
 <http://www.big-8.org/articles/m/o/d/Moderated_Newsgroups.html>

+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
 <http://www.big-8.org/articles/m/o/d/Moderated_Newsgroups.html#Moderation_Software>

+ Informationen �ber de.alt.test.moderated
| From: Thomas Hochstein <[email protected]>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2018-01-09>
|
| Posting-frequency: monthly
| Last-modified: 2018-01-09
| URL: https://th-h.de/net/usenet/faqs/datm-info/

+ 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
 <https://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 <[email protected]>
                      Michael Ottenbruch <[email protected]>

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 <[email protected]>
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: 8b56032  (HEAD -> master, tag: 2.2.4) 2018-01-27 11:28:33 +0100 Thomas Hochstein

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.