Re: [AG Liquid Democracy] CiviCRM und Prozesse / Was: An einem System als "berechtigt" gelten, obwohl ...

[Michael Vogel <icarus AT dabo.de>]

Moin!

Am 01.07.10 19:55, schrieb bvdb_pp AT kanka.de:
> Ahoi,
> 
> On 01.07.2010 11:27, Michael Vogel wrote:
>>> Kannst du noch einmal kurz erklären, welche Daten ein solcher Server dMn
>>> vorhält und welche Prozesse er wie unterstützt (oder auf eine Wiki-Seite
>>> schreiben)?
>>
>> - Eindeutige ID
>> - Pirat (d.h. bestehende Mitgliedschaft)
>> - Abstimmberechtigt (D.h. Mitgliedsbeitrag gezahlt)
>> - Zugehörigkeit (LV, KV, BV, AG?, Crew?)
> 
> Hmm, die jetzige Mitgliederverwaltung hat ja eine ID:
> http://wiki.piratenpartei.de/CiviCRM

Ich hab jetzt nicht nachgeschaut - ist die ID die Mitgliedsnummer? Die
würde ich nicht rausgeben wollen.

> Die Prozesse, wie diese jetzt benutzt wird, wären erst einmal zu
> recherchieren, und dann auch, wie der Prozess aussieht, wenn daraus
> Invitecodes für LF o.ä. generiert werden. Ein Anfang:
> http://wiki.piratenpartei.de/CiviCRM/UseCases
> 
> Klar ist IMO, dass ein ID-Server vom Datenschutz her jedenfalls nicht
> hinter den jetzigen Stand zurückfallen darf.

Das ist logisch.

>> ... Das Forum sollte nur die Info haben, ob die Person
>> Pirat ist oder nicht (für die angezeigte Mitgliedschaft). Das Wiki
>> benötigt evtl. nicht mal dies.
> 
> Verstehe ich recht, dass der Login in diese Systeme dann dMn auch den
> ID-Server berücksichtigt?

Was meinst Du damit genau? Ich würde den ID-Server gerne als
Single-Sign-On sehen - aber es muss auch ohne diesen Server eine
Anmeldung geben.

>> Die Zugehörigkeit kann allerdings auch dafür sorgen, den Piraten relativ
>> gut zuzuordnen, insbesondere, wenn man es auf Crew und AG-Ebene machen
>> würde. Wahrscheinlich wird aber auf einer so niedrigen Ebene sowieso
>> keine Abstimmung online erfolgen müssen, deswegen wird man darauf
>> verzichten können.
> 
> Zum Beispiel.
> Also, die einzelnen Prozesse müssen präzise definiert sein,

Klar - also am Besten nicht durch mich, sowas kann ich nicht :)

>> Genial wäre es natürlich, wenn man als User selber festlegen könnte,
>> welche Daten die Applikation sehen soll. Dazu müsste die Applikation
>> übermitteln, welche Daten sie mindestens benötigt und welche sie
>> optional gerne hätte.
> 
> Die Maxime ist jedenfalls Datenvermeidung, wenn die einen mehr liefern
> als die andern entsteht ggf (wieder) so ein sozialer Druck "Was hast du
> denn zu verbergen", allein das spricht für Minimal-Daten.

Soialer Druck wäre ja nur, wenn von außen erkennbar wäre, wer welche
Daten freigegeben hat. Wenn aber jemand für LF z.B. nur freigibt, ob er
wahlberechtigt ist (was er muss), aber nicht, aus welchem LV er kommt,
kann er eben nicht an Länderabstimmungen teilnehmen - das sieht aber
keiner von außen.

>> Ich sehe den ID-Service sehr hoch in der Priorität aufgehängt, da es nur
>> so möglich sein wird, auch LF-Alternativen zu berücksichtigen.
> 
> Noe, der Prozess für die Vergabe von Invitecodes ist ja nun auch (DSB,
> Bodos "Klage") in Verhandlung, und diesen Lernprozess können dann auch
> weitere Systeme nutzen, die eben ggf. nochmal (andere) Invitecodes
> generieren.

Wenn wir dann noch mehr Invitecodes machen, verhaspeln wir uns bald.

> Es ist IMO nicht unbedingt klar, dass dies zentralisiert
> besser ist.

Die Mitgliederdatenbank liegt zentral. Die einzelnen LVs pflegen diese
zentral, also ist es sinnvoll, wenn wir die Daten des ID-Servers damit
synchronisieren. Wenn einzelne LVs, KVs oder der Bund immer wieder Daten
exportieren und versenden müssen, ist das aus meiner Sicht nicht
wirklich sinnvoll. Mal davon abgesehen, dass es für den Start neuer
Dienste einfacher ist, wenn nicht immer wieder solche Aktionen
durchgeführt werden müssen.

Ich stelle es mir auf alle Fälle chaotisch vor, wenn z.B. bei einem
Austritt dann erstmal 3-4 Systeme benachrichtigt werden müssen, damit
die Daten dort entfernt werden können. Das empfinde ich als extrem
suboptimal. Ein (automatisch) synchronisierter ID-Server würde die
Arbeit extrem erleichtern.

Michael