SoSe16 AK IT: Unterschied zwischen den Versionen
(erster Protokollentwurf vom Protokollikon) |
(→Arbeitskreis: Akkreditierung: Formatierung gefixt) |
||
Zeile 16: | Zeile 16: | ||
: | : | ||
; Anwesende Fachschaften | ; Anwesende Fachschaften | ||
<!--:RWTH Aachen,--> | <!--:RWTH Aachen,--> | ||
<!--: Uni Bayreuth,--> | <!--: Uni Bayreuth,--> | ||
: FU Berlin, | : FU Berlin, | ||
: HU Berlin, | : HU Berlin, | ||
: TU Berlin, | : TU Berlin, | ||
<!--: Uni Bielefeld,--> | <!--: Uni Bielefeld,--> | ||
<!--: Uni Bochum,--> | <!--: Uni Bochum,--> | ||
Zeile 32: | Zeile 30: | ||
<!--: TU Darmstadt,--> | <!--: TU Darmstadt,--> | ||
<!--: TU Dortmund,--> | <!--: TU Dortmund,--> | ||
: TU Dresden, | : TU Dresden, | ||
<!--: Uni Duisburg-Essen,--> | <!--: Uni Duisburg-Essen,--> | ||
<!--: Uni Düsseldorf,--> | <!--: Uni Düsseldorf,--> | ||
<!--: Uni Erlangen-Nürnberg,--> | <!--: Uni Erlangen-Nürnberg,--> | ||
: Uni Frankfurt, | : Uni Frankfurt, | ||
<!--: TU Freiberg,--> | <!--: TU Freiberg,--> | ||
<!--: Uni Freiburg,--> | <!--: Uni Freiburg,--> | ||
Zeile 44: | Zeile 42: | ||
<!--: Uni Heidelberg,--> | <!--: Uni Heidelberg,--> | ||
<!--: TU Ilmenau,--> | <!--: TU Ilmenau,--> | ||
: Uni Jena, | : Uni Jena, | ||
<!--: TU Kaiserslautern,--> | <!--: TU Kaiserslautern,--> | ||
<!--: KIT,--> | <!--: KIT,--> | ||
<!--: Uni Kassel,--> | <!--: Uni Kassel,--> | ||
<!--: Uni Kiel,--> | <!--: Uni Kiel,--> | ||
: Uni Konstanz, | : Uni Konstanz, | ||
<!--: Uni Köln,--> | <!--: Uni Köln,--> | ||
<!--: Uni Marburg,--> | <!--: Uni Marburg,--> | ||
<!--: Uni München,--> | <!--: Uni München,--> | ||
<!--: TU München,--> | <!--: TU München,--> | ||
: Uni Münster, | : Uni Münster, | ||
<!--: Uni Oldenburg,--> | <!--: Uni Oldenburg,--> | ||
<!--: Uni Potsdam,--> | <!--: Uni Potsdam,--> | ||
Zeile 60: | Zeile 58: | ||
<!--: Uni Rostock,--> | <!--: Uni Rostock,--> | ||
<!--: Uni des Saarlandes,--> | <!--: Uni des Saarlandes,--> | ||
: Uni Siegen, | : Uni Siegen, | ||
<!--: Uni Wuppertal,--> | <!--: Uni Wuppertal,--> | ||
: Uni Würzburg, | : Uni Würzburg, | ||
<!--: TU Wien,--> | <!--: TU Wien,--> | ||
<!--: Uni Wien,--> | <!--: Uni Wien,--> | ||
Zeile 72: | Zeile 70: | ||
<!--: jDPG,--> | <!--: jDPG,--> | ||
<!--: Gäste--> | <!--: Gäste--> | ||
= Einleitung/Ziel des AK = | = Einleitung/Ziel des AK = |
Version vom 7. Mai 2016, 15:56 Uhr
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
Protokoll
Was wurde gemacht? Wiki:
- einige Programme wurde komplett in Wiki übernommen
→ Zapf komplett → einige von StudiWikis
- Problem zu beginn: Spam → Manuelle Anmeldung / Verifizierung per Mail
- Media Wiki: Account hat sein Limit erreicht, da Spams → Lösung wird gesucht (aufräumen)
- Zapf.ev liegt teilweise Still/ es gibt Probleme da Server in Frankfurt ist und alles über eine Person läuft, nun muss alles erneuert werden → weitere Ansprechperson aus Frankfurt um dies zu Regeln
- Statische Zapf.ev Seite erstellt → ging eine Zeitlang gut
- ABER: keine Kontrolle über Domain → großer Aufwand etwas zu ändern
- derzeit: eigenen Nameserver erstellt
- zwischenzeitlich waren einige Seite nicht abrufbar, da sie nicht von Zapf.ev gezahlt wurden
- Lösung: eigenen Nameserver verbessern (evtl wird nicht mehr benötigt oder hinreichend verbessert)
- allgemein wurde mehr Kontakt zu Zapf.ev aufgebaut
(*Zapf.ev wurde lang von einer Person geführt, wird nun aber nach und nach auf mehrere Personen aufgeteilt, Beginn ist schwer)
- nicht so viel vom eigentlichen wurde erreicht, dennoch wurde die Kommunikation deutlich verbessert und Fehler großteils beseitigt
- neue Wünsche : Zapf.ev will Dropbox o.ä.
→ Mailingliste erstellen um dies zu besprechen
- Allgemein ist der Topf eher ein besprechendes Gremium als Handelndes
- “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 To-Do´s aufgeführt und besprochen was sonst noch zu tun ist und was verbessert werden kann.