misc/tota-guidelines.txt

Tota-Guidelines
===============

1. Was ist Tota?

    "Tota" steht f<>r die fr<66>here Newsgroup "t-online.talk.allgemein",
    kurz t-o.t.a, urspr<70>nglich eine Smalltalk-Gruppe in der t-online.*-
    Hierarchie.  Nach der Schlie<69>ung der t-online.*-Hierarchie im
    Herbst 2009 haben sich Michael Hermes, Thomas Hochstein und Daniel
    Weber zusammengetan, um kurzfristigen Ersatz bereitzustellen und
    haben die tota.*-Hierarchie gegr<67>ndet. Auch wenn es in erster Linie
    um die Smalltalk-Aspekte ging, wurden Hilfestellungen von
    T-Online-Benutzern f<>r T-Online-Benutzer nicht ausgenommen.

2. Gruppenliste und Chartas

    Unter <http://news.tota-refugium.de/groups.txt> wird jede Nacht die
    aktuelle Gruppenliste inkl. der Kurzbeschreibungen bereitgestellt.
    Eine Auflistung inkl. der Chartas ist auf der Hierarchie-Website
    <http://tota-refugium.de> verf<72>gbar.

3. Entscheidungsfindung in tota.*

    Themen zur Pflege und Verwaltung der Hierarchie, z.B. Einrichtung
    und L<>schung von Gruppen, Peerings, Umgang mit Missbrauch u.<2E>.
    werden in tota.administration behandelt.

    Bei anstehenden Entscheidungen gibt es eine mindestens einw<6E>chige
    <20>ffentliche Diskussionsphase und im Anschluss (sp<73>testens aber eine
    Woche nach dem Ende der Diskussionsphase) eine einw<6E>chige
    <20>ffentliche Abstimmung. Zur Abstimmung aufgerufen wird in
    tota.administration durch den Proponenten oder einen vom
    Proponenten beauftragten Nutzer. Zur Auswahl stehen nur die im
    Stimmzettel genannten M<>glichkeiten.

    Abstimmungsteilnehmer posten den ausgef<65>llten Stimmzettel als
    Antwort auf den Abstimmungsaufruf in tota.administration. Es gen<65>gt
    die einfache Mehrheit, die Gr<47>nder der Hierarchie haben ein Veto-
    Recht gegen <20>nderungen des Status-Quo.

4. Peering

4.1 Peering-Konzept

    tota.* ist eine geschlossene Hierarchie, d.h. tota.* darf nicht von
    beliebigen Serverbetreibern an beliebige andere Serverbetreiber
    weitergegeben werden.

    Unter <http://news.tota-refugium.de/peers.txt> ist die offizielle
    Liste der teilnehmenden Server bereitgestellt.

4.2 Peering-Anforderungen

    Es ist technisch sicherzustellen, dass Beitr<74>ge nur mit anderen
    Peers aus der offiziellen Liste der Peers ausgetauscht werden.
    Sogenannte Lecks sind zu vermeiden.

    Peerings finden nur mit Newssystemen statt, welche die vollst<73>ndige
    Tota-Hierarchie f<>hren, auf dem aktuellen Stand halten,
    Missbrauchsmeldungen nachgehen und das Einstellen von Beitr<74>gen nur
    nach Authentifikation erlauben.

4.3 Peering-Anfragen

    Peering-Anfragen, die den obigen Peering-Anforderungen gen<65>gen,
    werden vom Newsmaster, der die Anfrage erhalten hat, oder in dessen
    Auftrag in tota.administration <20>ffentlich gemacht. Wenn binnen einer
    Woche kein Widerspruch erfolgt, kann das Peering eingerichtet
    werden; ansonsten wird das oben unter 3. dargestellte
    Entscheidungverfahren zur Anwendung gebracht.

4.4 Peering-Ausschluss

    Peers k<>nnen nach Entscheidung in tota.administration auch wieder
    ausgeschlossen werden, insbesondere bei Verst<73><74>en gegen die
    Peering-Policy der Hierarchie.

    Bei Verst<73><74>en gegen oben genannte Pflichten eines tota.*-Peers wird
    dieser von einem anderen Newsmaster oder den tota.*-Gr<47>ndern darauf
    hingewiesen und gebeten, den Missstand abzustellen. Bei wiederholten
    Verst<73><74>en oder ausbleibender Reaktion auf den ersten Hinweis wird
    der Ausschluss des Peers in tota.administration vorgeschlagen und
    nach den unter 3. genannten Regeln zur Entscheidung gebracht.

    Nach der Entscheidung zum Ausschluss des Peers haben alle anderen
    tota.*-Peers - sofern sie mit dem ausgeschlossenen Peer Beitr<74>ge
    ausgetauscht haben - sicherzustellen, dass keine Beitr<74>ge der
    tota.*-Hierarchie mehr ausgetauscht werden.

5. Nutzer-Konzept

    Jeder Peer kann Interessierten nach eigenem Ermessen Zugang
    gew<65>hren, ist dabei jedoch an die oben genannten
    Peering-Anforderungen gebunden.

6. Hierarchie-Verwaltung

    In tota.administration getroffene Entscheidungen zur Einrichtung,
    <20>nderung und L<>schung von Gruppen werden mittels Steuernachrichten
    von den Hierarchie-Verwaltern Thomas Hochstein und Daniel Weber
    unter Verwendung der Adresse <maintainer@tota-refugium.de> und des
    zugeh<65>rigen Schl<68>ssels umgesetzt.

7. Einrichtung/<2F>nderung/L<>schung von Gruppen

    Vorschl<68>ge zur Einrichtung, <20>nderung oder L<>schung von Gruppen
    k<>nnen von jedem Nutzer in tota.administration zur Entscheidung nach
    den unter 3. genannten Regeln gestellt werden.

8. Regeln f<>r Postings in Tota

    Die Nutzer der Hierarchie halten die Verwendung des echten Namens im
    From-Header von Beitr<74>gen f<>r eine h<>fliche Geste, es findet jedoch
    kein Zwang und keine Kontrolle statt. Realname-Diskussionen sind
    unerw<72>nscht, da zu diesem Thema bereits alle Sichtweisen zur Gen<65>ge
    ausgetauscht wurden.

    Ebenso ist erw<72>nscht, dass jeder Teilnehmer <20>ber eine Mailadresse im
    From oder, soweit gesetzt, Reply-To erreichbar ist. Keinesfalls darf
    dort eine Mailadresse verwendet werden, die unerlaubt einen fremden
    Namensraum nutzt.

    Unerw<72>nscht sind au<61>erdem Beitr<74>ge folgender Art:
      - Crossposts in tota.* und zugleich mindestens eine andere
        Hierarchie oder ein gesetztes Followup-To in eine andere
        Hierarchie bei einem Beitrag in tota.* oder umgekehrt
      - Crossposts <20>ber mehr als zwei Gruppen (mit Ausnahme von
        administrativen Hinweisen)
      - Multiposts, d.h. Beitr<74>ge mit identischem Inhalt
      - kommerzielle Werbung
      - Test-Postings au<61>erhalb von tota.test

9. Unstimmigkeiten

    Gibt es Unstimmigkeiten bei Regelfragen oder der
    Entscheidungsfindung entscheiden die Gr<47>nder mit einfacher Mehrheit.

10. <20>nderungen an diesem Text

    <20>nderungen an diesem Text, die den Sinn nicht ver<65>ndern (z.B.
    Korrektur von Fehlern, Aktualisierung von Begriffen) oder den Text
    an aktuelle technische Gegebenheiten (z.B. ge<67>nderte URLs) anpassen,
    k<>nnen direkt vorgenommen werden. Andere <20>nderungen k<>nnen nach
    obigem Verfahren in tota.administration zur Entscheidung gebracht
    werden.