Bundesgeschäftsstelle/Streitfragen Mitgliederverwaltung

In diesem Papier wurden offene Streifragen des Anforderungspapiers diskutiert:

http://wiki.piratenpartei.de/Bundesgeschäftsstelle/Anforderungspapier_Mitgliederverwaltung

Bei der Erstellung dieses Anforderungspapier sind einige Streitfragen offen geblieben, deren Entscheidung wir auf eine breitere Basis stellen wollen. Eine erste Runde der Rückmeldungen hat es bereits gegeben, diese sind in dieses Dokument mit eingeflossen.

TK: Thomas Krohn, Sachsen

AB: Alexander Bock, Bayern

JL: Jan Leutert, Hessen

SU: Stefan Urbat, Baden-Württemberg

TL: Thomas Laubel, Baden-Württemberg

MNE: Mark Neis, Sachsen

AL: Arne Ludwig, Niedersachsen

Vorbemerkung:

Es geht hier um eine Mitgliederverwaltung mit restriktiver Zugangskontrolle. Zu den Daten eines Mitglieds haben die Verbände Zugang, in denen das Mitglied gemeldet ist (bei Umzügen noch für eine Übergangszeit die alten Verbände).

Wenn hier von "veröffentlichen" die Rede ist, dann heisst das, dass auf den Ebenen BV, LV, BezV, KV und OV zusammen maximal ein Dutzend Personen Zugriff auf die Daten haben.

Eine Ausnahme hiervon gibt es - je nach Entscheidung der folgenden Streitfragen - bei Funktionsträgern, bei denen einige Daten mehr veröffentlich werden, jedoch auch nur an diejenigen, die Zugang zur Mitgliederverwaltung haben.

Fragestellung 1: Funktionalität versus Datenschutz

Datenschutz ist ein politisches Kernanliegen der Piratenpartei, von daher müssen wir selbst bei der Mitgliederverwaltung da vorbildlich sein. Das Maximum an Datenschutz wäre diesbezüglich allerdings dann erreicht, wenn die Partei aufgelöst und gar keine Daten mehr gespeichert werden - das wollen wir dann auch wieder nicht.

Konsens ist bislang, dass in der Mitgliederverwaltung die Daten gespeichert werden sollen, die zur Erfüllung der Aufgaben nach Parteiengesetz erforderlich sind. Diese Daten nennen wir "Minimaldaten", da umfasst zumindest Name, Adresse, Geburtsdatum, Status Beitragszahlung, zuständige Gliederungen.

Fragestellung 1a: Sollen überhaupt weitere Daten in der Mitgliederverwaltung gespeichert werden?

Zunächst wäre zu klären, ob den überhaupt weitere Daten in der Mitgliederverwaltung gespeichert werden sollen. Solche weiteren Daten könnten beispielsweise die Telefonnummer, die eMail-Adresse oder weitere Kontaktdaten sein. Das kann aber auch eine Information über Ordnungsmaßnahmen sein, beispielsweise die Aberkennung der Fähigkeit zur Bekleidung von Parteiämtern.

Es ist unstrittig, dass solche Daten überhaupt irgendwo gespeichert werden müssen. Die Speicherung innerhalb der Mitgliederverwaltung hat den Vorteil, dass die restriktiven Zugangsbeschränkungen derselben dort einen Schutz der Daten weitgehend sicherstellen - für die Speicherung an anderen Stellen müsste eine entsprechende Zugangsbeschränkung erst aufgebaut werden.

<TK>1a: Speicherung von Daten: Email, Telefon, "MB bis" sollten mit drin sein. Das passive Wahlrecht etc. ist echt ein heißes Eisen. Da es aber wichtig ist ja, mit rein.</TK>

<AB>1a: Ja, unbedingt Sachen wie z.b. E-Mail und Telefonnummer auch speichern. Hier geht es einfach um die Praktikabilität. Ich rede jetzt aus meiner Perspektive in Bayern: bei über 2500 Mitgliedern geht es nicht anders, die Leute zeitnah zu informieren, als per E-Mail. Sollte diese Adresse mal falsch geschrieben sein, kann man sie mit einem Telefonat schnell korrigieren. Diese beiden Daten sind keine kritischen, die irgendwelche tieferen Einblicke in die Persönlichkeit des Betreffende erlauben. Nur nötig für unsere Arbeit.</AB>

<JL>Ich bin der Meinung, das es Pflichtangaben in Form von Name, Anschrift geben sollte. Alle weiteren Daten sollten freiwillig sein und wenn sie Angegeben werden erfassbar sein. Hier sind Punkte wie zum Beispiel Geschlecht, Bankverbindung (auch für Einzugsermächtigung relevant) Telefonnummer, Faxnummer und Email Adresse zu nennen. Ordnungsmaßnahmen wären in meinen Augen wünschenswert, da dies für Akkreditierungen nützlich ist und weitere Listen erspart. Gleiches gilt für Amts- und Funktionsträger. Eine automatische Zuordnung von Landkreise, Regierungsbezirke und Wahlkreise sollten obligat sein. Es sollte auch der Fall berücksichtigt werden, in einer anderen als an dem Wohnsitz zuständigen Gliederung Mitglied zu sein.</JL>

<TL>Telefon, Email, Geschlecht, Ordnungsmaßnahmen die das aktive oder passive Wahlrecht betreffen, Geburtstag (wichtig bei Wahlen, da man sich erst ab 18 aufstellen lassen kann. Ich meine nicht die internen Ämter, sondern Landtagswahl, Bundestagswahl, ...) sollen rein, aber nicht als Pflichtfelder.

Auch sollten zwei Adressen eingegeben werden können: offizieller Wohnsitz (in BaWü brauchen wir das zB für die Aufstellungsversammlungen zur Landtagswahl) und Kontaktadresse (also wo man Pirat am besten erreicht). Eine zweite Adresse fällt bei mir unter "weitere Daten" daher erneut erwähnt

Bankverbindung und ein Flag "Lastschriftverfahren ja/nein" wäre für die Schatzmeister auch eine gute Idee.

Was Landkreise, Regierungsbezirke und Wahlkreise angeht, die Infos brauchen wir auch, das sehe ich nicht als optional an, sondern das muss automatisch ermittelt und immer befüllt sein.</TL>

<AL>Im wesentlichen Konsens. Ja, bestimmte Daten wie Telefonnnummer sollen gespeichert werden dürfen. Angabe ist ja auch freiwillig. Bestimmte andere Daten, wie Religion oder Geschlecht eher lieber nicht.

Da geht es wohl auch darum, ob die Daten ohne Wissen des Betroffenen erhoben werden, z.B. durch Ableitung des Geschlechts aus dem Vornamen oder durch externe Recherche.</AL>

Fazit

Speicherung von Daten über die sog. Minimaldaten hinaus scheint (mit unterschiedlichen Graden an "Bauchschmerzen" dabei) Konsens.

Fragestellung 1b: Sichtbarkeit von Zusatzinformationen OptIn, OptOut, Obligatorisch?

Konsens ist, dass für Nicht-Funktionsträger ein Opt-In-Verfahren gilt: Es werden die Daten nur dann sichtbar, wenn diese vom betreffenden Mitglied für die einsehende Gliederungsebene explizit freigegeben wurden.

<TL>Sichtbarkeit je Ebene festlegbar? Ich würde da ein "alle oder keine" bevorzugen, das hält den Aufwand klein, wenn eine neue Untergliederung hinzukommt und vereinfacht das Rechtekonzept.</TL>

Dissens besteht, wie das bei Funktionsträgern (Vorstandsmitglieder, Kassenprüfer, Schiedsrichter, Kandidaten für öffentliche Ämter) gehandhabt werden soll: Teilweise wird gefordert, dass auch hier das Opt-In-Verfahren gelten soll.

<TL>Ja und Nein. Ich würde sagen: Emailadresse eines jeden Funktionsträgers muss vorhanden sein. Weitere Kontaktdaten aber nur auf freiwilliger Basis. Ich habe meine Telefonnummer zB nicht veröffentlicht und werde das auch nie tun </TL>

Teilweise wird dort auch eine obligatorische Veröffentlichung für die betreffende und übergeordnete Gliederungsebenen gefordert. Die damit verbundene Einschränkung bei Datenschutz wird damit begründet, dass es Situationen gibt, die schnelles Handeln erfordern, da hat die handelnde Stelle nicht die Zeit und schon gar nicht die Nerven, sich die benötigten Informationen anderweitig zu beschaffen.

Beispiele für solche Situationen (aus der Praxis, nicht erfunden):

- Presse meldet sich in der BGS und möchte innerhalb der nächsten 4 Stunden ein Interview mit einem Landesvorsitzenden machen.

- Polizei ruft in der BGS wegen nicht ordnungsgemäß gehängter Wahlplakate an und droht mit einem Ordnungswidrigkeitsverfahren.

Anmerkung zur Problematik: Restriktiver Datenzugang führt üblicherweise dazu, dass sich die handelnden Personen ihre eigenen Datensammlungen anlegen und diese bisweilen auch "unter der Hand" weitergeben. Solche Datensammlungen verbleiben dann im Regelfall auch nach dem Ausscheiden aus der betreffenden Position in der Hand der ehemaligen Funktionsträgern - im Hinblick auf den Datenschutz sicher nicht die optimale Lösung.

<TK>1b: Zugriff weiterer Funktionsträger: Jain Grund: Die aktiven Mitglieder lassen sich über Mitgliederversammlungen, Email, Onlinemedien bereits sehr gut informieren. Alternativ könnte man für Funktionsträger öffentliche Daten vergeben. (sprich Mehrarbeit/Kosten) Diese würde mit ihrer Abwahl auch wieder aus dem Verzeichnis verschwinden und die Daten der restlichen Mitglieder wären alle geschützt. Das Sammeln von externen Datenbanken wäre fast vollständig unnötig. Erster Versuch war die Bundespressemappe. Sowas in sparsamer Form schweb mir auch vor. Weiterer Vorteil: Kommunikation zwischen den Verbänden wäre einfacher.</TK>

<AB>1b: Ich spreche mich dafür aus, dass Funktionsträger automatisch erreichbar gemacht werden. Wer sich in ein Amt wählen lässt, muss gewisse Dinge aufgeben, das gehört dazu.</AB>

<JL>Die Interne Veröffentlichung von Kontaktdaten von Vorstandsmitgliedern und Funktionsträgern, sollte möglich sein. Es muss aber dem Vorstandsmitglied/Funktionsträgern die Wahl gelassen werden, welche Kontaktmöglichkeiten er angibt. Der Zugriff auf diese Daten sollte auch restriktiert sein, und nur für Funktionsträger wie Pressesprecher oder BGS sowie für Amtsträger anderer Gliederungen zugänglich sein und nicht für jeden. Es sollte allerdings festgelegt werden, das min. eine Kontaktmöglichkeit veröffentlicht wird. Desweiteren müssen die Zugreifenden Personen angewiesen werden diese Kontaktdaten nicht nach aussen zu tragen.</JL>

<AL>Hier besteht kein Konsens bei uns. Manche meinen, alle sollten alles sehen, wenn jemand eine Zusatzinfo angibt. Ich sage, strenges Opt-In, aber nur mit der Möglichkeit allen eine Freigabe zu geben, allen nach oben, oder allen nach unten, oder nur der datenführenden Gliederung (z.Zt. LV) oder nur BGS. Jeder Gliederung einzeln macht eher keinen Sinn.

Obligatorisch halte ich für falsch. Eher kann man durch gutes Zureden mit schlagkräftigen Argumenten darauf hinwirken, dass Leute mit Amt oder Funktion es freiwillig machen.</AL>

Fazit

Wir haben diesbezüglich keinen Konsens und müssen die Software so flexibel halten, dass wir da auf unterschiedliche und sich ändernde Anforderungen reagieren können.

Fragestellung 2: Umfang der Offenheit

Aus Sicht der Funktionalität ist es wünschenswert, dass die Daten in jedem erdenkbaren Format exportiert werden können. Aufgaben, die von der Mitgliederverwaltung nicht selbst gelöst werden können, können dann von anderen Programmen bearbeitet werden.

Aus Sicht des Datenschutzes ist es wünschenswert, dass Daten überhaupt nicht exportiert werden können.

<AB>2: Ich muss auf einem Export bestehen. Auch im Jahre 2010 hat man noch nicht an jedem hintersten Eck, wo man Zugriff auf die Daten braucht (z.B. Kreisparteitag Hintertupfingen), auch einen Internetzugang. Die Export soll alles, was zu einem Mitglied gehört, exportieren können; nur so können in externen Programmen auch komplexe Fragestellungen und Aufgaben bewältigt werden. Mir ist klar, dass hier eine Gefahr des Missbrauchs steht, aber wir können nicht unseren Funktionsträgern misstrauen -- dann schaffen wir gar nichts.</AB>

<JL>Ein Missbrauch kann nicht Verhindert werden. Der Export sollte aber z.B. für Serienbriefe oder Anwesenheitslisten möglich sein.</JL>

<TL>Export in einem allgemein lesbaren Format ist ein Muss. CSV o.ä. schwebt mir da vor. Ich brauche sowas z.B. für Serienbriefe aus OpenOffice, bei Versammlungen mit Akkreditierung bei denen Nicht-Vorstände die Akkreditierung übernehmen, ...</TL>

<AL>Hier besteht kein Konsens. Manche meinen, technische Massnahmen könnten Geeks immer umgehen, andererseits ist die OCR-Scannung einer Bundesliste in einem ungewöhnlichen Font, die als physikalisches Exemplar vorübergehend einer Person z.B. auf einem Parteitag überlassen wird, leichter auf unbeabsichigtes "Wegkommen" zu überwachen als eine elektronische Liste auf einem USB-Stick.</AL>

Je restriktiver der Export gehandhabt wird, desto mehr muss die Mitgliederverwaltung selbst an Aufgaben abdecken. Dazu zwei Beispiele:

Beispiel 2a: Akkreditierung auf einer Mitgliederversammlung

Die Akkreditierung auf einer Mitgliederversammlung könnte mit Hilfe von Mitgliederlisten erfolgen. Spätestens bei Bundesparteitagen ermöglicht das den Komplettexport der gesamten Mitgliederdatei. Selbst wenn man einen Ausdruck erzwingen würde, könnte man über einen geeigneten Druckertreiber oder dann per OCR-Software die Informationen mit geringstem Aufwand wieder auf einen Datenträger bekommen.

Wenn die Erstellung solcher Listen unterbunden werden soll, dann muss die Software die Akkreditierung als Funktion abdecken (Beispielsweise: Mitgliedernummer eingetippt, Software spuckt aus, ob der Beitrag bezahlt ist und einschränkende Ordnungsmaßnahmen/Lebensalter vorliegen. Nach der Akkreditierung bekommt dann ggf. noch der Versammlungsleiter eine Liste der Teilnehmer mit einschränkenden Ordnungsmaßnahmen/Lebensalter)

<TK>Da ein Browserinterface genutzt werden soll ist ein Export dafür gar nicht mal nötig. Da sämtliche Software einen Rechner der Gensek/Schatzi vorrausetzt, sollte man dies auch mit einbeziehen. Ob man damit nun Internetzugriff zwingend voraussetzt oder eine temporäre Offlineversion zulässt.(Mehrkosten) Ich wäre hier für die Internetoption.</TK>

<MNE Ich halte eine Exportfunktion für zwingend, die mindestens die für eine Akkreditierung nötigen Daten bereitstellt. Internet ist nicht überall zu 100% der Zeit verfügbar. Käme es zu der Situation, dass eine Parteiversammlung, z. B. ein LPT, abgesagt werden muss, weil keine Akkreditierung vorgenommen werden kann, geben wir uns der Lächerlichkeit preis. Datenschutz ist wichtig, aber er darf nicht arbeitsverhindernd sein. Man könnte die Exportfunktion aber an weitere Restriktionen binden, z. B. an das 4-Augen-Prinzip (zweifache Bestätigung notwendig, um Fkt. zu aktivieren)</MNE>

<AL>Teilmengen der Daten sind weniger problematisch (hier nur Name, Vorname, ggf. Nummer und ggf. nur Teilgliederung). Akkreditierungsfunktion in der Software scheint mir aber eh sinnvoll.</AL>

Beispiel 2b: Einladung zu einer Mitgliederversammlung

Die Software muss den Einladungsprozess entweder satzungskonform abdecken, oder sie muss die Mitgliedsdaten für einen satzungsgemäßen Einladungsprozess zur Verfügung stellen - dann kommt man zumindest auf Bundesebene sehr einfach an eine Adressenliste aller Mitglieder.

Anmerkung zur Problematik: Gerade dann, wenn diese Funktion von der Mitgliederverwaltung abgedeckt werden soll, sollten die Satzungen harmonisiert werden.

<TK>2b. Wenn wir diesen Export ausschließen, muss die Software dies auch zwingend mitragen. Eine Emailanschreiben sollte es sowieso können. Schwieriger wird der Textausdruck. Wenn man hier Freitextfelder zulässt dürfte dies aber auch möglich sein jede Spezisatzung zuzulassen.</TK>

<AL>Vereinheitlichung des Einladungsprozederes z.B. auf email und öffentlicher Bekanntmachung scheint mir sinnvoll. Damit könnte man in der Regel aus der MV einladen und würde sich den Export der Adressenliste sparen.

Solange muss Komplettexport für die Gliederungen mit solchen Satzungen wo schriftlich eingeladen werden muss wohl obligatorisch zu erlauben.</AL>

Fazit

Mehrheitlich wird eine Exportfunktion als zwingend angesehen. Die Idee mit dem 4-Augen-Prinzip ist erst in der letzten Runde hinzugekommen und somit undiskutiert, scheint aber hilfreich.

Fragestellung 3: Umfang der Zugangskontrolle

Konsens ist, dass sich zumindest jeder User mit Username und Passwort beim System anmelden muss.

Strittig ist, ob es darüber hinausgehende Maßnahmen der Zugangskontrolle geben muss. Mit in der Diskusstion ist beispielsweise, ob für den Schreibzugriff Transaktionsnummern zu verwenden sind (auch: Eine TAN für eine komplette Login-Session).

<TK>3. Keine weiteren Zwangsmaßnahmen, das CIviCRM zeigt wie es nicht gehen sollte. Lieber die Beschränkungen für das Passwort hochsetzen. Mit TAN-Listen könnte ich mich anfreunden. das würde Mißbrauch vorbeugen, setzt aber wiederum ein Person voraus die sich darum kümmert.</TK>

<AB>3: Ist mir gleich. Da seid ihr die Experten. Ich würde aber vorsichtig nachfragen, ob man umfangreiche Logs dessen anfertigen kann, was jeder Benutzer im System treibt? So könnte man im Super-GAU-Fall eines gestohlenen Datenexports womöglich herausfinden, wer das zu verantworten hat. Jedenfalls wenn man den Export in die Finger kriegt.</AB>

<JL>Die Führung von TAN-Listen halte ich Persönlich für übertrieben und zu Aufwendig. Das bisherige System mit VPN und usr/pwd Authentifikation finde ich prinzipiell sehr gut. Ergänzt werden könnte es durch eine weitere Stufe mittels HTTP-Auth des Webserver vor der eigentlichen Applikation. Worüber man sich allerdings Gedanken machen sollte, ist wie die Zugänge einrichtet. Dies sollte optimiert werden, das neue Vorstandsmitglieder möglichst schnell und einfach Zugriff erhalten um Ihre Arbeit aufzunehmen.</JL>

<TL>TAN halte ich für zu viel des Guten. Die aktuelle Lösung "VPN plus user/passwort" ist ausreichend</TL>

<MNE>Weitere Zwangsmaßnahmen halte ich nicht für besonders effektiv, lieber eine ordentliche Passwort-Policy, die eine bestimmte Komplexität und einen turnusmäßigen Passwortwechsel erzwingt und ferner ein ordentliches Logging.</MNE>

<AL>Der Zugang mit Username und Passwort allein reicht nicht. Es muss mindestens noch ein schwieriger stehlbares Geheimnis, z.B. ein Zertifikat für einen VPN-Zugang o.ä. verwendet werden.

Session mit TAN muss man aus meiner Sicht nicht haben. Wenn es aber kein VPN o.ä. gibt, dann kann eine Session mit TAN wenigstens eine Verbesserung der Sicherheit sein, dann aber für Lese- UND Schreibzugriffe.

Evtl. die Passwörter vom System fest vorgeben lassen, um zu einfache Passwörter zu verhindern, insbesondere wenn wir zunehmend non-Geeks als GenSek haben werden.</AL>

Fazit

Reine Usernamen/Passwort-Zugänge scheinen mehrheitlich als nicht ausreichend angesehen zu werden. Bezüglich der genauen Ausgestaltung herrscht Uneinigkeit, wobei es keine Anzeigen dafür gibt, dass nicht auch andere Lösungen mitgetragen werden könnten, solange diese zumindest gründlich durchdacht sind.

Fragestellung 4: Schreibrechte

Konsens ist, Schreibrechte auf zuständige Gliederungen (also Verbände, in denen der betreffende Pirat Mitglied ist) zu beschränken.

Strittig ist, ob es stets eine festgelegte Zuständigkeit gibt, oder ob jeweils der Verband die Daten schreibt, der den Vorgang gerade auf dem Tisch hat.

<AB>4: Eine Möglichkeit einen Datensatz zeitweise zu blockieren wäre sicher hilfreich. Es sollte aber möglich sein, dass eine andere Gliederung die Blockade aufhebt und die Daten bearbeitet. Wenn eine Gliederung, aus welchem Grund auch immer, nicht ihren Aufgaben nachkommt, sollte eine andere jedenfalls alsbald einspringen können.</AB>

<AL>Vom Prozess her würde ich Subsidiarität vorschlagen, d.h. jede Gliederung gibt es solange nach unten, bis jemand zuständig ist. Das Wissen, wer zuständig ist, muss ja nicht oben bekannt sein, also ob z.B. ein kleiner Kreisverband die Zuständigkeit an den Bezirksverband abgegeben hat.

Wenn eine unzuständige Gliederung etwas bekommt, gibt sie es solange nach oben wie nötig bzw. gleich an den zuständigen LV und ggf. von da wieder nach unten.

Nach Möglichkeit sollte nur die zuständige Gliederung Änderungen vornehmen. Ob das technisch forciert werden soll, besteht kein Konsens. Ich meine ja, aber die BGS kann im Ausnahmefall tätig werden, wenn die zuständige Gliederung untätig ist. Das wird ja protokolliert. Das Protokoll kann die zuständige Gliederung einsehen.</AL>

Beispiel 4a: Umzug eines Mitglieds

Es sind Vorstellungen entwickelt worden, dass bei einem Umzug innerhalb desselben Landesverbandes der Landesverband den Umzug eingibt, bei einem Umzug in einen anderen Landesverband der Bundesverband. Meldet nun das Mitglieder an den falschen Verband, dann würde dieser den Vorgang weiterleiten. Das heisst, bei einer Unzugsmeldung an die BGS wird geprüft, ob sich dadurch der Landes-, Bezirks-, Kreis- oder Ortsverband ändert, dadurch der zuständige Verband und dessen Kontaktdaten ermittelt und dann der Vorgang dorthin abgegeben.

Denkbar wäre jedoch auch, dass in diesem Beispiel die BGS die Umzugsmeldung gleich selbst eingibt. (Vielleicht mit Benachrichtigung an alle betroffenen Verbände - dies wäre im Hinblick auf die Datensparsamkeit zu diskutieren, ebenso, ob bei einer "Verlustmeldung" angegeben werden soll, aus welchem Grund die Mitgliedschaft im betreffenden Verband endet (Wegzug, Austritt, Streichung, Ausschluss, Tod).)

<TK>4. Allgemein tritt hier das Problem der freiwählbaren Gliederung auf, mit Wohnort völlig wo anders. Bitte das mit berücksichtigen. Das Problem der Fremdaufnahme sollte durch einen Umzugspool mit gesichert werden. Einer zentralen Verwaltung des Umzugspools über die BGS würde ich zustimmen.</TK>

<JL>Hier sollten sich der abgebende und der aufnehmende Gebietsverband einigen. Der abgebende Gebietsverband ändert daraufhin die Daten zu dem neuen Gebietsverband. und hat mit dem letzmaligen speichern kein Schreibzugriff mehr auf die Daten. Der neue Gebietsverband hat ihn nun in seinem Stamm mit Schreibrechten. Es sollte aber geprüft werden, in wie weit die Mitgliedsdaten auch von nicht mehr der Gebietskörperschaft angehörigen Piraten z.B. für Rechenschaftsberichte benötigt wird. Sollte dies der Fall sein, muss es eine möglichkeit geben auch noch nachträglich auf den Datensatz in der abgegebenen Form Einsicht zu erhalten.

<TL>Das unterschreibe ich einfach mal so </TL> </JL>

<AL>Bei Umzug von A nach B könnte man das Mitglied vorübergehend in zwei Gliederungen führen, so dass die abholende Gliederung die Ursprungsgliederung entfernt? (Umzugspool etwas entschärft) Mir ist unklar, wie das mit der Benachrichtigung praktisch gehen sollte.

Inhaltliche Austrittsgründe sollten in der Regel nicht erfasst werden. Organisatorische Gründe (Wegzug, Austrtt, Tod) kein Konsens. Ich meine OK, andere nicht erfassen.</AL>

Fazit

Keine einheitliche Linie, es gibt aber keine Anzeichen dafür, dass wohldurchdachte Lösungen nicht mitgetragen würden.

ANMERKUNGEN 1. Rücklauf

<TK>Eine Bitte an euch als AG: Sollte wie es gerade bei mir geschieht jeder Speziwünsche äußern, die unvereinbar sind, die strittigen Punkte nicht unbedingt ausdiskutieren, sondern abstimmen oder innerhalb der Arbeitsgruppe entscheiden. Und als Hint: Wenn nur 1 bis n Optionen zur Verfügung stehen, diese auch wählen lassen, das macht die Auswertung einfacher. Sprich gleich als Umfrage.</TK>

<JL>Die Mitgliederverwaltung sollte ein Changelog für jeden User geben. Dieses sollte jede Änderung an dem Datensatz in Form von: Bearbeiter, Datum; Uhrzeit, Feld, alter Wert, neuer Wert enthalten.

<TL>Dafür!</TL>

Einen Self-Service im ersten Step lehne ich ab, da dieses in meinen Augen die gesamte Sicherheit des Servers gefährdet.

<TL>Self-Service lehne ich generell ab.</TL> <JL>

<SU>mir erscheint v.a. wichtig, dass man auch exportieren und offline arbeiten kann, sonst sind u.U. bei Mitgliederversammlungen welcher Art auch immer keine Akkreditierungen mehr möglich: man kann nicht einfach voraussetzen, dass stets online-Zugriff auf die Mitgliederverwaltung möglich ist.</SU>