Tobias Hößl

Die nächste größere Version von Antragsgrün biegt gerade auf die Zielgerade ein: alle Neuerungen sind eingebaut und nach internen Tests reif, auf breiter Basis genutzt zu werden. Auf antragsgruen.de wird sie bereits produktiv eingesetzt, das herunterladbare Paket zum Selbst-Hosten folgt in Kürze. Es gibt wieder an verschiedensten Stellen Verbesserungen:

Neu ist eine gesonderte Unterstützung für Satzungsänderungsanträge, die von Mitgliedern einerseits wie reguläre Anträge eingereicht werden können, auf der Startseite als eigenständige Anträge auftauchen und auch Kürzel wie z.B. „S1“ bekommen, in ihrer Text-Darstellung aber andererseits die Änderungsdarstellung von Änderungsanträgen nutzen. Um diese Funktion zu nutzen, legt man als Administrator*in zuerst einen neuen Antragstypen vom gleichnamigen Typen an und hinterlegt anschließend die Satzung als ganzes Dokument oder als einzelne Kapitel. Ab dann können Mitglieder Satzungsänderungsanträge einstellen, die sich auf die eingegebenen Texte beziehen.
Übrigens ist im Zusammenhang mit Satzungen auch erwähnenswert, dass schon in Version 4.6 deutlich flexiblere Listen eingeführt wurden, insbesondere hinsichtlich den Bedürfnissen von Satzungen.

Das Einpflegen von Änderungsanträgen bzw. die Beschlusserstellung wurde in einigen Punkten verbessert. Gibt es kollidierende Änderungsanträge (also zwei oder mehr Änderungsanträge, die sich auf das selbe Wort beziehen), werden nun auch ein Großteil der kollidierenden Änderungen direkt im Text angezeigt, um das Bearbeiten zu vereinfachen. Erst wenn größere Abschnitte eingefügt oder gelöscht werden und es dabei Kollisionen gibt, werden diese herausgelöst unterhalb des Absatzes wiederholt wie bisher.

Wird die Beschlusserstellung live auf einer Veranstaltung eingesetzt und im Text auch Kompromissvorschläge erarbeitet, lässt sich nun einstellen, dass von Admins eingegebener Text farbig erscheint.

Ist einmal unklar, wann und von wem eine Änderung an einem Antrag oder Änderungsantrag vorgenommen wurde, können Admins nun ein Aktivitäts-Protokoll speziell bezogen auf einzelne Anträge anzeigen lassen. Dazu geht man auf die Bearbeiten-Seite des (Änderungs-)Antrags und anschließend auf „Aktivität-Protokoll“ in der Seitenleiste rechts.

Auf ebendieser Seite ist es Admins nun auch möglich, (Änderungs-)Anträge nachträglich einzelnen Nutzer*innen zuzuordnen, sodass diese fortan Kontrolle darüber haben, als hätten sie ihn selbst eingereicht.

Um die Einreichung eines Antrags oder einer Bewerbung noch weiter zu erleichtern, ist es nun auch möglich, auf die Angabe der Antragsteller*in komplett zu verzichten. Dazu wählt man beim Bearbeiten des Antragstypen unter „Antragsteller*in“ -> Formular den Punkt „Keine Antragsteller*in“ aus.

Da eingescannte Bilder und Fotos häufig auch im PDF-Format gespeichert werden, ist es nun für Mitglieder auch möglich, zum Beispiel bei Bewerbungen ihr Foto oder eine ergänzende Abbildung als PDF hochzuladen. Dieses wird dann automatisch in ein reguläres Bildformat umgewandelt.

Wird Antragsgrün auch verwendet, um die Tagesordnung einer Veranstaltung zu planen, ist es nun möglich, einzelne Änderungsanträge eines Antrags auch innerhalb eines anderen Tagesordnungspunktes zu behandeln als den eigentlichen Antrag – beispielsweise wenn ein einzelner Änderungsantrag strittig genug ist, um einen eigenen Tagesordnungspunkt rechtzufertigen. Man kann den Änderungsantrag analog zum Antrag auf der Bearbeiten-Seite einem Tagesordnungspunkt zuordnen.

Bei größeren Veranstaltungen, bei denen mit Verfahrensvorschlägen gearbeitet wird, ist es nun auch möglich, Anträge und Änderungsanträge mit internen Schlagworten zu gruppieren, die der Antragskommission helfen kann, beispielsweise Verhandlungspakete zu gruppieren. Diese Schlagworte können beim Bearbeiten des Verfahrensvorschlags eingegeben werden und sind anschließend in der Antragsliste sichtbar und filterbar.

Eine besondere technische Herausforderung ist / war auch wieder die diesjährige Bundesdelegiertenkonferenz von Bündnis 90 / Die GRÜNEN, auf der für das Wahlprogramm behandelt wird. Über 4.000 Änderungsanträge wurden hier eingereicht, was das System mehrfach an den Rand des Absturz brachte (und, zugegebenermaßen, auch mitunter darüber hinaus). Viele der Performance-Verbesserungen, die schlussendlich umgesetzt wurden, um das ganze noch lauffähig zu halten, flossen auch in das reguläre Antragsgrün zurück und dürften so auch mittelgroßen Veranstaltungen in Zukunft helfen.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es, sobald die neue Version offiziell freigegeben wurde, auf der Github-Projekteseite.

Nach längerer Entwicklungszeit – zehn Monate seit der letzten größeren Version – ist nun Antragsgrün in der Version 4.7 erschienen. Eingeflossen sind unter anderem Neuerungen, die für Anwendungsfälle verschiedenster Organisationen umgesetzt wurden, vom Deutschen Bundesjugendring über den Deutsche Frauenrat hin zur European Green Party und natürlich Bündnis 90 / Die Grünen.

Wenn Antragsgrün während einer Veranstaltung genutzt wird, also zum Beispiel auf einem Online-Parteitag, lässt sich nun die Redeliste leicht über Antragsgrün verwalten. Teilnehmende können sich dabei auf eine Warteliste setzen, als Admin kann man diese Warteliste verwalten, umsortieren und festlegen, wer in welcher Reihenfolge spricht. Auf Wunsch lässt sich diese Redeliste dabei auch quotieren, um abwechselnde Redebeiträge zu ermöglichen. Aktivieren lässt sich diese Möglichkeit entweder beim Anlegen einer Veranstaltung oder nachträglich unter Einstellungen -> Aussehen / Bestandteile dieser Seite. Der Funktionsumfang der Redelisten ist aktuell noch recht überschaubar, wird in Zukunft aber je nach Bedarf erweitert.

Nutzt man Antragsgrün, um Bewerbungen für bestimmte Posten zu verwalten, kann man als Admin nun auch die Einreichung von Bewerbungs-Videos ermöglichen: man fügt dazu dem Typen Bewerbung den Antrags-Abschnitt „Eingebettetes Video“ hinzu, ab dann können Kandidierende Videos mit angeben, die vorher bei Youtube, Vimeo oder einer anderen Video-Seite hochgeladen wurden.

Unabhängig davon ist es nun etwas leichter, die Bewerbungen zu verwenden, da nun bei der Einrichtung einer Antragsgrün-Seite gleich zu Beginn abgefragt wird, welche Funktionen (Anträge, Wahlprogramm, Bewerbungen, Tagesordnung, Redelisten) genutzt werden sollen.

Nutzt man mehrere Antragstypen nebenher (z.B. Anträge, Dringlichkeitsanträge und Bewerbungen), ist es nun möglich, nicht mehr nur den Titel dieser Typen anzupassen, sondern auch Erklärungstexte beim Anlegen, Benachrichtigungs-E-Mails an die Antragstellenden, und weitere.

Generell wird Antragsgrün weiterentwickelt, um sich leichter mit weiteren Online-Tools und Login-Systemen verbinden zu lassen. Ein Beispiel hierfür ist die Online-BDK letzten November, bei der Antragsgrün mit der Online-Konferenzsoftware der Netzbegrünung zusammenarbeitete. Technisch basiert das auf einer REST-Schnittstelle (OpenAPI-Spezifikation), die noch recht überschaubar ist, in Zukunft aber je nach Bedarf weiterentwickelt wird.

Erwähnenswert ist noch, dass die mindestens vorausgesetzte PHP-Version nun auf Version 7.2 erhöht wurde – wobei natürlich hoffentlich ohnehin niemand mehr Versionen unter 7.3 einsetzt.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Es ist nun Version 4.6 von Antragsgrün erschienen, die wieder einige Neuerungen mit sich bringt.

Nummerierte Listen sind nun deutlich flexibler geworden: es sind nun verschiedene Nummerierungsschemata möglich, z.B. (1), 1. oder a.. Einzelne Listenpunkte können die reguläre Nummerierung überschreiben, um z.B. eingefügte Nummern wie „2a“ zu ermöglichen, oder um Nummern zu überspringen. Dadurch wird es leichter, Satzungen oder Gesetzestexte in Antragsgrün einzupflegen und Änderungsanträge dafür zu ermöglichen. Die Funktionen hierfür findet man, wenn man beim Eingeben eines Antrags eine nummerierte Liste anlegt und dann auf einen Listenpunkt rechts klickt.

Viel Arbeit floss in den letzten Wochen in die Barrierefreiheit von Antragsgrün. Es orientiert sich dabei am Standard WCAG 2.0 (AA), um Antragsgrün über Screenreader zugänglich zu machen, die Navigation per Tastatur zu vereinfachen und die Lesbarkeit der Schrift zu verbessern – wozu auch kleinere Layout-Anpassungen nötig waren. Falls hier in diesem Bereich jemand noch konkrete Verbesserungsvorschläge hat, kann sich übrigens gerne melden.

Manche nutzen die „Änderungsanträge einpflegen“-Funktion direkt auf ihren Veranstaltungen, um zusammen mit den Mitgliedern oder Deligierten live den fertigen Beschluss zu erstellen. Hier ist es nun möglich, dass die Mitglieder auch währenddessen noch neue Änderungsanträge erstellen. Werden diese freigeschaltet, erscheinen diese nun automatisch in der Einpflegen-Ansicht an der entsprechenden Stelle.

Das Bearbeiten von Tagesordnungen ist nun etwas leichter: Änderungen werden nun sofort gespeichert, wenn man den ✔-Button klickt, und müssen nicht nocheinmal zusätzlich gesammelt gespeichert werden.

Änderungsanträge zeigen nun bei den Textänderungen oft noch etwas mehr Kontext – also nicht mehr nur die eine sich ändernde Zeile, sondern auch die Zeile zuvor und danach, solange sich diese im selben Absatz befinden.

Und schließlich gibt es für Konferenzen, bei denen es potenziell auch internationale Interessierte gibt, nun die Möglichkeit, bei Anträgen, Änderungsanträgen sowie auf der Startseite einen Übersetzungs-Button einzublenden, der auf wahlweise Google Translate oder den Bing Translator zeigt. Dies lässt sich in Einstellungen -> Aussehen und Bestandteile der Seite -> Übersetzungs-Links einrichten.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Es ist nun Version 4.5 von Antragsgrün erschienen, die wieder einige Neuerungen mit sich bringt.

Antragsgrün hat nun eine neue Startseiten-Variante für Online-Diskussionsprozesse, bei denen es weniger um klassische Anträge und Änderungsanträge geht, sondern mehr um das Einreichen von Ideen sowie das Kommentieren derselben. Wer schon „Beteiligungsgrün“ genutzt hat, kennt den grundsätzlichen Aufbau: aktuelle Kommentare zu eingereichten Texten werden prominent angeteasert, darunter folgt eine nach Schlagworten filterbare Liste der Ideen / Texte. Aktivieren kann man diese Startseiten-Variante unter „Einstellungen -> Aussehen und Bestandteile der Seite“, die Schlagworte lassen sich unter „Einstellungen -> Diese Veranstaltung“ einstellen.

Legt man auf der Startseite eine Tagesordnung an (man kann diese auch unter „Einstellungen -> Aussehen und Bestandteile der Seite“ aktivieren, falls sie beim erstmaligen Einrichten der Seite nicht aktiviert wurde), kann man die Tagesordnung nun noch etwas flexibler gestalten: zum einen lassen sich den einzelnen Tagesordnungspunkten nun genaue Zeiten zuordnen. Zum anderen gibt es die Möglichkeit, Datumszeilen hinzuzufügen, was besonders bei mehrtägigen Veranstaltungen für mehr Übersichtlichkeit bei der Tagesordnung sorgt.

Wird Antragsgrün für Bewerbungen genutzt, gibt es verschiedene kleinere Verbesserungen beim Erzeugen der Druckansicht. Erfolgt die Bewerbung dadurch, dass die Kandidierenden ihre vorgefertigte PDF-Bewerbung hochladen, wird bei der Druckansicht nun standardmäßig kein (fast leeres) Deckblatt mehr vorangestellt. Bewirbt man sich hingegen über das Formular, bei dem man z.B. auch die eigene Unterschrift hochladen kann, wurden diverse häufig vorkommende Layout-Probleme behoben, unter anderem die oft zu groß erscheinende Unterschrift.

Beim Einpflegen von Änderungsanträgen in die Anträge wurde nun vor allem optisch hinsichtlich des Leseflusses noch einmal etwas nachgebessert. Darüber hinaus wurden einige kleinere Unstimmigkeiten beim Bearbeitungsfluss behoben.

Weitere kleinere Änderungen:

• Gibt es eine speziell gelayoutete Version eines Antrags, gibt es nun die Möglichkeit, die automatisch erzeugte PDF-Version eines Antrags durch ein vorgefertigtes PDF zu ersetzen. Diese Möglichkeit muss von den Admins einer Veranstaltung explizit aktiviert werden, indem dem Antragstyp ein Abschnitt „Alternatives PDF“ hinzugefügt wird.
• Die Twitter/Facebook-Teilen-Buttons wurden entfernt, da sie unserer Erfahrung nach praktisch nie genutzt wurden und optisch nicht zum Rest der Seite passten.
• Wenn es für Antragstellende zum Einreichen eines Antrags nötig ist, zuerst eine bestimmte Anzahl an Unterstützenden zu finden, ist es nun als Admin optional möglich, eine Unterseite auf der Startseite einzurichten, auf der alle Anträge aufgelistet werden, die aktuell Unterstützung suchen. Diese Seite lässt sich unter „Einstellungen -> Aussehen und Bestandteile der Seite“ aktivieren.
• Die automatischen Benachrichtigungs-E-Mails sehen nun etwas ansehnlicher aus.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Es ist nun Version 4.4 von Antragsgrün erschienen, die wieder einige Neuerungen mit sich bringt.

Häufig gewünscht wurde die Möglichkeit, für Änderungsanträge andere formale Voraussetzungen festlegen zu können als für die zugrundeliegenden Anträge. Beispielsweise dass zum Stellen eines Antrags eine bestimmte Anzahl an Unterstützenden angegeben werden muss, bei Änderungsanträgen zu einem solchen Antrag diese Anforderung aber entfällt (oder eine andere Mindestzahl fest steht). Solche Konstruktionen sind nun möglich. Standardmäßig gelten für Änderungsanträge weiterhin die selben Voraussetzungen wie für Anträge, aber man muss nur im Abschnitt „Antragsteller*in / Unterstützer*innen: Anträge“ die Auswahl von „Die selben Einstellungen auch für Änderungsanträge“ entfernen, und schon lassen sich die Einstellungen für Änderungsanträge separat einstellen.

Auf der Startseite einer Veranstaltung ist es nun möglich, den Teilnehmenden nach der einleitenden Willkommensnachricht auch eine Liste an beliebigen Dateien zum Herunterladen anzubieten – beispielsweise Formulare, Informationsbroschüren oder dergleichen mehr. Das Formular zum Hochladen dieser Dateien erscheint, wenn man auf der Startseite bei der Willkommensnachricht auf „Bearbeiten“ geht.

Wenn man mehrere Veranstaltungen administriert usd diese innerhalb der selben Subdomain liegen, ist es nun möglich, einzelne Anträge zwischen diesen Veranstaltungen hin- und her zu verschieben – inklusive der Möglichkeit, an der ursprünglichen Veranstaltung eine Referenz auf die neue Stelle beizubehalten. Diese Funktion findet sich, wenn man beim Bearbeiten eines Antrags in der Seitenleiste rechts auf „Verschieben“ geht.

Für größere Veranstaltungen mit vielen Administrierenden wurde nun die Möglichkeit eingeführt, (Änderungs-)Anträgen jeweils eine*n Verantwortliche*n innerhalb der Antragskommission festzulegen. Diese Funktion findet sich in der Admin-Antragsliste, man aktiviert sie, indem man einmalig oben unter „Funktionen“ den Punkt „Zuständigkeiten aktivieren“ auswählt. Ab dann wird sie für alle Antragstypen aktiviert.

Da es Landesverbände gibt, bei denen es für Anträge nicht nur eine Mindestzahl an Unterstützer*innen, sondern darunter auch eine Frauenquote gibt, wurde außerdem noch die Möglichkeit eingeführt, zusätzlich eine Mindestzahl an Frauen anzugeben, die sich unter den Unterstützenden finden muss.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Heute sind nach langer Vorbereitungszeit die ersten MVG Digitalstelen eröffnet worden. Die meisten stehen im Stadtteil Neuaubing, die Eröffnung fand beim Westkreuz statt. Sie stehen jeweils bei den neuen MVG Mobilitätsstationen, die öffentlichen Nahverkehr, Bike- und Carsharing und die Quartiersboxen bündeln.
Die Digitalstelen bieten einen interaktiven Umgebungsplan, über den man sowohl die Geschäfte, Sehenswürdigkeiten und Straßen erkunden kann als auch verschiedene Angebote der MVG einsehen kann, z.B. die Abfahrtszeiten von U-Bahnen und Bussen, E-Ladesäulen etc.
Auch die Messdaten der intelligenten Lichtmasten, die von der Stadt München im Rahmen des Smarter Together Projekts aufgestellt wurden, können über die Digitalstelen eingesehen werden (auch wenn es zurzeit nur von einem Lichtmast in der Wiesentfelser Straße tatsächlich Daten gibt).

Mein Beitrag dabei war die Software, die auf den Stelen läuft, sowie eine Backend-Komponente dazu. Beides entwickelte ich im Auftrag der Portalgesellschaft München, die auch die Website www.muenchen.de betreibt.

Backend: Echtzeitproxy / Node.JS

Das (softwaretechnisch) spannendste daran ist die Backend-Komponente, der sogenannte „Echtzeit-Proxy“. Dieser kommt nicht nur bei den Digitalstelen zum Einsatz, sondern auch bei anderen Produkten der Portalgesellschaft wie beispielsweise der Spielplatz-München-Karte, dem letztens überarbeiteten muenchen.de-Stadtplan und der neuen Version der Android-App.
Der Echtzeit-Proxy dient vor allem der Daten-Aggregation und -Aufbereitung und ist speziell für effiziente Kartenanwendungen ausgelegt. Wir standen bei den verschiedenen Kartenanwendungen bei muenchen.de vor dem Problem, dass wir es mit einer Reihe an verschiedenen Datenquellen zu tun haben:

• Das Branchenbuch von muenchen.de selbst, das über 100.000 Einträge umfasst.
• Der städtische Dienstleistungsfinder, der zwar über muenchen.de zu finden ist, technisch und organisatorisch komplett unabhängig läuft und Daten wie Spielplätze, öffentliche Toiletten, Behindertenparkplätze enthält.
• Die Schnittstellen der MVG, die Standorte und Abfahrtszeiten von öffentlichem Nahverkehr, MVG-Rädern, Carsharing und E-Ladesäulen bereitstellt und deren Daten sich daher viel häufiger ändern.
• Sowie einige weitere Datenquellen, die perspektivisch integriert werden sollen.

Die Daten sind jeweils deutlich anders strukturiert (z.B. sind die Branchenbuch-Einträge bei muenchen.de per n*m-Relation einem hierarchischen Kategorien-Baum zugeordnet, während Spielplätze sich eher nach Ausstattungsmerkmalen und Zielgruppen gegliedert sind) und haben unterschiedliche Anforderungen an Aktualität (beim Branchenbuch ist eine Zeitverzögerung von einem Tag akzeptabel, während bei den Standorten von frei stehenden MVG-Rädern eine Minute Verzögerung bereits viel ist).

Für die Kartenanwendungen, die auf diese Daten zurückgreifen, ist dagegen vor allem wichtig, die Netzwerklatenz, die Anzahl der HTTPS-Requests sowie die zu übertragene Datenmenge möglichst zu reduzieren:

• Um die Zeit für einen Request möglichst zu reduzieren setzen wir neben reinen Netzwerktechniken wie HTTP2 vor allem auf einen einfach gehaltenen Node.JS-Server, der komplett ohne Datenbank auskommt und einen Großteil des Datenbestands im Arbeitsspeicher vorhält. Dadurch kommen wir i.a. auf unter 50ms, sofern nicht externe Ressourcen nachgeladen werden müssen (z.B. die Bewertungen, Öffnungszeiten und Abfahrtszeiten, die bei jeweils externen APIs liegen). Auf ein dediziertes CDN für die Echtzeitproxy-API verzichten wir aktuell allerdings (im Gegensatz natürlich zu den statischen Ressourcen wie Icons und Bilder).
• Um die Anzahl der Requests und der Datenmenge zu reduzieren müssen verschiedene Abfrage-Modi unterstützt werden, die auf Kartenanwendungen zugeschnitten sind: vor allem Boundingbox-Abfragen mit kombinierten Kategorien-Abfragen („Alle Apotheken und Nahverkehrs-Haltestellen innerhalb des angezeigten Kartenausschnittes“) sind wichtig. Um die Datenmenge gering zu halten werden erweiterte Daten wie Beschreibungstexte nur auf explizite Anfrage hin ausgeliefert und bei Bedarf auch jeweils nur in der abgefragten Sprache (aktuell werden deutsche und englische Titel, Beschreibungen, Adressen etc. unterstützt, perspektivisch könnten aber auch weitere Sprachen hinzukommen). Und natürlich wieder gängige Netzwerk-Techniken wie gzip-Kompression.

Daneben gibt es (und nichts anderes erwartet man natürlich) auch ein kleines Sammelsurium an ad-hoc-PHP-Proxy-kripten – die in diesem Projekt aber tatsächlich nur eine untergeordnete Rolle spielen.

Frontend: Angular, Leaflet, Charts.js

Der Hauptteil des Frontends besteht aus einer Leaflet-Karte, die in ein Angular-Framework eingebettet ist. Hier entwickeln wir natürlich nicht für jede Kartenanwendung alles von Grund aus neu sondern verwenden für mehrere Anwendungen eine gemeinsame Code-Basis, die je nach Anwendung nur angepasst wird. Abgesehen von der Routing-Funktion (Fußgänger, Fahrrad, Auto und öffentlicher Nahverkehr – letzteres ist auf der Digitalstele allerdings aus Gründen™ nicht verfügbar) ist dabei technisch gesehen wenig Weltbewegendes dabei; ein Großteil der Arbeit bestand darin, die vielen verschiedenen Angebote abzubilden (eTrikes müssen anders behandelt werden wie eRäder, und die wiederum anders wie reguläre MVG-Räder; Stattauto-Stationen müssen anders behandelt werden wie Stattauto Flexy, usw. …).
Das Kartenmaterial selbst kommt von Mapbox, basierend auf OpenStreetMap.

Teilweise unabhängig davon gibt es noch ein teils unabhängiges Frontend für die intelligenten Lichtmasten, das als IFRAME in den Digitalstelen eingebunden wird. Diese Lösung wurde deshalb gewählt, da diese Seite nicht nur auf den Digitalstelen verwendet wird, sondern auch als Webview in der neuen Version der muenchen.de-Android-App eingebunden wird. Daher lief es auf eine technisch möglichst einfach gehaltene Seite auf Basis von jQuery und der Charting-Bibliothek Charts.js hinaus.

Antragsgrün hat in den letzten Monaten große Fortschritte gemacht und nähert sich nun der Version 4: der erste zweite Release Candidate wurde gerade veröffentlicht, womit die Version aus meiner Sicht nun prinzipiell einsatzbereit ist. Sowohl organisatorisch als auch funktional gibt es dabei grundlegend Neues, weswegen es seit langem wieder einen großen Versionssrung (von 3.8 auf 4.0) gibt.

Ins Leben gerufen wurde Antragsgrün vor allem für Parteitage von Bündnis 90 / Die GRÜNEN. Immer mehr zeigt sich aber, dass Antragsgrün auch Probleme anderer Organisationen löst, die ebenfalls Anträge, Programmentwürfe und Änderungsanträge transparent und basisorientiert diskutieren wollen. Schon seit längerem bringt sich daher der Deutsche Bundesjugendring sehr aktiv in die Weiterentwicklung und die Verbreitung von Antragsgrün mit ein. Mit NEOS – Das Neue Österreich und Liberales Forum setzt ab Herbst nun auch eine weitere Partei auf das Projekt und bringt sich entsprechend konstruktiv mit ein.

Konkrete Neuerungen:

Für alle, die Antragsgrün auf einem eigenen Server bzw. Webhoster betreiben, dürfte der neue Update-Mechanismus die wichtigste Neuerung sein. Mit diesem ist es möglich, künftige neue Versionen über die Web-Oberfläche mit wenigen Klicks einzuspielen. Mühsames erneutes Hochladen per (S)FTP, sowie händische Datenbank-Anpassungenn (die für die meisten wohl unzumutbar komplex waren) entfällt damit. Ich hoffe, dass dies verhindert, dass allzu viele veraltete Versionen online bleiben. Wer sich für den technischen Aspekt des Update-Mechanismusses interessiert, insbesondere wie die Integrität sichergestellt wird, kann hier das Sicherheitskonzept sehen.

Das Kommentarsystem wurde grundlegend erneuert: es ist nun möglich, auf Kommentare zu antworten, und dabei die Kommentare einzelner Anträge zu abonnieren – die Diskussionen zu Anträgen sollten dadurch deutlich vereinfacht werden. Auch optisch wurde das Kommentarsystem etwas verbessert.

Antragsgrün bietet nun auch deutlich bessere Möglichkeiten, redaktionelle Textseiten zu veröffentlichen – zum Beispiel Hilfeseiten, auf denen das Verfahren der jeweiligen Veranstaltung genauer erklärt wird oder weitere Informationen über die Mitgliederversammlung angeboten werden. Grundsätzlich lassen sich nun beliebig viele Inhaltsseiten anlegen und bei Bedarf im Menü oben verlinken. Neu ist dabei auch die Möglichkeit, dass man per Drag&Drop einfach Bilder hochladen kann; will man beispielsweise im Willkommenstext einer Veranstaltung eine Illustration einfügen, kann man beim Bearbeiten dieses Textes einfach ein Bild an die entsprechende Stelle schieben, und es wird automatisch hochgeladen.

Zuletzt gibt es auch eine Neuerung, die nach außen auf den ersten Blick kaum sichtbar ist, mittelfristig aber immer wichtiger werden dürfte: ein Plugin-System, mit dem sich sowohl Layout-Varianten als auch komplexere Workflows nachrüsten lassen. Das aktuell wichtigste konkrete Beispiel dafür ist das Tool Beteiligungsgrün, das vor kurzem vom Bundesverband der Grünen gestartet ist: sowohl die alternativen Antragslisten als auch das Konzept der Offenen Diskussion und des folgenden Unterstützungs-Sammelns werden über das neue Plugin-System gelöst. Auch die organisationsspezifischen Layouts (sowohl die beiden Grünen-Layouts als auch die neue NEOS-Variante) sowie die Verwaltung zum Anlegen neuer Subdomains werden als Plugin angeboten. Perspektivisch werden wohl auch weitere Login-Mechanismen (analog zur jetzigen SAML- und OpenID-Einbindung des Wurzelwerks) über das Plugin-System möglich sein.

Weitere Änderungen werden natürlich auch wieder im ausführlichen Changelog aufgelistet. Den Download gibt es auf der Github-Projekteseite.

Antragsgrün ist nun in der Version 3.8 erschienen, nachdem die Version auf der letzten Grünen-BDK bereits eingesetzt wurde. Neben einer ganzen Reihe an Bugfixes gibt es auch einige wichtige neuen Funktionen, die vor allem für größere Veranstaltungen relevant sind:

• Es gibt eine recht umfangreiche Möglichkeit für die Antragskommission, Verfahrensvorschläge für Anträge und Änderungsanträge festzulegen. Dazu gehören unter anderem alternative Versionen von Änderungsanträgen, das Festlegen von Abstimmungsblöcken und eine Kommentarfunktion für die Antragskommission.
• Wenn sich Änderungsanträge auf den Titel eines Antrags beziehen, wird diese Änderung nun auch in der „Laschenansicht“ neben dem Titel des Antrags angezeigt.
• Wenn Änderungsanträge in einen Antrag eingepflegt werden (oder aus anderem Grund eine neue Antragsversion erstellt wird), gibt es nun eine Vergleichsfunktion, welche die Änderungen der beiden Versionen in der Diff-Ansicht anzeigt.

Daneben gibt es einige Technische Änderungen unter der Haube, insbesondere die Kompatibilität mit PHP 7.2.

Die neue Version und das ausführliche Changelog gibt es hier:
https://github.com/CatoTH/antragsgruen/releases/tag/v3.8.0

Jetzt, wo ich schon seit ein paar Wochen an der neuen Version 3.8 von Antragsgrün arbeite, wird es auch langsam einmal Zeit, Version 3.7 offiziell zu veröffentlichen – was hiermit getan ist. 🙂

Diese Version wurde großteils vom Deutschen Bundesjugendring in Auftrag gegeben, der wie viele seiner Mitgliedsorganisationen inzwischen auch regelmäßig Antragsgrün einsetzt. Das genaue Einsatzszenario des DBJRs unterscheidet sich dabei aber doch deutlich von dem, wie Antragsgrün bei Bündnis 90 / Die GRÜNEN eingesetzt wird: vor allem das Überarbeiten des Antrags, bei dem die Änderungen der Änderungsanträge auf einer Präsenzveranstaltung eingepflegt werden, spielt hier eine große Rolle. Die wichtigsten Neuerungen in der Version 3.7 beziehen sich also auch auf diese Funktion.

Aber auch bei der Darstellung der Änderungen in Änderungsanträgen gab es eine ganze Reihe an Verbesserungen, besonders wenn längere Textpassagen davon betroffen sind. Insbesondere gibt es nun auch die Möglichkeit, Änderungsanträge als „Globalalternative“ zu kennzeichnen, die daraufhin separat dargestellt werden.

Eine der wichtigsten Neuerungen ist aber nicht-technischer Natur: es gibt nun erstmals auch ein Handbuch, das die wesentlichen Funktionen von Antragsgrün beschreibt.

Eine genaue Liste der Änderungen in der neuen Version gibt es im Changelog.

Über zwei Jahre ist es her, dass ich München Transparent veröffentlicht hatte – ein Projekt, das ich über mehrere Jahre hinweg zuerst alleine, später zusammen mit Konstantin Schütze und Bernd Oswald in meiner Freizeit entwickelt hatte. Die Seite ist nahezu durchgehend sehr gut angenommen worden, und obwohl wir nie größer Werbung dafür machten und die Weiterentwicklung seitdem zugegebenermaßen eher auf Sparflamme lief, hat sie täglich zwischen 400 und 500 Besucher. Bürgerinnen und Bürger Münchens können davon profitieren, dass sie E-Mail-Benachrichtigungen erhalten, wenn es Beschlüsse oder Auskünfte aus dem Stadtrat oder den Bezirksausschüssen zu ihrem Lebensumfeld gibt, Journalist*innen und Mitarbeiter*innen der Stadtverwaltung schätzen die unkomplizierte Suchfunktionen.

Als der Prototype Fund ausgerufen wurde, eine recht interessante Kooperation aus der Open Knowledge Foundation (OKF), dem Deutschen Luft- und Raumfahrtzentrum (DLR) und dem Bundesministerium für Bildung und Forschung (BMBF), hatten Konstantin unabhängig voneinander die selbe Idee: die Erfahrungen von München Transparent nutzen, um ein neues Ratsinformationssystem zu schreiben, das nicht nur auf München zugeschnitten ist, sondern sich für beliebige Kommunen einsetzen lässt – selbstverständlich als Open Source.

Die Bewerbung und die Vorbereitung nahm dabei einiges an Zeit in Anspruch: die Bewerbungsphase lief im März, im Juni schließlich bekamen wir den erhofften Anruf mit der Bestätigung, von Juni bis Juli hieß es dann, alle notwendigen Unterlagen sammeln, GbR gründen, Konto eröffnen, und jetzt, Anfang September, geht es endlich los! Heute fand der Kick-Off-Workshop in Berlin statt, bei dem wir die anderen geförderten Teams kennenlernen durften.

Zuerst heißt es einmal, den genauen Projektumfang abzustecken und die Arbeitsaufteilung festzulegen. Konstantin und ich haben recht unterschiedliche Schwerpunkte, was sich aber recht gut ergänzen dürfte: durch seine Arbeit am OParl-Standard hat Konstantin bereits viel Erfahrung mit der Modellierung von RIS-Daten und wird sich besonders um die Such-Funktionalität sowie das Backend kümmern, ich interessiere mich vor allem für die Geodaten, die Benachrichtigungs-Funktionalität sowie die Benutzerverwaltung und werde wohl auch größere Teile des Frontends übernehmen.

Generell ist das Ziel, ein Frontend für Ratsinformationssysteme zu schaffen, das sich aus den öffentlichen Daten eines existierenden RIS-Systems speist – Rechte-Verwaltung, interne Dokumente und dergleichen nehmen wir derzeit explizit aus – das sich möglichst einfach für andere Städte anpassen lässt. OParl wird dabei eine wichtige Rolle spielen, da es der einzige Standard ist, über den RIS-Daten maschinenlesbar ausgelesen werden können, was eine Voraussetzung für unser System ist (um nicht wie bei München Transparent für jede Stadt aufwändig einen Scraper schreiben zu müssen). Wir wollen das System dabei auf für mindestens eine Stadt prototypisch implementieren, schon alleine um die Vorteile unseres Systems anschaulich darstellen zu können. Welche Stadt das sein wird, werden wir aber erst evaluieren müssen.

PS: Die Bewerbungsphase für die dritte Runde des Prototype Funds läuft noch – wer also auch Open Source Anwendungen entwickelt und sich für eine Förderung interessiert, kann sich noch bis Ende September bewerben.