1. Arbeitstreffen AUS aka Redmine

Die Verwendung von einen Aufgabenumsetzungssystem ist neu. Es müssen Erfahrungen und daraus resultierende Anforderungen her, um zweckmäßige Anpassungen vornehmen zu können. Das beginnt mit dem Artikulieren von Kritik, geht über Analyse und Konzeption und endet mit der technischen Realisierung.

Als Software haben wir (nach Gutdünken) Redmine verwendet. Redmine zeichnet sich durch seine Vielfältigkeit aus. Redmine kann sehr versiert konfiguriert werden.

Praktisch befindet sich das Aufgabenumsetzungssystem - insbesondere mit Redmine - in der Einführung. Demnach müssen und hoffentlich werden viele Perspektiven entdeckt werden. Um Aufwand und andere Widrigkeiten zu vermeiden soll die Funktionsweise von unserer Instanz weiterentwickelt werden. Ideen, die zu einer Verbesserung führen können, sind willkommen.

Es soll eine Sammlung von Überlegungen, Entscheidungen und Gründen entstehen.

Beschreibung der bestehenden Konfiguration

• Zuweisen von einem Issue an eine Gruppe ermöglicht
  • Abweichend von der Voreinstellung wurde diese Option angewählt.
  • Üblicher Weise werden Aufgaben erst einmal einer Funktion zugewiesen. Praktisch hat eine "Struktureinheit" den "schwarzen Peter" zugeschoben bekommen. Alle, die der Gruppe angehören um diese Funktion auszuüben, haben die Aufgabe "an der Backe". Wenn es nur eine Person gibt, die die Funktion inne hat, dann besteht "die Gruppe" aus einer Person. Es obliegt der Leitung, die ja ohnehin sich gesamtheitlich dafür verantwortlich fühlen sollte, ein Übergeben der Aufgabe an eine einzelne Person zu entscheiden und womöglich später wieder zu ändern.

• Kategorisieren von einem Issue ermöglicht
  • #70#note-1
  • Abweichend von der Voreinstellung wurde diese Option angewählt.
  • Voraussetzung ist selbstverständlich, dass beim jeweiligen Projekt mindestens eine Kategorie erstellt wurde. * Anscheinend werden Kategorien je Projekt erstellt.
  • Wie bei unserer Aufgabenverwaltung Kategorien genutzt werden ist noch nicht klar. (Vielleicht werden langfristig Unterprojekte mit Kategorien ersetzt.)

einzelne Accounts (als Administratorin oder) als Administrator

Es gibt einen allgemeinen Account admin (Redmine Admin). Er wurde bei der standardmäßigen Installation generiert. Im Übrigen hat daher der Account auch die Nummer 1.

Darüber hinaus sind folgende Accounts aus folgenden Gründen mit administrativen Berechtigungen "beworfen wurden":

• JohannBoxberger (Projekt Aufgabenumsetzungssystem; Einrichtung von der Instanz Redmine; Verwaltung von Accounts für den StuRa und andere)
• PaulRiegel (Installation von der Instanz Redmine; Projekt Aufgabenumsetzungssystem; Einrichtung von der Instanz Redmine; Verwaltung von Accounts für den StuRa und andere)
• GeorgPolte (Projekt Aufgabenumsetzungssystem; Einrichtung von der Instanz Redmine; Verwaltung von Accounts für den StuRa und andere)
• WolfgangWohanka (Erfahrungen zur Verwaltung einer Instanz Redmine (temporäres Redmine für das Projekt )ESE_); Verwaltung von Accounts für das Projekt faranto; Einrichtung vom Projekt faranto)
• TobiasEhrlich (Verwaltung von Accounts für das Projekt faranto; Einrichtung vom Projekt faranto)

Tracker

Die standardmäßigen 3 verschiedenen Tracker wurden auf eine einzige Art von Tracker "eingedampft". Zur Einführung von Aufgabenumsetzungssystem wird angenommen, dass allein ein einziges Szenario gibt, die Aufgabe. Das Unterscheiden, etwa hinsichtlich unterschiedlicher Arbeitsabläufe, schien nicht gegeben. Daher gibt es lediglich den Tracker Aufgabe.

Perspektivisch kann sich überlegt werden, ob es weitere Fälle gibt.
Theoretisch könnte bestimmt auch die Antrags- und Beschlussverwaltung auch im Redmine erledigt werden. Vielleicht wäre das sogar nennenswert einfacher als im Plone. Für dieses Szenario wäre sicherlich eine eigene Art von Tracker sinnvoll.
Praktisch muss (sollte) erst ein konkreter Bedarf bestehen, bevor ein weiteres weitere Art Tracker konzipiert und implementiert wird.

Es wurde ein neuer Status erstellt (Gesichtet) dieser soll den Referatsleitern ermöglichen Probleme als Wahrgenommen aber nicht in Bearbeitung zu kennzeichnen, dadurch wird ermöglicht das diese Aufgaben nicht mehr als Neu ( sozusagen unbeachtet) wahrgenommen wird.

bestehende Konfigurationen, die einfach so sind, weil sie so waren

siehe /enumerations usw.

Ideen zur Verbesserung der Konfiguration

Unterscheidung zwischen einmaligen und wiederkehrenden Aufgaben

Können Aufgaben automatisch generiert werden?

Einfaches Beispiel: (Auch wenn das wohl nicht so richtig sauber festgeschrieben ist:) Eigentlich soll (wohl quartalsweise) von den verschiedenen Stellen (im Sinne von Funktionen) Rechenschaft gegenüber dem StuRa - ferner der Studentinnen- und Studentenschaft abgelegt werden. (Es soll benannt werden was so passierte, also gemacht wurden, und was so wieso entschieden wurde.) Es wäre doch arg charmant, dass es immer passend ein Issue gibt. Also mit Beginn des Quartals ist ein Vorgang da, der das Erstellen und Abgeben eines Berichtet benennt.

Unterscheidung zwischen zeitweisen und permanenten Aufgaben

Es könnte überlegt werden, ob im Aufgabenumsetzungssystem auch ständige (also permanente) Aufgaben "verwaltet" werden.

Praktisch wäre das dann ja wie eine Art detailliertere Aufgabensammlung. Das hilft neuen Aktiven vielleicht sich besser zurecht zu finden. Das Übersehen von wichtigen Aufgaben, die das Amt (die Funktion) mit sich bringt, kann aus Unkenntnis weniger passieren. Das kann neuen Aktiven das Gefühl von Sicherheit vermitteln. Gar könnten schon "nur Interessierte" daran orientieren, ob sie überhaupt Lust auf solche Aufgaben haben. Also eine falsche Erwartungshaltung kann so vermieden werden.

Untergliederung in Projekte zurückbauen

Tut das Not, dass wir das arg in kleine Projekte untergliedern? Das muss doch so nicht, oder? Sollte das konzeptionell nicht anders gelöst werden (können)?

standardmäßiges Konstrukt Kategorien passend nutzen

Redmine bietet das Konstrukt Kategorien. Das findet aktuell keine Anwendung bei unserer Instanz, oder? Vermutlich würde uns das aber arg beim Verwalten helfen können. (Vielleicht können wir das arge Untergliedern in Projekte vermeiden.)

• Kann ein Issue auch mehrere Kategorien haben?
• Was bedeutet eine Kategorie projiziert auf den StuRa bzw. die einzelnen Projekte?

Jeder Kategorie kann ein Assignee zugeordnet werden.

Plugins:

Eine Liste ausarbeiten mit welchen Plugins man zukünftig arbeiten sollte um die Strukturierung, Arbeit im System zu vereinfachen bzw zu verbessern. Diese gefunden Plugins konfigurieren und evtl testen ?

Plugins welche vorgeschlagen wurden werden in einem Ticket aufgelistet. diese werden in einer Testversion ausgelotet und danach auf die original Version gelegt.

• mentions
• what u see is what u get
• markdown
• tags
• ldap