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

[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

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 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?

> 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, und IMO muss da 
auch ein Dokumentations- und Revisions-Prozess für deren Hinterfragung selbst 
dazu.

> 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.

> 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. Es ist 
IMO nicht unbedingt klar, dass dies zentralisiert besser ist.
Richtig ist aber auf jeden Fall, die _organisatorischen Prozesse_ einheitlich 
zu beschreiben, verhandeln usw.

Gruß / Bernd

--
- Pirat b -