Wer Stud.IP nutzt, kennt es: Ein neues Feature taucht auf, etwas funktioniert plötzlich komfortabler, eine Funktion ergänzt das System sinnvoll. Aber wie kommt es eigentlich dazu? Hinter jeder neuen Funktion steckt mehr als nur eine gute Idee – es ist ein Zusammenspiel aus Bedarf, Community, Diskussionen, Qualitätssicherung und vielen Arbeitsschritten, bis es schließlich produktiv wird. In diesem Beitrag schauen wir einmal genauer hin.
Neue Funktionen entstehen auf unterschiedlichste Weise. Manche entspringen konkreten Anforderungen aus dem Lehralltag, manche kommen aus Fachdiskussionen, andere durch technische Weiterentwicklungen. Ideen kommen von Lehrenden, Studierenden, Betreibenden, Entwickelnden oder auch Gremien. Häufig tauchen sie erst ganz unscheinbar auf: in Foren, auf Community-Treffen, in einem Issue im GitLab oder einfach im Gespräch zwischen Beteiligten.
Sobald eine Idee greifbar wird, geht sie nicht direkt in die Entwicklung, sondern zunächst in einen strukturierten Diskussionsprozess. Wer eine Verbesserung vorschlägt – idealerweise jemand mit technischer Erfahrung – fasst sie in einem sogenannten StEP (Stud.IP Enhancement Proposal) oder einem TIC (Tiny Improvement Commit) zusammen. Dieses Format sorgt dafür, dass nicht nur die technische Umsetzung beschrieben wird, sondern auch der konkrete Nutzen für das System, mögliche didaktische Einsatzszenarien und Aspekte der Nutzererfahrung betrachtet werden. Die Richtlinien für diese Beiträge sind öffentlich einsehbar unter:
https://docs.gitlab.studip.de/entwicklung/docs/rules/introduction
Einmal formuliert, wird der StEP oder TIC im Stud.IP GitLab als Issue eingereicht. Von dort wird der Vorschlag automatisch auf dem Stud.IP Developer Board veröffentlicht – einer Stud.IP-Instanz, die speziell der Weiterentwicklung von Stud.IP dient. Dort findet die eigentliche Diskussion statt: Mitglieder der Community – insbesondere die Core Group – lesen mit, kommentieren, fragen nach und bringen eigene Sichtweisen ein.
Diese offene Diskussion hilft dabei, die Idee aus verschiedenen Perspektiven zu beleuchten: Ist sie strategisch sinnvoll? Ist der geschätzte Entwicklungsaufwand realistisch? Passt sie zu den Grundprinzipien von Stud.IP? Gerade diese Phase sorgt oft dafür, dass Ideen noch einmal geschärft, umgedacht oder präzisiert werden.
Damit ein StEP tatsächlich Teil der nächsten Stud.IP-Version wird, muss er bestimmte Fristen einhalten. Vor jedem Release gibt es ein klares Zeitfenster für die Einreichung. Nach Ablauf dieser Frist prüft die Core Group alle eingereichten StEPs. Diese Gruppe besteht aus langjährigen Mitgliedern der Community, die sich aktiv für die strategische Weiterentwicklung und Qualitätssicherung von Stud.IP einsetzen.
Über jeden StEP wird abgestimmt – für eine Annahme ist eine Zweidrittelmehrheit der Core Group erforderlich. Erst dann startet die eigentliche Entwicklung. Die Entwickelnden arbeiten dabei nicht isoliert: Unterstützung gibt es über den Stud.IP Chat, das Developer Board Forum und durch spezialisierte Gremien wie z.B. die UI/UX-Gruppe.
Auch für den Entwicklungsprozess gibt es klare Deadlines. Die Arbeiten müssen rechtzeitig abgeschlossen sein, damit ausreichend Zeit bleibt, die verschiedenen Qualitätsmerkmale zu prüfen: saubere Code-Struktur, sinnvolle Nutzerführung, barrierefreie Gestaltung und eine verlässliche Funktionalität gehören zu den festen Standards.
Sind alle Prüfungen bestanden und verbleibende Mängel behoben, erfolgt der Einbau in das Main Repository. Abschließend wird die Gesamtheit der Änderungen nochmals gemeinsam betrachtet, kleinere Korrekturen werden vorgenommen – dann ist das neue Stud.IP-Feature bereit. Wann sie tatsächlich an den Hochschulen ankommt, hängt letztlich vom Update-Zyklus der jeweiligen Standorte ab.
Stud.IP entwickelt sich nicht durch Einzelentscheidungen, sondern durch die Kraft der Community. Die Wege von der Idee bis zum Feature-Release mögen manchmal länger sein, doch sie sorgen dafür, dass Funktionen durchdacht, nachhaltig und breit abgestimmt sind. Jeder kann sich einbringen – mit Ideen, Konzepten, Feedback oder Code. Denn am Ende lebt Open Source davon, dass viele Köpfe gemeinsam daran arbeiten, das System besser zu machen.
