146 lines
6 KiB
Plaintext
146 lines
6 KiB
Plaintext
Tota-Guidelines
|
|
===============
|
|
|
|
1. Was ist Tota?
|
|
|
|
"Tota" steht für die frühere Newsgroup "t-online.talk.allgemein",
|
|
kurz t-o.t.a, ursprünglich eine Smalltalk-Gruppe in der t-online.*-
|
|
Hierarchie. Nach der Schließ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ü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ü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.ä.
|
|
werden in tota.administration behandelt.
|
|
|
|
Bei anstehenden Entscheidungen gibt es eine mindestens einwöchige
|
|
öffentliche Diskussionsphase und im Anschluss (spätestens aber eine
|
|
Woche nach dem Ende der Diskussionsphase) eine einwöchige
|
|
ö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üllten Stimmzettel als
|
|
Antwort auf den Abstimmungsaufruf in tota.administration. Es genügt
|
|
die einfache Mehrheit, die Gründer der Hierarchie haben ein Veto-
|
|
Recht gegen Ä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ä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ändige
|
|
Tota-Hierarchie führen, auf dem aktuellen Stand halten,
|
|
Missbrauchsmeldungen nachgehen und das Einstellen von Beiträgen nur
|
|
nach Authentifikation erlauben.
|
|
|
|
4.3 Peering-Anfragen
|
|
|
|
Peering-Anfragen, die den obigen Peering-Anforderungen genügen,
|
|
werden vom Newsmaster, der die Anfrage erhalten hat, oder in dessen
|
|
Auftrag in tota.administration ö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ößen gegen die
|
|
Peering-Policy der Hierarchie.
|
|
|
|
Bei Verstößen gegen oben genannte Pflichten eines tota.*-Peers wird
|
|
dieser von einem anderen Newsmaster oder den tota.*-Gründern darauf
|
|
hingewiesen und gebeten, den Missstand abzustellen. Bei wiederholten
|
|
Verstöß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äge
|
|
ausgetauscht haben - sicherzustellen, dass keine Beiträge der
|
|
tota.*-Hierarchie mehr ausgetauscht werden.
|
|
|
|
5. Nutzer-Konzept
|
|
|
|
Jeder Peer kann Interessierten nach eigenem Ermessen Zugang
|
|
gewähren, ist dabei jedoch an die oben genannten
|
|
Peering-Anforderungen gebunden.
|
|
|
|
6. Hierarchie-Verwaltung
|
|
|
|
In tota.administration getroffene Entscheidungen zur Einrichtung,
|
|
Ä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örigen Schlüssels umgesetzt.
|
|
|
|
7. Einrichtung/Änderung/Löschung von Gruppen
|
|
|
|
Vorschläge zur Einrichtung, Ä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ägen für eine höfliche Geste, es findet jedoch
|
|
kein Zwang und keine Kontrolle statt. Realname-Diskussionen sind
|
|
unerwünscht, da zu diesem Thema bereits alle Sichtweisen zur Genüge
|
|
ausgetauscht wurden.
|
|
|
|
Ebenso ist erwünscht, dass jeder Teilnehmer ü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ünscht sind außerdem Beiträ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 über mehr als zwei Gruppen (mit Ausnahme von
|
|
administrativen Hinweisen)
|
|
- Multiposts, d.h. Beiträge mit identischem Inhalt
|
|
- kommerzielle Werbung
|
|
- Test-Postings außerhalb von tota.test
|
|
|
|
9. Unstimmigkeiten
|
|
|
|
Gibt es Unstimmigkeiten bei Regelfragen oder der
|
|
Entscheidungsfindung entscheiden die Gründer mit einfacher Mehrheit.
|
|
|
|
10. Änderungen an diesem Text
|
|
|
|
Änderungen an diesem Text, die den Sinn nicht verändern (z.B.
|
|
Korrektur von Fehlern, Aktualisierung von Begriffen) oder den Text
|
|
an aktuelle technische Gegebenheiten (z.B. geänderte URLs) anpassen,
|
|
können direkt vorgenommen werden. Andere Änderungen können nach
|
|
obigem Verfahren in tota.administration zur Entscheidung gebracht
|
|
werden.
|