KIF440:KIF went digital

Aus KIF
Version vom 7. Mai 2016, 18:41 Uhr von Johannes (Diskussion | Beiträge)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Leiter: luelistan und johnny

Anwesende: ca. 11

  • Vorstellung des genutzten Systems
  • https://github.com/d120/kifplan
  • Anmerkungen:
    • Erstrebenswert wären getrennte Apps für Personenverwaltung (mit Anmeldung), KdV usw. Möglicherweise OAuth zur Verknüpfung
    • Engelsystem evtl. auch über OAuth anbinden
  • Engelsystem sehr unübersichtlich, aber nach wie vor ausreichend und es gibt wenig besseres
  • Man könnte das Engelsystem vielleicht verbessern, indem die Tabelle transponiert wird und das Kalendersteuerelement der AK-Wall eingebaut wird.
  • Idee: AK-Erstellung andersrum machen: im System registrieren, dann zum Wiki exportieren
  • Systeme sollten beim KIF e.V. zentralisiert und idealerweise auch vom e.V. gehostet werden
  • Feedback zum rotierenden Anzeigebild auf dem Dashboard: eher nervig, nach Wartezeit war die Info, die man haben wollte, auch schon zu schnell wieder weg
  • Idee: eine Anzahl von Kiosk-Systemen (etwa Tablets) über den KIF e.V. anschaffen und neben einem Fernseher etc. zur Verfügung stellen. Anmerkung: die meisten Menschen haben ohnehin bereits ein Gerät dabei. Allerdings könnte die Hürde, die Seite erstmal aufzurufen, genommen werden.
  • Alternative zum Zeitcycle: ein kleines Board mit Knöpfen an die Raspberry Pis anbringen, um die Ansicht zu wechseln
  • Diskussion über das Hosting der Systeme: zentral bei der ausrichtenden KIF oder dezentral. Viele Systeme (Anmeldung, Wiki) laufen bereits seit langem stabil dezentral. Der KIF e.V. möchte aktuell keinen Server mieten, da er nur selten und auch nur vielleicht von einigen KIFs genutzt werden würde. Vorteil an zentralisierter Software: Motivation zur Entwicklung (z.B. durch Pull Requests) auch über einen längeren Zeitraum und von verschiedenen KIF-Orgas. Anmerkung: einige Software (Beispiel Schildergenerator) kann eigentlich nur lokal sinnvoll installiert werden.
  • Aachen: mobile App kam sehr gut an, insbesondere das Feature zur Erinnerung über AK-Zeitänderungen wurde sehr stark genutzt. Anmerkung: die meisten Dinge (bis auf Offline-Nutzung) können durch Browser-Push auch ohne App umgesetzt werden.
  • Thema Beamer in der Schlafhalle: wurde genutzt, war sinnvoll. Ein Fernseher hätte prinzipiell auch gereicht. Viele Kiffels haben ihren Laptop nicht mit zur Schlafhalle genommen, daher war die AK-Wall sehr sinnvoll. Off-Topic: eine Ladestation in der Schlafhalle wäre nützlich. Der KIF e.V. könnte vielleicht Vielfach-Ladegeräte anschaffen.
  • Scheduling-Problem sollte eigentlich durch bestehende Software schon gelöst sein, wir haben aber nichts funktionierendes gefunden. Genetische Algorithmen scheinen am besten geeignet zu sein, Gewichtung der Constraints muss gegeben sein.
  • Die Erfassung der Teilnehmika-Interessen sollte nicht durchgeführt werden (um Konflikte mit gleichzeitig stattfindenen AKs zu minimieren), da der Aufwand vermutlich nicht gerechtfertigt ist. Problem auf der KIF ist, dass die Menge der angebotenen AKs erst nach dem Anfangsplenum bekannt ist, sodass keine Zeit zur Interessensbekundung bleibt. Vorerhebung könnte allenfalls statistische und partielle Informationen bereit stellen. Die Interessenserfassung nicht mehr beim Anfangsplenum durchzuführen, birgt Probleme wie Ablenkung durch Geräte, Internet etc.
  • Konsens: denzentrale Systeme ("loosely coupled") die zentral entwickelt werden. Entscheidung der KIF-Orga, ob die Systeme zentral oder lokal gehostet werden. Bereitgestelltes Interface, um KdV usw. anzubringen. Möglichkeit der KIF-Orga, weitere Systeme nach Bedarf zustzlich zu bauen.
  • Thema Vergleich zu nicht-digitaler Verwaltung: fast kein Unterschied für Teilnehmer*innen. Es ist auch auf Papier (fast) nicht möglich, einfach AKs umzuhängen. Hauptvorteil ist, dass die AK-Wall an vielen Stellen einsehbar ist (eigener Laptop, Schlafhalle, ...).
  • Vorschlag: Pflege einer KIF-VM mit den Systemen zunächst bei einer Fachschaft, anschließend Verteilung von Backups über möglichst viele Fachschaften. Einwurf: möglicherweise Docker. Dies sollte aber (zunächst) hinten angestellt werden.