Das Ethos eines Contributors

Wenn Du Deine Nachbarn besuchst, wirst Du wahrscheinlich ihr Haus nicht betreten, ohne geklopft zu haben oder an der Tür zu läuten, selbst wenn die Tür offen steht. Ebenso wirst Du in einem InnerSource Projekt nicht direkt im Code Repository Änderungen machen können oder dazu eingeladen werden.

Stattdessen musst Du Deine Änderungen am Projektcode mit einem Pull-Request übermitteln. Ähnlich wie Du nicht einfach beim Nachbarn anfängst, große Umbauten vorzunehmen oder was Du für Verbesserungen hältst, solltest Du Dir die Zusammenarbeitsregeln vorher angeschaut haben und befolgen. Im Gegenzug werden Dir die Gastgeber den Weg zeigen - im Kontext von InnerSource Projekten bedeutet das, dass sich die dort benannten Trusted Committer Zeit nehmen, um für Dich als Mentoren bereit zu stehen.

Stell Dir eine gelungene Gartenparty vor. Dabei fällt für gewöhnlich im Vorfeld einiges an Planung an, z.B. um das richtige Datum zu finden, für ausreichend Essen und Trinken zu sorgen, oder dafür, dass die Gäste dazu z.B. mit Salaten beitragen. Das Gleiche geschieht bei größeren Änderungen in InnerSource Projekten: Das Projekt wird Dich aller Voraussicht nach vor einer größeren Änderung um eine genauere Beschreibung bitten, was Du benötigst und wie Deine vorgeschlagene Lösung aussieht. Der Contributor spart sich viele Iterationen, wenn man sich das Zieldesign zuerst genauer anschaut, anstatt direkt in die Implementierung zu springen. Eine frühzeitige gemeinsame Abstimmung - selbst wenn noch nicht alle Fragen geklärt sind - hilft dem Hostteam den Contributor dabei zu unterstützen, eine bessere Lösung zu entwickeln. Ähnlich wie es in Yonik’s law of unfinished patches erklärt wird: "Ein halbgarer Patch in Jira ohne Dokumentation, ohne Tests und ohne Abwärtskompatibilität ist besser als überhaupt kein Patch"

Heißt das, dass in InnerSource Projekten kein Wert auf persönliche Gespräche gelegt wird? Nicht ganz: persönliche Gespräche sind wichtig. Jedweder geschriebener Kommunikation fehlt eine ganze Menge an Informationen im Vergleich zu einem persönlichen Treffen: Man sieht keine Geste oder Mimik und auch die Tonlage geht verloren. Persönliche Treffen sind insbesondere wichtig für zwischenmenschliche Aufgaben, oder um Konflikte und Missverständnisse aufzulösen. Trotzdem sollten die Kommunikation von Projektentscheidungen in schriftlicher Form erfolgen, so dass auch andere teilhaben und Einfluss nehmen können und damit es sogar Jahre später möglich ist, nachzuverfolgen, warum bestimmte Entscheidungen getroffen wurden.

Hier unsere allgemeine Faustregel: Trefft Euch von Zeit zu Zeit bei einem Kaffee. Das hilft ein stärkeres Gemeinschaftsgefühl zu entwickeln, insbesondere wenn das Team auf verschiedene Standorte verteilt ist. Stellt sicher, dass alle Entscheidungen für jeden transparent und asynchron getroffen werden, so dass jeder, eingeschlossen derer, die nur nebenbei zuhören (lurking), jederzeit aktiv und Contributor werden kann. Ein Beispiel dafür, wie weit diese Entscheidungsfindung gehen werden kann, findet man in mehreren Übungen in Open Organization Workbook.

Wie aber findest Du die zukünftige Richtung eines Projekts heraus und ob ein InnerSource Projekt bereit ist Änderungen zu diskutieren? Viele InnerSource Projekte beschreiben in ihrem README.md wie sie sich die ersten Schritte in der Zusammenarbeit mit möglichen Contributoren vorstellen. Falls das README.md darüber zu groß wird, werden die Richtlinien für Contributoren oft in ein File namens CONTRIBUTING.md ausgelagert. Das Befolgen dieser Richtlinien hilft Contributoren ungemein dabei, Ihre Ideen dem Projekt nahe zu bringen.

Sei bei allen Interaktionen mit dem Hostteam vorbereitet, das Team von den Vorteilen Deines Beitrags zu überzeugen. Formuliere den Wert, der Dein Beitrags für das Ökosystem bringt.

Das Hostteam wird die Pflege und Wartung für Deine Änderungen übernehmen. Es macht Sinn für Deinen Beitrag eine 30-day warranty anzubieten. Dies kann die Angst des Hostteams mildern, dass der Contributor nach der Änderung nicht mehr zur Behebung von Fehlern zur Verfügung steht.

Wenn Du Deine Nachbarn besuchst, werden sie Dir die Räumlichkeiten zeigen, wie es zum Wohnzimmer geht und wo die Toilette ist. Wenn Du länger bleibst, werden sie Dich vermutlich mehr Details einweihen, in meinen Fall wäre es zu Beispiel, dass man nie den Geschirrspüler und den Wasserkocher gleichzeitig einschalten darf, weil ansonsten die Sicherung fliegt.

Ebenso hat jedes Softwaresystem seine eigenen Macken und Feinheiten. Oft sind die offensichtlichsten gut dokumentiert. Bei kleineren Projekten können diese im README.md gefunden werden. In größeren Projekten ist die Dokumentation für Contributors oft in einem eigenen CONTRIBUTING.md Dokument gespeichert.

Hier solltest Du alle notwendigen Informationen finden, wie man das Projekt auschecked und baut, wie die Testsuite gestartet wird und wie man Änderungen am Projekt hinzufügt. Möglicherweise sind dort Verweise auf weitere Dokumentationen zu finden, z.B. wenn das Projekt stark von üblichen Toolings abweicht, oder wenn es spezielle Dinge zu beachten gibt, wenn Du Änderungen vornehmen willst.

Normalerweise beweist sich das Lesen der Dokumentation als sehr zeitsparend für Deine weitere Arbeit, bewahrt es Dich doch davor falsch abzubiegen oder vor Sackgassen. Falls Du aus Deiner Erfahrung in der Dokumentation fehlende Aspekte findest - Ergänzungen für die Dokumentation sind typischerweise sehr willkommen: Niemand ist besser geeignet die Dokumentation zu verbessern als ein Contributor, der zum erstem Mal verisucht sich in dem Projekt zurecht zu finden.

Versuche gemeinsam mit dem Projekt den besten Kommunikationskanal zu finden, in dem die Sinnhaftigkeit Deiner Änderungswünsche besprochen werden können. Am Anfang kann es beängstigend sein, diese in einem öffentlichen Unternehmenskanal, der archiviert und durchsuchbar ist, zu führen. Der Vorteil hierbei ist allerdings, dass auch andere nach Dir mit ähnlichen Vorschlägen kommen werden, anstatt das Gleiche nocheinmal vorzuschlagen, können sie aus dem was bereits diskutiert wurde lernen und von dort aus starten.

Ein Contributor zu sein bedeutet enger mit dem Hostteam zusammen zu arbeiten als jemand, der nur ein Feature anfragt. Trotzdem ist man als Contributor nicht verantwortlich für das Softwareprojekt, zu dem man beiträgt.

Infolgedessen hat das Hostteam das letzte Wort bezüglich der Umsetzung des Beitrags. Es ist besser bescheiden an die Sache heranzugehen, immer in dem Glauben daran, dass letztendlich alle zum Nutzen des gemeinsamen Projekts zusammenarbeiten. Es hilft offen und transparent zu sein, nicht nur bzgl. was implementiert wurde und wie, sondern auch warum die Änderung benötigt wird.

Nimm jedes Feedback als ein Geschenk an: Andere versuchen Deine Lösung zu verbessern, um Dich vor vorhersehbaren Probleme zu bewahren.

Natürlich kann es auch passieren, dass das Hostteam Deinen Beitrag nicht akzeptiert. In diesem Fall hilft es, mit dem Team zusammenzuarbeiten und herauszufinden, ob es nicht vielleicht einen Teilaspekt gibt, der im Hostprojekt umgesetzt werden kann. Arbeite mit dem Team zusammen, um den Teilaspekt zu implementieren, und finde dann einen Weg den fehlenden Part in Deinem Projekt zu lösen.