AG Liquid Feedback

Aus Piratenwiki
Wechseln zu: Navigation, Suche
Symbol neutral vote.svg
Diese AG ist ruhend. Wende dich bei Interesse an den Koordinator.
Mehr zum AG-Status

Mission Statement

Von einer kleinen Schaluppe ist die Piratenpartei zu einem stolzen Viermaster angewachsen. Damit ist aber die Richtung, in die wir segeln, nicht mehr so leicht zu ändern, denn bei uns steuert die ganze Crew gemeinsam. Die erfolgten Abstimmungen sprechen eine eindeutige Sprache: Wir fahren auch in Zukunft weiter in Richtung des Leuchtturms, der Liquid Feedback heißt. Unserer Ansicht nach ist dieser Leuchtturm jedoch auf einer zu schwachen Basis erbaut. Diese AG will sich daher aufmachen, diesen Leuchtturm auf einem stabilen und zukunftsfähigen Fundament zu erneuern.

Wer wir sind

Wir sind ein Team von Software Entwicklern und wollen die Verwendung von Liquid Feedback (lqfb) in der Piratenpartei unterstützen. Aufgrund der großen Verbreitung von lqfb in der Piratenpartei halten wir es nicht für sinnvoll, zu versuchen, ein anderes Tool zu etablieren. Wer in der Piratenpartei direkte, internetgestütze demokratische Strukturen etablieren will, kommt an Liquid Feedback kaum vorbei. Wir sehen aber auch, dass die in Berlin entwickelten Versionen 1.0 und 2.0 so große strukturelle Schwächen im Softwareaufbau und im Developer Support aufweisen, dass die Weiterentwicklung vor großen Hürden steht.

Was wir wollen

Ziel dieser AG ist es, auf Basis der Tabellenstrukturen von lqfb 2.0 die Software mit besser geeigneter Technologie nachzuentwickeln, um so die Basis für zukünftige Erweiterungen zu legen. Wir wollen dabei innerhalb der Piratenpartei eine Entwicklercommunity aufbauen, so dass auch die zukünftige Wartung und Weiterentwicklung gewährleistet sind. Die gesamte Entwicklung soll ohne Bezahlung der Entwickler als Open Source Projekt geschehen. Sie muss daher sowohl technologisch als auch methodisch so interessant sein, dass sich genügend ehrenamtliche Helfer finden.

Indem wir die Tabellenstukturen von lqfb 2.0 verwenden, ermöglichen wir ein probemloses Upgrade auf unsere Neuentwicklung und den Erhalt aller Inis/Benutzer/Delegationen/usw. vom "alten" lqfb.

Was wir nicht wollen

Ziel dieser AG ist es nicht, den Sinn von lqfb oder Liquid Democracy zu diskutieren, dies geschieht parallel in der AG Liquid Democracy. Wir wollen lediglich eine Basis für die Weiterentwicklung von lqfb schaffen und später darauf aufbauend von der Parteibasis gewünschte lqfb Erweiterungen hinzu entwickeln.

Kommunikation

Unsere Mailingliste findet Ihr unter: http://lists.pp-international.net/listinfo/lqfb
Sie ist mit dem Syncom Forum synchronisiert: https://news.piratenpartei.de/forumdisplay.php?fid=637

Liste der Schwächen von lqfb 1.0 und 2.0

Diese Liste führen wir, um zu begründen, warum es diese AG geben muss und wieso wir uns nicht einfach in die bestehende lqfb Entwicklung einklinken.

  • Der "core" besteht aus einer einzigen 4500 Zeilen langen pgsql Datei.
  • Das "Frontend" verwendet ein nur für diesen Zweck entwickeltes Webframework auf Basis der Skriptsprache "LUA", die gar nicht für die Webentwicklung gedacht ist.
  • Lua bietet keine brauchbare Unterstützung für i18n (Internationalization) wie mit GNU Gettext.
  • Der "core" wird ausschließlich vom lqfb Entwickler "jbe" gepflegt.
  • Das "Frontend" wird fast ausschließlich vom lqfb Entwickler "bsw" gepflegt (sehr seltene Unterstützung von "jbe", vor einem halben Jahr hat "Ingo Bormuth" 20 Zeilen beigesteuert).
  • Entwickler zu finden, die bereit sind, sich in diesem Umfeld ehrenamtlich einzubringen, ist fast unmöglich.

Koordinatoren

Interessenten

Hier kannst Du Dich eintragen, wenn Du Dich an den Abstimmungen zu Punkt 2 des Fahrplans beteiligen möchtest und Dir je nach Ausgang von Punkt 3 vorstellen kannst, Dich an der Entwicklung zu beteiligen. Ein Softwareentwicklungsteam braucht auch Qualitätssicherer und Tester, Du bist daher auch herzlich willkommen, wenn Du nicht programmieren willst, sondern auf unserer zukünftigen Testinstanz herumklicken und uns Tickets einstellen willst.

Zielarchitekturen

Hier sammeln wir Vorschläge für die neue Zielarchitektur, über die wir bis 1.11. abstimmen.

  • Java Enterprise 6 mit JBoss 7 und Postgres Datenbank. Continuous Integration mit Jenkins, Hosting des Codes bei Google und Apache Lizenz.
  • Hypertext Preprocessor PHP/MySQL. Code bei github hosten und CC Lizenz
  • Python, Ruby oder node.js. Dazu passend ein ORM um endlich unabhängig von einer spezifischen Datenbank zu sein. Code bei github oder bitbucket. Lizenz AGPL3, GPL3 oder was mit BSD im Namen.
  • NoSQL Datenbank wie MongoDB (oder ähnliches), Java-Basiertes Frontend mit gängigen Web-Framework (z.B Struts 2), Code-Hosting bei github
  • Liferay Portal (Java) auf Tomcat, Spring, Vaadin-Framework (on top of GWT) Maven, JPA (Vorschlag von @00v3rdr1v3)
  • Play Framework 1.2 (Java), Code bei bitbucket oder github
  • 3-Schichten-Modell, Datenbank steht offenbar fest. Backend Java basierend auf Applicationserver mit Spring, Frontend offener gestalten. Mobile Apps? Apache Wicket, Grails/Groovy, TDD
  • Python, node.js api-server mit ORM. Html + javascript frontend or python, node.js frontend consuming api. Github hosting. Lizenz GPL oder ähnliches.
  • Ruby on Rails für das Frontend (weil es cool ist und viele Entwickler anziehen würde)
  • .net Framework für die core-Logik (schnittstelle via Sockets), ASP.net Framework und IIS fürs frontend (core und Frontend komplett getrennt), datenbank ODBC/ADO.net/ etc. mit Wrapperklassen
  • C++ für Kryptografiefunktionen
  • PHP mit geeigneten Framework (z.B. CodeIgniter). HTML wird auf Basis des Frameworks YAML4 erzeugt. Datenbank auf Basis von MySQL. (Begründung: 1. Große Community bei PHP, 2. Standardsetup von den meisten Providern erlaubt meist nur PHP und (My)SQL. das System sollte auch von Admins einsetzbar sein, die nicht in der Lage sind, Tomcat und zusätzliche Libs zu installieren )
  • Go: viele Sprachfeatures, performt gut
  • Python, Django, Flask, SQLAlchemy, PostGreSQL, BitBucket/Github, Trac, Jenkins, Nagios/Icinga, Python-Ecosystem, jQuery, node.js, Apache/nginx, GPL/BSD, plus mobil: Android, iOS
  • Keinem Server vertrauen müssen: dezentral und unabhängig auf Basis von GNUnet

Ideen

  • Die Abstimmung innerhalb der neuen Community sollte nach festen Regeln geschehen. Hierzu würden sich die bewährten Regeln der Apache Software Foundation anbieten.
  • Wenn eine größere Entwicklercommunity etabliert ist, wäre es evtl. wünschenswert, die Entwicklung beispielsweise innerhalb der Apache Community fortzuführen. Dies würde eine Mitwirkung auch für internationale Entwickler interessanter machen.
  • Vorschlag: Zur Prüfung, ob jemand abstimmberechtigt ist, bitte den ID-Server verwenden.
  • Vorschlag: auf Englisch Dokumentieren, damit wir das auch Europaweit ausrollen können - da haben wir in D eine Vorreiterrolle
  • Bitcoin ähnliche Netzwerkstruktur. Alle Rechner im Verbund prüfen alle Ergebnisse nach.

ToDos

Manche davon sollten VOR der Technologiewahl zumindest andiskutiert werden...

  • Ziele priorisieren (Stabilität, Performance, Funktionalität, Wartbarkeit, Pflegbarkeit, Erweiterbarkeit....)
  • Mengengerüst (vie viele concurrent User, wieviele parallele Aktionen)
  • Aufstellung Use Cases (gibt's da bereits was?) bzw. User Stories
  • Grobarchitektur (erstmal Technologie-neutral...) malen
  • Nichtfunktionale Anforderungen (Sicherheit, Performance, betriebliches Reporting ...)
  • Übergreifende funktionale Anforderungen (Mandantenfähigkeit?!!, Skinning, Einbindbarkeit (meshing) in andere Anwendungen (z.B. Wiki, Pad), fachliches Reporting, Einbindungsoffenheit von z.B. Wiki/Pad...)
  • K-Fall Konzept (Katastrophenfall, was ist zu tun, um das System datenverlustfrei möglichst zeitnah wieder ans Laufen zu bekommen) (Replikation?)
  • Hochverfügbarkeit? 99, 99.9, 99.99 oder was?

Material

Media:Lqfb-er.pdf

AG_Liquid_Feedback/Use_Cases

Erstes Projekt-Gerüst in Maven/JPA/Java/Spring

Abgerufen von „https://wiki.piratenpartei.de/wiki/index.php?title=AG_Liquid_Feedback&oldid=2633205“