Inner­Source: Colla­bo­ration Tooling

Published On: 28. Februar 2020|Categories: Tech|
So far we have covered colla­bo­ration through GitHub.

So far we have covered colla­bo­ration through GitHub, mostly in issues and pull requests. In this article we will dig deeper into the other commu­ni­cation and colla­bo­ration tools that can be useful — and how to link them together.

(German version below)

Using Slack

In our Inner­Source initiative we’ve setup our channels in a way based on inspi­ration from the mailing list setup at The Apache Software Foundation:

Currently we are using three slack channels in addition to a repository on GitHub:

  • One Slack channel called #inner­source for free flow discussion, brain­storming, announce­ments and as a general first point of contact. By now traffic there is relatively low as most questions and discus­sions are being worked on in the GitHub issue tracker.
  • Another Slack channel with the name #inner­­source-private for discussion on adding new trusted committers.
  • And yet another channel named #inner­­source-github for mirroring activity on GitHub to a Slack channel. That’s helpful for two use cases: seeing quickly in a mobile connection what kind of traffic there is in the project without checking all email notifi­ca­tions. But also allowing to follow those notifi­ca­tions when joining the project later. I found it helpful to have the same notifi­ca­tions in the same place for everyone.

Using external tools and linking

So, does that mean we are using GitHub exclu­sively? Nope! There’s blog posts being published on the company blog. Training slides developed in G Suite. Even some text documents with company external colla­bo­rators won’t end  up in our systems — think of a draft for a chapter in a book.

How do we deal with that?

While sub optimal in terms of searching by keywords, it still helps to link to these resources: In issues while they are under develo­pment as well as in the final documen­tation. With adding links we create one place of reference for all artifacts created.

When we started intro­ducing Inner­Source at Europace the tooling explained above was far from standard. We decided to use it anyway so the repository and project could serve as a living template for future Inner­Source projects.

However that meant deviating from company standard tooling in some  cases. This also implies hurting findability inten­tio­nally. In order to help ease that issue what we did was to provide bread­crumbs, like a page explaining mission and including a link to the GitHub repository in existing knowledge management tooling — in our case for instance the company internal wiki.

In addition we tried to link all commu­ni­cation and knowledge sharing tools used together so that people who had found one piece of it by chance were likely to discover the rest as well.

In summary: Default to open

Throughout the work on Inner­Source at Europace we aspire to be open by default. Therefore we are pulling others into our Slack channel and GitHub issue tracker. While this needs a bit of encou­ra­gement and occasio­nally coaching and explaining tools it does move people closer together across organiza­tional boundaries and silos.

Again the reasoning is simple:

  • Allow others to lurk and learn from reading and watching.
  • Allow others coming later to find answers to questions someone already asked.
  • Allow more colle­agues to provide their experience.
  • Parti­cipate outside of the need to find common meeting slots which can become incre­asingly hard when crossing organiza­tional boundaries

There are a few discus­sions left to private channels, most important of all are those related to people questions. In addition trainings and individual tool support often benefit way more from personal inter­action to restrict those to written formats.

Infor­mation from this blog post is currently under review as an upstream Inner­Source pattern.

Kommu­ni­ka­ti­ons­tools

Bisher haben wir uns auf die Koope­ration über GitHub konzen­triert, dort dann haupt­sächlich über Issues und Pull Requests. In diesem Artikel gehen wir darauf ein, welche Tools wir darüber hinaus nutzen — und wie wir diese zusam­men­führen.

Slack

In unserer Inner­Source Initiative haben wir die Slack Kanäle in einer Form aufge­setzt, die den Mailing­listen der Apache Software Foundation ähnelt. Wir nutzen aktuell drei Slack Channels zusätzlich zum GitHub Repository:

  • Ein Slack Channel mit dem Namen #inner­source für freie Diskus­sionen, Brain­storming, Ankün­di­gungen und als allge­meiner Kontaktort. Aktuell ist der Traffic auf diesem Kanal noch relativ niedrig, da die meisten Fragen und Diskus­sionen in GitHub im Issue Tracker statt­finden.
  • Ein weiterer Slack Channel mit dem Namen #inner­­source-private für die Diskussion rund um das Hinzu­fügen neuer Trusted Committers.
  • Ein weiterer Channel mit dem Namen #inner­­source-github um Aktivität auf GitHub nach Slack spiegeln zu können. Dies ist dann hilfreich, wenn über eine mobile Verbindung schnell ein Überblick über das was im Projekt passiert geschaffen werden soll — ohne sämtliche Mails zu überprüfen. Außerdem hilft es denen, die dem Projekt später beitreten beim Nachvoll­ziehen dessen, was passiert ist.

Externe Tools und Verlinkung

Heißt das, dass wir außer bei der Kommu­ni­kation exklusiv auf GitHub setzen? Nein! Blog Posts werden im Unter­neh­mensblog veröf­fent­licht — nachdem sie als Draft über einen Pull Request zum Inner­Source GitHub Repo reviewed werden konnten. Training Folien werden in der internen G Suite entwi­ckelt. Selbst für einfache Texte ist es stellen­weise erfor­derlich, diese auch außerhalb von GitHub zu teilen — spätestens dann, wenn sie mit Unter­­nehmens-Externen geteilt werden sollen, z.B. weil die Texte für ein Buchka­pitel zum Thema Inner­Source bei Europace gedacht sind.

Wie gehen wir mit solchen Situa­tionen um?

Auch wenn es sub-optimal ist in Bezug auf die Suche und Findbarkeit über Keywords, hilft es dennoch, externe Resourcen zu Verlinken: In Issues, während die externen Resourcen entwi­ckelt werden, aber auch in der finalen Dokumen­tation. Auf diese Weise entsteht ein Ort, von dem aus alle relevanten Dokumente erreicht werden können.

Als wir bei Europace mit der Einführung von Inner­Source begannen, war das oben beschriebene Tooling weit vom Standard entfernt. Wir beschlossen, es trotzdem zu verwenden, damit das Repository und das Projekt als lebende Vorlage für zukünftige Inner­­Source-Projekte dienen konnten.

Das bedeutete jedoch, dass wir in einigen Fällen von den Standard­werk­zeugen des Unter­nehmens abweichen mussten. Dies bedeutet auch, dass die Auffind­barkeit absichtlich beein­trächtigt wird. Um dieses Problem zu entschärfen, haben wir Bread­crumbs bereit­ge­stellt, z. B. eine Seite, die die Mission erklärt und einen Link zum GitHub-Repository in bestehenden Wissens­­ma­­nagement-Tools enthält — in unserem Fall z. B. im firmen­in­ternen Wiki.

Darüber hinaus versuchten wir, alle verwen­deten Kommu­­ni­­ka­­tions- und Wissens­aus­­tausch-Tools mitein­ander zu verknüpfen, so dass Personen, die einen Teil davon zufällig gefunden hatten, auch den Rest entdecken konnten.

Default to open

In unserer Arbeit an Inner­Source bei Europace versuchen wir dem Prinzip open by default zu folgen. Dafür ziehen wir gern andere in unseren Slack channel oder GitHub issue tracker. Oft braucht dies ein gewisses Maß an Ermutigung und manchmal coaching aber es führt Menschen näher zuein­ander über Organi­sa­ti­ons­grenzen und Silos hinweg.

Die Begründung ist einfach:

  • Andere bekommen die Möglichkeit, zuzuschauen und im Hinter­grund zu lernen.
  • Andere, die später kommen, finden nicht nur frühere Fragen, sondern auch die Antworten darauf.
  • Mehr Kollegen bekommen die Möglichkeit, sich mit ihrer Expertise einzu­bringen.
  • Mitarbeit ist möglich, auch außerhalb der Notwen­digkeit gemeinsame Meeting Slots zu finden — was zunehmend schwerer wird, je größer die Organi­sation wächst.

Aus diesem Grund werden Diksus­sionen in privaten Channels minimiert, aller­dings besonders wichtig: people questions bleiben weiter vertraulich. Eine weitere Ausnahme bilden Trainings und indivi­du­eller Tool Support die oft von persön­licher Inter­aktion profi­tieren im Gegensatz zu rein schrift­lichen Formaten.

Die Infor­ma­tionen aus diesem Blog Post sind aktuell unter Review als Inner­Source Pattern.

Written by: Isabel Drost-Fromm Developer @ Europace