Archiv der Kategorie: Philosophie

Grundsätzliches zur Stud.IP-Philosophie und Visionäres

Die Stud.IP-Philosophie

Seit Beginn der CoreGroup gibt es die Stud.IP-Philosophie. Stud.IP wird entlang dieser Grundsätze entwickelt, und das seit mehr als 10 Jahren. Die Philosphie ist mehr als ein Lippenbekenntnis. Sie ist der moralische Kompass des Projekt, auf den bei Diskussionen und Entwicklungen immer wieder geschaut wird. Sie ist wichtig, und deshalb muss sie auch immer wieder mal hier im Blog aufgegriffen werden.

Zu jedem Punkt hat Tobias Thelen in einem eigenen Beitrag genauer beschrieben was dahintersteckt (Link am Ende des Absatzes).

Stud.IP-Philosophie

1. Ein offenes kommunikatives System für alle.
Stud.IP-Nutzer sind nicht allein in den Weiten des Netzes, sondern haben die Möglichkeit, sich im Austausch mit anderen einzubringen. Dazu stellt Stud.IP verschiedene Kommunikationswege bereit, die unterschiedlichen Nutzungsszenarien und Erwartungen gerecht werden. Aktivität steht gegenüber passiver Informationsaufnahme im Vordergrund. Alle NutzerInnen haben die gleichen Grundfunktionen und werden gleichrangig behandelt. Link

2. Studierende ernst nehmen.
Studierende sind in Stud.IP keine verwalteten, beobachteten und beaufsichtigten Objekte, sondern die wichtigste Gruppe, die aktiv, eigenverantwortlich und kreativ das „Leben“ im System bestimmt. Deshalb heißen Studierende in Stud.IP „AutorInnen“: Sie verfassen Diskussionsbeiträge, stellen Dateien und Lernmodule zur Verfügung und können wie Lehrende auch Informationen über sich selbst frei und flexibel veröffentlichen. Link

3. Attraktive und konsistente Benutzeroberfläche.
Einfache Benutzbarkeit und ein ausgewogenes, durchdachtes Design stehen über der Möglichkeit, jeder Veranstaltung ein individuelles Gesicht zu geben. Eine konsistente Bedienung des Systems sorgt dafür, dass Inhalte vor Gestaltung und Finden vor Suchen stehen. Bedienung, Funktionsumfang und Design bilden dabei jedoch nicht drei „konkurrierende“ Pole, sondern bedingen und unterstützen einander. Link

4. Orientierung an den Strukturen deutscher Hochschulen.
Stud.IP ist dafür ausgelegt, große Mengen von Veranstaltungen gesamter Hochschulen beherbergen zu können. Deshalb bilden bewährte Kategorisierungen die Grundlage der Organisation und Rechtestruktur und erleichtern die Orientierung in großen Datenbeständen: Fakultäten und Fächer, Studiengänge und Studienbereiche sowie Semester werden in Stud.IP 1:1 abgebildet. Durch die ständige Weiterentwicklung durch viele Einrichtungen, die Stud.IP bereits einsetzen, entwickelt sich das System gemeinsam mit den Hochschulen und nicht entkoppelt von diesen. Link

5. Dezentrale Erfassung und Pflege von Daten.

Nur wenn Informationen auch dort verändert werden, wo sie anfallen, kann ein aktuelles und zuverlässiges Informationssystem entstehen. Die Erfassung und Pflege von Daten erfolgt daher so dezentral wie möglich und so zentral wie nötig: jede NutzerIn pflegt ihre persönlichen Daten, Lehrende betreuen ihre Veranstaltungen, FachbereichsadministratorInnen verwalten die Mitarbeiterlisten ihrer Einrichtungen, eine RaumadministratorIn vergibt von allen genutzte Räume. Zentrale Eingriffe und Beschränkungen durch AdministratorInnen geschehen transparent, d.h. Nutzer werden über Veränderungen ihrer Daten informiert und können jederzeit einsehen, was über sie gespeichert ist. Link

6. Unterstützung für alle statt Spezialfeatures für wenige.
NutzerInnen mit technischem Know-How und ambitionierten Sonderwünschen brauchen Stud.IP weniger dringend als Studierende und Lehrende mit Berührungsängsten oder wenig Lust und Zeit zur Einarbeitung in komplexe Abläufe. Stud.IP richet sich vor allem an NutzerInnen, die von der Technik eine grundlegende, einfach nutzbare und überschaubare Unterstützung ihrer inhaltlichen Arbeit erwarten. Deshalb soll nur behutsam von der Möglichkeit Gebrauch gemacht werden, beispielsweise aufwendige Content-Projekte mit Stud.IP zu koppeln. Link

7. Geringstmögliche technische Anforderungen für Nutzer/-innen.
Stud.IP erfordert neben einem Internetzugang und einem Webbrowser keine besonderen technischen Voraussetzungen. Das System ist mit jedem aktuell verbreiteten Browser nutzbar, Javascript und besondere Plugins werden für die Grundfunktionen des Systems nicht benötigt. Link

Heartbleed oder die Open-Source-Frage

Ganz große Aufregung dieser Tage: Der Softwarefehler, der unter dem Codenamen „Heartbleed“ bekannt wurde. Er sitzt im Programmcode von OpenSSL, das zum Aufbau einer verschlüsselten Verbindung mit einem Server genutzt wird. Durch die Lücke lassen sich bei geschickter Ausnutzung Infos vom Server abrufen, die der niemals preisgeben sollte, z.B. Passwörter anderer Nutzer. Das ist richtig schlimm, weil OpenSSL in sehr, sehr vielen Servern eingesetzt wird. Keine Ahnung warum die Tagesschau nur von „600 betroffenen Webseiten“ fabuliert, vermutlich war bei denen die Tinte des Agenturfax verschmiert, denn die Anzahl der betroffenen Seiten liegt weitaus höher. Tatsächlich muss jetzt bei jedem betroffenen Server eine Fehlerbehebung durchgeführt werden, dann sollte das Serverzertifikat getauscht werden, und eigentlich muss auch jeder Mensch all seine Passwörter in allen Onlinesystemen ändern. So schlimm ist es.

Was das Ganze mit Stud.IP zu tun hat? Nun, Stud.IP ist Open Source-Software, genau wie OpenSSL. Das bedeutet, dass die Software benutzt, verändert und weitergegeben werden darf, ohne das jemals Lizenzkosten anfallen. Außerdem kann man den Quellcode ansehen und ändern (wenn man programmieren kann). Das Gegenteil von Open Source ist proprietäre Software. Bei der Art darf man nicht in den Quellcode sehen, und die Benutzung der Software kostet meist Geld in Form von Lizenzen.

Im Zuge der „Heartbleed“-Berichterstattung gibt es nun Kommentare, dass man Open-Source-Software jetzt aber mal professionalisieren sollte, damit solche schlimmen Fehler nicht passieren. Man bräuchte dringend Vollzeitentwickler und vor allem Manager, fordert z.B. ein Kommentar in der ZEIT.

Mich ärgert diese Forderung, weil sie die Vorhut eines erneuten Angriffs auf das Open-Source-Entwicklungsmodell darstellt. Der Kampf proprietäre Software vs. Open Source läuft seit Jahren, und die Argumente sind immer die gleichen. „Proprietäre Software ist sicherer als Open Source-Software“, ist meist das Hauptargument, und das falscheste überhaupt. Denn bei der Open-Source-Entwicklung gucken viele Personen über den Code eines Entwicklers, stellen Fragen und bügeln Fehler aus. Das geht, weil alle an den Code rankommen. Bei proprietärer Software ist der unter Verschluss.

Noch etwas anderes ist entscheidend, und das hat Fefe in seinem Blog schön zusammengefasst:

Open Source als Bewegung ist das Konzept, dass man Leute Code schreiben lässt, deren Herzensblut dranhängt. Die es eben nicht kurz herunterpfuschen, weil sie dafür bezahlt werden. Open Source ist die Beobachtung, dass manche Menschen es lieben, Code zu schreiben. Und wenn man sie nicht mit Deadlines und Deliverables und dem monatlichen Paycheck unter Druck setzt, dann nehmen sie sich die Zeit und machen ihr Projekt ordentlich. Viel ordentlicher jedenfalls als die durchschnittliche kommerzielle Software.

(Quelle)

Kernaussage: Open Source-Entwicklung gibt einem auch nicht-monetäre Belohnung. Wenn man Open-Source-Projekte anfängt wie Wirtschaftsunternehmen zu führen, wird das Geld einen Druck erzeugen, der zu betriebswirtschaftlichen Optimierungen und dadurch zu sinkender Qualität führt.

Tatsächlich ist es bei Stud.IP so, dass wir gute Erfahrungen mit einer Firma im Open-Source-Modell gemacht haben. Data-quest bringt professionelles know-how in die Entwicklung mit ein und ist Teil der Entwicklercommunity. Auf dieses feine Detail muss man aber Wert legen: Wir sind TEIL der Community, wir managen das Projekt nicht. Für die Stud.IP-Entwickler bei data-quest ist das eine komfortable Situation: Sie tun etwas, an dem ihr Herzblut hängt und was sie gerne machen und werden dafür sogar noch bezahlt*. Das ist oft ein Spagat, aber es funktioniert, weil uns was an dem liegt was wir tun.

Der Punkt ist aber: Stud.IP funktioniert, weil viele Leute daran mitarbeiten, und dabei viel freiwillig investieren und sich Mühe geben, dass, was sie machen, so gut wpie möglich zu tun. Stud.IP ist mehr als lieblos runterprogrammierter Code, und das trifft auf fast jedes Open Source-Projekt zu. Das ist aber nur der Anfang. Alles was bei Stud.IP getan wird, wird anschliessend so genau wie möglich geprüft. Bevor eine neue Funktion im Release landet, muss sie durch Abstimmungs- und Reviewprozesse, Tests und Codeaudits. Dafür hat die CoreGroup eigene Regularien aufgestellt. Natürlich wäre es wünschenswert, wenn die daran beteiligten Personen mehr Zeit für diese Arbeiten aufbringen könnten oder der Personenkreis größer wäre. Und es ist nicht so, als wenn unser kleines Projekt keine Unterstützung in monetärer Form brauchen könnte. Dafür gibt es den Stud.IP Verein, der mit relativ wenigen Mitteln (eben aus Spenden und Mitgliedsbeiträgen) viel Gutes macht. Aber der Umbau eines Open Source-Projekts in ein Unternehmen ist da genau der verkehrte Weg, das funktioniert nicht.

Open Source-Software ist nicht unsicherer als propritäre Software. Das Gegenteil ist der Fall, und daran sollte sich jeder erinnern, wenn demnächst die ersten Rufe laut werden, dass Open-Source-Projekte entweder wie Unternehmen geführt werden oder gleich verstaatlicht werden sollten.

________________________
* Übrigens: Es sind noch Stellen frei.

#7 Geringstmögliche technische Anforderungen für NutzerInnen.

Ich durfte längere Zeit mit einer Web-Anwendung arbeiten, die ein komplexes Zusammenspiel aus Javascript, Real-Player und SVG-Plugin realisiert hat, um wirklich tolle Dinge zu leisten. Oder sagen wir bessern: Hätte dürfen. Wenn mich die permanenten Plugin-Download-Aufforderungen, Plugin-Versionsproblem-Meldungen und Browserinkompatibilitäten nicht hartnäckig davon abgehalten hätten. Ich hatte den Eindruck, dass eine der Komponenten immer veraltet war, egal, wann ich das System genutzt habe.

Prinzipiell lässt sich auch als Web-Anwendung fast alles realisieren, was man sich erträumen könnte. Insbesondere für die Entwickler ist es einfacher, sich dabei auf mehr als HTML stützen zu können. Oder exotische Browser außen vor zu lassen. Aktuelle Versionen von jedem und allem zu fordern.

Aber wie sieht das bei den NutzerInnen aus? Jedes zu installierende Plugin, jede Browser-Einschränkung schafft Hürden. Stud.IP ist ein Informations- und Kommunikationssystem, das mit ganz unterschiedlichen Voraussetzungen genutzt wird. Zum Beispiel von einem beliebigen Rechner unterwegs. Da lassen sich keine Plugins installieren. Sollte man deshalb jemanden davon ausschließen, sich für eine Veranstaltung anzumelden?

Deshalb lautet der siebte und letzte Punkt der Stud.IP-Philosophie:

Stud.IP erfordert neben einem Internetzugang und einem Webbrowser keine besonderen technischen Voraussetzungen. Das System ist mit jedem aktuell verbreiteten Browser nutzbar, Javascript und besondere Plugins werden für die Grundfunktionen des Systems nicht benötigt.

Wir nehmen das ernst. Wirklich. Stud.IP lässt sich auch mit Urlaut-Netscapes der Versionen 4.7 (Baujahr 1999) bedienen. Nicht perfekt und manches sieht etwas unschön aus. Aber es funktioniert. Wer jetzt gähnt, laut „Web 2.0!“ schreit und sich fragt, wer denn sowas Prähistorisches noch benutzt, dem sei gesagt: Wir finden häufig Sekretariatsrechner, die seit der Jahrtausendwende kein Browserupdate mehr gesehen haben.

Derart alte Browser sind aber nicht der Hauptgrund für die geringen technischen Anforderungen. Beispiel Javascript: Wir wollen weder NutzerInnen mit wenig verbreiteten Browsern aussperren, noch die, die aus Sicherheitsbedenken Javascript abgeschaltet lassen wollen. Darum funktioniert Stud.IP auch ohne Javascript. Etwas unbequemer, aber es tut alles Notwendige. Jetzt zeigt der „Web-2.0!“-Rufer wieder auf. Modernes Web heißt doch Ajax und Drag und Drop und volldynamisch und das ganze eben wie eine Desktopanwendung. Das geht nicht ohne Javascript. Wer darauf verzichtet, baut altbackene, langweilige Sachen.

Das mag stimmen, ein bisschen. Deshalb gibt es ab Version 1.6 auch Ajax-Effekte in Stud.IP. Und eine verbindliche Regelung für den Umgang mit Ajax, die als StEP101 beschlossen wurde. Darin heißt es: „Das System muss weiterhin auch ohne Java-Script vollständig bedienbar bleiben.“ Das heißt: Tolle Web-2.0-Effekte — Ja. Aber: Es muss immer noch einen Weg ohne geben. Der kann etwas umständlicher sein, aber – auch wenn das für die Entwickler doppelten Aufwand bedeutet – ohne geht es nicht.

Für Plugins gelten diese harten Auflagen übrigens nicht zwangsläufig. Überlegen Sie deshalb als Betreiber gut, ob Sie Ihren NutzerInnen mit installierten Plugins Steine in den Weg legen, die der Einsatzzweck nicht rechtfertigt.

Dieser Beitrag ist eine Fortsetzung zu #6 Unterstützung für alle statt Spezialfeatures für wenige.

#6 Unterstützung für alle statt Spezialfeatures für wenige.

Der Tumbau zu Babel
Nicht verwirren, sondern klare Wege anbieten!

»Das Zeugsein des Zeugs besteht in seiner Dienlichkeit. Aber wie steht es mit dieser selbst? Müssen wir nicht das dienliche Zeug in seinem Dienst aufsuchen?« (Heidegger)

In seiner ebenso informativen wie amüsanten Reihe zu den Stud.IP-Anfängen erläutert Cornelis sehr schön, was zum einen Triebfeder der Entwicklung war und zum anderen heute noch Hauptunterschied zu anderen Plattformen ist: Stud.IP ist nicht von der Theorie komplexer E-Learning-Szenarien her gedacht, sondern vom »normalen« Nutzer, der in der »traditionellen« Präsenzlehre deutscher Universitäten zu Hause ist und elektronische Unterstützung sucht.

Das heißt: Stud.IP geht nicht von umfassend medienerfahrenen Nutzern aus, für die ein Mehr an Gestaltungs- und Konfigurationsmöglichkeiten, ein Mehr an unterstützten didaktischen Szenarien, ein Mehr an fein abgestuften Varianten automatisch ein Gewinn an persönlicher Freiheit und Entfaltungsmöglichkeiten ist. Sondern: Stud.IP unterstützt besonders denjenigen, der sich langsam herantasten will an etwas Neues, der dankbar ist, wenn ihm eine Umgebung angeboten wird, die bereits so eingerichtet ist, dass er vertraute Begriffe wiederfindet und die Möglichkeiten und Funktionen nicht für jede Veranstaltung neu suchen und einrichten muss, sondern sich schnell und sicher zurechtfindet.

Deshalb lautet der sechste Punkt der Stud.IP-Philosophie:

NutzerInnen mit technischem Know-How und ambitionierten Sonderwünschen brauchen Stud.IP weniger dringend als Studierende und Lehrende mit Berührungsängsten oder wenig Lust und Zeit zur Einarbeitung in komplexe Abläufe. Stud.IP richet sich vor allem an NutzerInnen, die von der Technik eine grundlegende, einfach nutzbare und überschaubare Unterstützung ihrer inhaltlichen Arbeit erwarten. Deshalb soll nur behutsam von der Möglichkeit Gebrauch gemacht werden, beispielsweise aufwendige Content-Projekte mit Stud.IP zu koppeln.

Wir halten diesen Punkt für einen weiteren wesentlichen Baustein des Stud.IP-Erfolges. E-Learning-Spezialwerkzeuge für E-Learning-Spezialisten gibt es viele. E-Learning-Basiswerkzeuge für erfahrene Praktiker in der Präsenzlehre nur wenige.

Doch die Zeit steht nicht still und die Stud.IP-Entwicklung ebensowenig. Musste man vor zehn, fünf oder auch nur drei Jahren noch davon ausgehen, dass normale Lehrende und Studierende unserer Hochschulen wenig Erfahrung im Umgang mit Online-Medien verfügen und daher auch nur wenige Sonderwünsche konkret formulieren können, hat sich das Bild inzwischen etwas gewandelt. Zum Teil auch dank Stud.IP, denn an den Hochschulen, die das System seit längerem einsetzen, ist die Basisunterstützung und -nutzung selbstverständlich geworden. Der Blick der Nutzer weitet sich und die Wünsche werden spezieller. Hinzu kommt der derzeitige Trend zur Systemintegration. Die Anforderung, Stud.IP mit den vor Ort betriebenen Systemen X, Y und Z zu koppeln, gehört zum Standardanforderungskatalog neu hinzukommender Betreiber.

Dieser sechste Punkt der Stud.IP-Philosophie ist zweifelsohne der, gegen den die Entwickler in der Vergangenheit in gewisser Weise am häufigsten verstoßen haben. Zu leicht landen Features im System, die für einen Standort oder eine bestimmte Nutzergruppe genau richtig und perfekt angepasst sind, anderen aber nur zum Teil schmecken. Diesem prinzipiellen Problem begegnen wir auf zwei Weisen:

Eine Plugin-Schnittstelle erlaubt es, beliebig spezialisierten Code zu produzieren, der nicht zur Stud.IP-Grundausstattung gehört, aber von den Betreibern vor Ort einfach hinzugeladen werden kann. Unter http://plugins.studip.de findet sich eine stetig wachsende Liste veröffentlichter Plugins. Wer die einsetzt muss sich darüber im Klaren sein, dass dort nicht alle Punkte der Stud.IP-Philosophie in gleichem Maße gelten und die Lösungen häufig spezifische Fälle abdecken, die nicht mit den eigenen übereinstimmen. Aber dort wie sonst auch gilt: Die Entwickler sind nur eine handvoll Klicks entfernt und helfen gern und schnell.

Die zweite Möglichkeit, speziellere individuelle Ansprüche an Stud.IP als E-Learning-System erfüllen zu können, besteht in der so genannten E-Learning-Schnittstelle. Mit ILIAS und PmWiki lassen sich zwei Systeme, die multimedial aufbereitete E-Learning-Inhalte samt Autorenumgebung vorhalten können, direkt an Stud.IP anbinden. Zwar findet ein gewisser Bruch statt, das Layout ist nicht identisch, ein neues Fenster öffnet sich, aber damit auch beliebige Gestaltungsoptionen. Spezielle vorgefertige Skins und Templates mildern den Bruch ab und das wichtigste: Alle Fragen der Nutzerauthentifizierung und -authorisierung werden unsichtbar im Hintergrund erledigt.

Mit diesen beiden Optionen wird Stud.IP auch für Sonderanforderungen, Spezialanwendungen und ganz individuelle E-Learning-Szenarien zur Schaltstelle und Drehscheibe. Denn das wird von allen Nutzern an »Stud.IP-Hochschulen« immer wieder als der alles schlagende Vorteil genannt: Endlich alles an einem Platz, endlich alles einheitlich geregelt, endlich alles verständlich und sauber immer und von überall zugänglich.

#5 Dezentrale Erfassung und Pflege von Daten

Das Recht auf freie Meinungsäußerung hat den Nachteil, dass mitunter auch Widersprüchliches, Falsches, Dummes oder gar Beleidigendes oder Bösartiges gesagt wird. Wenn wir aber alles in allem nehmen, sind wir doch eher bereit, uns damit abzufinden, als dieses Recht abzuschaffen. Mehr noch: Wir verteidigen es als wichtigtige Errungenschaft und erziehen unsere Kinder dazu, sich in einer Welt vielfältiger Meinungen zurechtzufinden.

Die freie Meinungsäußerung in Stud.IP findet ihren Platz an vielen Stellen: In Foren und Wikis, im Chat und auf den persönlichen Homepages. Unter dem Schlagwort »Studierende ernst nehmen« hat sich bereits der zweite Satz der Stud.IP-Philosophie mit dieser Art von Freiheit befasst. Weitergesponnen verlangt der rote Faden durch Stud.IP – nämlich jedem Nutzer selbst Freiheit zu lassen und jeden Nutzer selbst in die Verantwortung zu nehmen – nach Freiheit und Selbstverantwortung auch für andere Informationen, die nicht individuelle Meinung sind, sondern eher offiziellen Charakter haben.

Die Wikipedia macht es vor: Seriöse und verlässliche Informationen können auch dann entstehen, wenn jeder, der glaubt zu wissen, auf reden darf und Kontrolle eher von unten statt von oben ausgeübt wird. Eric Raymonds The Cathedral and the Bazaar argumentiert für die Softwareentwicklung, dass viele kleine Standbetreiber etwas Verlässlicheres zustande bringen können, als ein über allem thronender Baumeister. Für Informationen in Stud.IP heißt das: Lasst diejenigen Veranstaltungsdaten, Sprechstundentermine und akademische Titel eintragen, die es am besten wissen, also Dozenten und Sekretariate anstelle zentral bestellter Administratoren. Auch auf die Gefahr hin, dass mitunter Uneinheitliches, Halboffizielles oder Anmaßendes erscheint. Die Administratoren kann es trotzdem geben, und sie können eingreifen wenn nötig – aber sie sind nicht das Nadelöhr, durch die jede Information vor ihrer Veröffentlichung (und das hießt dann oft: kurz nach dem Verfallsdatum) gehen muss. Und so heißt es im fünften Punkt der Stud.IP-Philosophie:

5. Dezentrale Erfassung und Pflege von Daten.

Nur wenn Informationen auch dort verändert werden, wo sie anfallen, kann ein aktuelles und zuverlässiges Informationssystem entstehen. Die Erfassung und Pflege von Daten erfolgt daher so dezentral wie möglich und so zentral wie nötig: jede NutzerIn pflegt ihre persönlichen Daten, Lehrende betreuen ihre Veranstaltungen, FachbereichsadministratorInnen verwalten die Mitarbeiterlisten ihrer Einrichtungen, eine RaumadministratorIn vergibt von allen genutzte Räume. Zentrale Eingriffe und Beschränkungen durch AdministratorInnen geschehen transparent, d.h. Nutzer werden über Veränderungen ihrer Daten informiert und können jederzeit einsehen, was über sie gespeichert ist.

Wenn ein solches Modell eingeführt wird, sind Ängste da: Dass jemand für Fehler verantwortlich gemacht wird, die nicht in seinem Einflussbereich liegen. Dass renitente Professoren versuchen, Absprachen und Regelungen zu umgehen. Dass Studierende sich Titel anmaßen und Verwirrung stiften. An der Universität Osnabrück beginnt gerade das achte Semester nach der Umstellung vom Kathedralen- auf das Basar-Modell. Das Ergebnis: Ja, es gibt Fehler, es gibt Ungereimtheiten, es gibt Einzelne, die sich freuen, Extrawürste nicht nur braten, sondern auch an den Mann bringen zu dürfen. Aber es gibt auch: Frühere Ungereimtheiten, die plötzlich auffallen, weil Informationen für jeden sichtbar sind. Oder das Gefühl von eigener Verantwortung, weil die Studierenden jetzt beim Dozenten selbst nachfragen, warum die Informationen nicht da sind, wo sie sein sollten. Und: Fehler und Unstimmiges gab es früher auch, denn die verlässliche, immeraktuelle und konsensfindende zentrale Verwaltung von Daten kostet viel mehr, als sich eine Universität leisten kann oder sollte.

Dieser Beitrag ist eine Fortsetzung zu: #4 Orientierung an den Strukturen deutscher Hochschulen