SoSe16 AK IT

Vorstellung des AKs

Verantwortliche/r: Jörg (FUB), Fabs (TUB), (Jan (FUB))

In diesem AK stellt der TOPF seine bisherige Arbeit vor und möchte über weitere Projekte sprechen, die Henkel übernehmen können.

Arbeitskreis: Akkreditierung

Protokoll vom 06.05.2016

Beginn

13.30

Ende

14.58

Redeleitung

Jörg (FUB), Fabs (TUB), Jan (FUB)

Protokoll

Annika, Bähring (Uni Konstanz)

Anwesende Fachschaften

FU Berlin,

HU Berlin,

TU Berlin,

TU Dresden,

Uni Frankfurt,

Uni Jena,

Uni Konstanz,

Uni Münster,

Uni Siegen,

Uni Würzburg,

Einleitung/Ziel des AK

In diesem AK soll berichtet werden was der TOPF in den letzten sechs Monaten getan hat und was die Pläne für die Zukunft sind.

Protokoll

Was wurde gemacht?

Wiki

Das ZaPF-Wiki wurde auf den ZaPF-Server umgezogen und das Studienführer-Wiki wurde auf dem ZaPF-Server nachgebaut. Problem zu Beginn: Spam. Dies wurde durch manuelle Anmeldung / Verifizierung per Mail für das ZaPF-Wiki gelöst, aber für das Studienführer-Wiki wurde dies vergessen, wodurch es von Spammern überrant wurde. Dies muss aufgeräumt werden, da derzeit auch keine Anmeldungen mehr möglich sind; möglicherweise wurde ein Useraccountlimit erreicht.

ZaPFev.de

Die ZaPF e.V. Website war mehrmals unerreichbar, da der Server in Frankfurt den Geist aufgegeben hat und Domains nicht bezahlt wurden. Sie wurde als statische Seite auf Github nachgebaut.

Das Nicht-Bezahlen von Domains nahm zwischenzeitlich einige Dienste vom Netz, da der Nameserver, der eingerichtet wurde, da der TOPF keinen Zugriff auf die Domainverwaltung hat. Dies soll in der nächsten TOPF-Periode gelöst werden, entweder durch Kontrolle über die Domainverwaltung oder eine Verbesserung unseres Nameserver. Allgemein wurde durch diese Episode die Kommunikation mit dem ZaPF e.V. stark verbessert.

Verschiedenes

Nicht so viel vom eigentlich gewollten wurde erreicht, dennoch wurde die Kommunikation deutlich verbessert und viele kleinere Fehler beseitigt, die spontan aufgetreten sind.

Der TOPF versteht sich als managendes, administrierendes Gremium und nicht als Entwickler.

Was soll gemacht werden

Der ZaPF e.V. wüscht sich für seine Arbeit eine dropboxartige Lösung oder zumindest ein SFTP oder WebDAV.

→ Mailingliste erstellen um dies zu besprechen

• “Ansible“ wurde erstellt um Aufbau der Server zusammen zu fügen → zu finden auf (Gitter.com/zapf)→ Ziel mit mehr Leuten arbeiten um „Ideen auszutauschen“

• Ansible- Rollen werden erstellt um Kommunikation zu verbessern und die Arbeit aufzuteilen

• Wunsch: mehr Helfer, welche die Kompetenzen haben um Ansible-Rollen zu übernehmen:

→ Erreichbarkeit über #topf aut freenode oder topf@lists.physik.tu-berlin.de

• Viele Kritische Aspekte

Kommen wird (to do´s):

• finden von Person, die sich in das komplette System einarbeitet
• ordentliche Backups

(* Studienführer)

• Studienführerwiki muss aufgeräumt werden und wird relevanter
• Zapf.ev möchte ein paar Sachen haben
• Wiki Plugin

• Zapf.App von Kn wird aufgeräumt und öffentlich gemacht

→ evtl wird es wieder eine Einheitliche App geben (es wird sich darum gekümmert) → Verbesserung: aktuelles Angaben sollen besser zu sehen sein

• App ist momentan Datei, welche direkt von Tagungsbüro aktualisiert wird → es wird nach Verbesserung gesucht.

Weitere Anregungen/ Kritik/ Fragen :

• Mailingliste nur für allgemeine Dinge und Leute außerhalb des Topfs, Rest ist auf #topf auf freenode

• Kommunikation verbessern (auch für Allgemeinheit?)
• Gruppennachrichten über signal gehen verloren oder kommen mehrmals an
• Kommunikation Henkel Topf ist dafür eigl. Zuständig
• Kommunikation so simpel wie möglich gestalten
• über Java-Server (ist in Arbeit)

• Anzahl der Leute 2, als Verantwortliche sind Kontakt zu Stapf, sollen dennoch nicht alleine arbeiten, sind ausreichend
  • Übergabe Läuft damit
  • immer erreichbar

• mehr Leute welche beim „Brainstorm“ helfen

→ Interne und Externe Mailingliste (um Datenschutz zu sichern)

• freiwillige Helfer sollen nicht alle Anonyme Daten erhalten, im Spezialfall kann dies aber zugeteilt werden (vom „Gremium“/ Verantwortliche) beziehungsweise Probleme zusammen zu lösen ohne den Datenschutz nicht zu verletzen

• Testcase finden um Fehler zu vermeiden

• unter den Topfdeckeln sind KEINE Programmierer

• StaPF darf laut „Gesetz“ auf Daten zugreifen → StaPF kann diese beantragen und ohne Gewissenbissen können diese weitergegeben werden

• man kann zur Not auch alles über eine Mail regeln (Notlösung)

→ wenn alles im letzten Moment ausfallen würde

• nächste Rechnung für ZapfEv ist da und wird evtl rechtzeitig bezahlt
• vollständiger Datenverlust ist ein Problem (worst case)

→ evtl Lösung über zweiten anderen Server starten → Metall der Uni eher weniger, da wieder Personen und Uni abhängig → ZapfEv kann evtl. weiteres Pensum weiterer Server/Anbieter auch bewältigen

Zusammenfassung

Es wurde die Geschehnisse des letzten halben Jahr durchgesprochen und kommende ToDos aufgeführt und besprochen was sonst noch zu tun ist und was verbessert werden kann.