dana-manual/dana-manual

Archive-name: de-newusers/dana-manual
Posting-frequency: weekly
Version: 2.1.5
Last-modified: (unreleased)
URL: http://www.kirchwitz.de/~amk/dai/dana-manual
URL: http://th-h.de/faq/dana-manual.txt

          Erl<72>uterungen zur Einrichtung neuer Gruppen in de.*         
          ===================================================

Inhalt
------

0. Einleitung
   0.1. Zielgruppe und Inhalt
   0.2. Das Einrichtungsverfahren im <20>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<6F>berlegungen
   1.1. Bedarf f<>r eine neue Gruppe
   1.2. Status quo: bestehende Gruppen und fr<66>here Vorschl<68>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<72>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. <20>berleitung zur Abstimmung oder R<>ckzug des Vorschlags

4. Abstimmungsphase
   4.1. Voraussetzungen f<>r die Durchf<68>hrung einer Abstimmung
   4.2. Inhalt und Aufbau eines CfV
   4.3. Abstimmungsphase
   4.4. Auswertung und Ergebnis der Abstimmung

5. Verfahrensabschluss und Umsetzung

6. Quellen
   6.1. Grundlegende Informationen
   6.2. Weiterf<72>hrende Hinweise
   6.3. Webseiten

7. Maintainer und Kontakt
   7.1. Derzeitige Maintainer
   7.2. Fr<46>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<EFBFBD>utern. Er gibt dabei notwendig den Blick der Autoren bzw.
Maintainer auf die Verh<72>ltnisse in de(.admin.news).* und ihre
Erfahrungen wieder.

[1] Ver<65>ffentlicht in de.admin.infos:
|   From: 3.14@piology.org (Boris 'pi' Piwinger)
|   Newsgroups: de.admin.infos,de.alt.admin
|   Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
|   
|   Archive-name: de-admin/einrichtung
|   Posting-frequency: weekly
|   Last-modified: 2005-08-06
|   URL: http://www.kirchwitz.de/~amk/dai/einrichtung

(Eine Liste aller in diesen Erl<72>uterungen genannten Quellen findet
sich noch einmal in Abschnitt 6.)

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<6E>chige Diskussion keinen gar zu heftigen
Gegenwind, wird die Gruppe eingerichtet.

0.2. Das Einrichtungsverfahren im <20>berblick
-------------------------------------------

Newsgroups werden nicht auf einem zentralen Server angeboten, sondern
dezentral auf vielen verschiedenen Newsservern gef<65>hrt, die ihre
Beitr<EFBFBD>ge jeweils untereinander austauschen. Damit das funktionieren
kann und jeder Benutzer dieselben Newsgroups zur Verf<72>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<EFBFBD>glich. Daher werden f<>r gepflegte Newsgroups-Hierarchien wie de.*
Listen der Newsgroups gef<65>hrt, die zur Hierarchie geh<65>ren; mit dieser
Liste kann dann jeder Newsserverbetreiber seinen Gruppenbestand
abgleichen.

F<EFBFBD>r de.* wird die definitive Liste der bestehenden Newsgroups von der
Moderation von de.admin.news.announce gef<65>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<EFBFBD>r die Aufstellung dieser Liste sind vielerlei M<>glichkeiten denkbar;
in de.* entscheiden die Benutzer <20>ber ihren Inhalt. <20>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 <20>berlegungsphase vorangehen,
in der Bedarf und Attribute der neuen Gruppe (Name, Kurzbeschreibung,
Status, Charta) einschlie<69>lich ihrer Einordnung in den bestehenden,
hierarchisch strukturierten Gruppenbestand durchdacht und ggf. auch
mit anderen Interessenten diskutiert werden k<>nnen. Am Ende dieser
Vor<EFBFBD>berlegungen steht dann zumeist ein erster Vorschlag, wie die neue
Gruppe hei<65>en soll, was ihre Inhalte sein werden und wie sie sich
thematisch gegen<65>ber bestehenden Gruppen abgrenzt. Mit der
Ver<EFBFBD>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<65>hrt wird, wird der Vorschlag auf
inhaltliche Qualit<69>t und Akzeptanz abgeklopft und ggf. ver<65>ndert oder
verfeinert; nicht selten folgen ein oder mehrere weitere RfDs, bis der
Vorschlag abstimmungsreif erscheint. Die Ver<65>ffentlichung eines
Abstimmungsaufrufs ("Call for Votes", kurz "CfV") beendet dann die
Diskussionsphase und leitet in die Abstimmungsphase <20>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: bernd@tenuki.de (Bernd Gramlich)
| Newsgroups: de.admin.infos
| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
| 
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Last-modified: 2004-12-06
| URL: http://www.tmt.de/~gramlich/dan-glossar.html
| 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<72>utert werden sollen:

0.3.1. Vorbereitung

* Ideenfindung
* Information <20>ber den status quo, Bedarfsabsch<63>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<75>bersicht
der Moderation von de.admin.news.announce [2] aufgenommen und erh<72>lt
einen Verfahrensbetreuer zugewiesen. Dieser Verfahrensbetreuer pr<70>ft
den RfD (und die weiteren Verfahrensbeitr<74>ge) auf Vereinbarkeit mit
den Regeln, nimmt die n<>tigen Ver<65>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<72>gung.

[2] "Aktueller Stand der Diskussionen und Abstimmungen", unter dem
    Betreff "dana-Status" w<>chentlich in de.admin.news.announce
    ver<65>ffentlicht und im WWW unter <http://www.dana.de/status.html>
    abrufbar.

0.3.2. Diskussionsphase

* Beginn mit Ver<65>ffentlichung des 1. RfD in de.admin.news.announce,
  de.admin.news.groups und weiteren betroffenen Newsgroups
* <20>ffentliche Diskussion des Vorschlags in de.admin.news.groups
* Mindestdauer: 14 Tage
* Einreichung beliebig vieler weiterer RfDs mit ge<67>nderten Vorschl<68>gen

Der Diskussion sollte ausreichend Zeit gelassen werden, um die Meinung
der <20>brigen Teilnehmer zu ergr<67>nden; <20>nderungsvorschl<68>ge k<>nnen
gesammelt und in einer neuen Fassung des Vorschlags (als 2. RfD, 3.
RfD usw.) aufgenommen werden. Wenn alle Facetten er<65>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<75>ckzieht. Die zur Abstimmung gestellte Fassung
muss mit dem letzten ver<65>ffentlichen RfD im Wesentlichen
<EFBFBD>bereinstimmen.

Die Diskussionsphase endet mit dem Abbruch des Verfahrens (durch
R<EFBFBD>ckzug des Vorschlags oder Verfall durch Nichtbetreiben <20>ber f<>nf
Wochen) oder der Ver<65>ffentlichung des 1. CfVs.

0.3.3. Abstimmungsphase

* Beginn mit Ver<65>ffentlichung des 1. CfV in de.admin.news.announce und
  den <20>brigen Gruppen
* Abstimmung erfolgt per E-Mail, Stimmabgaben werden in der Regel per
  E-Mail best<73>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<6E>chige Einspruchsfrist

Die Abstimmung wird durch einen Abstimmungsleiter ("Votetaker")
durchgef<EFBFBD>hrt, der den 1. CfV zur Ver<65>ffentlichung einreicht, die
Stimmen per E-Mail sammelt, best<73>tigt und ausz<73>hlt und am Ende das
Ergebnis der Abstimmung zur Ver<65>ffentlichung einreicht. Es muss sich
dabei ausdr<64>cklich nicht um dieselbe Person wie den Proponenten
handeln; da die Durchf<68>hrung und Ausz<73>hlung einer Abstimmung einen
gewissen technischen und organisatorischen Aufwand erfordert und auch
Erfahrung im Umgang mit Zweifelsf<73>llen - auch Manipulationsversuchen -
w<EFBFBD>nschenswert ist, besteht die M<>glichkeit, einen erfahrenen Usenet-
Teilnehmer um die <20>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<65>ffentlichung des Ergebnisses. Daran schlie<69>t
sich ein einw<6E>chiger Einspruchszeitraum an, in dem Regelverst<73><74>e durch
einen Einspruch bem<65>ngelt werden k<>nnen. Nach Verstreichen dieses
Zeitraums wird das Ergebnis der Abstimmung bestandskr<6B>ftig.

0.3.4. Umsetzung

Wenn der Vorschlag in der Abstimmung angenommen wurde - wozu
mindestens 60 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<6F>berlegungen
==================

1.1. Bedarf f<>r eine neue Gruppe
--------------------------------

Ganz am Anfang der <20>berlegungen zur Einrichtung einer neuen Newsgroup
stellt sich zun<75>chst die Frage, ob die angedachte Gruppe denn auch
tats<EFBFBD>chlich ben<65>tigt wird und der Vorschlag Aussicht auf Erfolg hat.
Das ist zumeist nur dann der Fall, wenn mit einer ausreichenden
zuk<EFBFBD>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 <20>berf<72>llt ist.

Die zuk<75>nftige Nutzungsintensit<69>t der vorgeschlagenen Gruppe wird
dabei regelm<6C><6D>ig anhand der derzeitigen Lage beurteilt:

* Gibt es bereits Diskussionen zu dem Thema im Usenet?

* Wenn ja: Ist die bisher daf<61>r genutzte Gruppe <20>berf<72>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<73>ndig ist; die
  meisten denkbaren Themen passen in eine oder mehrere bereits
  bestehende Gruppen thematisch hinein.

  Sind die derzeitigen Diskussionsteilnehmer bereit, zuk<75>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<75>tzlich zu diesem auch das Usenet als Diskussionsmedium zu
  benutzen?

* Wenn nein: Warum ist dennoch damit zu rechnen, dass die Gruppe
  zuk<75>nftig einigerma<6D>en intensiven Zuspruch erfahren wird?

Die Erfahrung hat gezeigt, dass die empfundene oder tats<74>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 <20>berdies dahin, dass es nicht sinnvoll ist,
f<EFBFBD>r "Orchideenthemen" eigene Newsgroups einzurichten, die dann
(weitgehend) ungenutzt bleiben; vielmehr wird es <20>berwiegend als
w<EFBFBD>nschenswert empfunden, lieber weniger thematisch breiter
aufgestellte Gruppen zu haben, die dann intensiver genutzt werden und
auf diese Weise den gegenseitigen Austausch beleben und f<>rdern.

Siehe auch:

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

+ Missverstaendnisse in de.admin.news.groups
| From: 3.14@piology.org (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
| 
| Archive-name: de-admin/dang-faq
| Posting-frequency: weekly
| Last-modified: 2009-01-24
| URL: http://www.kirchwitz.de/~amk/dai/dang-faq

1.2. Status quo: bestehende Gruppen und fr<66>here Vorschl<68>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<EFBFBD>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<73>ter wieder aus der Gruppenliste
entfernt wurde? Aus diesen <20>berlegungen ergeben sich Hinweise auf die
Erfolgsaussichten des Vorschlags und m<>glicherweise auch Anregungen
f<EFBFBD>r seinen Inhalt. Nicht zu empfehlen ist es, einen gescheiterten
Vorschlag vor Ablauf von mindestens sechs Monaten oder ohne
wesentliche <20>nderungen in Inhalt oder Begr<67>ndung erneut einzubringen.

[3] Am bekanntesten d<>rfte das Angebot von Google Groups sein:
    <http://groups.google.com/>

    de.admin.news.announce bei Google Groups:
    <http://groups.google.com/group/de.admin.news.announce/>

    Erweiterte Suche: <http://groups.google.com/advanced_search>

1.3. Mitinteressenten
---------------------

     "Gemeinsam sind wir stark."

In der Diskussionsphase kommt es weniger auf die Anzahl der
Bef<EFBFBD>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<47>beln im stillen K<>mmerlein.

Auch in der Diskussion ist es f<>rderlich, einen Vorschlag nicht
alleine argumentativ zu st<73>tzen; nicht nur deshalb, weil eine Mehrzahl
von Interessenten, die sich auch selbst in die Diskussion einbringt,
<EFBFBD>berzeugender ein dauerhaftes Interesse signalisiert als ein
Einzelner. Auch aus psychologischen Gr<47>nden ist es angenehmer, die
eigene Position nicht alleine vertreten zu m<>ssen.

Eine Mitwirkung anderer Interessenten kann dabei auf vielf<6C>ltige Weise
erfolgen. Ein Vorschlag kann durch mehrere Proponenten eingebracht
werden; die Mitwirkung kann sich aber auch auf Unterst<73>tzung bei
inhaltlichen und Formulierungsfragen oder der formalen Abwicklung des
Einrichtungsverfahrens oder Beitr<74>ge in der Diskussionsphase
beschr<EFBFBD>nken.

2. Einrichtungsvorschlag
========================

Vor der Einrichtung einer neuen Newsgroup oder dem Beginn der
Abstimmung <20>ber den entsprechenden Vorschlag m<>ssen nach den
Einrichtungsregeln Name und Attribute der vorgeschlagenen Gruppe
feststehen:

|   Ein CfV kann nicht ver<65>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 <20>hnlichen Gruppen ihren Platz
finden.

Sinnvoll ist es daher, sich zun<75>chst Gedanken <20>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
<EFBFBD>berlegen, wo die Gruppe in de.* thematisch am besten passt und wie sie
demnach hei<65>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; <20>berdies sollte ein
Konzept f<>r die Moderation vorliegen und die technischen
Voraussetzungen hinreichend gekl<6B>rt sein.

2.1. Auswahl des Gruppennamens
------------------------------

2.1.1. Einordnung

Zun<EFBFBD>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<65>stelungen aufweisen. Diese Struktur
ist im Lauf der Zeit gewachsen; nicht immer ist sie daher vollst<73>ndig
logisch stringent, und regelm<6C><6D>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<EFBFBD>hen, den bestm<74>glichen Ort f<>r die neue Gruppe zu finden. Dazu
geh<EFBFBD>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<EFBFBD>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<63>ftigen sich mit den
  - im Usenet umf<6D>nglich vertretenen - Themenbereichen der
  Kommunikation und Kommunikationstechnik und sind daher noch weiter
  diversifiziert, im Wesentlichen in die Bereiche

  * Anbieter: 
  de.comm.anbieter.* - Festnetz- und Mobiltelefonprovider und Tarife
  de.comm.provider.* - Internetprovider und Onlinedienste

  * Ger<65>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<69>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<65>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<63>ftigt sich mit
  Freizeitaktivit<69>ten ("recreational activities") aller Art und
  enth<74>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<65>ren das Bahnwesen, Autos und andere Fahrzeuge,
  Finanzen und Banking, (kreatives) Schreiben und Sprache, Post,
  Notfallrettung und Milit<69>rwesen oder auch die Haushaltsf<73>hrung.

* de.markt.*
  In de.markt.*, dem Kleinanzeigenbereich des deutschsprachigen
  Usenets, - und nur hier! - haben private, nicht-kommerzielle
  Angebote und Gesuche Platz.

Siehe auch:

+ Die Newsgruppen der de-Hierarchie
| From: Daniel Roth <25.8@bluemail.ch>
| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
| Subject: <Datum> Die Newsgruppen der de-Hierarchie
| 
| Archive-name: de-newusers/de-newsgruppen
| Posting-frequency: weekly
| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen

2.1.2. Namenswahl und technische Vorgaben

Der "eigentliche" Name der Gruppe, insbesondere also der letzte
Namensbestandteil, sollte so aussagekr<6B>ftig und allgemeinverst<73>ndlich,
aber zugleich auch so kurz wie m<>glich gew<65>hlt werden. Kryptische oder
mehrdeutige Abk<62>rzungen sollte man m<>glichst nicht verwenden. Wenn
diese gar nicht zu vermeiden sind, sollten sie in der
Kurzbeschreibung, sp<73>testens aber in der Charta erl<72>utert werden.

F<EFBFBD>r die Wahl des Gruppennamens sind zudem technisch gepr<70>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
  <20>berschreiten.

[4] Beschlossen im Jahr 2000: 
|   From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
|   Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
|   Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
|   Date: 2000/07/18
|   Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
    <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>

2.2. Kurzbeschreibung
---------------------

Die Kurzbeschreibung soll in Erg<72>nzung zum Gruppennamen das Thema kurz
umrei<EFBFBD>en. Im Gegensatz zur Charta, der ausf<73>hrlichen thematischen
Beschreibung des Gruppeninhalts, wird sie in der Regel zusammen mit
dem Gruppennamen auf den Newsservern vorgehalten und kann in den
g<EFBFBD>ngigen Newsreadern angezeigt und ggf. auch durchsucht werden;
Gruppenname und Kurzbeschreibung zusammen werden auch "Tagline"
genannt. Diese Tagline ist auch Bestandteil der regelm<6C><6D>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<73>ndlich sein. "Diskussion
<EFBFBD>ber" oder "Informationen von" sind zum Beispiel notorisch
<EFBFBD>berfl<EFBFBD>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<68>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<65>hnlich eine Maximall<6C>nge
von 60 Zeichen.

Kann ein Newsreader - aus welchem Grund auch immer - nicht die ganze
Kurzbeschreibung anzeigen, wird er sich <20>blicherweise auf den Anfang
der Kurzbeschreibung beschr<68>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<EFBFBD>hrlich wie n<>tig umrei<65>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
<EFBFBD>blichkeiten im deutschsprachigen Usenet - gelten sollen.

Es ist hilfreich, f<>r das Thema der Gruppe einige Beispiele als nicht
abschlie<EFBFBD>ende Aufz<66>hlung aufzunehmen; so lassen sich auch (weitere)
Schlagworte unterbringen, nach denen m<>glicherweise gesucht wird.
Dabei ist aber zu ber<65>cksichtigen, dass die Charta nur in
entsprechenden Listen im Usenet und auch im WWW ver<65>ffentlicht wird,
aber im Gegensatz zu Namen und Kurzbeschreibung nicht unmittelbar im
Newsreader zur Verf<72>gung steht.

Wenn bestimmte Facetten eines Themas in der neuen Gruppe nicht
diskutiert werden sollen, obwohl m<>glicherweise Name und
Kurzbeschreibung bei fl<66>chtiger Durchsicht zu dieser Annahme f<>hren
k<EFBFBD>nnten, empfiehlt es sich, diese Facetten - oder Themen - in der
Charta ausdr<64>cklich auszuschlie<69>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<74>nderung n<>tig w<>rde.

Soweit in der vorgeschlagenen Newsgroup teilweise andere Konventionen
gelten sollen als sonst im Netz <20>blich sollte auch dies in der Charta
vermerkt werden. Zu denken w<>re bspw. an die (ausdr<64>ckliche) Akzeptanz
anonymer Beitr<74>ge oder von Inseraten. Gleichfalls sollten vorgesehene
ungewohnte technische Ma<4D>nahmen - zu denken w<>re hier bspw. an die
Eingangsbest<EFBFBD>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<65>cksichtigt werden, dass eine
Wiederholung ohnehin bestehender Regeln und Konventionen in der Charta
in der Regel ausdr<64>cklich abgelehnt wird, sowohl wegen der unn<6E>tigen
Verl<EFBFBD>ngerung der Charta als auch, weil dies den Eindruck vermitteln
k<EFBFBD>nnte, die entsprechenden Regeln und Konventionen h<>tten nur dort
Geltung, wo sie ausdr<64>cklich in der Charta stehen. Andererseits darf
man bei der Formulierung solcher abweichenden <20>blichkeiten nicht aus
den Augen verlieren, dass sowohl technische als auch soziale Vorgaben
in der Regel gute Gr<47>nde haben und zudem als feststehende Gewohnheiten
betrachtet werden, so dass Abweichungen vom Regelfall meist nur bei gut
begr<EFBFBD>ndeten Sonderf<72>llen Aussicht auf Erfolg haben werden.

Die Charta sollte so knapp wie m<>glich gehalten werden; weitergehende
Erl<EFBFBD>uterungen und solche Regeln, die sich voraussichtlich h<>ufiger
<EFBFBD>ndern werden, geh<65>ren nicht in die Charta, sondern sollten Gegenstand
einer (regelm<6C><6D>ig geposteten und nach M<>glichkeit auch im WWW
bereitgestellten) Einf<6E>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<72>hnung finden;
die einzelnen angedachten Tags geh<65>ren dann in eine anderweitig
bereitgestellte Erl<72>uterung. Auch das Moderationskonzept einer
moderierten Gruppe geh<65>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<65>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<65>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<EFBFBD>pfige Moderation). Diese entscheidet dann <20>ber die
Ver<EFBFBD>ffentlichung.

2.4.1. Pro und contra moderierte Gruppen

Moderierte Gruppen haben den Vorteil einer meist besseren
<EFBFBD>bersichtlichkeit und h<>heren inhaltlichen Qualit<69>t, weil Beitr<74>ge
vorgefiltert werden k<>nnen; ihr Nachteil ist die zwangsl<73>ufig
entstehende Verz<72>gerung durch die Weiterleitung jedes Beitrags an
einen Moderator, der ihn best<73>tigen muss. Sie eignen sich daher vor
allem f<>r Ank<6E>ndigungen oder FAQs. Ein Beispiel hierf<72>r ist
de.admin.news.announce, wo nur Aufrufe zu Diskussionen und
Abstimmungen ver<65>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 <20>berpr<70>fung der
Ver<EFBFBD>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<65>ffentlicht werden.

Diskussionsgruppen werden nur selten moderiert. Dies kann zwar der
Erhaltung einer h<>heren inhaltlichen Qualit<69>t dienen und erm<72>glicht
vor allem den Ausschluss von bewussten St<53>rern, begegnet im Gegenzug
aber oft dem Vorwurf der Zensur, so unbegr<67>ndet dieser im Einzelfall
auch sein mag, und birgt vor allem die Gefahr, dass die auftretenden
Verz<EFBFBD>gerungen vor Ver<65>ffentlichung eines Beitrags den Fluss der
Diskussion st<73>ren und an Ver<65>ffentlichung ihrer Beitr<74>ge in Echtzeit
gewohnte Teilnehmer verprellen. Au0erdem ist der technische und vor
allem personelle Aufwand nicht zu untersch<63>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<74>ge so zeitnah wie
m<EFBFBD>glich zu pr<70>fen und freizugeben.

2.4.2. Einrichtung moderierter Gruppen

Wenn die Einrichtung einer moderierten Gruppe vorgeschlagen wird, sind
im Einrichtungsverfahren zus<75>tzliche Angaben zur Moderation zu machen;
dazu geh<65>ren der oder die vorgesehene(n) Moderator(en) und die
Moderationsadresse, also die E-Mail-Adresse, an die alle Einreichungen
f<EFBFBD>r die Newsgroup zur Freigabe weitergeleitet werden sollen. Au<41>erdem
muss die Kurzbeschreibung entsprechend erg<72>nzt werden. Schlie<69>lich
sollte f<>r die Durchf<68>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<65>ffentlichung des Vorschlags seine entsprechende Bereitschaft
  erkl<6B>rt haben; in der Regel wird es sich empfehlen, ein mehrk<72>pfiges
  Team oder zumindest einen oder mehrere Vertreter zu benennen, damit
  auch im Falle eines mehrw<72>chigen Urlaubs oder gar eines dauerhaften
  Ausfalls des Moderators - der bspw. irgendwann am Usenet nicht mehr
  interessiert sein mag  - die Moderation handlungsf<73>hig bleibt und
  Beitr<74>ge weiterhin ver<65>ffentlicht werden k<>nnen. F<>r moderierte
  Diskussionsgruppen wird regelm<6C><6D>ig ein ausreichend gro<72>es Team
  zwingend vorzusehen sein, damit Beitr<74>ge zumindest tags<67>ber zeitnah
  ver<65>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<69>lich absehbar
  f<>r l<>ngere Zeit f<>r diese T<>tigkeit zur Verf<72>gung stehen. Erfahrung
  im Usenet und ggf. die notwendigen technischen Kenntnisse zur
  Durchf<68>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 <20>ndern; au<61>erdem sollte die Adresse
  zuverl<72>ssig erreichbar sein und ggf. die M<>glichkeit f<>r
  ausreichende Spamfilterung bieten; langj<67>hrig aktive und regelm<6C><6D>ig
  ver<65>ffentliche Mailadressen ziehen mit der Zeit erhebliche Mengen an
  Spam an.

  Daneben sollte eine weitere Adresse ver<65>ffentlicht werden, <20>ber die
  der Moderator oder die Moderation kontaktiert werden k<>nnen, ohne
  dass eine Ver<65>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<68>sselwort
  "(Moderated)" in exakt dieser Schreibweise enden, bspw. so:
| de.gruppe.mod   Moderierte Gruppe. <moderation@domain.example> (Moderated)

* Falls die zu moderierende Gruppe keine Diskussionsgruppe ist,
  sondern nur Ank<6E>ndigungen, FAQs o.<2E>. enthalten soll, sollte eine
  Gruppe bestimmt werden, in der diese Ank<6E>ndigungen oder FAQs
  anschlie<69>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<74>ge akzeptiert oder zur<75>ckgewiesen werden, ob
  sie ggf. ver<65>ndert ver<65>ffentlicht werden k<>nnen und wie mit
  Teilnehmern ggf. kommuniziert wird. Insbesondere bei einer
  mehrk<72>pfigen Moderation stellt dies eine einheitliche Handhabung
  sicher. Dieses Konzept sollte bereits in der Diskussion vorgestellt
  werden und danach (regelm<6C><6D>ig) ver<65>ffentlicht werden.

  Entsprechende Beispiele finden sich in bereits bestehenden
  moderierten Gruppen; der bereits genannte Text "Die Newsgruppen der
  de-Hierarchie" enth<74>lt teilweise Verweise darauf.

* Die Moderation einer Newsgroup erfordert in technischer Sicht eine
  M<>glichkeit, einen per E-Mail <20>bersandten Beitrag unter Beibehaltung
  der wesentlichen Informationen auch im Header - aber unter Wegfall
  mancher und Erg<72>nzung anderer Headerzeilen - als Posting zu
  ver<65>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<73>tzen. In der Regel wird die Moderation einer Newsgroup also
  die Installation entsprechender Software auf dem eigenen Rechner
  oder sogar die Einrichtung auf einem <20>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<72>gung zu stellen. Die Auswahl und Erprobung der
  vorgesehenen Moderationssoftware bzw. entsprechende Nachfragen und
  Kontaktaufnahmen sollten aber sp<73>testens parallel zum laufenden
  Einrichtungsverfahren erfolgen; Tests k<>nnen bspw. in der Newsgroup
  de.alt.test.moderated erfolgen.

Siehe auch:

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
  <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>
+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
  <http://pages.swcp.com/~dmckeon/mod-faq.html>
+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
  <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>
+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
  <http://www.big-8.org/wiki/Moderated_Newsgroups>
+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
  <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>
+ Informationen <20>ber de.alt.test.moderated
| From: Thomas Hochstein <thh@inter.net>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2011-03-03>
| 
| Last-modified: 2011-03-03
| Posting-frequency: monthly  

2.5. Sonderf<72>lle
----------------

Die vorstehenden Erl<72>uterungen decken den Regelfall der Einrichtung
einer neuen Gruppe ab. Denkbar sind daneben jedoch noch verschiedene
Sonderf<EFBFBD>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<47>ndung der Hierarchie
|   f<>hrende RfD hat hierzu die notwendigen Angaben bereitzustellen.
|   Wird die Unterhierarchie nur mit der .misc-Gruppe eingerichtet, so
|   findet hier<65>ber eine normale Abstimmung statt.

  Soll also von der bestehenden Gruppe de.rec.outdoors eine Gruppe f<>r
  Ausr<73>stungsfragen ("de.rec.outdoors.ausruestung") abgespalten
  werden, dann muss zugleich die Gruppe "de.rec.outdoors.misc"
  eingerichtet werden. Dies geschieht regelm<6C><6D>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<6E>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<65>cksichtigen ist, dass Vorschl<68>ge grunds<64>tzlich nicht "en
  bloc" zur Abstimmung gestellt werden k<>nnen; vielmehr ist <20>ber jeden
  Vorschlag einzeln abzustimmen. Die Einrichtungsregeln machen dazu in
  Teil 7 folgende Vorgaben:

| <20>bertragbarkeit: Stimmen k<>nnen nicht auf einen anderen
|   Abstimmungsvorschlag <20>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<65>hlt
|   werden. <20>ber jede Gruppe wird einzeln abgestimmt, Verkn<6B>pfungen
|   von Wahlen sind nicht m<>glich.

* Diskussion mehrerer Alternativen

  Ziel der Diskussion sollte es regelm<6C><6D>ig sein, am Ende der
  Diskussionsphase genau einen Vorschlag zur Abstimmung zu stellen.
  Das schlie<69>t nicht aus, in der Diskussion zun<75>chst mehrere denkbare
  Alternativen vorzuschlagen; die Diskussion sollte aber schlie<69>lich
  zu einem mehrheitsf<73>higen Vorschlag f<>hren. Ggf. kann dazu auch ein
  unverbindliches Meinungsbild ("Strawpoll") eingeholt werden. Mehrere
  sich ausschlie<69>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<72>lt (obwohl
  die Mehrzahl der Abstimmenden durchaus generell f<>r eine Einrichtung
  der entsprechenden Gruppe(n) ist) oder am Ende ein Konglomerat von
  Vorschl<68>gen angenommen wird, dass 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<6D>en:

| Ein CfV kann mehrere Gruppen zur Auswahl anbieten, von denen
| h<>chstens eine eingerichtet werden soll ("kombiniertes Voting").
| Dabei wird <20>ber die Einrichtung jeder einzelnen Gruppe gem<65><6D> den
| obigen Regeln abgestimmt.
| 
| In einem weiteren Abstimmungsblock innerhalb desselben CfV findet
| zus<75>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<72>ltnis Zustimmung : Ablehnung aufweist.

  Siehe dazu auch:

  + FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|   From: faq@wortrei.ch (Adrian Suter)
|   Newsgroups: de.admin.news.regeln,de.admin.infos
|   Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
|   
|   Archive-name: de-admin/entscheidung
|   Posting-frequency: weekly
|   Last-modified: 2003-12-31
|   URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
|   URL: http://www.kirchwitz.de/~amk/dai/entscheidung

3. Diskussionsphase
===================

Wenn alle Vor<6F>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<50>fung ver<65>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<67>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 <20>berzeugen.

<EFBFBD>blicherweise beginnt er mit Namen und Kurzbeschreibung, dem Status
und der Charta der vorgeschlagenen Gruppe. Darauf folgt die
Begr<EFBFBD>ndung, die den Hintergrund f<>r den Vorschlag und die <20>berlegungen
insbesondere zu den bereits oben unter 1. ("Vor<6F>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<41>erdem enth<74>lt der RfD
nat<EFBFBD>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<EFBFBD>lich ist auch zu entscheiden, in welchen Gruppen der RfD
ver<EFBFBD>ffentlicht werden soll; das sind mindestens de.admin.news.announce
und de.admin.news.groups, zus<75>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<68>nkt werden oder
die sonst thematisch verwandt sind. Insbesondere relevant sind dabei
nat<EFBFBD>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<EFBFBD>glich und nur so lang wie n<>tig sein sollte; dies schon deshalb,
weil in <20>berm<72><6D>ig viele Gruppen verteilte Postings heutzutage
m<EFBFBD>glicherweise als Spam ausgefiltert werden.

Eine Ver<65>ffentlichung durch die Moderation von de.admin.news.announce
kann nur in de.* erfolgen und auch dort in moderierten Gruppen nur im
Einverst<EFBFBD>ndnis mit deren Moderation. In Gruppen au<61>erhalb von de.*,
auch in anderen deutschsprachigen Hierarchien, in Mailinglisten,
Webforen o.<2E>. kann der Proponent nach Ver<65>ffentlichung des RfDs einen
Hinweis auf diesen ("Pointer") ver<65>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<EFBFBD>r die formale Gestaltung eines RfD gibt es keine verbindlichen
Vorgaben; allenfalls haben sich <20>blichkeiten entwickelt. Es empfiehlt
sich auch hier, einige <20>ltere RfD in de.admin.news.announce als Muster
heranzuziehen. Das kann dann bspw. so aussehen:

|             1. RfD (Diskussionsaufruf)
|             ==========================
| 
| zur Einrichtung der neuen Gruppe
| 
| [Gruppenname]   [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.

oder

| Status
| ------
|
| Die Gruppe ist moderiert.
| 
| Moderatoren sind Adam Berthold <adam@berthold.example> und
| Charlotte Dominik <charlotte@dominik.example>.
| 
| Die Submissionsadresse lautet <submissionen@domain.example>.
| 
| Charta
| ------
| 
| [Charta]
| 
| Hintergrund / Begr<67>ndung
| -----------   ----------
| 
| [Begr<67>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. <20>ber ein Formular werden die
notwendigen Bestandteile eines RfD abgefragt, die Eingaben auf einige
Fehler hin <20>berpr<70>ft und daraus dann ein Text erzeugt, der als RfD
eingereicht werden kann.

3.2. Einreichung des RfD
------------------------

Der fertige RfD ist dann per E-Mail an <moderator@dana.de> an die
Moderation von de.admin.news.announce einzureichen. Neben dem
eigentlichen Text sollte dabei auch die Liste der Gruppen <20>bermittelt
werden, in denen der RfD ver<65>ffentlicht werden soll. Der RfD kann auch
bereits einschlie<69>lich des Headers (mit Absender, Betreff,
Gruppenliste etc.), bspw. als angeh<65>ngte Textdatei, <20>bermittelt
werden.

<EFBFBD>blicherweise wird die Moderation den Eingang des RfD best<73>tigen und
ihn in den w<>chentlich geposteten Status aufnehmen, der auch auf den
Webseiten der Moderation ver<65>ffentlicht wird. Danach wird ein
Moderationsmitglied als Verfahrensbetreuer bestimmt, das den RfD
<EFBFBD>berpr<EFBFBD>ft, ggf. R<>cksprache mit dem oder den Proponenten nimmt und ihn
schlie<EFBFBD>lich in de.admin.news.announce und den <20>brigen Gruppen
ver<EFBFBD>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<6B>rt werden. Die
Verfahrensbetreuer der Moderation von de.admin.news.announce haben
<EFBFBD>blicherweise bereits l<>ngerfristige Erfahrungen mit de.* und dem
Einrichtungsverfahren gesammelt und k<>nnen daher im Zweifel Tips und
Hinweise geben oder beratend t<>tig werden.

Siehe auch:

+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
  <http://dana.de/modkonzept.html>

3.3. Diskussionsphase
---------------------

Nachdem die Moderation den RfD ver<65>ffentlicht hat, findet in
de.admin.news.groups die Diskussion <20>ber den Vorschlag statt. Die
Proponenten sollten die Diskussion verfolgen und sich an ihr
beteiligen, dabei auf Einw<6E>nde und Kritik eingehen und ggf. ihre
Begr<EFBFBD>ndung verfeinern.

H<EFBFBD>ufig wird die Diskussion sinnvolle Erg<72>nzungen zum urspr<70>nglichen
Vorschlag bringen, die in einen neuen, ge<67>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<EFBFBD>ffentlichung eingereicht werden, der den modifizierten Vorschlag
und eine Begr<67>ndung, warum welche Vorschl<68>ge aufgenommen oder
verworfen wurden, enth<74>lt. Dieser zweite RfD erscheint als Antwort
("Followup") auf den ersten.

Besteht weiterer Diskussionsbedarf, k<>nnen auch mehrere weitere RfDs
ver<EFBFBD>ffentlicht werden. Dabei sollte der Verlauf der Diskussion nicht
unn<EFBFBD>tig verl<72>ngert oder verz<72>gert werden; es ist aber auch nicht
sinnvoll, im Rhythmus weniger Tage neue Fassungen des Vorschlags zu
ver<EFBFBD>ffentlichen. Vielmehr sollte die Diskussion beobachtet und die
sich herauskristallisierenden Verbesserungsvorschl<68>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<68>ge und
<EFBFBD>nderungen zusammenzufassen, ggf. selbst noch einmal zur Diskussion zu
stellen und dann auf dieser Basis einen ge<67>nderten Vorschlag als
weiteren RfD zu ver<65>ffentlichen.

Die Diskussion sollte im Interesse des Vorschlags und der Beteiligten
m<EFBFBD>glichst konstruktiv gef<65>hrt werden. Als Proponent sollte man sich
jedoch darauf einrichten, dass der Diskussionsverlauf nicht immer
ausschlie<EFBFBD>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<72>pfige und unfreundliche. Auch dort gilt aber,
dass aus der Diskussion das wird, was die Diskutanten aus ihr machen.

3.4. <20>berleitung zur Abstimmung oder R<>ckzug des Vorschlags
-----------------------------------------------------------

Am Ende der Diskussion sollte(n) der/die Proponent(en) sich dar<61>ber
Rechenschaft ablegen, ob nach dem Verlauf der Diskussion der Vorschlag
voraussichtlich erfolgversprechend sein wird. Ist das nicht der Fall,
kann das Verfahren zur<75>ckgezogen werden.

Anderenfalls kann dann, wenn nach Auffassung des oder der Proponenten
der aus seiner/ihrer Sicht nunmehr endg<64>ltige Vorschlag feststellt,
zur Abstimmung geschritten werden. Dabei ist zu beachten, dass der
Vorschlag nur in der Form des letzten ver<65>ffentlichen RfDs zur
Abstimmung gestellt werden kann, denn der Abstimmungsaufruf (CfV) muss
inhaltlich mit dem letzten Diskussionsaufruf (RfD) im wesentlichen
<EFBFBD>bereinstimmen (siehe 4.2.). Ggf. ist also vor dem Beginn der
Abstimmung noch einmal ein weiterer RfD mit den letzten vorgesehenen
<EFBFBD>nderungen zu ver<65>ffentlichen.

Nach M<>glichkeit sollte am Ende der Diskussion nur noch ein einziger,
einheitlicher Vorschlag stehen (siehe 2.5.). Jedenfalls m<>ssen aber
f<EFBFBD>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 <20>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<EFBFBD>hlt und am Ende ein Ergebnis der Abstimmung mit Namen, E-Mail-
Adresse und Stimmabgabe aller Teilnehmer ver<65>ffentlicht. Die
Durchf<EFBFBD>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<68>hrung einem erfahrenen Usenet-Teilnehmer oder den
"German Volunteer Votetakers" (GVV) zu <20>berlassen.

4.1. Voraussetzungen f<>r die Durchf<68>hrung einer Abstimmung
----------------------------------------------------------

Eine regelkonforme Abstimmung ist kein Hexenwerk, bedeutet aber einen
gewissen Aufwand. Folgende Voraussetzungen sollte man im Vorfeld
pr<EFBFBD>fen:

* F<>r die Durchf<68>hrung der Abstimmung ben<65>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<73>ndnisse
  auftreten oder Wahlscheine in der sonstigen Post verloren gehen.
  Wichtig ist insbesondere auch, dass der Account ungefiltert ist, also
  keine Spamfilter oder Blacklists aktiv sind, die ggf. dazu f<>hren,
  dass legitime Abstimmungs-E-Mail nicht angenommen werden. Filterung
  von E-Mail ist heutzutage weit verbreitet; die meisten kostenlosen
  Mailanbieter sind daher ebenso ungeeignet wie viele Standardaccounts
  von Webhosting- oder Internetzugangsanbietern.

  Siehe dazu auch:

  + Zu Abstimmadressen und Filtermassnahmen
|   From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
|   Organization: Moderation von de.admin.news.announce
|   Newsgroups: de.admin.news.announce,de.admin.news.regeln
|   Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
|   Date: Sat, 12 Mar 2011 23:15:00 +0100
|   Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>
|   
|   Filterma<6D>nahmen bei der Durchf<68>hrung von Abstimmungen
|   =====================================================

* Es empfiehlt sich meistens, die eingehenden Stimmzettel nicht von
  Hand zu bearbeiten, sondern daf<61>r geeignete Software zu verwenden,
  die Plausibilit<69>tspr<70>fungen vornimmt, Best<73>tigungen per E-Mail
  versenden kann und Auswertungen automatisch erstellt.

  Die verbreitetste Softwarel<65>sung daf<61>r ist UseVote; mehr
  Informationen dazu und eine Downloadm<64>glichkeit gibt es auf
  <http://www.usevote.de>.

* Weil ungefilterte Mailaccounts zunehmend schwer zu finden sind,
  haben sich einige regelm<6C><6D>ige Teilnehmer in de.admin.news.* dazu
  bereiterkl<6B>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.<2E>.
  zu erm<72>glichen. Dazu z<>hlen u.a.

  - Ralph Angenendt <ihr.name@strg-alt-entf.org>
  - Ralf D<>blitz <doeblitz@doeblitz.net>
  - Karsten D<>sterloh <kd-usenet@tprac.de>
  - Michael Grimm <trashcan@odo.in-berlin.de>
  - Emil Schuster <emil@wieslauf.sub.de>

  Im Zweifel empfiehlt es sich, rechtzeitig mit einem der Genannten
  Kontakt aufzunehmen und die Einzelheiten der Vorgehensweise
  abzustimmen.

* Daneben besteht auch die M<>glichkeit, die Abstimmung gar nicht
  selbst durchzuf<75>hren, sondern damit einen Dritten zu beauftragen,
  der weitergehende technische M<>glichkeiten oder gr<67><72>ere Erfahrungen
  mit der Durchf<68>hrung von Abstimmungen hat. <20>berdies ist es zwar
  zul<75>ssig und auch der von den Einrichtungsregeln urspr<70>nglich
  vorgesehene Regefall, dass der Proponent auch die Abstimmung
  durchf<68>hrt, manchmal ist es aber erw<72>nscht, damit einen unabh<62>ngigen
  Dritten zu beauftragen.

  Dieser Dritte kann jeder interessierte Netzteilnehmer sein. Einige
  erfahrene Votetaker haben sich <20>berdies zu den "German Volunteer
  Votetakers" (GVV) zusammengeschlossen und sind unter der Adresse
  <gvv@dana.de> erreichbar. Jeder Proponent kann unter dieser Adresse
  - rechtzeitig! - nachfragen, ob ein Mitglied der GVV bereit und in
  der Lage ist, f<>r ihn die Abstimmung durchzuf<75>hren. In den letzten
  Jahren wurde die absolute Mehrzahl aller Abstimmungen in de.* durch
  Mitglieder der GVV durchgef<65>hrt.

  Siehe dazu auch:

  + GVV-FAQ
|   From: Thomas Hochstein <thh@votetaker.de>
|   Newsgroups: de.admin.infos,de.admin.news.groups
|   Subject: <2011-09-24> GVV-FAQ
|   
|   Archive-name: de-admin/gvv-faq
|   Posting-frequency: weekly
|   Last-modified: 2011-09-24
|   URL: http://votetakers.de/faq.php
|   URL: http://www.kirchwitz.de/~amk/dai/gvv-faq

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

Auch f<>r den Inhalt eines CfV bestehen nur wenige formale Vorgaben; er
muss die notwendigen Eigenschaften der einzurichtenden Gruppe (Name,
Kurzbeschreibung, Charta, Status, ggf. Moderator) und die f<>r die
Teilnahme an der Abstimmung notwendigen Informationen, namentlich die
Abstimmadresse und den Abstimmungszeitraum sowie einen Wahlschein mit
den einzelnen Abstimmungspunkten, enthalten. Der Abstimmungszeitraum
muss mindestens drei Wochen, darf aber h<>chstens vier Wochen betragen.

Schlie<EFBFBD>lich muss der CfV mit dem letzten RfD im wesentlichen
<EFBFBD>bereinstimmen, wie Teil 6 der Einrichtungsregeln festh<74>lt:
| Nach der Diskussionsperiode kann ein Abstimmungsaufruf -- engl.
| "Call for Votes" oder kurz CfV -- bei der Moderation eingereicht
| werden. Dieser mu<6D> mit dem letzten RfD im wesentlichen
| <20>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<69>ten; an diesen
d<EFBFBD>rfen keine <20>ber die Behebung von Schreibfehlern o.<2E>. hinausgehenden
<EFBFBD>nderungen vorgenommen werden. Kurz und gut: Der zur Abstimmung
gestellte Vorschlag darf keinen anderen Sinngehalt haben als der zuvor
diskutierte. Eine <20>nderung der Begr<67>ndung - soweit sie <20>berhaupt im
CfV wiederholt wird - ist hingegen regelm<6C><6D>ig unproblematisch.

<EFBFBD>blich ist es, auf Basis des letzten ver<65>ffentlichen RfD einen CfV zu
entwerfen. Dabei kann der Begr<67>ndungsteil gek<65>rzt werden oder ganz
entfallen und durch einen Verweis auf die gef<65>hrte Diskussion -
Message-IDs der RfDs - ersetzt werden. Hinzugef<65>gt werden dann die
Abstimmungsmodalit<EFBFBD>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<75>blich.
Bei einfachen Abstimmungen erweist sich eine solche Darstellung
n<EFBFBD>mlich als <20>berfl<66>ssig; bei komplexeren Abstimmungen hingegen w<>rde
die Darstellung aller m<>glichen Abstimmungsvarianten und der
entsprechenden Ergebnisse solcherma<6D>en un<75>bersichtlich und aufwendig,
dass regelm<6C><6D>ig darauf verzichtet wird. Wenn jedoch die einzelnen
Abstimmungsm<EFBFBD>glichkeiten dargestellt werden, dann m<>ssen sowohl die
Abstimmungsm<EFBFBD>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<EFBFBD>gliche Gestaltung w<>re folgende:

|             1. CfV (Abstimmungsaufruf)
|             ==========================
| 
| zur Einrichtung der neuen Gruppe
| 
| [Gruppenname]   [Kurzbeschreibung]
|
| Status: Die Gruppe ist unmoderiert.
|
| Charta
| ------
| 
| [Charta]
| 
| Hintergrund / Begr<67>ndung
| -----------   ----------
| 
| [kurze Begr<67>ndung, ggf. Verweis auf die Diskussion]
|
| Proponent(en)
| -------------
| 
| [Name(n) und Mailadresse(n)]
|
| Abstimmungsmodalit<69>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<65>ffentlicht sind. Sie erl<72>utern das Wahlverfahren detailliert und
| sollten vor der ersten Teilnahme an einer Abstimmung gelesen werden.
| 
| Gez<65>hlt werden nur per E-Mail bei der Abstimmadresse eingegangene
| Stimmen. Diese werden einzeln per E-Mail best<73>tigt. Das Ergebnis wird
| nach dem Ende der Wahl ver<65>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<65>ffentlichung der
| abgegebenen Stimme entsprechend Hinweis im Wahlschein n<>tig.
| 
| 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<EFBFBD>chlichen Namen anzugeben, da m<>glicherweise im E-Mail-Programm
ein Pseudonym konfiguriert ist.  Der Wahlschein im obigen Beispiel ist
durch die Abstimmungssoftware Usevote generiert (siehe 4.1.).

Der fertige CfV ist dann wie gewohnt per E-Mail an <moderator@dana.de>
an die Moderation von de.admin.news.announce einzureichen. Auch hier
geh<EFBFBD>rt die Liste der Gruppen dazu, in denen der RfD ver<65>ffentlicht
werden soll; diese sollte dem letzten RfD entsprechen. Auch der CfV
kann bereits einschlie<69>lich des Headers (mit Absender,
Betreff, Gruppenliste etc.), bspw. als angeh<65>ngte Textdatei,
<EFBFBD>bermittelt werden.

Die Ver<65>ffentlichung des CfVs wird <20>blicherweise l<>nger dauern als bei
den RfD, weil der Abstimmungsaufruf durch die Moderation von
de.admin.news.announce nach dem 4-Augen-Prinzip <20>berpr<70>ft wird. Daher
kann - und sollte - der 1. CfV ruhig m<>glichst fr<66>hzeitig eingereicht
werden. Den zutreffenden Endtermin der Abstimmung, der sich aus dem
Zeitpunkt der Ver<65>ffentlichung ergibt, setzt die Moderation dann
selbst ein.

4.3. Abstimmungsphase
---------------------

W<EFBFBD>hrend der drei- oder vierw<72>chigen Abstimmungsphase muss der
Abstimmungsaccount durchgehend erreichbar sein. Jede abgegebene Stimme
sollte - nach M<>glichkeit einigerma<6D>en zeitnah, am besten
automatisiert - per E-Mail best<73>tigt werden; in dieser Best<73>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<73>tigung versandt werden, um sicherzustellen, dass
diese Stimme auch tats<74>chlich vom angegebenen Absender stammte (und
die Abstimmadresse replyf<79>hig ist, d.h. E-Mail dort empfangen werden
kann). Au<41>erdem sollte in der Best<73>tigung angegeben sein, wie eine
Stimme nachtr<74>glich ge<67>ndert oder komplett zur<75>ckgezogen werden kann
(wenn bspw. eine E-Mail-Adresse verwendet wurde, die nicht im Usenet
ver<EFBFBD>ffentlicht werden soll.)

In der Mitte der Abstimmungsphase ist es <20>blich, einen 2. CfV zu
ver<EFBFBD>ffentlichen, der dem 1. CfV inhaltlich entspricht, der aber eine
Liste der Abstimmenden (Name, und E-Mail-Adresse, aber keinesfalls die
Stimmabgaben!) enth<74>lt; dabei kann auch bereits angegeben werden, ob
Stimmen voraussichtlich als ung<6E>ltig gewertet werden. Weil auch der 2.
CfV im Rahmen der <20>blichen Bearbeitungszeiten regelm<6C><6D>ig nicht sofort,
sondern erst nach einigen (Stunden oder) Tagen ver<65>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<65>ffentlichungszeitraum einzureichen.

Mit dem Ablauf der Abstimmungsperiode (in der Regel um Mitternacht)
endet die Abstimmung. Versp<73>tete Stimmen werden nicht mehr gez<65>hlt.

4.4. Auswertung und Ergebnis der Abstimmung
-------------------------------------------

Nach dem Ende der Abstimmung wird diese durch den Votetaker ausgez<65>hlt.

Dabei werden zun<75>chst die JA- und NEIN-Stimmen sowie Enthaltungen
gez<EFBFBD>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<65>gen (Angabe eines falschen oder nicht
vollst<EFBFBD>ndigen Namens, nicht replyf<79>hige Abstimmadresse), d<>rfen nicht
gewertet werden. Der Votetaker sollte auch die M<>glichkeit von
Manipulationsversuchen (mehrfache Stimmabgaben unter verschiedenen
Identit<EFBFBD>ten, Weitergabe des Wahlscheins au<61>erhalb der Gruppen, in
denen er ver<65>ffentlicht wurde, Beeinflussung der Abstimmung durch
"Campaigning") im Auge behalten und entsprechende <20>berpr<70>fungen
vornehmen. Unklarheiten sollten mit den betroffenen
Abstimmungsteilnehmern gekl<6B>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<66>heren Zweifelsf<73>llen zu Rate zu ziehen. Diese
sind, soweit sie eine Bedeutung <20>ber den konkret entschiedenen
Einzelfall hinaus haben und nicht sp<73>ter revidiert wurden, unter
<http://www.dana.de/archiv.html> auch im Web ver<65>ffentlicht.

Bei der Auswertung sollte der Votetaker im eigenen Interesse die
datenschutzrechtlichen Regelungen der Jurisdiktion(en), der oder denen
er unterliegt, ber<65>cksichtigen. Dies gilt insbesondere, sofern zur
Speicherung, Verarbeitung und vor allem Ver<65>ffentlichung der
personenbezogenen Daten der Abstimmungsteilnehmer ausdr<64>ckliche
Einwilligungserkl<EFBFBD>rungen erforderlich sind.

Danach ist eine Ergebnisver<65>ffentlichung ("Result") vorzubereiten.
<EFBFBD>blich ist es, die Gesamtzahl der g<>ltigen Stimmen und sodann f<>r
jeden Abstimmungspunkt die JA- und NEIN-Stimmen sowie die Enthaltungen
und ung<6E>ltigen Stimmabgaben zu nennen. Angenommen ist der Vorschlag,
wenn mindestens 60 JA-Stimmen eingegangen sind und die Anzahl der JA-
Stimmen mindestens doppelt so gro<72> ist wie die Anzahl der NEIN-Stimmen
(2/3-Mehrheit).

Zwingend ist zudem die Ver<65>ffentlichung einer Liste aller Abstimmenden
mit Namen und E-Mail-Adresse sowie Stimmabgabe. Auch Enthaltungen und
ung<EFBFBD>ltige Stimmen sind anzugeben, bei letzteren unter Angabe einer
stichwortartigen Begr<67>ndung f<>r die Nichtwertung. Dies erm<72>glicht es
allen Interessierten, das Ergebnis der Abstimmung nachzuvollziehen.

In besonderen F<>llen kann die Ver<65>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<47>nden die Verwendung von Pseudonymen
akzeptiert wird.

5. Verfahrensabschluss und Umsetzung
====================================

Mit der Ver<65>ffentlichung des Results durch die Moderation von
de.admin.news.announce beginnt eine einw<6E>chige Einspruchsfrist, in der
jeder Interessierte Einspruch mit der Begr<67>ndung einlegen kann, dass
bei der Durchf<68>hrung der Abstimmung schwerwiegende Unregelm<6C><6D>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.4. angerissenen Manipulationsversuche.

Mit fruchtlosem Ablauf der Einspruchsfrist wird das Ergebnis der
Abstimmung bestandskr<6B>ftig; die Moderation von de.admin.news.announce
wird dann die entsprechenden digital signierten Steuernachrichten
versenden, die <20>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<EFBFBD>nzen.

Ansonsten wird die Moderation <20>ber eingegangene Einspr<70>che entscheiden
und das Ergebnis der Abstimmung entweder entsprechend anpassen oder
schlimmstenfalls annullieren. Wenn feststeht, dass der Einspruch das
ver<EFBFBD>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 <20>ber den Einspruch abschlie<69>end entschieden ist.

Das Einrichtungsverfahren ist damit beendet.

6. Quellen
==========

Alle in diesen Erl<72>uterungen genannten Quellen sind hier noch einmal
zusammengefasst und um weitere Hinweise erg<72>nzt.

6.1. Grundlegende Informationen
-------------------------------

Folgende Texte sollten einem Proponenten unbedingt bekannt sein:

+ Einrichtung von Usenet-Gruppen in "de.*" (Einrichtungsregeln)
| From: 3.14@piology.org (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.alt.admin
| Subject: <2005-08-06> Einrichtung von Usenet-Gruppen in "de.*"
| 
| Archive-name: de-admin/einrichtung
| Posting-frequency: weekly
| Last-modified: 2005-08-06
| URL: http://www.kirchwitz.de/~amk/dai/einrichtung

+ Missverstaendnisse in de.admin.news.groups
| From: 3.14@piology.org (Boris 'pi' Piwinger)
| Newsgroups: de.admin.infos,de.admin.news.groups,de.alt.admin
| Subject: <2009-01-24> Missverstaendnisse in de.admin.news.groups
| 
| Archive-name: de-admin/dang-faq
| Posting-frequency: weekly
| Last-modified: 2009-01-24
| URL: http://www.kirchwitz.de/~amk/dai/dang-faq

+ Die Newsgruppen der de-Hierarchie (Gruppenliste)
| From: Daniel Roth <25.8@bluemail.ch>
| Newsgroups: de.newusers.infos,de.admin.news.groups,de.alt.admin
| Subject: <Datum> Die Newsgruppen der de-Hierarchie
| 
| Archive-name: de-newusers/de-newsgruppen
| Posting-frequency: weekly
| URL: http://www.kirchwitz.de/~amk/dni/de-newsgruppen

6.2. Weiterf<72>hrende Hinweise
----------------------------

Folgende Texte sind allgemein oder f<>r spezielle Fragen hilfreich oder
von Interesse:

+ Moderationskonzept der derzeitigen Moderation von d.a.n.a
| From: moderator@dana.de (Moderation von de.admin.news.announce)
| Newsgroups: de.admin.news.announce,de.admin.news.misc
| Subject: <2010-11-01> Moderationskonzept der derzeitigen Moderation
  <http://dana.de/modkonzept.html>

+ Wichtige Begriffe in de.admin.news.* (dan-Glossar)
| From: bernd@tenuki.de (Bernd Gramlich)
| Newsgroups: de.admin.infos
| Subject: <2004-12-06> Wichtige Begriffe in de.admin.news.*
| 
| Archive-name: de-admin/dan-glossar
| Posting-frequency: weekly
| Last-modified: 2004-12-06
| URL: http://www.tmt.de/~gramlich/dan-glossar.html
| URL: http://www.kirchwitz.de/~amk/dai/dan-glossar

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

+ Erste Schritte zur Einrichtung neuer Gruppen
  <http://www.babylonsounds.com/usenet/rfd_howto.html>

+ FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| From: faq@wortrei.ch (Adrian Suter)
| Newsgroups: de.admin.news.regeln,de.admin.infos
| Subject: <2003-12-31> FAQ: Entscheidungsfindung bei mehreren Moeglichkeiten
| 
| Archive-name: de-admin/entscheidung
| Posting-frequency: weekly
| Last-modified: 2003-12-31
| URL: http://www.wortrei.ch/usenet/admin/entscheidung.php3
| URL: http://www.kirchwitz.de/~amk/dai/entscheidung

+ Regeln fuer Newsgruppennamen
| From: "Christian Schulz - GVV" <gvv@spinfo.uni-koeln.de>
| Newsgroups: de.admin.news.announce,de.admin.news.regeln,de.admin.news.groups,de.alt.admin
| Subject: Regeln fuer Newsgruppennamen angenommen (247:25)
| Date: 2000/07/18
| Message-ID: <result-regel-newsgruppennamen-18.07.2000@dana.de>
  <http://groups.google.de/group/de.admin.news.announce/msg/b850df16546fd0ea>

+ GVV-FAQ
| From: Thomas Hochstein <thh@votetaker.de>
| Newsgroups: de.admin.infos,de.admin.news.groups
| Subject: <2011-09-24> GVV-FAQ
| 
| Archive-name: de-admin/gvv-faq
| Posting-frequency: weekly
| Last-modified: 2011-09-24
| URL: http://votetakers.de/faq.php
| URL: http://www.kirchwitz.de/~amk/dai/gvv-faq

+ Filterma<6D>nahmen bei der Durchf<68>hrung von Abstimmungen
| From: karim.senoucci@dana.de (Karim 'Kasi Mir' Senoucci)
| Organization: Moderation von de.admin.news.announce
| Newsgroups: de.admin.news.announce,de.admin.news.regeln
| Subject: [ADMIN] Zu Abstimmadressen und Filtermassnahmen
| Date: Sat, 12 Mar 2011 23:15:00 +0100
| Message-ID: <Admin-Filtermassnahmen-20110312-2@dana.de>

+ Unknown: NetNews Moderator's Handbook (1994, engl.)
  <http://www.eyrie.org/~eagle/usefor/other/moderators-handbook>

+ Denis McKeon: Moderated Newsgroups FAQ (1997, engl.)
  <http://pages.swcp.com/~dmckeon/mod-faq.html>

+ Russ Allbery: Pitfalls of Newsgroup Moderation (engl.)
  <http://www.eyrie.org/~eagle/faqs/mod-pitfalls.html>

+ Big-8 Moderation Board Wiki: Moderated Newsgroups (engl.)
  <http://www.big-8.org/wiki/Moderated_Newsgroups>

+ Big-8 Moderation Board Wiki: Moderation Software (engl.)
  <http://www.big-8.org/wiki/Moderated_Newsgroups#Moderation_Software>

+ Informationen <20>ber de.alt.test.moderated
| From: Thomas Hochstein <thh@inter.net>
| Newsgroups: de.alt.test.moderated
| Subject: Info: de.alt.test.moderated <2011-03-03>
| 
| Last-modified: 2011-03-03
| Posting-frequency: monthly  

+ Entscheidungen der Moderation von de.admin.news.announce
  <http://www.dana.de/archiv.html>

6.3. Webseiten
--------------

Folgende Webseiten sollten bekannt sein oder k<>nnen bei der Durchf<68>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<65>ffentlicht in de.admin.news.announce
  <http://www.dana.de/status.html>

+ RfD-Generator
  <http://piology.org/cgi-bin/rfd.pl>

+ GVV-Status<75>bersicht
  <http://votetakers.de/status.php>

+ Abstimmungssoftware UseVote
  <http://www.usevote.de>

7. Maintainer und Kontakt
=========================

7.1. Derzeitige Maintainer
--------------------------

Maintainer dieser FAQ: Thomas Hochstein <thh@inter.net>
                       Michael Ottenbruch <dana-manual@ottenbruch.net>

Das dana-Manual wurde im M<>rz/April 2011 vollst<73>ndig <20>berarbeitet und
neu gefasst.

Weitere <20>nderungen und Erg<72>nzungen nehmen die Maintainer gerne
entgegen. Vorschl<68>ge k<>nnen per E-Mail an <dana-manual@usenet.th-h.de>
gerichtet werden. Im Falle einer <20>ffentlichen Diskussion solcher
Vorschl<EFBFBD>ge ist ein Hinweis an die Maintainer hilfreich.

Das dana-Manual ist auch in einem Git-Repository unter
<http://code.th-h.de/?p=faqs/dana-manual.git> verf<72>gbar und kann <20>ber
die Weboberfl<66>che eingesehen oder via "git clone" ausgecheckt werden.
Bei <20>nderungsvorschl<68>gen sind Git-Patches am einfachsten zu
verarbeiten; nat<61>rlich nehmen die Maintainer aber auch jede andere
Form von Anregungen entgegen.

F<EFBFBD>r Hinweise, Anregungen und Verbesserungsvorschl<68>ge sei insbesondere
- Stephan Manske
- 0liver Seyfert
gedankt.

7.2. Fr<46>here Fassungen
----------------------

Maintainer bis 2010: Thomas Roessler, Dirk Nimmich

Zu der urspr<70>nglichen Fassung dieses Textes und seiner Entstehung
haben au<61>erdem beigetragen:

- Lutz Donnerhacke
- Kristian K<>hntopp
- Rolf Krahl
- Martin Recke
- Heiko Schlichting
- Adrian Suter
- Hans-Christoph Wirth

Herzlichen Dank!