Export feedback

[tillprochaska]

Ich sammele hier mal Feedback zu unserem Export-Feature:

Feedback 1

Eine feste URL der Datei wäre gut. Falls man nicht auf https://howtheyvote.eu/files/export/export.zip verweisen möchte, könnte man auf die entsprechende URL von GitHub verweisen: https://github.com/HowTheyVote/data/releases/latest/download/export.zip

Das können wir im Zweifel ja auch einfach im Readme verlinken.

Cool wäre, wenn es eine URL mit dem Datum des letzten Exports geben würde, also z.B. eine status/date/version.txt, die nur das Datum enthält. So könnte ein Scraper mit einem Request checken, ob es ein Update gab.

Könnte ja auch einfach ein Plaintext-Release-Asset sein, oder?

ZIP und CSV sind super für Excel-Nutzer*innen, aber schwierig für Scraper/Skripte:

• Das ZIP-Format kann zwar jeder öffnen, hat aber den Nachteil, dass der Index am Ende ist und damit der Inhalt nicht als Stream lesbar ist. Ein Skript muss also die Datei erst auf der Festplatte speichern, dann entpacken und kann dann den Inhalt öffnen.

Wir könnten anstelle des ZIP-Archivs (oder zusätzlich) auch einfach die einzelnen CSV-Dateien als Release-Assets hochladen, oder?

• CSV ist ein problematisches Dateiformat, dass u.a. nicht ausreichend standardisiert ist. Strings können Komma oder Anführungszeichen enthalten, so dass man erstmal eine CSV-Bibliothek installieren muss, um das Format sauber parsen zu können.
• Alternativ könnte man auch JSONL/NDJSON- oder TSV-Dateien in einem .tar.gz-Container ablegen. Aber vermutlich wäre das mehr Aufwand für euch, als es bei den 2-3 Nutzer*innen einspart. Vielleicht genügt es, die Issues im Repo zu aktivieren, und erstmal auf Feedback zu warten ...

Alternative Datenformate würde ich glaube ich erstmal lassen, aber wir könnten im Readme natürlich darauf hinweisen, dass wir uns über Feedback entweder über Issues oder per Mail freuen.

Feedback 2

Es kam als Rückfrage, was die Dokumentreferenzen, genauer die Präfixe A/B/RC-B, bedeuten. Das könnten wir erklären bzw. auf eine geeignete Erklärung auf der Parlamentsseite verlinken. Gleiches gilt vermutlich auch für die Verfahrensreferenzen.

[linusha]

Das können wir im Zweifel ja auch einfach im Readme verlinken.

Das ist da ja schon verlinkt? Wir können aber natürlich noch explizit dranschreiben, dass diese URL sich nicht verändert? Wenn wir auf einzelne Assets umstellen, müssten wir das eh kurz anfassen.

Könnte ja auch einfach ein Plaintext-Release-Asset sein, oder?

Das geht garantiert schöner, wenn Nutzende sich die Mühe zu machen GitHub API zu benutzen, aber klar, kommt dazu, kostet ja nichts. Gleiches gilt für die Plaintextfiles statt/zusätzlich zur zip. Ich hatte sogar so mal angefangen, hatte da glaube ich im Nachhinein nur einen Typo drin und deswegen hatte es damals nicht funktionier. Schau ich mir an. Ich habe keine starke Meinung ob nur das eine oder nur das andere, würde aber glaube ich tendentiell die .zip da lassen, weil das praktisch ist? Außer GitHub macht einem eh ne Sammeldatei mit allem, das würde ich nochmal prüfen.

Alternative Datenformate würde ich glaube ich erstmal lassen, aber wir könnten im Readme natürlich darauf hinweisen, dass wir uns über Feedback entweder über Issues oder per Mail freuen.

Ja, ich stimme zu. Über die Kritik an CSV kann man bei genügend Kaltgetränken auch super streiten - wird nen guter Abend in Dresden 😂

[linusha]

ToDos

• activate issues
• create issue template/something else to point out what the issues should be used for (and where errors in the data should be reported)
• add file with date of export
• add plaintextfiles to release
• mention feedback requests in readme
• explicitly spell out in readme that links are fixed (and possibly give an example of how to link to a single plain file inside of the release)
• add changelog to exports, should be an additional plaintextfile where changes to the contents/format of the export are listed in descending order by date (thoughts @tillprochaska?)
• add information about references numbers for documents
• enhance ✨ explanation for main votes