(German translation below)

... for asking questions

In addition to tracking decisions in the making issues are being used for those who would like to ask InnerSource related questions. Asking them in the issue tracker instead of in 1-on-1 settings has three advantages:

  • There's more than one knowledgeable individual that can answer the question.
  • Others who may have the same question later on (or even now, in case  they are afraid to ask the question) see that there are others who  openly learn something new. Plus they see the answer to the question without having to ask themselves.
  • Also should the question come up frequently having the answer at a  place that can be reached by a URL makes sharing the answer easier.

... for tracking tasks

In addition to that issues are a great place to make work visible to others - potentially providing an option for them to become active as well and help out.

Summary

So to summarize, in the gh#innersource project we are using issues for a couple of purposes:

  • Discussing options to solve a certain problem at hand, coming up  with solutions to that problem and driving alignment towards a common  solution.
  • Organizing our monthly internal meetup, including the publication of  date and location, agenda building and publishing a protocol after the  meetup.
  • Allowing others to ask questions publicly and transparently.
  • To track our own tasks and work.

With that in InnerSource project the issue tracker turns from a mere digital white board with sticky notes attached to it into one central place for communication and coordination.

Pull principle

There's one deviation from how issue trackers are used in some companies: instead of assigning issues to people, we tend to leave it to the person solving them to self sign. Experience has shown that in our case self assignment is more rewarding and more fun - likely for similar reasons as with the pull principle known from agile software development. Using the pull principle generally leads to higher commitment and responsibility.

Typically though assignment isn't even needed: People involved will drive these issues forward, even if sometimes it takes a bit of time. Also typically there are so many people involved in a resolution that assignment wouldn't make a lot of sense anymore to signal who is the one  human who resolved the issue: Typically it's a long list of everyone involved. It does make sense to use it in cases where contributors provided significant steps towards resolution as a way to publicly praise their work.

The information in this blog post are currently under review as an upstream InnerSource pattern.

Translated version

... für Fragen und das Tracking von Aufgaben.

... zum Fragen

Im letzten Blog Post sind wir darauf eingegangen, wie Issue Tracker im Inner Source Kontext zum Brainstorming eingesetzt werden können. In diesem Post konzentrieren wir uns auf die Aspekte "Fragen stellen" und "Tracking von Aufgaben".

Wir nutzen den Issue Tracker nicht nur um Entscheidungen nachvollziehbar zu halten, sondern nutzen Issues auch als eine Möglichkeit für Nutzer (in unserem Fall der Methode InnerSource) Fragen zu stellen. Stellt man seine Fragen auf diese Weise öffentlich anstatt im persönlichen 1-zu-1 Setting hat drei Vorteile:

  • Es gibt mehr als einen einzelnen Kollegen, der die Frage beantworten kann.
  • Andere Kolleginnen, die später (oder gar jetzt) die gleiche Frage haben, können anderen beim Lernen über die Schulter schauen und mitlernen - dabei idealerweise ihr eigenes Verständnis verbessern.
  • Letztlich hilft es bei Fragen, die häufig vorkommen, die Antwort über eine URL erreichbar zu machen um die Antwort später einfacher teilen zu können.

... zum Tracken von Aufgaben

Issues sind auch weiterhin ein gutes Mittel, um aktuelle Aufgaben sichtbar zu machen und anderen zu signalisieren welche Aufgaben sich aktuell in Bearbeitung befinden - und welche noch warten. Auf diese Weise kann man auch sehr einfach signalisieren bei welchen Themen noch helfende Hände gebraucht werden.

Summary

Zusammengefasst nutzt das gh#innersource Projekt Issues für unterschiedliche Zwecke:

  • Für die Diskussion von Lösungen für konkrete Probleme.
  • Um unser monatliche internes Treffen zu koordinieren - inklusive der Publikation von Datum und Raum, den Aufbau der Agenda und die Publikation eines Protokolls im Anschluss.
  • Um Außenstehenden, die zum Thema Fragen haben, eine Möglichkeit zu geben, Antworten auf diese Fragen zu bekommen.
  • Um Aufgaben zu tracken und offene Aufgaben für andere sichtbar zu machen.

Damit wandelt sich bei InnerSource Projekten der Issue Tracker von einer reinen digitalen Form eines Whiteboards mit Klebezetteln zu einem zentralen Ort für Kommunikation und Koordination.

Pull Prinzip

Es gibt einen Unterschied in der Art wie wir Issue Tracker einsetzen zu einzelnen anderen Unternehmen und Teams: Anstatt Personen Issues zuzuweisen, tendieren wir dazu, es den Kollegen zu überlassen, sich die Issues selbst zuzuordnen. Erfahrungsgemäß hat dies dazu geführt, dass sich Aufgaben dankbarer, spannender und erfüllender angefühlt haben - mit Sicherheit aufgrund ähnlicher Gründe, die bei der Agilen Softwareentwicklung zur Verwendung des pull principle geführt haben. Auch dieses führt üblicherweise zu höherem Einsatz und Verantwortungsgefühl.

Typischerweise ist eine Zuweisung von Issues unnötig: Die involvierten Personen sorgen dafür, dass Issues umgesetzt werden, auch dann, wenn sie sich als umfangreicher herausstellen als ursprünglich geplant. Hinzu kommt, dass nicht selten soviele Personen an einer Lösung mitgewirkt haben, dass nicht länger ein einzelner identifiziert werden kann.

In einem Fall ist eine Zuweisung von Issues allerdings sehr sinnvoll: Man kann diese gut nutzen, um zu signalisieren welche (Projekt-externen) Contributoren signifikante Schritte zur Lösung beigetragen haben um deren Arbeit öffentlich zu loben.

Die Informationen aus diesem Blog Post befinden sich aktuell unter Review als InnerSource Pattern.

Weitere Artikel, die in dieser Serie erschienen sind: