Protokoll des MausNet© SysOp-Treffens 1996
Version 1.2 vom 18. Oktober 1996
Das SysOp-Treffen fand am 20. und 21. September 1996 im Jugendgästehaus in Bremen statt. Anwesend waren 79 SysOps aus 48 Mäusen. Unter den SysOps waren 74 männlichen und 5 weiblichen Geschlechts.
Die eigentliche Tagung fand am 21.09.1996 in der Zeit von 10:00 Uhr bis 17:30 Uhr statt. Sie wurde durch Mittagessen (12:30 Uhr) und Kaffeetrinken (16:00 Uhr) unterbrochen. Sebastian Hempel @ WUN und Thomas Meißner @ OS2 übernahmen die schwere Aufgabe der Protokollführer.
Die Tagung bestand aus zwei Teilen. Am Vormittag wurden in einzelnen Arbeitsgruppen verschiedene Themen diskutiert. Die Ergebnisse dieser Arbeitsgruppen wurden am Nachmittag im Plenum vorgetragen und evtl. Abstimmungen dazu durchgeführt. Den Vorstellungen der Arbeitsgruppen schloß sich eine Diskussion im Plenum zu allgemeinen Themen an.
Thema
Die Arbeitsgruppe beschäftigte sich mit den Umgangsformen im MausNet und denen von SysOps ("Du arrogantes Arschloch") oder anderen Usern mit Ämtern im speziellen.
Andreas Hoffmann @ K2
Ergebnisse
Im Allgemeinen werden die Umgangsformen im MausNet eingehalten. Bei öffentlichen Streitereien sollten sich andere User des öfteren per PM einmischen. Es kann jedoch Probleme geben, wenn einer der beteiligten Personen ein Amt (Betreiber, SysOp, AL-Team, etc.) inne hat und auch auf PMs nicht reagiert.
Um das Eskalieren von Streitereien in Zukunft zu vermeiden, wird von der Arbeitsgruppe die Einführung einer Schlichtungsinstanz (Schiedsgericht, Schiedsstelle) mit entsprechender Macht vorgeschlagen.
Die Arbeitsgruppe macht folgenden Vorschlag zum Profil des Schiedsteams.
In erster Linie ist das Schiedsteam für den Fall gedacht, daß ein Sysop oder Betreiber in eine Streitigkeit involviert ist.
Das Schiedsteam soll nur auf Anforderung hin aktiv werden. Hierfür müssen sich User aus mindestens 10% der Mäuse (auf 5er aufgerundet), mindestens aber aus 15 unterschiedlichen Mäusen beim Schiedsteam über einen User beschweren.
Das Schiedsteam entscheidet dann in relativ kurzer Zeit mit einfacher Mehrheit über evtl. Sanktionen. Als Sanktion ist das Abklemmen der die Streitigkeit betreffenden Gruppe(n) - SysOp-Gruppen für 7 Tage und (in letzter Konsequenz) User-Gruppen für 3 Tage - vorgesehen.
Die Kommunikation des Schiedsteams kann über eine eigene Gruppe, eine Mailingliste oder per Voice (Telefon) erfolgen.
Das Schiedsteam berichtet anschließend über die Entscheidung, inklusive einer kurzen Begründung. Diskussionsverlauf und Entscheidungsfindung müssen weder öffentlich verfolgbar ablaufen, noch nachträglich dokumentiert werden.
Eine Info-Mitteilung über das Schiedsteam wird regelmäßig in Maus.Info gepostet. In dieser Mitteilung soll darauf hingewiesen werden, daß die Anrufung des Schiedsteams das letzte Mittel ist. Vorher sollten alle anderen Möglichkeiten zur Schlichtung eines Streits (lokale Gespräche, Einschalten des SysOps, etc.) verwendet werden.
Das Schiedsteam soll 5 Mitglieder (ohne Vertreter) umfassen und eine unbeschränkte Amtszeit besitzen.
Das Schiedsteam entscheidet nur über die Form nicht jedoch über den Inhalt einer Diskussion. Es handelt sich um keine Moderation.
Abstimmungen
Soll ein Schiedsteam eingerichtet werden, das auf Anforderung hin über Sanktionen entscheidet? Als Sanktion ist hierfür das Abklemmen von Usergruppen für 3 Tage und für SysOp-Gruppen für 1 Woche vorgesehen.
Ergebnis: 38 dafür, 18 dagegen, 10 Enthaltungen (66)
Es wird ein Schiedsteam eingerichtet.
Das Schiedsteam wird erst auf Anforderung von Usern aus 5% der Mäuse, mindestens jedoch 3, hin aktiv.
Ergebnis: 54 dafür, 2 dagegen, 10 Enthaltungen (66)
Das Schiedsteam wird erst bei der Aufforderung von Usern aus 5% der Mäuse, mindestens jedoch aus 3 Mäusen, hin aktiv.
Sollen die Mitglieder des Schiedsteams auf dem SysOp-Treffen gewählt werden?
Ergebnis: 45 dafür, 9 dagegen, 12 Enthaltungen (66)
Die Mitglieder des Schiedsteams werden auf diesem SysOp-Treffen gewählt.
Es gibt 6 Vorschläge für die Mitglieder des Schiedsteams: Harald Krusekamp @ MS, Steffen Engel @ SZ2, Andreas Hoffmann @ K2, Marco Hahn @ SL, Philipp Oelwein @ HH2 und Marcus Ohlhaut @ BA. Es wird über jeden Vorschlag einzeln abgestimmt. Die 5 Vorschläge mit den meisten Stimmen werden Mitglieder des Schiedsteams.
Harald Krusekamp @ MS erhält 47 Stimmen
Steffen Engel @ SZ2 erhält 37 Stimmen
Philipp Oelwein @ HH2 erhält 31 Stimmen
Andreas Hoffmann @ K2 erhält 16 Stimmen
Marcus Ohlhaut @ BA erhält 17 Stimmen
Marco Hahn @ SL erhält 15 Stimmen
Somit besteht das Schiedsteam aus: Harald Krusekamp @ MS, Steffen Engel @ SZ2, Philipp Oelwein @ HH2, Andreas Hoffmann @ K2 und Marcus Ohlhaut @ BA.
Thema
Die Arbeitsgruppe beschäftigte sich mit dem Verhältnis zwischen Usern und SysOps.
Karl Reinberg @ UN
Ergebnisse
Das Mißtrauen einiger User gegenüber den SysOps entsteht aufgrund der mangelnden Information der User über die Aufgaben, Möglichkeiten und Tätigkeiten der SysOps. Die Einführung eines MausRates, wie er in den letzten Monaten in der Gruppe Maus diskutiert wurde, ist zur Lösung dieses Problem ungeeignet. Außerdem hat eine Umfrage unter den Usern gezeigt, daß von der Mehrheit der User ein MausRat auch nicht gewünscht wird.
Die Arbeitsgruppe schlägt die Einführung eines neuen Infofiles vor. In diesem Dokument soll über die Aufgaben, Rechte und Pflichten der einzelnen Personen mit entsprechendem Userstatus (Betreiber, SysOp, Programmteilwart, Gruppenchef, AL-Team) informiert werden. Durch dieses Infofile soll auch über die Pflichten des SysOp aufgeklärt werden. Axel Katerbau @ BM erklärt sich dazu bereit die Erstellung dieses Dokuments in Maus.Doku zu koordinieren.
Der Einführung eines derartigen Infofiles wird allgemein zugestimmt, weshalb keine Abstimmung darüber notwendig ist.
Die Usermitbestimmung in technischer Hinsicht kann nur vorschlagenden Charakter haben. Wie auch die SysOps den MAUS-Programmierern nur Vorschläge machen können. Die Mitbestimmung der User auf administrativer Ebene ist eine Angelegenheit der lokalen Autonomie.
Die Beteiligung der User an der Netzpolitik kann u.a. durch die Information der User über Diskussion in der Gruppe SysOps verbessert werden. Die Informationen beschränken sich dabei auf das Thema und nicht auf den Inhalt der Diskussion. Diese Information auf lokaler Ebene wird jeder MAUS im MausNet empfohlen.
In der anschließenden Diskussion wird die u.U. recht lange Antwortzeit von Mitteilungen an SysOp @ MAUS moniert. Es wird eine allgemeine Empfehlung ausgesprochen, daß Mitteilungen an den WoSy einer MAUS innerhalb von 3 Tagen zu beantworten sind.
Über die Mitleser in den technischen SysOp-Gruppen von Fremdmäusen (kommerzieller Einsatz der MAUS-Software) wird abgestimmt. Es wird darauf hingewiesen, daß nur im ISB eingetragene Personen lesenden Zugriff auf SysOp-Gruppen haben dürfen.
Abstimmungen
SysOps von Fremdmäusen werden als Gast-SysOp im ISB eingetragen. Als Kürzel wird hierbei das Kürzel der Fremdmaus eingetragen.
Ergebnis: 56 dafür, 1 dagegen, 13 Enthaltungen (70)
SysOps von Fremdmäusen werden in obiger Form im ISB eingetragen.
Thema
Die Arbeitsgruppe behandelte die Problematik der IN-Teilnahme und die Frage, ob alle Mäuse verpflichtend Mitglieder einer Domain sein müssen. Anselm Kruis @ M2
Ergebnisse
Mitteilungen von Mäusen, die nicht am IN teilnehmen, werden nicht exportiert werden. Desweiteren ergibt sich die Problematik, daß auf öffentliche Mitteilungen aus diesen Mäusen keine privaten Kommentare geschrieben werden können. Diesen Umstand könnte man u.U. durch eine entsprechende Absenderangabe kenntlich machen, die von den Gateways mit einem Bounce behandelt wird.
Es können nicht alle Mäuse an der Teilnahme am IN verpflichtet werden, wenn sie bereits über einen kommerziellen Provider versorgt werden. In der Arbeitsgruppe wurde auch überlegt, die Domain maus.de aus dem IN zu nehmen. Diese Überlegungen zielen jedoch auf die ferne Zukunft hin.
Es wird jeder MAUS dringend empfohlen, Mitglied einer Domain zu sein.
Thema
Die Arbeitsgruppe beschäftigte sich mich mit Regeln zum Kommerz in den MausNet-Gruppe und der Werbung in der MAUS selbst.
Patrick Jerchel @ B
Ergebnisse
Der lokale Kommerz ist aufgrund der lokalen Autonomie erlaubt. Es wird zwischen dem Kommerz von Seiten des Betreibers, dem Kommerz durch einen Sponsor und dem Kommerz durch Dritte im allgemeinen unterschieden. Der Kommerz kann in lokalen Gruppen, dem InfoFile Kommerz und durch entsprechende Hinweise in mtitel.dat und mende.dat erfolgen.
Die Arbeitsgruppe möchte auf dem SysOp-Treffen Entscheidungen über den Status von lokalen Kommerzgruppen (Pflicht und/oder Default), den Hinweis auf lokale Kommerzgruppen und dem Umfang von Kommerz in Titel und Abspann erreichen. Der lokale InfoText über Kommerz bleibt weiterhin zur freien Verfügung.
Des weiteren soll über die Verwendung der MausNet-Adresse - nicht der IN-Adresse - für kommerzielle Belange entschieden werden. In diesem Zusammenhang soll auch der Status der Chef-Adressierung und der Verwendung von Weiterleitungsdämonen geklärt werden.
Die Arbeitsgruppe diskutierte auch über den MausNet-weiten Kommerz und den erlaubten Umfang. Zur Entlastung der *.news Gruppen von kommerziellen Mitteilungen wird die Gründung einer MausNet-weiten Kommerzgruppe vorgeschlagen. Kommerzielle Mitteilungen könnten in dieser Gruppe kanalisiert werden. Die Diskussion über die Inhalte der *.news Gruppen konnte aus zeitlichen Gründen nicht erfolgen. Über den Umfang von Postings in diesen Gruppen wird daher in der Gruppe info.temp diskutiert.
Abstimmungen
Dürfen kommerzielle lokale Gruppen den Pflicht-Status haben?
Ergebnis: 0 dafür, 68 dagegen, 3 Enthaltungen (71)
Lokale kommerzielle Gruppen dürfen nicht den Status Pflicht haben.
Darf eine lokale kommerzielle Gruppe den Status Default haben, wenn der Benutzer darauf hingewiesen wird, wie er diese wieder abstellen darf?
Ergebnis: 24 dafür, 31 dagegen, 13 Enthaltungen (68)
Eine lokale kommerzielle Gruppe darf nicht den Status Default haben.
Darf in lokalen Pflichtgruppen auf die Existenz von lokalen kommerziellen Gruppen hingewiesen werden?
Ergebnis: 31 dafür, 19 dagegen, 19 Enthaltungen (69)
In lokalen Pflichtgruppen darf auf die Existenz von lokalen kommerziellen Gruppen hingewiesen werden.
Im Titel darf ein Hinweis (1 Zeile) auf kommerzielle Gruppen bzw. den kommerziellen Inhalt gegeben werden.
Ergebnis: 59 dafür, 7 dagegen, 3 Enthaltungen (69)
Im Titel der MAUS darf ein Hinweis (1 Zeile) auf die kommerzielle Gruppe gegeben werden.
Im Abspann der MAUS dürfen 5 Zeilen (incl. Sternchen) für kommerzielle Belange verwendet werden.
Ergebnis: 32 dafür, 22 dagegen, 11 Enthaltungen (65)
Der Hinweis auf kommerzielle Belange darf im Abspann durch 5 Zeilen erfolgen.
Darf die MausNet-Adresse (Realname) nach außen hin für kommerzielle Belange verwendet werden?
Ergebnis: 44 dafür, 5 dagegen, 17 Enthaltungen (66)
Die MausNet-Adresse (Vorname Nachname @ MAUS-Kürzel) - nicht die maus.de Adresse (Vorname_Nachname@MAUS-Kürzel.maus.de) - darf für kommerzielle Belange verwendet werden.
Darf die technische Adressierung (Info-Account, Chef) nach außen hin für kommerzielle Belange verwendet werden?
Ergebnis: 1 dafür, 56 dagegen, 9 Enthaltungen (66)
Die technische Adressierung darf nach außen hin nicht für kommerzielle Belange verwendet werden.
Darf bei Fragen in öffentlichen (netzweiten) Gruppen öffentlich mit kommerziellen Inhalten geantwortet werden?
Ergebnis: 0 dafür, 51 dagegen, 15 Enthaltungen
Es darf auf öffentliche Anfragen nicht öffentlich mit kommerziellen Inhalten geantwortet werden.
Soll eine neue (netzweite) Gruppe zur Kanalisierung von kommerziellen Inhalten gegründet werden?
Ergebnis: 21 dafür, 37 dagegen, 8 Enthaltungen
Es wird keine kommerzielle Gruppe im MausNet gegründet.
Thema
Die Arbeitsgruppe beschäftigte sich mit dem Problem von Hackern und "Megahackern".
Holger Wulfers @ HB
Ergebnisse
Die beste Gegenmaßnahme gegen Hacker ist die Aufklärung der SysOps über Sicherheitslöcher und deren Beseitigung. Die beste technische Maßnahme gegen evtl. Zerstörungen ist das Backup.
Für das Verhalten bei sogenannten Megahackern kann keine Empfehlung gegeben werden. Es gibt auch keine Maßnahmen durch die derartige Zwischenfälle vermieden werden können. Es wird der Hinweis gegeben, daß eine dauerhafte Kontrolle der Inhalte nicht notwendig ist. Der SysOp muß erst Handeln, wenn er von verbotenen Inhalten Kenntnis erlangt (z.B. durch Hinweise von Usern).
Thema
Die Arbeitsgruppe beschäftige sich mit den Themen
Headerei, Quoterei, Footerei
PGP-Signierung von öffentlichen Mitteilungen
Pseudos und dem Problem des Doppelaccounts
Markus Ohlhaut @ BA
Ergebnisse
Der Status von Headern, dem Quoteverhältnis und Footern wird wie bisher beibehalten. Header, übermäßige Quotes und Footer sind zu unterlassen. Die PGP-Signierung von öffentlichen Mitteilungen ist nicht erwünscht. Nur für gewisse Mitteilungen mit wichtigem bzw. dokumenthaftem Charakter ist eine Ausnahme erlaubt. Außerhalb von Info- und News-Gruppen wird die Signierung als Footer angesehen.
Zu Pseudos bzw. dem Problem des Doppelaccounts findet eine Abstimmung statt.
Abstimmungen
Pro natürliche Person, pro MAUS ist nur ein Account zum Schreiben ins Netz unter Realname erlaubt.
Ergebnis: 64 dafür, 3 dagegen, 3 Enthaltungen (70)
Pro natürlicher Person ist pro MAUS nur ein Account zum Schreiben ins Netz unter Realname erlaubt. Bestehende Doppelaccounts sind von dieser neuen Regelung betroffen!
Thema
Die Arbeitsgruppe behandelte die Umbenennung der MausNet-Gruppen. Durch die Verwendung von langen Gruppennamen sollen die MausNet-Gruppen in Hierarchien gruppiert werden. Für diese Gruppierung existieren verschiedene Vorschläge. Karsten Iwen @ HL
Ergebnisse
Durch die Abwesenheit von Andreas Mayer @ ZW, der bereits verschiedene Vorschläge gesammelt hat, konnte diese Arbeitsgruppe keine Ergebnisse liefern. Da die Vorschläge nicht vorlagen, konnte auf dem Treffen auch keine Abstimmung über die verschiedenen Vorschläge durchgeführt werden.
Ab dem 23.09. wird daher in der Gruppe Importgruppen.Rahmendiskussion eine endgültige Ausarbeitung des CfVs zum "Great Renaming" durchgeführt. Neben Karsten Iwen @ HL haben sich Friedrich Lämmle @ H, Uwe Ohse @ DU3, Peter Böhnke @ HB2 und Peter Redecker @ BOR bereit erklärt die Ausarbeitung zu übernehmen.
Themen
Die Arbeitsgruppe behandelte verschiedene Themen zu Gateways.
zukünftiger Status von Kreuzvernetzungen
Transitproblematik und Strategien zur Dupevermeidung
Mindestanforderungen an Gateways
Georg Bauer @ MS3
Ergebnisse
Außer den Gruppen Netzwesen, Gateways und Gatebau werden alle Kreuzvernetzungen in nächster Zeit aufgelöst. Bei allen anderen Gruppen wird einem der an der Kreuzvernetzung beteiligten Netze die Gruppe zugesprochen und deren Name für die Gruppe übernommen. Neue Kreuzvernetzungen werden nicht mehr eingerichtet. Bei der Gründung einer Gruppe ist deren Exportname festzulegen, an den sich alle anderen Netze halten müssen.
Die Transitproblematik - z.B. Zustellung einer Mitteilung vom Internet an das FidoNet über das MausNet - wird durch verschiedene Maßnahmen beseitigt. Die Maßnahmen tragen außerdem zur Vermeidung von Dupes bei.
Das einheitliche Splitting von Mitteilungen am Gateway und deren Kennzeichnung ist bereits geregelt, wird aber noch nicht von allen Gateways unterstützt.
Die Header-Zeilen sender, follow-up und reply-to werden in einer der nächsten MAUS-Versionen verfügbar sein. Sobald diese Zeilen implementiert sind, werden sie auch von Gateways verwendet werden.
Nicht mehr exportierbare Mitteilungen sollten von Gateways gekennzeichnet werden. Dies ist z.B. bei Crosspostings notwendig, da durch den Wegfall von Header-Zeilen ein vernünftiger Export nicht mehr möglich ist.
Beim Import von Mitteilungen aus dem MausNet ist die kurze MsgID aus der langen MsgID zu extrahieren und zu verwenden.
Die Gateways verwenden die Domain-Einträge der einzelnen EXP-Files um den einzelnen Mäusen die korrekte Domain zuzuordnen. In der MsgID selbst wird allerdings immer die Domain maus.de verwendet.
Das Weiterleiten einer Mitteilung aus dem Internet an eine MausNet Adresse und weiter an eine Internet Adresse ist erlaubt.
Durch obige Maßnahmen ist ein Transit von Mitteilungen durch das MausNet kein Problem mehr.
In der weiteren Diskussion wurden folgende Mindestanforderungen für Gateways im MausNet festgelegt. Die genauen Mindestanforderungen sollen bis 31.10.1996 inhaltlich mit den anderen Gateway-Programmierern in den entsprechenden Gruppen abgesprochen werden.
Die Splittingkonventionen müssen realisiert werden.
Sender/Reply-To/Followup-To müssen unterstützt werden, sobald sie verfügbar sind.
Mitteilungen, die beim Import so verändert werden, daß ein Export nicht sinnvoll ist, müssen geeignet gekennzeichnet werden. Entsprechend gekennzeichnete Mitteilungen dürfen an anderen Gates nicht exportiert werden. Was zu einer Kennzeichnung führt, muß in Zusammenarbeit der Programmierer ausgearbeitet werden.
Der Pathhack (news.maus.de in den Path eintragen) wird nur noch für Fremdnetzmitteilungen gesetzt. Bei Mausmitteilungen wird er weggelassen. Statt dessen werden bei Mausmitteilungen beim Reimport aus der langen Message-ID die kurze Id ermittelt und als Temp-ID verwendet.
Als Absenderadressen sind die Angaben aus der D-Zeile im EXP zu verwenden. Mäuse ohne D-Zeile werden nicht exportiert.
Transit von Mail, verursacht durch den PM-Forwarder (Usenet an Maus weitergeleitet an Usenet) muß erlaubt sein.
Die Konventionen zur M-Zeile müssen implementiert sein (rudimentäre Mime-Unterstützung)
Das Bouncen von öffentlichen Mitteilungen ist verboten. Am Rande der Diskussion wurde die Gruppe SysOp.Gate als "offizielle" Gruppe für Diskussionen zu Gateways im MausNet festgelegt.
Thema
Die Arbeitsgruppe diskutierte die derzeitige Problematik des AL-Teams, den Modus für Neuwahlen, die Länge der Amtszeit und die Möglichkeit zur Beteiligung von Usern am AL-Team.
Thomas Meißner @ OS
Ergebnisse
Die Arbeitsgruppe schlägt die Aufteilung des AL-Teams in ein SysOp- und ein User-Team vor. SysOp- und User-Team sind getrennt. Das User-Team bearbeitet die Abstimmungen auf Userseite, das SysOp-Team kümmert sich ausschließlich um SysOp-Abstimmungen und "kontrolliert" das User-Team.
In der anschließenden Diskussion werden weitere Möglichkeiten zur Entlastung des AL-Teams angesprochen. So wird vorgeschlagen, daß User automatisch einen CfO zur Einrichtung einer neuen Gruppe durchführen können, wenn sie auf die Anfrage beim AL-Team keine negative Antwort bekommen. Auch könnte die derzeitige Struktur des AL-Teams (nur SysOps) beibehalten werden, wenn das AL-Team Aufgaben delegieren könnte und somit nur noch koordinierende Aufgaben hat.
Es wird vorgeschlagen, daß das AL-Team als erste Handlung nach seiner Wahl den nächsten Wahltermin festlegt. Somit könnte die derzeitige Situation - AL-Team ist weit über seine eigentliche Amtszeit immer noch im Amt - vermieden werden. Es wird festgelegt, daß das AL-Team regulär im Netz zu wählen ist. Nur in Ausnahmefällen soll eine Wahl auf dem SysOp-Treffen stattfinden.
Von den derzeitigen Mitgliedern des AL-Teams wird angeregt, einen einzigen Abstimmungsdämon im MausNet zu installieren. Bisher habe jedes AL-Teams seinen eigenen Dämon verwendet. Der Dämon des derzeitigen AL-Teams befindet sich in FÜ und kann von außen nicht betreut und "bedient" werden. Markus Schmidke @ BM erklärt sich bereit, bis 19.10. einen funktionsfähigen Abstimmungsdämon zu programmieren. Jürgen Conradi würde ihn in der HB installieren. Der Dämon soll in Zukunft von allen AL-Teams verwendet werden.
Abstimmungen
Sollen User am AL-Team beteiligt werden?
Ergebnis: 28 dafür, 35 dagegen, 9 Enthaltungen (72)
Das AL-Team wird weiterhin nur aus SysOps bestehen.
Soll das AL-Team ermächtigt werden, Aufgaben an User zu übertragen?
Ergebnis: 71 dafür, 1 dagegen, 1 Enthaltung (73)
Das AL-Team darf Aufgaben in Zukunft an User übertragen.
Soll das AL-Team auch weiterhin aus 3 Personen bestehen?
Ergebnis: 73 dafür, 0 dagegen, 0 Enthaltungen (73)
Das AL-Team besteht aus 3 Personen.
Soll die Amtsdauer des AL-Teams 1 Jahr betragen?
Ergebnis: 68 dafür, 0 dagegen, 3 Enthaltungen (71)
Die Amtszeit des AL-Teams beträgt 1 Jahr
Soll das AL-Team jetzt sofort auf dem SysOp-Treffen gewählt werden?
Ergebnis: 12 dafür, 35 dagegen, 18 Enthaltungen (65)
Das AL-Team wird nicht auf dem SysOp-Treffen gewählt.
Soll das AL-Team in spätestens einem Monat gewählt werden?
Ergebnis: 52 dafür, 1 dagegen, 12 Enthaltungen (65)
Das AL-Team wird in spätestens einem Monat im Netz gewählt.
Jörg Stattaus @ W2 berichtet vom derzeitigen Status der Netzzentrale in Aachen (AC).
Frank Berger arbeitet in Paris und kommt nur jedes 2. Wochenende nach Aachen. Der andere SysOp der MAUS Aachen (Robert Hecht) kann ebenfalls aus Zeitgründen nicht schnell auf evtl. Probleme reagieren. Frank möchte daher aus zeitlichen Gründe die MAUS Aachen und damit die Netzzentrale abgeben.
Michael Keukert @ AC2 hat sich lokal bereits angeboten, die AC und damit die Netzzentrale als Zweitmaus zu übernehmen. Für die Übernahme der Zentrale haben sich ebenfalls "Fritz mit dem langen Namen" (Frithard Meyer-zu-Uptrup @ S3) und Friedrich Lämmle @ H bereit erklärt.
Die Entscheidung über den Standort der neuen Netzzentrale wird vertragt und in den SysOp-Gruppen besprochen.
Das einzige MausTausch-FrontEnd, das in dieser Hinsicht aus der Reihe tanzte, war CrossPoint von Peter Mandrella @ LU. Peter ist derzeit dabei, die Unstimmigkeiten zu beseitigen. Somit besteht kein Diskussions- und Handlungsbedarf in dieser Hinsicht.
Jörg Stattaus @ W2 erstattet als einziger anwesender Programmierer der MAUS-Software Bericht.
Kai Henningsen @ MS ist nicht mehr im Programmier-Team der MAUS dabei. Frithard Meyer-zu-Uptrup @ S3 ist seit diesem Jahr neu in das Team eingestiegen. Er kümmert sich um die OS/2-Umsetzung der MAUS und den Programmteil. Die Portierung der MAUS auf OS/2 ist größtenteils abgeschlossen. Es fehlen nur noch Feinheiten und die Fossil-Unterstützung. Nach der Portierung will sich Fritz um den Programmteil kümmern. Er übernimmt dafür die Sourcen von Achim Reinhardt und wird wohl als erstes den SaugTausch implementieren.
Die Sourcen der OS/2-MAUS sind übrigens mit denen der normalen MAUS unter DOS identisch. Die verschiedenen Versionen werden durch Compilerschalter realisiert. Die beiden Versionen (DOS und OS/2) werden daher immer den gleichen Stand haben.
Die MessageBase der MAUS 9 ist von Jörg fertig "designed" und basiert auf dem MausTausch-Format. Das Format kann daher in Zukunft beliebig ohne größere technische Probleme erweitert werden. Der MausTausch kann durch das neue MessageBase-Format sehr einfach implementiert werden. Es existiert bereits ein Importer/Exporter in einer Alpha-Version, der die bisherigen Netzpakete in die neue MessageBase einsortieren bzw. daraus erzeugen kann.
Gereon Steffens @ K2 kümmert sich derzeit um die laufende Wartung der MAUS-Software (Bugfixes, neue Features). Gereon ist im Gegensatz zu Jörg etwas skeptischer, was die Realisierung der MAUS 9 angeht.
Durch die neue Arbeitsstelle hat Jörg jedoch weniger Zeit für die Programmierung der Software. Er ruft deshalb interessierte und motivierte Programmierer zur Mitarbeit im Programmierer-Team auf. Georg Bauer wird sich um die Weiterentwicklung des FidoNet-Gateway kümmern.
Uwe Ohse @ DU3 berichtet über den derzeitigen Stand der Quark.
Die Quark kann bei der derzeitigen Struktur des MausNet nicht als Standardmaus eingesetzt werden. Der Austausch von Netzpaketen funktioniert derzeit nur zwischen Quarks. Eine Abhilfe ist evtl. durch die MAUS 9 möglich.
Ansonsten ist die Entwicklung soweit abgeschlossen. Auch er ruft interessierte Programmierer zur Mitarbeit an der QUARK auf. In Zukunft ist u.a. die MultiPort-Fähigkeit der QUARK-Software vorgesehen.
Das Umpacken von Shareware ist nach dem Urheberrechtsgesetzt verboten.
Durch den Paragraph 2 des Urheberrechtsgesetzes fällt auch Shareware bzw. Software im allgemeinen unter die Regelungen dieses Gesetzes. Im Paragraph 17 dieses Gesetzes wird das Verbreitungsrecht geregelt. Durch diesen Paragraph ist das Umpacken und Hinzupacken gesetzlich verboten. Der Autor von Shareware gibt die Art der Verbreitung vor. Ein Umpacken der Archive bzw. ein Hinzupacken von weiteren Dateien ist somit nicht erlaubt.
Das Umpacken von Archiven kann u.U. auch Überprüfungen auf die Authentizität unmöglich machen. Einige Packformate erlauben dieses Verfahren, damit man die Veränderung von Originalarchiven erkennen kann.
FidoNet-Gateways
Timm Ganske @ OF berichtet über den Stand der Gateways zum FidoNet. Er beschäftigt sich derzeit mit der Erstellung von Pseudo-Rules, die für exportierte MausNet-Gruppen im FidoNet gelten sollen. Auch ist er um die Zusammenstellung einer Liste aller ins FidoNet exportierten Gruppen bemüht.
Die Verbreitung der MausNet-Gruppen im FidoNet beschränkt sich auf Inseln. Tests haben ergeben, daß nur kleine Bereiche des FidoNet mit MausNet-Gruppen versorgt werden. Es wird daher der Export von Mitteilungen an allen FidoNet-Gateways aktiviert. Sobald es zu Dupes kommen sollte, sind entsprechende Maßnahmen sofort einzuleiten.
GerNet-Gateway
Michael Keukert @ AC2 kann nichts besonderes über das Gateway zum GerNet in AC2 berichtet. Er weist jedoch auf das Vorhandensein von weiteren Areas außer der ins MausNet importierte Area ct hin. Wenn Interesse am Import dieser Areas besteht, können diese sofort in AC2 importiert werden.
TK-Gesetz und Auswirkungen auf das MausNet
Die Auswirkungen des neuen TK-Gesetzes sollten von Leuten mit juristischem Hintergrundwissen untersucht werden. Interessant in diesem Zusammenhang ist u.a. die Definition von geschäftsmäßig, die schon bei der Anmeldung von privat geführten Mailboxen beim BAPT eine Rolle gespielt hat. Auch der Unterschied zwischen den Begriffen Dienst und Dienstleistungen könnte für die Auswirkungen des TK-Gesetzes auf das MausNet relevant sein.
Es wird die Einrichtung einer temporären, MausNet-weiten Gruppe zu diesem Thema vorgeschlagen. In dieser Gruppen sollen auch User beteiligt werden.
Das SysOp-Treffen 1997 findet in Bamberg statt. Für 1998 hat sich der Frankfurter Raum als Austragungsort des SysOp-Treffens angeboten.
Teilnehmerliste
MAUS Vorname Name AC2 Boris Meltzow AC2 Michael Keukert AC2 Stefan Rupp A-W Thomas Moser AN Gert Stamminger B Christian Goßlar B Patrick Jerchel BA Marcus Ohlhaut BA Martin Schwenk BA Michael Neumann BB Ulrich Frey BIR Ulrich Schilken BM Axel Katerbau BM Marcus Schmidke BOR Georg Feuersträter BOR Peter Redecker D Andreas Jülicher DO2 Udo Erdelhoff DO2 Uwe Blenz DU Georg Schroers DU Klaus Abele DU Michael Wolf DU3 Uwe Ohse EL Uwe Sonntag GP Michael Wist H Friedrich Lämmle HB Holger Wulfers HB Jürgen Conradi HB Mick Schmidt HB Rosi Brase HB2 Olaf Peters HB2 Peter Böhnke HB2 Thomas Wilkens HB2 Volkmar Jürgens HH Harald Labeit HH2 Philipp Oelwein HH3 Gunnar Landgrebe HL Karsten Iwen HM Ingolf Heilemeier HM Jens Lüthje HRO Andreas Klebow K2 Andreas Hoffmann KI Klaus Atzpodien KR Henry Rolofs LB Andreas Frank LB Uwe Seidler LU Andreas Kögel LU2 Frank Roeske LU2 Stefan Huerter M2 Anselm Kruis MK2 Dirk Reinarz MK2 Martin Loos MS Harald Krusekamp MS Michael Steinwachs MS3 Georg Bauer OF Jens Hefter OF Marc Hefter OF Timm Ganske OF2 Frederico Hernandez-Püschel OG Alexander Porntepcharoen OG Andreas Mandel OG Patrik Schindler OS2 Thomas Meißner S Gerhard Meiser S5 Inge Meiser S5 Michael Kugelmann SL Marco Hahn SZ Steffen Engel TBB Hans-Peter Bock TBB Stefan Heidrich UN Edgar Rosenboom UN Karl Reinberg UN Rosemarie Rosenboom W2 Jörg Stattaus WHV Silke Tintelott WHV Thomas Morgenthaler WUN Sebastian Hempel WÜ Elke Freier WÜ Roland Füßl
Am 21. September 1996 wurde in Bremen beim SysOp-Treffen die Wahl des schönsten Sysops durchgeführt.
Nun möchten wir den "normalen" ;-) Usern nicht vorenthalten, welche Herren dort von einer fachkundigen Jury - bestehend aus 5 weiblichen Sysops - zu den schönsten Sysops im MausNet gewählt wurden.
Vielleicht kann man ja ein bewunderndes Pfeifen in die nächste Mail einbauen, mit der man sich jetzt endlich mal zum Maustreffen anmeldet, weil die Neugierde einfach zu groß ist. ;-)
Marcus Schmidke @ BM
Jörg Stattaus @ W
Timm Ganske @ OF, Harald Krusekamp @ MS
Sebastian Hempel @ WUN
Dirk Reinarz @ MK2, Peter Böhnke @ HB2
Karsten Iwen @ HL, Patrick Jerchel @ B, Martin Schwenk @ BA
Peter Redecker @ BOR, Roland Füßl @ WÜ, Stefan Heidrich @ TBB
Hans-Peter Bock @ TBB, Ulrich Frey @ BB, Markus Ohlhaut @ BA,
Thomas Morgenthaler @ WHV, Uwe Ohse @ DU3
Uwe Seidler @ LB, Andreas Hoffmann @ K2
Steffen Engel @ SZ, Harald Labeit @ HH
Copyright © by Christian Goßlar
Letzte Aktualisierung am 6. November 1997