So far we have covered collaboration through GitHub, mostly in issues and pull requests. In this article we will dig deeper into the other communication and collaboration tools that can be useful - and how to link them together.

(German version below)

Using Slack

In our InnerSource initiative we’ve setup our channels in a way based on inspiration 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 #innersource for free flow discussion, brainstorming, announcements and as a general first point of contact. By now traffic there is relatively low as most questions and discussions are being worked on in the GitHub issue tracker.
  • Another Slack channel with the name #innersource-private for discussion on adding new trusted committers.
  • And yet another channel named #innersource-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 notifications. But also allowing to follow those notifications when joining the project later. I found it helpful to have the same notifications in the same place for everyone.

Using external tools and linking

So, does that mean we are using GitHub exclusively? Nope! There’s blog posts being published on the company blog. Training slides developed in G Suite. Even some text documents with company external collaborators 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 development as well as in the final documentation. With adding links we create one place of reference for all artifacts created.

When we started introducing InnerSource 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 InnerSource projects.

However that meant deviating from company standard tooling in some  cases. This also implies hurting findability intentionally. In order to help ease that issue what we did was to provide breadcrumbs, 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 communication 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 InnerSource 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 encouragement and occasionally coaching and explaining tools it does move people closer together across organizational 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 colleagues to provide their experience.
  • Participate outside of the need to find common meeting slots which can become increasingly hard when crossing organizational boundaries

There are a few discussions 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 interaction to restrict those to written formats.

Information from this blog post is currently under review as an upstream InnerSource pattern.

Kommunikationstools

Bisher haben wir uns auf die Kooperation über GitHub konzentriert, dort dann hauptsächlich über Issues und Pull Requests. In diesem Artikel gehen wir darauf ein, welche Tools wir darüber hinaus nutzen - und wie wir diese zusammenführen.

Slack

In unserer InnerSource Initiative haben wir die Slack Kanäle in einer Form aufgesetzt, die den Mailinglisten der Apache Software Foundation ähnelt. Wir nutzen aktuell drei Slack Channels zusätzlich zum GitHub Repository:

  • Ein Slack Channel mit dem Namen #innersource für freie Diskussionen, Brainstorming, Ankündigungen und als allgemeiner Kontaktort. Aktuell ist der Traffic auf diesem Kanal noch relativ niedrig, da die meisten Fragen und Diskussionen in GitHub im Issue Tracker stattfinden.
  • Ein weiterer Slack Channel mit dem Namen #innersource-private für die Diskussion rund um das Hinzufügen neuer Trusted Committers.
  • Ein weiterer Channel mit dem Namen #innersource-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 Nachvollziehen dessen, was passiert ist.

Externe Tools und Verlinkung

Heißt das, dass wir außer bei der Kommunikation exklusiv auf GitHub setzen? Nein! Blog Posts werden im Unternehmensblog veröffentlicht - nachdem sie als Draft über einen Pull Request zum InnerSource GitHub Repo reviewed werden konnten. Training Folien werden in der internen G Suite entwickelt. Selbst für einfache Texte ist es stellenweise erforderlich, diese auch außerhalb von GitHub zu teilen - spätestens dann, wenn sie mit Unternehmens-Externen geteilt werden sollen, z.B. weil die Texte für ein Buchkapitel zum Thema InnerSource bei Europace gedacht sind.

Wie gehen wir mit solchen Situationen 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 entwickelt werden, aber auch in der finalen Dokumentation. Auf diese Weise entsteht ein Ort, von dem aus alle relevanten Dokumente erreicht werden können.

When we started introducing InnerSource 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 InnerSource projects.

However that meant deviating from company standard tooling in some cases. This also implies hurting findability intentionally. In order to help ease that issue what we did was to provide breadcrumbs, 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 communication 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.

Default to open

In unserer Arbeit an InnerSource 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 zueinander über Organisationsgrenzen und Silos hinweg.

Die Begründung ist einfach:

  • Andere bekommen die Möglichkeit, zuzuschauen und im Hintergrund 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 einzubringen.
  • Mitarbeit ist möglich, auch außerhalb der Notwendigkeit gemeinsame Meeting Slots zu finden - was zunehmend schwerer wird, je größer die Organisation wächst.

Aus diesem Grund werden Diksussionen in privaten Channels minimiert, allerdings besonders wichtig: people questions bleiben weiter vertraulich. Eine weitere Ausnahme bilden Trainings und individueller Tool Support die oft von persönlicher Interaktion profitieren im Gegensatz zu rein schriftlichen Formaten.

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

Weitere Artikel, die in dieser Serie erschienen sind: