# APFIFoGeS-Reboot Protokoll des AKs auf der KIF 49,0: https://md.kif.rocks/kif490_napfifoges# ## Datenhaltung * Historische Daten halten oder nur letzten Stand? * z.B. Basisdaten und Studi-Zahlen wären praktisch zu behalten * "Fachschaftsinformationstool" * Dauerhaftes Tool hat den Vorteil: Dinge können sofort eingetragen werden, nicht erst zur KIF * CC -> mediawiki (automagisch) ### Datenpunkte - \* - Zeitstempel (last change) - Bundesland - Land - Name + Kürzel - Rechtsform-Optionen für Studi-Vertretungen - HSG-Link - Hochschule - Name - Gesamt-Studi-Zahl - (Land?+)Bundesland - zusätzliche freie "Kategorien" (key+val; z.B.: `Sysakkreditiert: true`) - FS - Name - sind da <!-- gibt es da nicht was von pretix? xD --> - mit wie vielen (opt-in) - \# vertretene Studis - Position/Geo-Daten - Kontaktinformationen - "Außendarstellungs-Stuff" (website url, Bild?/Logo) - zusätzliche freie Schlagworte/-Sätze - mit optinal Erklärtext; z.B.: "Personalmangel" -> "weil alle den Abschluss gemacht haben" - mit "wichtigkeit" (default, low, high?) - mit Reihenfolge - - Studiengang (pro FS) - Name - \# Studis (bucket-sizing? Master vs. Bachelor?) ### DB - RDBMS - Pro: mostly reliable, consitent structure, vorwissen + Instanzen - Con: teils etwas unflexibel - Software: Postgres (vorhanden), MariaDB/MySQL, ... - ist konsensfähig - Object-DB - Pro: flexibel - Con: weniger erfahrung damit - Software: mongodb, redis, ... - whatever-DB (z.B. Graph-DBs) - Con: noch weniger Erfahrung damit - ## Backend (Sprache + Framework) - Python (z.B. AK, RL-System?) - Django - Flask - Ruby (z.B. KDV) - Rails - JS - Rust, C++, Go, ... <!-- - PHP (gotos waren ein Feature in 5.3!) --> ## Auth? - wollen wir das? -> vermutlich - "Trollschutz" - für das meiste ist einerseits Vertrauen da, und andererseits kein großes Angriffsszenario - für was? - lvl: admin (z.B. liste von FSorg IDs) - Daten löschen (ganze Bundesländer, Hochschulen, ... oder auch einzelne Versionen) - Bundesland anlegen - lvl: login (z.B. irgendein FSorg account) - Bundesland ändern - Kommentare zu Datensätzen - - wie machen wir das? - integration in stuff (fsorg per LDAP/oauth/whatever) - wir müssen keine PErsonen-Daten haben (maximal UIDs von admins) - z.B. oauth via FSorg -> keine Cookies bei uns, Auth-Header reicht - eigene Datenhaltung - datenschutz, datensicherheit, etc. ... nope - "root"-PW in configs (o.Ä.) - 2do: für Implementierungsdetails mit Dortmundern reden (da liegt das SSO) ## API - "there is no SOAP in this RESTroom" - ## wie gehts weiter? - Tasks - Repos/Projektgruppe anlegen -> done - wir haben [FITNESS](https://gitlab.fachschaften.org/kif/fitness) - DB Schema basteln (aka. Spaß mit Foreign-Keys) - API "ausformulieren" - Backend Framework init (aka. Projekt anlegen) - Backend basteln - depends: Projekt init - depends: lernen wie Framework funktioniert - depends: DB Schema für DB-Code - depends: API Struktur für ... API - frontend(s) basteln - depends: API Struktur - - nächste Treffen - in welchem Zyklus? - aktuell ist "in Ruhe Vorschläge ausarbeiten" sinnvoll - in der Implementierung wäre "intensiveres" gut - längeres Gespräch/Treffen irgendwann - keine zu engen Zeitraster -> nicht förderlich - das nächste - irgendwann Mitte Juli - DB schema finalisieren - Projekt init - - die KIF 49.5 wird kein FITNESS machen ... vielleicht 50.0 - wir sind zuversichtlich weiter zu kommen, als bei bisherigen Anläufen ## Sonstiges - evtl. beim AK-Tool Sachen abschauen https://gitlab.fachschaften.org/kif/akplanning -