StuRa Diskussion:Aufgabenumsetzungssystem

Warum roundup?

ganz einfach:

It's like Bugzilla without the six years of training, or RT without that tedious MySQL rubbish.
It's just Python 2.1, a BSD-style DB, a cgi-bin script, some command line utilities, and a mail
forward. Full admin over the Web or e-mail, not very scaleable but eminently hackable.
Just like your life.

[1] JohannesSchneemann 12:42, 3. Okt 2011 (CEST)

FAQ

How to use Redmine (oder in Deutsch für English for dummies: Wie nutzt man das Ticketsystem Redmine?):

Q: Was sind Projekte in Redmine?

A: Projekte im Redmine Gliedern sich in zwei Kategorie

1. Projekt - Dies sind alle Projekte auf der ersten Ebene von diesen zweigen sich Unterprojekte ab.
2. Unterprojekt - Dies sind Projekte auf der zweiten bis letzten Ebene. Bedeutet Von Unterprojekten zweigen auch immer Unterprojekte ab.

Das Projekt im Ticketsystem des StuRa HTW Dresden ist "Studentinnen- und Studentenrat" von dem gehen die ersten Unterprojekte "Ausschüsse", "Beauftragte","Referate" usw ab, welche wiederrum in weitere Unterprojekte aufgesplittet sind.

A: Beim Redmine ist mit Projekte die Gliederung in Verzeichnisse gemeint. Auf unser (StuRa HTW Dresden) Redmine bezogen bedeutet das große Ganze ist die Studentinnen- und Studentenschaft, wovon der StuRa das Organ ist.

Q: Wie ist die Projektstruktur im Redmine aufgebaut?

A: Die Projektstruktur ist wie die Gliederung der studentischen Vertretungen aufgebaut. Wie beispielsweise auch bei der Website, ist der StuRa selbst einer der "Hauptverzeichnisse". Demnach ist der StuRa ein (das) haupsächliche "Projekt". Aber neben dem StuRa selbst gibt es weitere von der Wurzel (aka root) der studentische Vertretungen. Diese sind, wie eben auch auf der Website, in 2 weitere Hauptgruppen zusammengefasst: Vertretungen der Studentinnen und Studenten (außerhalb der studentischen Sebstverwaltung) (z.B. die studentische Vertretung im Senat) und weitere Organe innerhalb der studentischen Sebstverwaltung (z.B. der Wahlausschuss der Studentinnen- und Studentenschaft).

Q: Warum sind im Redmine die Bereichsleitungen Mitwirkende (Rolle) in ihrem übergeordneten Referat?

A: Die Bereichsleitungen können so die erstellten Tickets, die sich im übergeordneten (Projekt) Referat befinden, beobachten.

Q: Wer erhält welches Ticket?

A: Tickets werden in dem dazu gehörigen Projekt erstellt und an die identischen Benutzer verwiesen. Beispiel(1): Im Unterprojekt "Referat HoPo" wird dann den Benutzer HoPo im Ticket verwiesen. Beispiel(2): Das Referat Kultur möchte an Kino ein Ticket schreiben um ihnen zu sagen, dass sie ein Kühlschrank bestellen sollen. Dann muss das Referat Kultur im Unterprojekt "Bereich Kino" ein Ticket erstellen und an den Benutzer Kino verweisen.

A: Tickets sollen in dem dazu gehörigen Projekt erstellt werden. Üblicher Weise sollte das Ticket dann auch den entsprechenden Benutzer(innen) zugewiesen werden. Diese werden auch schon bei der Erstellung an entsprechender Stelle von selbst angezeigt und müssen nur noch ausgwählt werden.

Beispiel 1: Im Unterprojekt Referat Hochschulpolitik wird auf das Benutzungskonto (durch die Administration künstlich erzugte Accounts) HoPo im Ticket verwiesen, sodass dies es HoPo zugewiesen werden kann.

Beispiel 2: Das Referat Öffentlichkeitsarbeit möchte dem Bereich Erscheinungsbild ein Ticket erstellen. Etwa könnte sich die Referatsleitung Öffentlichkeitsarbeit die Erarbeitung einer Vorlage für Pressemitteilungen wünschen. Dann muss das Referat Öffentlichkeitarbeit im Unterprojekt "Bereich Erscheinungsbild" ein Ticket erstellen und an das Benutzungskonto Kino verweisen.

Q: Wie beobachte ich Tickets?

A: Der Bereich Konzerte möchte dem gesamten Referat Kultur für die Referatsleitung ein Ticket schreiben und es beobachten, dann wird dies im Unterprojekt "Referat Kultur" erstellt und an das Benutzungskonto Kultur verwiesen und das Benutzungskonto Konzerte für die Beobachtung des Tickets markiert.

Q: Wird dies das AUS des StuRa sein?

C: Wenn ich ...but eminently hackable. lese - jappp, das ist das Ende ;) .

Alternative zu Redmine

Aktuell wird Redmine zur Probe angewendet. Mir ist aufgefallen, dass aber gar nicht klar ist, wieso Redmine die passendste Software sein soll. Können die alternativen Angebote (Software) für das Aufgabenumsetzungssystem bewertet werden?

Es sei erwähnt, dass ich es als wichtig empfände, die Entscheidungsgründe für die verwendete Software abzubilden.

Alternativ würde ich gern [#Alternative OTRS|OTRS] "probieren" wollen.

-- PaulRiegel 17:00, 18. Mär 2012 (CET)

Alternative OTRS

Zur BuFaK ins Ansbach wurde durch die Leitung des ansäßigen Rechenzentrums eine kleine Einführung zu OTRS gegeben. Großartige Veranstaltung!

Projekt Koordination für den Bereich Administration Rechentechnik

Für was?

• Feststellung und Koordination von Aufgaben

Was wird benötigt?

Ein System, um Aufgaben zu verfolgen, zu verteilen, den zeitlichen Umfang fest zustellen und an wiederkehrende Aufgaben zu erinnern. Ein Feedback-Oberfläche wäre auch nicht zu verachten.

Welche Informationen sollte ein Ticket besitzen?

• Start und Endzeit
• Gruppen und/oder Personen Zuordnung
• Fortschrittsanzeige
• Zeitaufwand
• Kommentarierung
• Ticketabhängigkeiten
• Statusanzeige
• "Schwarzer Peter" - Prinzip [Weiterreichen]
• Versionskontrolle für sources
• (Eskalationsmeldung)
• (Kategorisierung)

weitere Software

• KanBan/ KanBoard
• Taiga

--141.56.67.72 21:38, 14. Jan. 2015 (CET)

Erfahrungen mit AUS

Die Software Roundup ist mit einigen Anpassungen bei der FSFW Dresden im Einsatz, Redmine beim C3D2. Persönlich kann ich letzteres besser anwenden und die Verzahnung mit ergänzenden Modulen gefällt mir gut, allerdings hatte ich bei der Installation einer eigenen Testinstanz Probleme. --Mr N (Diskussion) 13:05, 31. Dez. 2015 (CET)

---

Redmine konnte ich schon erfolgreich aufsetzen (bilde ich mir ein). :-)

Siehe auch: Server/Redmine

Das mache ich jetzt die Tage auch einfach noch für den StuRa richtig. Eigentlich ist meinerseits dazu schon fast alles fertig.

--Paul 17:50, 4. Jan. 2016 (CET)

Realisierung mit Redmine

Kultur zur Erstellung von Accounts und Tickets

• Sollen sich Menschen einfach einen Account erstellen können? (wie beim Wiki oder eher wie bei der Website)
  • Vorerst sollen ausschließlich Mitglieder der studentischen Selbstverwaltung Accounts haben.
  • Später kann vielleicht noch einmal geprüft werden, ob es Fälle gegeben hat, wo es sinnvoll gewesen wäre, dass sich auch "Fremde" einen Account hätten erstellen können. (Aber irgendwie muss ja sichergestellt sein, dass die Accounts dann auch bestätigt und den richtigen Gruppen usw. zugeordnet werden.)
• Sollen auch Tickets ohne Account erstellt werden können?
  • Vorerst sollen ausschließlich erstellte Accounts von Mitgliedern der studentischen Selbstverwaltung Tickets (Aufgaben) erstellen können.
  • Später kann vielleicht noch einmal geprüft werden, ob ….

Einstellung vom Redmine

• Projekte
• Benutzer
  • Ein jedes Mitglied der studentischen Vertretung (StuRa usw.)
• Gruppen
  • alle verschiedenen Stellen (Funktionen, wie etwa Referate usw.)
• Rollen und Rechte
  • "alles machen dürfen"
    • Bereich Koordination
    • Referat studentische Selbstverwaltung & Organisation
    • Sprecherinnen und Sprecher
  • Tickets verschieben, beenden (?) usw.
    • Referatsleitungen
  • Tickets eintragen
  • Tracker

    Das sind die unterschiedlichen Arten von Tickets.

    • Brauchen wir das überhaupt? (Reicht nicht (erstmal nur) Aufgabe?)
  • Ticket-Status

    Hier müssen wir uns echt Gedanken machen. (Der Status ist zentral für den Arbeitsablauf.)

  • Workflow

    Arbeitsablauf

    • WTF? (Keine Ahnung! Das können wir erstmal lassen und werden das dann an der Praxis "ausrichten", oder?)
  • Benutzerdefinierte Felder
  • Aufzählungen
  • Konfiguration
  • LDAP-Authentifizierung
    • Aktuell betreiben wir noch keine Instanz für LDAP.
  • Plugins
  • Informationen

    nur eine Anzeige

--Paul 16:50, 31. Mär. 2016 (CEST)

• Welche Projekte gibt es?
  • Bieten wir FSRä es an, dass sie ein eigenes Projekt bekommen können?

---

• Projekt StuRa angelegt
• Alle Tracker gelöscht.
• Den Tracker Aufgabe erstellt. (Damit es überhaupt einen Tracker gibt, denn jedes Ticket muss einer Art von Tracker zugeordnet sein.)
  • Beim Erstellen erstmal alles bei Standardwerte dabei gelassen. (Was ist zum Beispiel Zielversion? Keine Ahnung! Womöglich später mal Herauswerfen.)
• (erste) Gruppen
  • alles was uns so erstmal einfiel

---

zu erledigen:

• kein Registrieren zulassen (weil wir vorerst nur kontrolliert Accounts)