Eine erste Übersicht für die anzugehende Aufgabe »Projektportal«. Ein Portal für Projekte und Gruppen an der BTU.

Zusammenschluss von Studierenden um etwas für die Studierendenschaft (und sich selber) zu tun, wie zum Beispiel:

• Studentische Vertreter in Gremien (Senat, Fakultätsräte, Prüfungsausschüsse, Kommissionen),
• Gruppen die für Gremien o.ä. etwas ausarbeiten (z.B. die FüS-Gruppe),
• kulturelle Aktionen wie ZK-KASI (Koordination von Theater/Kino-Besuchen),
• integrative Projekte (z.B. die AAA/Wohnheimtutoren, DSH-Helfer),
• Interessensvertretungen/-verbände und
• vielleicht auch kleinere Party-Gruppen (warum nicht?).

Diese Gruppen sollten grundsätzlich offen für alle Studierenden sein, auch wenn es natürlich Schwerpunkte in den Zielgruppen gibt.

Die meisten dieser Projekte bzw. Gruppen sind viel kleiner als echte Vereine (eV) und durch die Themenorientierung teilweise auch sehr kurzlebig bzw. nur sporadisch aktiv. Das heißt, sie haben weder eigene Ressourcen noch Bedarf für eine eigenständige Webseite. Dementsprechend werden sie aber von potentiellen Helfern und Interessenten nicht gefunden.

Auch für die Gruppenarbeit ist es hilfreich, eine ganz kleine, einfach zu editierende Webseite zu haben. Vor allem Ausarbeitungen und Stellungnahmen verschickt man nicht gern an X unterschiedliche Personen per Email. Spätestens nach ein paar Monaten ist unklar, welches die nun die offizielle/aktuelle Version ist. Einarbeitung neuer Mitstreiter ist aufwändiger als notwendig, weil die interessanten Materialien erst zusammengesucht und verschickt werden müssen (aktuellste Version usw.).

Die Arbeit leidet darunter, dass man nur selten weiß, wer was macht und es ist zur Zeit schwierig, die richtigen Ansprechpartner für eigene Probleme oder Fragen zu finden. Es gibt StuRa-Referenten und Fachschaftsrätler die gerne Ansprechpartner sein wollen. Aber trotzdem muss die Information über die eigentlichen Ansprechpartner/Projekte irgendwo herkommen bevor sie an Anfragende weitergereicht werden kann. Und so hängt nun alles an dem Überblickswissen einiger weniger Personen - die schlimmstenfalls bald ihr Studium beenden. Im Allgemeinen kann davon ausgegangen werden, dass durch persönliche Interessensfilter viele Informationen verloren gehen.

Die Arbeit dieser kleinen Gruppen kann unmittelbar und effektiv mit einer allgemein zugänglichen, leicht editierbaren Webseite unterstützt werden. Im einfachsten Fall hat jede Gruppe/Projekt _eine_ Seite mit:

• Projektname (Name des Gremiums o.ä.),
• Zielstellungen/Aufgaben,
• Ansprechpartner und
• Links zu weiteren Informationen (z.B. richtige Webseite, falls vorhanden).

Nach Bedarf kann diese Seite auch um weitere Inhalte erweitert werden:

• Mitglieder der Gruppe und weitere Ansprechpartner, Rollenverteilung,
• Termine (Treffen, Deadlines)
• aktuelle Tätigkeiten und Stand der Arbeit,
• Mitteilungen, Berichte,
• angehängte Arbeitsdokumenten (PDF, Word/ODF, …),
• Diskussionen/Argumente bzw. Links auf entsprechende Threads im BTU-Forum…

Ein sehr nützlicher Nebeneffekt ist, dass so eine zentrale Übersicht über bestehende Projekte und engagierte Studierende entsteht. Thematische Übersichtsseiten können schnell den Weg zu entsprechenden Projekten (oder deren Nichtexistenz) leiten.

Zum Beispiel mit einem Wiki, wie bei Wikipedia oder der IMT-Fachschafts-Seite.

• flexible Authentifizierung
• Emailabos, bzw. RSS-Feeds: wichtig für Seiten, die selten editiert werden, da dann selten aktiv nachgeschaut wird
• Zugriffsschutz: Seiten vor dem Editieren schützen, Dokumente nur Campus- bzw. Gruppenintern lesbar machen

• einfache Syntax: schneller Erfolg für Neulinge, bzw. Wenignutzer
• leichte Wartbarkeit des Gesamtsystems, gute Softwarearchitektur: Projekt muss an andere übergeben werden und weitergeführt werden können; mehr als eine Person muss das System überschauen können
• schlichtes Design wie hier

• simple Activities/Tasks (Aufgaben, Zuweisung, Stand in %)
• simpler Terminkalender (chronologische Auflistung als Kalenderblatt dargestellt)
• Suchfunktion
• Tagging: thematisches markieren von Projektseiten durch die Benutzer/Leser, Tag-Cloud, Suche nach Tags

Missbrauch öffentlich editierbarer Seiten ist nach unseren Erfahrungen ein seltenes und relativ leicht behebbares Problem. Sollte es dennoch Probleme geben, gibt es eine Rehe möglicher Gegenmaßnahmen:

• nur registrierte Benutzer dürfen editieren
• Registrierung nur mit einer Uni-Email-Adresse, und dadurch keine Anonymität
• Schutz vor automatischen Programmen durch Bild→Text Überprüfung (CAPTCHA?)

Folgende Software sollte in die Diskussion einbezogen werden. Wenn alle Anforderungen gesammelt sind, kann man diese dann vergleichen. Eine erste Quelle ist die WikiMatrix.

• http://wiki.splitbrain.org/wiki:dokuwiki
• WikiMatrix>DokuWiki
• PHP
• Datei-basiert
• sehr viel lokale Erfahrung
• bessere Softwarearchitektur als PmWiki
• Caching von gerenderten Webseiten und kompaktierten CSS-Dateien
• sehr leichte Erstellung neuer Seiten-Designs

Nachteile:

• Dateirechte auf dem Server schlecht steuerbar
• verlinkt auf PHP-Scripte in Unterverzeichnissen (z.B. bin/indexer.php u.a.) ⇒ Funktioniert nicht im Safemode wenn nur Zugriff auf Dateien unterhalb des Start-Scripts erlaubt ist.
• Kein Zugriffsschutz für Datei-Uploads ??? doch, siehe »hochladen« unter Zugangsrechten
• Zugriffsschutz nur von Administratoren einstellbar? Einstellrechte an Gruppen übertragbar
• Viele Plugins sind noch nicht aktualisiert keine API-Änderungen in den letzten 2 Versionen
• langsam wenn viele Plugins benutzt(???)

• http://pmwiki.org/
• WikiMatrix>PmWiki
• Konflikt-Auflösung
• Dateibasiert, aber mir MySQL soll auch gehen
• AccessControll mit Passwörtern auf Seiten-/Gruppen-Basis oder Sitzungen mit Benutzername+Passwort, siehe http://www.pmwiki.org/wiki/PmWiki/Passwords und http://www.pmwiki.org/wiki/PmWiki/AuthUser
• Anhänge können geschützt werden (eingeschränkter Lese-Zugriff), siehe http://www.pmwiki.org/wiki/Cookbook/SecureAttachments
• nur genau ein Einstiegspunkt (pmwiki.php) und keine Scripte in Unterverzeichnissen ⇒ weniger Probleme mit PHP-Safemode

Nachteile

• Dateirechte auf dem Server schlecht steuerbar
• Seitendesign ist schwerer erweiterbar, da kein PHP Script sondern Template-Engine
• kein Caching?

• http://www.twiki.org/
• WikiMatrix>TWiki
• Datei-basiert
• sehr viele Plugins für Gruppenarbeit
• scheint schnell zu sein?
• nette Datei-Anhänge (auch mit Zugriffsschutz)
• Zugriffsschutz lokal konfigurierbar (im Seitentext)

Nachteile:

• Aufwendige Konfiguration ⇒ viel Arbeit bis zur Sicherheit
• Perl

• TikiWiki
• WikiMatrix>TikiWiki
• PHP
• MySQL o.ä. Datenbanken

Nachteile:

• starre Struktur, sieht mehr wie ein CMS aus
• wenig Erfahrung
• File-Upload/Download mehr wie ein Dateibrowser, verlinken durch kopieren der kompletten HTTP-Adresse

• Trac
• kann direkt mit SVN verbunden werden, so dass offene Bugs, Tickets, FeatureRequests im Wiki angezeigt werden koennen
• fuer laengerfriste Projekte gut geeignet

Nachteile:

• bisher nicht bekannt

• Betreuer (1-4 Personen)
• Server
• Internetverbindung
• Web-Adresse

Eine Kooperation mit dem BTU-Forum ist sinnvoll, da es auch ein Musterbeispiel ist, wie solche Dienstleistungen von Studenten angeboten und betreut werden können.

Der StuRa kann eine wichtige Rolle in der moralischen und finanziellen Unterstützung spielen. Dieses Meta-Projekt kann eigentlich keiner einzelnen Fakultät oder Fachschaft zugerechnet werden. Da die meisten Nutzer auf dem Campus sind, ist es ökonomisch sinnvoll die Hardware auch auf dem Campus zu belassen. Dann braucht es allerdings einen Verhandlungspartner gegenüber dem RZ, oder?

Zielgruppe sind zuallererst die Studierenden. Falls wider erwarten Professoren gefallen daran finden und das auch nutzen wollen, kann man überlegen wie das Wissen ins IKMZ exportiert oder der Benutzerkreis erweitert werden kann.

Ziel ist in erster Linie die Vorstellung von Projekten, studentischen Arbeitsgruppen und Gremienmitgliedern. Dies soll den Überblick und die Suche nach solchen Gruppen verbessern.

Wenn die technischen Voraussetzungen es erlauben spricht nichts dagegen, dass die Gruppen die Seiten für die Veröffentlichung und den Austausch von (hauptsächlich öffentlichen) Dokumenten benutzen. Dies würde die Kommunikation innerhalb der BTU vereinfachen und beschleunigen.

Natürlich kann alles misbraucht werden. Aber die Betreiber/Moderatoren sind nicht wehrlos: Schreibrechte können auf registrierte Benutzer eingeschränkt werden, wie beim BTU-Forum. Zusätzlich kann die Angabe einer Uni-Mail-Addresse verlangt werden. Dann beschränkt sich der Nutzerkreis auf die Uni-Angehörigen und bei Missbrauch ist der Übeltäter direkt bekannt und kann von der Nutzung ausgeschlossen werden.

Zweckentfremdung ist ein schwierigeres Thema. Das ist in diesem Fall mehr eine Art Fokusverlust und es wird im Ermessen der Moderatoren liegen, nicht ganz passenden Projekten/Gruppen die Tür zu weisen.

Technischer Aufbau/Wartung:

• Kenntnisse in Serveradministration, Sicherheit
• Installation und Konfiguration des Wikis und Erweiterungen
• in der Anfangsphase Test und Vergleich verschieder Varianten
• Backup und Wiederherstellung
• ev. Vertragsverlängerungen (Rechner, Netzwerk, Firewall)

Technischer Support:

• Anleitung wie man es Benutzt, Beantworten von Fragen. (Anleitungen sind eigentlich schon vorhanden.)
• Richtlinien zur Benutzung dokumentieren. Empfohlene Seitenstruktur und wie bestimmte Aufgaben umgesetz werden sollen.

Moderation/Zensur der Inhalte:

• Änderungen (Email-Benachrichtigungen oder RSS-Feeds), stichprobenartig lesen und schauen, ob es zu den Benutzungsrichtlinien passt.
• Beschwerden nachgehen.

Gute Frage. Ca. 3 Studenten sollten reichen. Anfangs ist vor allem der technische Aufbau kernbeschäftigungsfeld, dann Richtlinien und Benutzer-Doku, später eigentlich fast nur noch Moderation/Überwachung.

Hängt von der Umsetzung ab. Man braucht einen Rechner, einen Standort für denselbigen, eine Internetverbindung und eine Webaddresse(URL). Letztere zwei bekommt man von der Uni kostenneutral wenn die Hardware auf dem Campus bleibt. Bleibt also die Hardware. Wie stark die sein sollte muss ausprobiert werden. Anfangs können es vielleicht auch ältere Labor-Rechner machen. Stromkosten?

1. Techniker finden
2. Technik ausprobieren, Regelmäßige Treffen (z.B. wöchentlich), Dokumentationen lesen, testen
3. Serverstandort finden
4. finalen Server einrichten
5. Benutzer-Dokumentation, Beispielinhalte
6. Werbung
7. Moderation und Benutzer-Support

Wenn sie solch einen Dienst sinnvoll finden, können sie ja selber überlegen inwiefern sie helfen können und dafür sorgen, dass es Realität wird. Offensichtlich geht fast alles auch ohne StuRa und Fachschaftsräte.

Ersteres macht technisch wahrscheinlich mehr Aufwand als Sinn. Verlinken und Benutzen wäre sehr nett. Wenn die Seiten nicht mehr ganz leer sind, wäre eine kleine Informationskampagne angebracht.