Ideen Roadmap Adhocracy 3.0 ff
Architektur
- evtl. Datenbank auf NoSQL-Basis (z.B. MongoDB oder ZODB (objectdatenbank))
- Framework-Upgrade (Pylons -> Pyramid)
- Softwaredesign (schrittweises Umstellen auf components ? -> flexiblere Kundenanpassungen möglich)
- Diskussionen auch frei von Vorschlägen
- Diskussionen in Statements strukturieren
- Vorschläge basieren (optional) auf Statements
- Relationen zwischen Entitäten
- Einander Zuordnen von Statements, Vorschlägen etc.
- Mergen von Entitäten (z.B. Duplikate)
- Workflows auf Basis von Grundelementen zusammenstöpseln
- Abbildung des Policy Cycles
- Migrationspfad von A1.2 aus
- volle Versionierung aller Elemente
Datenmodell
Motivation:
- Unterschiedliche Projektpartner haben unterschiedliche Anforderungen an Adhocracy, die momentan durch Anpassungen des Codes umgesetzt werden. Diese Anpassungen sind zum Teil recht unelegant.
- Zusätzlich dazu entstehen (im Verein) neue inhaltliche Ideen, wie partizipative Entscheidungsprozesse durchgeführt werden könnten. Diese Ideen werden naturgemäß von Adhocracy momentan nicht abgedeckt.
Beide Punkte lassen es sinnvoll erscheinen, dass Adhocracy idealerweise ein flexibles Framework ist, mit dem sich unterschiedliche inhaltliche Konzepte und Workflows schnell umsetzen lassen.
(Diese Umsetzungen -- also das Implementieren von Workflows -- muss zumindest am Anfang durch im Framework erfahrene ProgrammiererInnen erfolgen.)
Content (auch Relationen), User, Workflow
Es soll einen Datenbestand geben, in dem Inhalte und darauf definierte Aussagen abgelegt werden können. Dieser Datenbestand hat eine Graphstruktur. Dieser Datenbestand ist als eigenständige Wissens- oder Informationssammlung gedacht, die also auch unabhängig von der Userdatenbank gedacht werden kann.
Zudem sind die Objekte in einer flexiblen Hierarchie angeordnet, über die Permissions vererbt und ObjectTraversal ermöglicht wird. Die Permissions verstehen wir als mit einem Objekt jeweils mögliche Aktionen.
Die Objekthierarchie soll im Allgemeinen nicht verwendet werden, um inhaltliche Beziehungen auszudrücken. (So sollte ein Kommentar zu einem Statement in einer expliziten "kommentiert"-Beziehung stehen.)
Ein Workflow definiert die verwendeten Objektypen, deren initialen Zustand, deren weitere Zustände, deren Zustandsübergänge sowie die für den Zustand verfügbaren Permissions. Über die Hierachie kann er lokal überschrieben werden (Räume).
Vorteile der Objekthierarchie:
- lokale, vererbte Permissions
- Workflows in einem Teilbaum der Hierarchie definierbar
- Objekt Traversal (Addressierbarkeit über den Baumpfad, z.B. in einer URL)
Beispiel einer Hierarchie:
/
- instances (statementscontainer)
- statements
- Kommentare(geschachtelt), Dokumente, iframes...
- userscontainer (statementscontainer)
- users
- statements, ...
(
Eine offene Frage: Sollen im Datenbestand die Aussagen (z.B. "A widerspricht B") als eigenständige Objekte oder nur als (eventuell annotierte) Relationen abgelegt werden.
- Eigenständige Objekte (Ressourcen): Aussagen können ihrerseits in Aussagen einfach eingebunden werden (z.B. "Alice verifiziert die Aussage 'A widerspricht B'"). Nachteile: immer eine Indirektion mehr, und Aussagen sind nicht mehr Kanten sondern werden Knoten -- der Graph wird komplexer.
- (annotierte) Relationen: naheliegendere Umsetzung; Inhalte sind Knoten, Aussagen sind Kanten. Nachteile: Komplexere Zusammenhänge müssen über Annotationen ausgedrückt werden; zukünftige Ausdrucksmöglichkeiten werden eventuell eingeschränkt; bestimmte Abfragen werden komplizierter (z.B. "Welche Relationen hat Alice verifiziert?").
)
Klassen
Statements (Proposals, Papers, Fragen, Kommentare, Normen, ...)
Aussagen über Statements (RDF triple: one-way, two-way, eventuell multiway)
Statement-Container (Instance, Userordner, Gruppenordner..)
globaler Workflow und Konfiguration
User
Implementierung Graphstruktur
- zodb zc.relations catalog ( 1 zu 1 und 1 (N) zu N (1) Relations)
- custom sqllösung
- sqlalchemy rdfstorage
API
- Bessere Möglichkeiten Adhocracy über API's in andere Seiten einzubinden (z.B. über HTML-Schnipfel in Blogs, Apps in Facebook etc.)
- Mobile Android- / iPhone-App
Misc
- Dezentrale / Globale Normendatenbank (Installation Stadtverwaltung München verwaltet ihre Stadtplanungsdokumente, Änderungen werden auf der Instanz)
- Aber auch lokaler / dezentraler Bezug auf Objekte (ich pflege meine Meinungsdatenbank lokal)
- "Hot" / gemischt Algorithmus überarbeiten, z.B. Aufrufe miteinbeziehen
- Welche Diskussionen sind gerade am aktivsten?
- Lesezugriffe aus Piwik-API / Webserver-Logs
- "Scheduled participation" - verabreden zum an etwas Arbeiten
- Verbindung mit Offline-Treffen / Terminen
- Plugin-Struktur für Normenbasis
- verschiedene Objektarten (Bilder, Karten, Bürgerhaushalt ...)
- verschiedene Text-Dokumenttypen (PDFs, Doc, ...)
- (sind auch alles nur statements)
- Verwalten meiner Positionen
- bezieht auch Daten anderer Adhocracies ein, die in Bezug stehen
- (optional) Lese-Transparenz nur für Mitglieder der Organisation
- Flüssige Authentifizierungsstufen
- 0: Nicht authentifiziert (z.B. Statements von Nicht-Nutzern einpflegen)
- 1: E-Mail / OpenID / OAuth (Google / Facebook) / SMS / Postident - verifiziert
- 2: Trust-Network (wie auch immer implementiert)
- 3: Authentifiziert durch Organisation
- Auswertung von Abstimmungen etc. abhängig von Authentfizierungsstufe
- Mitglieder authentifizieren
- Authentifizierungsstufe 3 verifizieren
- Mitglieder mit Organisations-Badges versehen
- Spenden entgegennehmen (10% an Liqd e.V.)
- Idee: Mehrere Profile/Identitäten pro User erlauben. Auf jeder Instanz kann ein anderes Profil gewählt werden (z.B. Klarname / Pseudonym)
- Soziale Graphen von sozialen Netzwerken einbinden - IJAB
- Recommender System (dich könnte auch interessieren ...)
- Integration in SocialSwarm (verteilter, auch nicht-öffentlicher Content)
- Zurückspulen zu früheren Zuständen (mit Kommentarliste), vgl. Etherpad
= Alte Diskussion von ca. 2010 =
== Probleme ==
* Wenig soziale Dynamik
* Schnell unübersichtlich
* Diskussionen
* Viele Papiere an einem Vorschlag
* Navigation
= Dinge, die wir über Adhocracy 2 wissen =
=== Basics ===
* Es wird weniger können, das besser -> Features auswählen, manches weg lassen?
* Kill-Liste:
* Vorschlagsalternativen (kann man automatisch machen)
* Das Wiki (können andere einfach besser, sogar MD hat noch eins)
*
* Bündnisse + Organisationen verheiraten zu einem Träger von Mitgliedschaft
* Rechtevergabe per Organisation
* Gebietsmarkierungen geben Verhältnisse zwischen Gruppen wieder, i.e.:
* Die Grünen sind in Deutschland, dt. Normen treffen auf die Grünen zu
* Die Kulturflatrate ist in den Grünen und in Attac, kann daher auf beider
Organisationen Normen Bezug nehmen. Und auf die von Deutschland (s.o.)
* Delegation erfolgt innerhalb von Gruppen, die das erlauben
* Delegation erfolgt an Gruppen, die das erlauben
*Collaboration mit Metapartei u.ä.
=== Antragsentwicklung ===
* Globale Normen (was auch immer das heißt)
* Vorschläge beziehen sich auf "Beschlüsse". "Beschlüsse" sind beschlossene Vorschläge.
* Echtes DVCs? Eher nicht.
=== Delegation und Abstimmung ===
* irgendwo kommt ein doodle-Tool vor
=== Technik ===
* wir müssen mal Tests schreiben
