Vor ziemlich genau einem Jahr hatten wir das Vergnügen die Aufgabe, für ein Urabstimmungsverlangen eingereichte Unterschriftenlisten zu prüfen. Eine Premiere der jüngeren Geschichte der verfassten Studierendenschaft in Bonn! Was dabei gut lief und wo man¹ Dinge hätte besser machen können, möchte ich an dieser Stelle niederschreiben.

Beginnen wir mit dem, was zu tun war: Eine Urabstimmung kann von fünf Prozent der Mitglieder der Studierendenschaft verlangt werden. Die tragen ihre Namen, Matrikelnummern und Unterschriften auf Listen ein, die dem Studierendenparlament eingereicht werden. Um zu prüfen, ob dieses Verlangen erfolgreich ist, muss dann geprüft werden, ob tatsächlich mindestens fünf Prozent der Mitglieder der Studierendenschaft dieses Verlangen unterschrieben haben.

Wir benötigen also:

• Die Unterschriftenlisten
• eine Liste mit Vornamen, Nachnamen und Matrikelnummern aller Mitglieder der Studierendenschaft zum Stichtag²

Und zu tun ist:

1. Für jeden Eintrag in den Unterschriftenlisten prüfen, ob es sich um ein Mitglied der Studierendenschaft handelt
2. Fehler und Duplikate rauswerfen
3. Die Gesamtzahl der gültigen Unterschriften ermitteln (“den Rest zählen”)

Für die Prüfung hatte die Universitätsverwaltung netterweise die passende Liste zur Verfügung gestellt. Zudem hatte ich eine kleine Applikation entwickelt, mit der diese Liste indexiert und recht fix durchsucht werden konnte. Punkt 1 war also abgehakt.

Um auf den Unterschriftenlisten bei der Prüfung Anmerkungen anbringen zu können, wurde nicht mit den Originalen gearbeitet, sondern mit Kopien. Dass es sich dabei um den Ausdruck eines Scans mit einem Xerox-Gerät handelte, war vielleicht nicht allzu kluk, aber in diesem Fall verschmerzbar.

Die Unterschriftenlisten wurden auf mehrere Zweierteams aufgeteilt, die jeweils ihren eigenen Stapel verifizierten.

Direkt zu Beginn fiel auf, dass am Ende noch Duplikate eliminiert werden mussten. Das hatte ich zuvor nicht bedacht, und daher in die Suchapplikation auch nicht eingebaut, dass die gefundenen Einträge irgendwie gespeichert werden. Zum Glück gab die Anwendung aber den Namen einer Person aus, wenn man auf ihren Eintrag doppelklickte – ein Debugging-Überbleibsel, das sich nun als überaus nützlich erwies. Flugs die Ausgabe des Programms in eine Datei umgeleitet, und fertig war der Behelfs-Log.

Die eigentliche Prüfung lief dann recht reibungslos: Eine Person des Zweierteams tippt, die andere geht die Liste durch und hakt ab, beziehungsweise notiert Unstimmigkeiten wie falsche Namen, Matrikelnummern oder Personen, die gar nicht auffindbar sind.

Als es dann daran ging, für die Deduplizierung Einträge aus der Logdatei in den Unterschriftenlisten wiederzufinden, zeigte sich, dass es sehr nützlich gewesen wäre, die Position der Einträge (Seite/Zeile) mitzuloggen. So musste ungefähr anhand der Zeilennummern geschätzt werden. Nicht optimal.

Zuletzt wurde entschieden, dass Zahlendreher, anderweitig fehlerhafte Matrikelnummern, fehlerhafte Namen, fehlende Unterschriften, doppelte Einträge (einfach) und nicht auffindbare Einträge nicht gewertet werden³. Die übrigen, fehlerlosen Unterschriften wurden gezählt und das Quorum wurde erreicht.

Fazit

• Die Prüfung auf mehrere Teams aufteilen spart Zeit
• Gefundene Einträge mit ihren Positionen abspeichern spart hinterher Zeit bei Nachprüfungen