Zur Maus 7 kündigte Gereon einige Änderungen an. Es wird in Zukunft möglich sein, das MausMeter per MausTausch abzurufen. Diese Version wird frühestens in 2 Wochen freigegeben, da dieses Feature noch nicht von den Frontends unterstützt wird. Diese Infofiles benötigen keine CRC-Berechnung, da sie bei jedem Abruf verschieden sein werden. Für Remote-SysOps ist es dann auch möglich, das MCALL.LOG per MausTausch abzurufen. Gereon kündigte auch an, daß er für vernünftige Anregungen jederzeit offen ist, solange es sich nicht um irgendwelche obskuren Vorschläge handelt (O-Ton Gereon: "Nicht wahr, Wolfgang?").
Die Mausprogrammierer haben sich bereits Gedanken gemacht, was nach Maus 9 kommen soll. Der Hintergrund ist der, daß für Maus 9 nicht irgendwelche Datenstrukturen festgelegt werden, die in 2 Jahren wieder umgeworfen werden müssen. Diese "Maus 10" soll eine Multi-Port-Maus werden, wodurch ein Multitasking-Betriebsystem (z. B. OS/2) vorausgesetzt wird. Hier wurde auch daran gedacht, DR-DOS 7.0 als Betriebsystem zu verwenden (O-Ton Gereon: "Bitte nicht schlagen"), wobei eine Art Client-Server-Struktur Verwendung finden könnte.
Jörg Stattaus äußerte sich skeptisch, was die Fertigstellung der Maus 9 angeht. Bisher wurde davon ausgegangen, daß die Maus 9 im Jahre 1993 fertiggestellt wird (siehe auch Flensburger Protokoll 3.1), was aus Zeitmangel der Programmierer nicht möglich war. Jörg stellte die Frage, ob jemand in "C" eine neue Maus programmieren möchte, da eine Portierung nicht sinnvoll ist. Die aktuelle Maus soll dabei als Pflichtenheft angesehen werden. Diese Maus soll eine Alternative zur Maus 9 sein, was nicht heißen soll, daß Maus 9 begraben wird.
Fritz Elfert gab darauf bekannt, daß eine Mailingliste existiert, in der bereits Grundüberlegungen zu einer Unix-Maus (UMaus) angestellt wurden. Evtl. kann Ende 1993 in die Programmierung eingestiegen werden. Mitte des Jahres wurden die ersten Planungen dazu begonnen, die sich mit den Vorstellungen von Gereon zur Maus 10 decken. Diese Maus soll auf jeden Fall netzwerkfähig werden. Allerdings befindet sich diese Maus noch im Planungsstadium. Jörg, Kai und Gereon gaben bekannt, daß sie diese Maus unterstützen werden. Sie werden alle Informationen (insbesondere zu den Datenstrukturen) zur Maus herausgeben. Nach Jörg's Aussagen können beide Seiten davon profitieren.
Frank Baumgart gab abschließend noch einen kurzen Überblick über den derzeitigen Stand der Quark-Soft, die inzwischen komplett von BASIC nach C portiert wurde. Die Quark-II wird "in der nächsten Woche" wieder in die Beta-Phase gehen. Es gibt nach Franks Worten bereits Überlegungen zu einer Quark-III, die ebenfalls in C programmiert werden soll und so portabel wie möglich gehalten werden soll, damit sie auf alle Plattformen (TOS, Linux) leicht portiert werden kann. Diese Quark-Version wird auch multiport-fähig sein.
Zur Problematik "einheitliche Gruppennamen im MausNet" wies Erwin Sienknecht darauf hin, daß Frontends keine Änderung des Gruppennamens erkennen, was bei der Namensänderung bestehender Gruppen zu Problemen führen würde. Da dies ein technisches Problem zwischen der Maus und den Frontends ist, wurden u. a. Steuermessages zur Gruppenumbenennung vorgeschlagen. Da dieses Thema bisher noch nicht zu einem Konsens in TAUSCHBAU geführt hat, wird es eine technische Lösung wohl so schnell nicht geben. Es stellte sich nun die Frage, ob eine "politische" Lösung gefunden werden sollte, oder ob die Gruppennamen wie bisher bleiben sollten. Frauke Cremer wies auf die Problematik der Quarks hin, die ihre Nachrichten bekanntlich per MausTausch bekommen. Frauke sagte, daß es ärgerlich sei, wenn eine neue Netzgruppe eingerichtet wird und in der Servermaus einen anderen Namen als den Netznamen bekommt. Der Quark-SysOp kann ja nur den Netznamen wissen, so daß die Quark bei abweichenden Gruppennamen die Fehlermeldung bekommt, daß es die bestellte Gruppe nicht gibt. Die folgende Abstimmung ergab eine deutliche Mehrheit zur Vereinheitlichung der Gruppennamen. Als Termin wurde der 1. November 1993 festgelegt. Michael Keukert brachte daraufhin den Einwand, daß manche Netzgruppennamen nicht korrekt seien (Beispiel: Die MausNet-Gruppe heißt CT, die Zeitschrift aber C'T). Es wurde per Akklamation beschlossen, daß Michael Keukert erstmal eine Vorschlagsliste erarbeitet. Anschließend sollen die Namen in den betreffenden Gruppen mit einfacher Mehrheit abgestimmt werden. Gereon machte abschließend noch den Vorschlag, in die Maus-Software etwas einzubauen, was diese Umstellung für die Frontends einfacher machen wird. Dieses Feature steht nach seinen Aussagen ganz oben auf der "Maus-to-do-Liste".
Von Florian Helm kam der Vorschlag, eine SysOp-Gruppe einzurichten, in der allerdings nur Betreiber schreiben dürfen. Gereon wies darauf hin, daß die Gruppe von ca. 5 Personen vollgemüllt wurde, wodurch eine Mengenbeschränkung sinnvoller sei als eine Betreibergruppe. Michael Keukert wandte ein, daß Mengen-Beschränkungen technisch derzeit nicht möglich, und von daher schwer durchzusetzen sind. Jörg Stattaus schlug vor, da befristete Schreibsperren gebraucht werden, evtl. mal über eine moderierte Gruppe SYSOPS nachzudenken. Michael zeigte dazu die derzeit üblichen Arten der Moderation (Fido: Moderator meckert User an, die Gruppen zumüllen und können diesen Schreibzugriff entziehen. UseNet: Mails werden als PM an den Moderator geschickt, der die Nachrichten dann in die Gruppe postet) auf. Georg Bauer brachte zu Jörgs Vorschlag, eine Betreibergruppe einzurichten, den Einwand, daß Betreiber als Moderatoren ihrer Co-SysOps unbrauchbar sind, da die letzten Diskussionen in SYSOPS gezeigt haben daß die Fronten zwischen den Mäusen und nicht zwischen den SysOps bestanden. Eine Betreibergruppe würde nichts ändern, da zwar weniger Namen zu lesen sind, aber immer noch die gleichen Argumente wiederholt werden.
Das bereits vor Wochen in SYSOPS angeregte Abstimmungsleiter-Team (AL-Team), könnte die Rolle eines Diskussionsleiter-Teams (DL-Team) übernehmen, schlug Jörg vor. Sevo bekräftigte dies, da Einzelpersonen als Abstimmungsleiter - wie die Erfahrung der letzten Jahre gezeigt hat - zu schnell demontiert werden. Frauke schlug vor, daß das DL-Team aus drei und nicht aus fünf Personen bestehen sollte, da unter 3 Leuten eher eine Einigung möglich sei als unter 5 Leuten. Michael regte an, für Diskussionen des DL-Teams eine eigene Gruppe einzurichten, die zwar von allen SysOps gelesen, aber nur vom DL-Team beschrieben werden kann.
Da schnell mal ein Mitglied des DL-Teams ausfallen kann (Klausur, Urlaub), regte Frauke an, drei Stellvertreter zu wählen (für jedes Mitglied einen). Kai schlug vor, daß die Mitglieder des DL-Teams aus verschiedenen Mäusen kommen sollten, da (wie schon von Georg festgestellt) die Fronten zwischen verschiedenen Boxen, aber nicht innerhalb einer Maus existierten. Jörg Henne griff nochmal den Vorschlag von Jörg Stattaus auf, das DL-Team solle in Personalunion mit dem AL-Team stehen.
Im Laufe der Diskussion wurde sich darauf geeinigt, daß dem DL-Team die Kompetenz eingeräumt werden soll, "totgelaufene" Diskussionen in SYSOPS für beendet zu erklären und evtl. SysOps, die sich daran nicht halten, für eine bestimmte Zeit aus der Gruppe SYSOPS auszuschließen. Jörg Stattaus stellte heraus, daß die Schreibsperre durch die Leserschaft der Gruppe SYSOPS zu legitimieren ist. Sevo machte darauf aufmerksam, daß der Abstimmungszeitraum kürzer gemacht werden sollten. Auf ein Abstimmungsergebnis zu einer Schreibsperre kann man nicht ein paar Wochen warten. Da das AL-Team mit der Gruppe SYSOPS und dem Lesen der Gruppen MAUS.INFO und MAUS überlastet wäre, schlug Michael Keukert vor, daß das AL-Team Abstimmungen über Gruppeneinrichtungen und Gruppenex- und Importe an User delegieren können sollte.
Die folgende Abstimmung, ob wir "eine Gruppe von Leuten, die auf die Gruppe SYSOPS irgendwie einwirken können" haben wollen, ergab eine deutliche Mehrheit - bei einer Gegenstimme - zugunsten eines DL-Teams.
Die Abstimmung über die Zusammensetzung des DL-Teams ergab 16 Stimmen für den Vorschlag, daß die Mitglieder des DL-Teams aus verschiedenen Orten kommen sollen und 54 Stimmen für den Vorschlag, daß die Mitglieder aus 3 verschiedenen Mäusen kommen müssen.
Bei den folgenden Abstimmungen ging es nun um die Kompetenzen des DL-Teams. Der Vorschlag "Das DL-Team hat die Kompetenz, ein Thema abzuwürgen" wurde mit einer Gegenstimme und fünf Enthaltungen angenommen. Der Vorschlag "Das DL-Team kann gegenüber einem Schreiber in der Gruppe SYSOPS eine Verwarnung aussprechen" wurde mit fünf Gegenstimmen und 4 Enthaltungen angenommen.
Diese Verwarnung kann ausgesprochen werden, wenn ein SysOp sich nicht an die Bestimmung hält, daß ein Thema beendet ist, oder wenn er rumflamed.
Ebenfalls eine deutliche Mehrheit fand der Vorschlag, daß der SysOp, über den der CFV läuft, während des CFV Schreibverbot hat. Mit deutlicher Mehrheit abgelehnt wurde der Vorschlag, daß während ein CFV gegen einen SysOp läuft (wenn dieser zu einem Thema geflamed hat), das Thema für alle in der Gruppe SYSOPS tabu ist. Dafür fand sich eine deutliche Mehrheit dafür, daß über den CFV nicht diskutiert werden darf, während dieser läuft.
Eine weitere Abstimmung über die Kompetenzen des DL-Teams ergab bei drei Gegenstimmen und sechs Enthaltungen, daß das DL-Team die Befugnis hat, gegen einen SysOp ein Schreibverbot zu verhängen. Dieses muß durch einen CFV durch die SysOps legitimiert werden. Das Schreibverbot gilt defaultmäßig für 14 Tage und das Ergebnis des CFV muß drei Tage nach posten des CFV veröffentlicht werden. Sonderregelungen für den Wiederholungsfall müssen seperat bestimmt werden. Die anschließende Abstimmung über die Verlängerung der Abstimmung von drei auf fünf Tage wurde bei vier Pro-Stimmen und 14 Enthaltungen abgelehnt.
Der Vorschlag, den Abstimmungsleiter durch das "3+3 AL-Team" zu ersetzten, wurde bei fünf Gegenstimmen und sechs Enthaltungen angenommen. Bei fünf Gegenstimmen und 12 Enthaltungen wurde Personalunion zwischen dem DL-Team und dem AL-Team beschlossen.
Die Amtszeit des AL-Teams wurde bei drei Gegenstimmen und 24 Enthaltungen auf ein halbes Jahr festgesetzt. Falls Proteste gegen das AL-Team aufkommen sollten, so finden die Regeln zur Abwahl des Abstimmungsleiters aus dem Mosbacher Protokoll für jedes einzelne AL-Team-Mitglied Anwendung. Dieses wurde ohne Gegenstimmen, bei 10 Enthaltungen beschlossen. Der alte Abstimmungsleiter (bzw. AL-Team) führt die Wahl zum neuen AL-Team durch. Die Wiederwahl ist möglich.
Ohne Gegenstimmen, bei drei Enthaltungen wurde auch das Wahlverfahren beschlossen: Jeder SysOp hat 3 Stimmen, die er auf 3 verschiedene Kandidaten verteilen kann. Die Ergebnisliste wird in der Reihenfolge der Anzahl der erhaltenen Stimmen von oben nach unten ausgewertet unter der Voraussetzung, daß aus einer Maus nicht mehr als 1 Mitglied pro Maus im AL-Team ist (außer als Stellvertreter eines anderen). An dieser Stelle verweisen wir noch auf die Thematik "Doppelmäuse", die zu einem späteren Zeitpunkt behandelt wurde (Anm. d. Protokollführer).
Mit einer deutlichen Mehrheit wurde beschlossen, daß das AL-Team von den SysOps gewählt wird. Acht Stimmen entfielen auf den Punkt "Wahl des AL-Teams durch die User" und sieben Enthaltungen wurden registriert.
Bezüglich einer eigenen Diskussionsgruppe SYSOP.AL für das AL-Team (alle SysOps dürfen lesen, schreiben darf nur das AL-Team) stimmten 10 SysOps gegen diesen Vorschlag, 16 enthielten sich der Stimme und die Mehrheit stimmte dafür.
Nach anschließender Diskussion wurde dieses Ergebnis wieder verworfen und auf Antrag von Michael Keukert (mit deutlicher Mehrheit) festgehalten, daß der Ausschluß einer Maus zwar das letzte und schwerwiegendste Mittel ist, welches im Sanktionsfall eingesetzt werden kann, aber daß dieses Mittel existiert.
Um das Adresschaos mit Fido-Adressen innerhalb des MausNet zu vermindern, sollen die Gateways umbenannt werden (Fido-F/Fido-AC), damit die Adresse eindeutiger ist.
Gegen eine Box, die sich nicht an Abstimmungsergebnisse hält, sollen Sanktionen verhängt werden können. Der Abstimmungaufruf zu Gruppenexporten soll in Zukunft eindeutiger formuliert werden.
Peter Böhnke regte an, anstelle der Stimmensammlung sofort eine Abstimmung durchzuführen, weil immer jemand gegen ist. Damit würde auch die Bewertung von "deutlichem Widerspruch" wegfallen. Vorgeschlagen wurde auch, den Ablauf der Gruppeneinrichtungen für Exporte zu übernehmen. Fritz Elfert schlug vor, einen Prozentwert der Teilnehmer anzusetzen. Wenn mehr als 10 % der Teilnehmer bei einer Umfrage unter den Lesern der Gruppe gegen einen Export sind, findet der Export nicht statt.
Weiterhin wurde angeregt, daß der Aufruftext standardisiert werden sollte. Peter Böhnke forderte, daß der Aufruf nur in der Gruppe und nicht in MAUS.INFO oder anderswo gepostet wird. Ebenso sollte der Aufruf, so Michael Keukert, positiv formuliert werden. Er sollte zum Beispiel nicht so aussehen: "Ist jemand dagegen, daß nicht exportiert wird?".
Der Vorschlag, den Ablauf zur Gruppeneinrichtung zu übernehmen wurde nochmals in die Diskussion eingebracht. Das Thema wurde damals ausreichend diskutiert, warum sollte es nochmals ausgearbeitet werden, zumal es gut funktioniert.
Folgender Ablauf zu Gruppenexporten wurde dann bei 8 Gegenstimmen und 6 Enthaltungen festgelegt: Der User (der den Export wünscht) wendet sich an das AL-Team, welches ihm eine Bestätigung und den formulierten Abstimmungsaufruf schickt. Hiermit autorisiert das AL-Team den User zum posten des Abstimmungsaufrufes und zur Stimmensammlung. Der Aufruf wird nur in der betreffenden Gruppe gepostet und enthält nur die Punkte "Dafür" und "Dagegen". Die einfache Mehrheit reicht für den Export.
Mit 4 Enthaltungen und keiner Gegenstimme wurde noch beschlossen, daß das Ergebnis von Exportabstimmungen grundsätzlich nach MAUS.INFO gepostet wird.
Stefan berichtete, daß der Gateway derzeit auf seinem Notbook läuft, aber er hofft, daß es in Kürze unter OS/2 auf der Maus K laufen wird.
Frauke Cremer bat noch einmal darum offenzulegen, an wen was bezahlt werden muß. Stefan erläuterte, daß der IN-Beitrag, der zur Teilnahme am IN und damit zum Bezug und Versand von Mail und News ins Usenet berechtigt, an den Domainverantwortlichen gezahlt wird. Die Servergebühr ist an die Maus Köln zu zahlen, da dies die Telefonkosten sind, die der Maus Köln für den UseNet-Gateway entstehen. Eine volumenabhängige Abrechnung will Stefan nicht erstellen, da der Aufwand zu hoch sei. Mäuse mit eigenem UseNet-Gateway brauchen keine Servergebühr bezahlen.
Zur Mailbeschränkung besteht derzeit folgende Regelung: Die maximale Mailgröße von einem User an den gleichen User ist pro Tag auf 48 KB festgelegt. Bei Überschreitung dieser Größe wird ab 100 KB eine Strafgebühr in Höhe von 10,-- DM pro angefangenem MB erhoben. Die Kosten sind eine reine Abschreckung und nicht die tatsächlichen Kosten, die hierbei entstehen.
Jörg Stattaus schlug vor, daß die Strafgebühren dem Gateway zugute kommen sollen und somit die Servergebühr vermindert werden kann.
Ohne Gegenstimme bei 11 Enthaltungen wurde beschlossen, daß die Grenze für Mailmassen weiterhin bei 48 KB liegt. Alles, was darüber hinausgeht, wird nicht weitergeleitet, sondern gelöscht. Absender und Empfänger erhalten eine freundliche Aufforderung, das in Zukunft doch besser zu unterlassen. Ab 100 KB werden pro angefangenem MB wird eine Strafgebühr in Höhe von DM 10,-- erhoben.
Eine Betreiberabstimmung zu Servergebühr ergab ein einstimmiges Votum für DM 8,-- pro Jahr und Maus die Mail über den Kölner Gateway laufen läßt.
Klaus Abele warf den Domainverantwortlichen vor, daß in SYSOP.IN ein Informationsdefizit bestehe. Es sollten mehr Informationen von den DVs an die SysOps weitergegeben werden. Peter Böhnke verteidigte die DVs. Wenn Jürgen oder Günter auf irgendwas angesprochen werden, erzählen sie immer was. Wenn sie nicht gefragt werden, können sie natürlich auch nichts sagen. Bisher ist auf Anfrage immer was von den beiden gekommen. Abschließend sagte Peter noch, daß wir uns um eine kostengünstigere Lösung kümmern sollten, worauf Michael Keukert noch zu bedenken gab, daß die billigste Lösung nicht immer die günstigste ist.
An dieser Stelle wurde die Diskussion dann beendet.
Irgendwo sollte festgehalten werden, wer bei SysOp-Abtimmungen stimmberechtigt ist. Peter Böhnke machte den Vorschlag, daß Co-SysOps im ISB stehen sollten, damit das AL-Team eine Liste der bei SysOp-Abstimmungen stimmberechtigten Personen an der Hand hat. Vorschlag einer Definition: Co-Sysop ist, wer im ISB steht. Betreiber werden extra ausgewiesen. Kai warf ein, daß es "völlig Banane" ist, wer die Stimme für die Maus abgibt.
Die folgende Abstimmung ergab dann bei einer Enthaltung und sechs Gegenstimmen, daß SysOps und Co-SysOps mit ihrem Namen im ISB stehen müssen. Die Adresse ist keine Pflicht.
Nach kurzer Diskussion, bezüglich der Stimmberechtigung der SysOps wurde das Ergebnis der Abstimmung verworfen und die Abstimmung neu formuliert: "SysOps, die abstimmungsberechtigt sind, müssen im ISB stehen." Dieser Antrag wurde bei 15 Enthaltungen und vier Gegenstimmen angenommen.
Jörg Henne schlug vor, das ISB im PMK-Token-Format zu vereinheitlichen. Sam Jost befürwortete das, da die Abstimmungsleiter dann das ISB maschinell auswerten könnten. Wer seine SysOps dann nicht im PMK-Token-Format ins ISB einträgt, ist halt nicht abstimmungsberechtigt. Michael Keukert wies darauf hin, daß das ISB bei Maus 9 automatisch vorgegeben wird, um Fehler zu vermeiden. Daher sollte das derzeit noch nicht zur Pflicht gemacht werden.
Sevo teilte zum Thema ISB noch mit, daß die Maus F ihre Rufnummer jetzt im internationalen Format im ISB eingetragen hat. Damit Probleme mit den österreichischen und Schweizer Mäusen nicht auftreten, sollten das bei allen Mäusen so gemacht werden.
Es folgte eine Abstimmung, ob ein System mit dem gleichen Betreiber, räumlich beieinander stehend, bei gleichem Angebot der beiden Systeme (Ausnahme z.B. UN(2), die auf dem zweiten Port nur Spiele usw. anbieten) als ein System oder mehrere Systeme zu betrachten sei. Dreizehn Stimmen fanden sich für den Punkt "mehrere Systeme", sieben Stimmen waren Enthaltungen und der Rest stimmte für den Punkt "ein System".
Nun fand eine Betreiberabstimmung über die Verteilung der IN-Gebühr statt. Jörg Stattaus schlug vor, daß die Mäuse sich selbst einschätzen (22 Stimmen). Der Vorschlag von Gereon Steffens, daß jede Maus das gleiche zahlt erhielt 18 Stimmen. Sieben Betreiber einthielten sich der Stimme.
Kai Henningsen regte an, diese Abstimmung in die Gruppe SYSOPS zu verlegen, da das Ergebnis recht knapp war. Dieser Vorschlag fand allgemeine Zustimmung.
Marcel Sieling brachte den Einwand, daß das Thema lang und breit diskutiert wurde. Es gibt den MausNet-Guide, der fast fertig ist. Den lokalen SysOps sollte überlassen werden, was sie damit machen. Der MausNetGuide ist ganz gut konsensfähig, warum sollte SysOps, die sich nicht damit anfreunden können der Guide vorgeschrieben werden? Jede Maus sollte das halten wie die lokalen SysOps wollen. Michael Keukert vertrat die gleiche Meinung. Die Netiquette ist Sache der User und sollte nicht von oben herab bestimmt werden.
Die Abstimmung, ob der MausNet-Guide als freiwillige Richtschnur anzusehen ist, und es den lokalen Mäusen überlassen wird, was sie damit machen wurde ohne Gegenstimme bei drei Enthaltungen angenommen.
Die lauten Vertreter der Leute außerhalb des MausNet sind der Ansicht, daß der "Gelesen"-Status ziemlich krass gegen den Datenschutz verstößt, allerdings scheint es auf der Seite auch einige Unklarheiten über die Technik zu geben. Erwin Timmerbeil hat einen Datenschutzbeauftragten gefragt, der meinte daß es kein Problem wäre, wobei es auch im MausNet ein deutliches Mißverständnis zwischen dem "Angekommen"-Staus und dem "Gelesen"-Status gibt. Der "Gelesen"-Status wird entweder explizit vom Frontend gesetzt oder eben nicht, Crosspoint setzt ihn, wenn eine bestimmte Option gesetzt ist, auf 12 Uhr anstatt ihn gar nicht zu setzen. Dieser Streit hat schon einige heftige Äußerungen ausserhalb des MausNet hervorgerufen hat, bis zur Äußerung, daß wir in einem faschistoiden Netz leben würden. Michael fragte noch, wie weit das bekannt sei, und wie weit Diskussionsbedarf besteht.
Sevo Stille vermutete, daß diese Leute den "Gelesen"-Status nicht ganz verstanden haben und von der Meinung ausgehen, daß das in irgendeiner Form öffentlich lesbar sei und daß dabei konkrete Zeiten mitgeschickt werden. Die Frontends sollten optional anbieten, die Uhrzeit mitzuliefern, was das Datenschutzproblem umgehen würde.
Michael Keukert regte an, in die MausTausch-Doku mit aufzunehmen, daß ein User, der den Status setzt, dies richtig zu tun hat. Wer den Status nicht herausgeben will, setzt den Status nicht, damit falsche Statusmeldungen unterdrückt werden. Jörg Stattaus machte deutlich, daß dieses defaultmäßig der Fall sein sollte.
Die folgende Abstimmung über den Vorschlag, daß Frontend-Programmierer dazu angehalten werden, den Status so zu behandeln, daß dieser vom Frontend richtig gesetzt wird, oder gar nicht wurde bei fünf Gegenstimmen und neun Enthaltungen angenommen.
Der Antrag, daß Statusmeldungen nur auf explizite Anforderung des Users verschickt werden, wurde bei fünf Enthaltungen und einer Pro-Stimme abgelehnt.
Nach ausführlicher Diskussion über die Vor- und Nachteile dieser Gruppe wurde diese bei einer Abstimmung mit siebzehn Pro-Stimmen und vierunddreißig Enthaltungen abgelehnt.
@AC Jörg Stattaus
@HN Frauke Cremer @S Gerhard Meiser
@AC2 Michael Keukert Frank Düring Inge Meiser
Stefan Rupp Andreas Frank
Frank Landrock @K Stefan Radermacher Hans-Peter Deist
Joachim Hoss
@AC3 Claus Wickinghoff @S2 Markus Wagenmann
@K2 Gereon Steffens Peter Ahlert
@BB Jörg Henne Edgar Fuß Uwe Schlenther
Ulrich Fey Dirk Steins Florian Unger
@BM Marcus Schmidtke @KA2 Wolfgang Walter @S3 Fritz Meyer-Zu-Uptrup
Matthias Stürmer Uwe Poliak
@BN Florian Helm Michael Wist
@KI Klaus Atzpodien
@CB Romeo Rakow Nils-Henner Krüger @SB Ralf Bühr
@CLP Joachim Theile @KL Gabriel Schmidt @SL Marco Hahn
Michael Schlüter
@DO Michael Roder @KR Elmar Höttges
Stefan Hintz Marcel Sieling @SN Jörn Kresse
Peter Redecker Harro Hedemann
@ST Lorenz Isbeih
@DO2 Erwin Sienknecht @L Matthias Bachmann Ralf Siepker
Alfred Schmidt Andre Dütsch
Udo Erdelhoff @LU Olaf Boss Ralf Czekalla
@DU Klaus Abele @M Lutz Grünewald @ST2 Georg Bauer
Georg Schroers /MS3 Martin Koyro
Dietmar Hannemann @M4 Christian Hohendorf
Claudia Hohendorf @SU Tobias Bartelt
Vanessa Rehde
@F Sevo Stille @MS Kai Henningsen
Timm Ganske @TBB Hans-Peter Bock
Petra Ilyes @N Udo Fleckenstein
Detlef Woltmann @UN Rosemarie Rosenboom
@NF Gerhard Trimpin Edgar Rosenboom
Joern Haase Martin Loos
@FL Maik Standtke
Sam Jost @OG Andreas Mandel @WOB Jens Barth
Thomas Przetak Stefan Llabres
@WÜ Markus Klingspor
@GÖ Mario Adam @PB Bernd Becker Fritz Elfert
Frank Baumgart Jochen Krapf
@H Friedrich Lämmle Uwe Ohse
Dittmar Knoop @WUN Sebastian Hempel
Andreas Zenner @PB2 Carsten Ellermann
Wolfgang Völker @ZW Andreas Mayer
@PE Lars-Iver Kruse Ulrich Pfister
@HB2 Peter Böhnke Jürgen Stessun
Ulli Handorf Steffen Engel
Thomas Wilkens Jürgen Loos
@R Thomas Gallert
@HD Philipp Oelwein Markus Fertsch
@HG Ralf Lenz @RO Marian Maier
Thomas Fey
@RS Thorsten Floeck
@HH Harald Labeit Claudia Hessling
Michael Przetak (Gast)
@HL Karsten Iwen