Kommunikationsrichtlinie für Redmine

{{>toc}}

Redmine bildet das Rückgrat der organisatorischen Infrastruktur von Do-FOSS. Es erlaubt das Ausdiskutieren verschiedener Standpunkte im Forum, das Formulieren, Beobachten und Dokumentieren von Aufgaben in Tickets und das Festhalten der erarbeiteten Inhalte im Wiki - wann welcher Mechanismus der richtige ist, beschreibt die Kommunikationsrichtlinie. Im vorliegenden Artikel wird die Benutzung der einzelnen Features beschrieben.

Dieses Projekt ist öffentlich einsehbar und soll so die Auseinandersetzung mit unseren Inhalten fördern. Im Idealfall erlaubt es ähnlichen Initiativen aus unseren Erfahrungen zu lernen.
Um die Wiederverwendbarkeit möglichst einfach zu machen, handelt es sich bei allen in dieser Redmine-Instanz veröffentlichten Informationen um Free Content.

Tickets

Tickets halten Aufgaben fest. Ihre Zuordnung zu Trackern, Kategorien und Zielversionen (aka Meilensteinen) sowie ihre Priorität ermöglichen eine einfache Verortung jeder Aufgabe. Ihr Status, Fortschritt (% erledigt) und die Zuweisung zu einer und Assoziationen mit mehreren Person machen es leicht, den aktuellen Zustand abzulesen.

Damit Tickets einen Überblick über den Zustand des gesamten Projekts geben können, müssen sie aktuell gehalten werden! Dies ist die Aufgabe desjenigen, dem sie zugewiesen sind. Falls ein Ticket veraltet zu sein scheint (z.B. wegen wochenlanger Inaktivität) kann am Ticket um eine Aktualisierung gebeten werden.

Die folgenden Richtlinien sind nicht erschöpfend. Bei Rückfragen zur Handhabung können sie ergänzt werden; sonst hilft oft auch ein Blick in bereits existierende Tickets.

Form und Umfang

Das ist ein wichtiger Aspekt:

> Jedes Ticket entspricht einer zu erledigenden Aufgabe.

Diese kann sehr umfangreich sein und durchaus aus mehreren Schritten bestehen. Allerdings sollte es sich um ein klar umrissenes einzelnes Arbeitspaket sein, das nicht unterschiedliche Aufgaben aufzählt (also z.B. nicht Impressum verfassen und Mailinglist einrichten).
Stellt sich im Rahmen der Bearbeitung eine Tickets heraus, dass es weitere damit verwandte Aufgaben gibt, ist es im Regelfall sinnvoll weitere Tickets zu erstellen.

Der Titel des Tickets sollte die Aufgabe in sehr wenigen Worten beschreiben. Dabei ist der Mittelweg zwischen unbrauchbar kurz ("Blogartikel verfassen") und unbrauchbar lang ("Blogartikel zum Thema ... verfassen, der auf ... eingeht") zu finden.

Die Beschreibung muss nicht jedes Detail der Aufgabe beschreiben. Sie sollte allerdings so genau sein, dass sich jeder einen groben Überblick verschaffen kann.

Zuweisung und Assoziation

Viele Aufgaben erfordern Zusammenarbeit. Dabei sollen alle Personen, deren Mitarbeit an einem Ticket in Zukunft noch erforderlich ist, mit diesem assoziiert werden. D.h., dass die Assoziation gelöst werden soll, wenn eine Person ihren Beitrag geleistet hat. Das erlaubt die Verwendung darauf basierender Filter, um die eigene Arbeitslast abzuschätzen.

Ein Ticket kann an eine einzelne Person zugewiesen werden. Diese ist für den nächsten wichtigen Arbeitsschritt sowie den Zustand des Tickets verantwortlich.

Rückfragen

Im Laufe der Bearbeitung eines Tickets ergeben sich oft Fragen. Diese können in einem Kommentar gestellt werden; dabei sollte gleichzeitig der Status auf Rückfrage gestellt werden. Gibt es einen konkreten Ansprechpartner, kann das Ticket ihm zugeordnet werden.

Entscheidend ist, dass die Antworten nicht ebenfalls in einem Kommentar erfolgen sollten! Statt dessen soll die Beschreibung des Tickets passend ergänzt werden. So ist sie immer auf dem aktuellen Stand und erlaubt einen besseren Einblick in den aktuellen Stand der Dinge.

Status

Der Status definiert den "Lebenszyklus" eines Tickets. Dieser lässt sich im Rahmen der Redmine-Administration in Regeln gießen und so festlegen. Da das zu Frustrationen führen kann, wurde zunächst der weniger explizite Weg gewählt, diesen Lebenszyklus nur zu beschreiben.

Neu

Ein Ticket ist Neu, wenn es erstellt wurde, aber die Initiative noch nicht beschlossen hat, ob sie es auch umsetzen möchte. In diesem Zustand kann das Ticket auch noch unvollständig definiert sein (d.h. die Angaben müssen noch nicht vollständig sein).

Bestätigt

Sobald die Initiative beschließt, eine Aufgabe zu erledigen, wird der Status auf Bestätigt gesetzt. Dabei sollte sichergestellt sein, dass alle geforderten Angaben gemacht wurden.

In Bearbeitung

Sobald die Bearbeitung des Tickets beginnt, sollte der Status auf In Bearbeitung gesetzt werden. Im Laufe der Bearbeitung sollte der Fortschritt regelmäßig aktualisiert werden. Falls sich daran gehalten wird, ist schnell zu erkennen, woran eine Person gerade arbeitet.

Unterbrochen

Falls die Arbeit am Ticket nicht fortgesetzt werden kann, weil z.B. auf externe Prozesse gewartet werden muss, kann der Status auf Unterbrochen gestellt werden. In dem Fall sollte der Kommentar erklären, warum die Arbeit unterbrochen wurde.

Rückfrage

Oft ergibt sich im Laufe der Bearbeitung eines Tickets eine Frage an jemandem. Diese kann dann in einem Kommentar am Ticket gestellt werden bevor der Status auf Rückfrage gestellt und das Ticket dem Gefragten zugewiesen wird. Darüber hinaus gilt das im Abschnitt Rückfragen Gesagte.

Erledigt

Wenn der Bearbeitende der Meinung ist, die Arbeit am Ticket sei abgeschlossen, kann er des Status auf Erledigt stellen und jemandem zuweisen, der das prüft. Diese Person sollte das Ticket wirklich beurteilen können; im Idealfall ist es der Eröffner. Sollte sich keine solche Person finden, kann das Ticket auch direkt geschlossen werden.

Je nach Ausgang der Prüfung kann das Ticket entweder geschlossen werden oder zurück in Bearbeitung gehen.

Geschlossen

Die Arbeit am Ticket ist erledigt. Theoretisch kann es wieder eröffnet werden, aber das ist ein absoluter Ausnahmefall. Sollten sich anschließende Aufgaben ergeben, kann ein neues Ticket eröffnet und zum geschlossenen in Beziehung gesetzt werden.

Kategorien

Tickets sollen immer einer Kategorie zugeteilt werden, sofern eine passende existiert. Falls nicht, bitte kurze Mail an die Administration.

• Infrastruktur: Für alle Tickets, die den Unterbau von Do-FOSS betreffen. Dazu gehört insbesondere die technische Seite, aber auch anderweitige Vorarbeiten sind eingeschlossen. Für die wichtigsten Bereiche existieren "Unterkategorien", d.h. Kategorien mit dem Namensschema Infrastruktur - ....
• Kommunikation: Für jegliche Kommunikation nach außen, sei es zur Öffentlichkeitsarbeit, zur Absprache mit Einzelpersonen oder Gruppen oder auch zu inhaltlichen Auseinandersetzungen. (Eine Aufteilung in Unterkategorien scheint wünschenswert, aber die Übergänge sind zu fließend, um die trennscharf umsetzen zu können.)
• Meta: Arbeiten, die sich mit Do-FOSS als Organisation befassen. Dabei geht es insbesondere darum organisatorische Entscheidungen zu treffen und festzuhalten.
• Thema: Hierunter fällt die inhaltliche Arbeit. Das sind insbesondere Posts und andere Veröffentlichungen. Es existieren Kategorien für die einzelne Themenfelder.

Beziehungen

Tickets können mit anderen Tickets in Beziehung gesetzt werden, um so einen Zusammenhang auszudrücken und dem Bearbeiter eines Tickets notwendigen Kontext mitzugeben. Wegen der nicht ganz offensichtlichen Nebenwirkungen einiger Beziehungen, sollte hier nur Beziehung mit gewählt werden.

Wiki

Erarbeitetes Wissen darf nicht verloren gehen! Statt dessen soll es im Wiki dokumentiert werden, damit die Initiative möglichst unabhängig von ihren konkreten Mitgliedern agieren kann. Außerdem ergibt sich so die Möglichkeit für andere Initiativen, aus unseren Erfahrungen zu lernen.

Ein einigermaßen umfangreiches Wiki so zu verwalten, dass es von hoher Qualität ist und zugänglich bleibt, kann eine komplexe Aufgabe sein. An dieser Stelle können nicht die vielen dafür notwendigen Details aufgelistet werden. Es folgt ein kurzer Abriss der - subjektiv - wichtigsten Aspekte.

Struktur

Eine gute Struktur ist wohl der wichtigste Aspekt, um einen einfachen Zugang zu einem Wiki zu ermöglichen.

Übergeordnete Seite

In Redmine hat jeder Artikel mit Ausnahme der Hauptseite eine übergeordnete Seite. Dadurch ergibt sich eine Baumstruktur, die sich hinter dem Link Seiten nach Titel sortiert (rechts neben jedem Artikel) verbirgt. Dieser Baum verschafft einen sehr guten Überblick über den Inhalt eines Wikis, weswegen es wichtig ist, ihn zu pflegen.

Bei jedem Artikel kann unter dem Bearbeitungsfenster die übergeordnete Seite ausgewählt werden. In den meisten Fällen gehört der bearbeitete Artikel klar zu einem Oberthema und dessen Artikel sollte die übergeordnete Seite sein. Die Auswahl ist also meist ziemlich einfach - dieser Absatz will nur darauf hinweisen, diese Entscheidung jedes Mal bewusst zu treffen und auf keinen Fall einfach den vorgeschlagenen Wert zu belassen.

Überschriften

Artikel sollten durch Überschriften sinnvoll gegliedert werden. Eine Überschrift kann mit den folgenden drei Zeilen erstellt werden:

h4. Überschriften

Die Leerzeilen müssen eingefügt werden, damit Redmine das Markup erkennt. Die Ziffer kann zwischen 1 und 6 liegen.

Die Überschriften stehen in einer Hierarchie zueinander, wobei h1. die Artikelüberschrift definiert (sollte also nur dort verwendet werden) und die Überschriften mit absteigender Ziffer immer tiefer rutschen. Diese Hierarchie wird zur Erstellung des Inhaltsverzeichnisses verwendet und hat dementsprechend eine semantische Bedeutung. Auf keinen Fall sollte eine Überschrift aus stilistischen Gründen eingefügt oder vermieden werden.

Überschriften erzeugen einen Anker, auf den ein Link erstellt werden kann, z.B. wird dieser Link durch [[Kommunikationsrichtlinie Redmine#Überschriften|dieser Link]] erzeugt - man beachte die Raute zwischen Artikelnamen und Überschrift. Dabei spielt keine Rolle auf welcher Ebene die Überschrift liegt.

Inhaltsverzeichnis

Alle Artikel sollen auf der rechten Seite ein Inhaltsverzeichnis haben. Dazu müssen direkt unter der primären Überschrift die folgenden drei Zeilen eingefügt werden:

{{>toc}}

Ohne die Leerzeilen darüber und darunter wird Redmine das Markup nicht erkennen.

Forum

Das Forum ist der richtige Ort, um ergebnisoffene und potentiell umfangreiche Diskussionen zu führen, z.B. über die Lizenz für Do-FOSS-Inhalte (message#1) oder die Art der Verwendung von PGP-Schlüsseln (message#8). Für kurze [[Kommunikationsrichtlinie Redmine#Rückfragen|Rückfragen]] zu existierenden Aufgaben ist das dazugehörige Ticket besser geeignet.

Die Verwendung des Forums unterliegt den üblichen Forenregeln zum Umgangston und der Geradlinigkeit der Unterhaltung. Neue Themen können bei Bedarf erstellt werden. Falls sich dazu kein passender Bereich findet, bitte eine kurze Mail an den Administrator.

Offene Diskussionen

Ursprünglich war es auch anonymen Nutzern möglich, im Forum zu posten und sich so an der Diskussion um und mit Do-FOSS zu beteiligen.

Leider hat dies zu einem großen Spam-Aufkommen geführt und wir haben keine gangbare technische oder organisatorische Lösung dafür gefunden (siehe #100). Falls sich Außenstehende an einer Diskussion beteiligen wollen, müssten sie dies leider auf einem der anderen Wege machen, z.B. per Twitter oder per E-Mail an den passenden Ansprechpartner.

Dokumentenmanagement

Unter dem Menüpunkt Dokumente lassen sich Dateien ablegen. Redmine erlaubt, mehrere inhaltlich zusammenhängende Dateien als ein Dokument zu archivieren, d.h. ein Dokument (im Sinne Redmines) kann aus mehreren Dateien bestehen. Zu jedem Dokument kann Name, Beschreibung und Kategorie angegeben werden.

Name

Der Name sollte ausdrucksstark sein; meist bietet sich der Dateiname (ohne Endung) an. Dabei ist keine besondere Rücksicht auf Sonderzeichen zu nehmen, d.h. diese können nach Belieben verwendet werden.

Beschreibung

Die Beschreibung sollte in wenigen Sätzen den Inhalt beschreiben und zur besseren Suche einige wichtige Schlagworte aufzählen - angenehm ist es, wenn die Schlagworte Links zu weiterführenden Informationen sind. Außerdem muss die Beschreibung Informationen enthalten, die zum Zitieren und Weiterverwenden nötig sind: Autor, Quelle, Abrufdatum, Lizenz.

Kategorien

Jedes Dokument wird einer Kategorie zugeordnet. Falls von den hier aufgelisteten keine passt, kann ein Ticket erstellt werden.

• Bibliothek - FOSS: für Schriften Dritter zu Freier Software, mit denen wir nicht öffentlich arbeiten, die aber zur Recherche für uns und andere dienen
• Bibliothek - Sonstiges: für alles was im Ökosystem von Freier Software existiert, aber nicht direkt damit zu tun hat
• Interna: für Dokumente, die Do-FOSS zur internen Organisation benötigt, z.B. Rechnungen
• Literatur: für Schriften Dritter zu Freier Software, mit denen wir öffentlich arbeiten
• Medien: Veröffentlichungen in den Medien über Do-FOSS
• Open Offices: für Dokumente für und von Open Offices
• Schriftwechsel: für Dokumente, die von Do-FOSS oder von Dritten für Do-FOSS erstellt wurden
• Veranstaltung: für Veranstaltungsankündigungen von Do-FOSS (Vorträge, etc.)
• Veröffentlichung: für Dokumente, die Do-FOSS erstellt hat oder die unter Mitwirkung von Do-FOSS erstellt wurden
• Vordrucke: für Vordrucke wie Briefköpfe u.ä.

• Sonstiges: für alles, was sonst nirgends reinpasst

Dabei ist die Trennung zwischen Literatur und Bibliothek tatsächlich nur die Nutzung durch Do-FOSS. Dies soll verhindern, dass eine umfangreiche Sammlung von Literatur zum Thema FOSS uns den Blick auf die von uns verwendeten Dokumente verstellt.

Dateien

Für Dateien gelten einige Bedingungen, die im Gegensatz zu vielen anderen Teilen der Richtlinie verpflichtend sind. Dies schließt alle hochgeladenen Dateien ein, egal ob als Anhang für ein Ticket oder Forenbeitrag, Inhalt einer Wiki-Seite oder Teil eines Dokuments.

Copyright

Unbedingt zu beachten ist ob die Lizenz der Datei diese Art der Verbreitung erlaubt. Auf keinen Fall dürfen Dateien hochgeladen werden, deren Verbreitung aus lizenzrechtlichen oder sonstigen juristischen Gründen untersagt ist!

Offene Formate

Wie in der allgemeinen Kommunikationsrichtlinie beschrieben müssen offene Formate verwendet werden. Dazu zählen insbesondere folgende:

• OpenDocument Text (.odt, .fodt)
• OpenDocument Presentation (.odp, .fodp)
• OpenDocument Spreadsheet (.ods, .fods)
• OpenDocument Graphics (.odg, .fodg)
• Portable Document Format (.pdf)

Dateinamen

Damit die Dateinamen nach dem Herunterladen auf verschiedene Betriebssysteme lesbar bleiben, sollten sie nur sehr eingeschränkt Sonderzeichen enthalten. Ausschließlich folgende sind gestattet:

• Leerzeichen: " "
• Bindestrich: "-"
• Unterstrich: "_"

Damit sind z.B. Umlaute und das scharfe S "ß" ausgeschlossen.

Interne News

Wann immer ein wichtiger Arbeitsschritt abgeschlossen, ein Meilenstein erfüllt oder etwas besonderes angekündigt werden soll, kann das als News veröffentlicht werden. Sie sollen in unregelmäßigen Abständen vom internen Fortschritt der Initiative berichten. So können Gelegenheitsmitwirkende und Teilnehmer die Initiative verfolgen ohne sich mit einzelnen Tickets auseinandersetzen zu müssen. Sie sind im Menü zu finden und haben eine eigene Kategorie in der Aktivitätenliste.

Abzugrenzen sind die internen News von dem Blog und dem Blog-Newsletter. Die internen News sind für die Teillnehmer und Mitwirkende gedacht und sollten daher nur Themen aufgreifen, welche nicht schon über den Blog veröffentlicht wurden und von öffentlichem Interesse sind.

In den meisten Fällen werden News kurz und kompakt sein. Das gilt natürlich für den möglichst prägnanten Titel, aber auch für die Beschreibung. Falls sie umfangreichere Themen abdecken soll, kann auf entsprechende Inhalte (Meilensteine, Tickets, Wiki-Artikel, ...) verlinkt werden. Weder in der Aktivitätenliste noch in der News-Übersicht erscheint die Zusammenfassung (zumindest im Theme, das wir Mitte 2014 verwenden), weswegen sie leer gelassen werden kann.