Praktische Details der Contributor Rolle

Ein wesentlicher Unterschied ist die Durchlaufzeit. Bei jedem erstmaligen Beitrag kommen Sie zu einem neuen (Gast-)Team. Daher müssen Sie deren Codebasis, die verwendeten Technologien und auch deren bevorzugte Entwicklungsumgebung (z. B. Test-Framework, Build-System) kennenlernen. Selbst in Fällen, in denen diese Art von Tooling standardisiert ist, wird jedes Team einige individuelle Eigenheiten entwickelt haben. Neben der technischen Seite können Sie auch mit Unterschieden in der Kommunikation konfrontiert werden (z. B. Code-Reviews). Selbst wenn Sie nach einiger Zeit wiederkommen, haben sich die Arbeitsweise und die Mitglieder der Teams möglicherweise verändert. Nehmen Sie sich die Zeit, die Sie brauchen würden, wenn Sie sich mit einem Freund treffen würden, den Sie schon lange nicht mehr gesehen haben und den Sie jetzt besuchen.

Geben Sie sich genügend Vorlaufzeit. Beginnen Sie früh genug, so dass Ihre Arbeit zu dem Zeitpunkt, an dem Sie sie brauchen, zur Verfügung steht. Es ist besser, anfangs mehr Zeit einzuplanen - Sie werden ein Gefühl für die Bearbeitungszeiten bekommen, wenn Sie mit dem Gastteam zusammenarbeiten. Häufig werden Sie feststellen, dass sich die Durchlaufzeiten pro Host-Team verringern, nachdem Sie einige erfolgreiche Beiträge für dieses Host-Team geleistet haben. Dieser Effekt ist auch bei Open Source zu beobachten, mehr dazu können Sie hier lesen.

In Ihren klassischen Teams hatte jeder eine Vorstellung von den erwarteten Durchlaufzeiten. Im InnerSource-Kontext ist dies möglicherweise nicht der Fall, entweder aufgrund großer Zeitzonenunterschiede (z. B. Seattle, USA mit PDT vs. Berlin, Deutschland mit MESZ) oder weil Sie nicht wie mit Ihrem ursprünglichen Team Vollzeit zur Verfügung stehen, selbst wenn sich das Team am selben Ort befindet wie Sie selbst. Um also Frustration auf beiden Seiten, Ungeduld und andere nicht vertrauensbildende Effekte zu vermeiden, müssen Sie explizit ein Erwartungsmanagement in Bezug auf Ihre erwarteten Reaktionszeiten betreiben. Eine Möglichkeit ist es, auf das Feedback eines Trusted Committers schnell mit einem "Ich kümmere mich darum, werde aber in den nächsten Tagen nicht dazu kommen" zu reagieren, wenn Sie wissen, dass Sie erst in ein paar Tagen darauf zurückkommen können. Idealerweise können Sie ihnen eine grobe Schätzung geben, wann Sie wahrscheinlich Zeit haben werden, um sich ihren Beitrag anzusehen. Auf diese Weise schaffen Sie Vertrauen durch Verlässlichkeit, selbst bei nicht physischem Kontakt, größerer Entfernung oder anderen asynchronen Medien. Auf der Grundlage dieses Vertrauens können Sie Unsicherheiten auf dem vor Ihnen liegenden Weg der Zusammenarbeit überwinden.

InnerSource legt großen Wert auf schriftliche Kommunikation - vor allem, wenn es um Projektentscheidungen geht. Bedeutet das, dass die persönliche Kommunikation verboten ist?

Natürlich nicht: Während die schriftliche Kommunikation im Hinblick auf die Archivierung und Suche von Vorteil ist, ist die persönliche Kommunikation im Hinblick auf die Kommunikationsbandbreite von Vorteil. Versuchen Sie, sich Zeit zu nehmen, um sich mit den Menschen hinter den Namen zu treffen. Wenn möglich, treffen Sie sich mit ihnen zum Essen oder ihren Lieblingsgetränken. Wenn Sie die Menschen sprechen hören können und ihre Eigenheiten kennen, wird die Zusammenarbeit einfacher.

Haben Sie eine großen Beitrag, die Sie beisteuern möchten? Ausgezeichnet! Wäre es nicht furchtbar, wenn Ihre ganze Arbeit umsonst wäre? Das kann passieren, wenn das Team des Gastgebers bereits etwas sehr Ähnliches entwickelt, die Software veraltet ist oder das, was Sie vorschlagen, nicht in das Projekt passt. Dieses Problem tritt häufig auf, und viele Teambeziehungen haben darunter gelitten, dass man sich nicht im Voraus einig war, dass ein Beitrag gut passt.

Machen Sie sich selbst und das Team des Gastgebers glücklich (und sparen Sie möglicherweise Arbeit), indem Sie a priori die Zustimmung für die Kontribution einholen, bevor Sie an Ihrem Beitrag arbeiten und einen Pull Request starten. Sie müssen verstehen, wie das Team des Gastgebers möchte, dass Sie dies erreichen. Am besten fragen Sie einen Trusted Committer, wie Sie Ihren Vorschlag am besten besprechen können.

Eine Weisheit aus dem Open Source Bereich die sich immer wieder als wahr erweist ist, dass wenn Sie wählen können, wie Sie Ihren Vorschlag diskutieren wollen, Sie versuchen sollten, einen schriftlichen Weg zu wählen. Idealerweise wählen Sie den Weg, bei dem die Artefakte öffentlich, durchsuchbar und dauerhaft verlinkbar sind, sodass Sie oder andere später auf Ihren Vorschlag verweisen zu können.

Diese Art von frühzeitiger Einigung auf einer mehr abstrakten Ebene spart Zeit bei der Überarbeitung oder Ablehnung Ihres Pull Requests im Nachhinein.

Großartig, Sie haben sich mit der Herangehensweise des Host-Teams vertraut gemacht und sie freuen sich darauf, Ihren Pull Request zu erhalten. Welche Stolpersteine warten nun auf Sie?

Erstens werden Sie in weniger direktem Kontakt mit dem Gastgeberteam stehen. Zweitens wird von Ihnen nicht erwartet, dass Sie so sachkundig und kompetent sind, wie Sie es vielleicht bei den Vollzeitprojekten Ihres Teams sind. Wie können Sie nun am besten damit umgehen?

Versuchen Sie, die Dokumentation, die Gesprächsarchive und die Code-Artefakte des Gastteams durchzusehen, um sich selbst und das Gastteam zu entlasten. Dies ist ähnlich wie die Situation, in der Sie und wahrscheinlich die meisten Leute sich befinden, wenn sie eines der beliebten OSS-Projekte verwenden.

Ähnlich wie bei Open-Source-Projekten sollten Sie das Host-Team um Hilfe bitten, wenn sie an einer Stelle allein nicht mehr weiter kommen. Die Fragen, die Sie stellen, und die Antworten, die Sie erhalten, werden anderen helfen, die nach Ihnen kommen gleiche oder ähnliche Probleme zu lösen. Stellen Sie sicher, dass Ihre Kommunikation in einem durchsuchbaren Archiv landet, das eng mit dem Projekt selbst verbunden ist. Sollten Sie einfache Verbesserungsmöglichkeiten sehen, um das besagte Ziel in der asynchronen, textuellen Kommunikation zu erreichen, wenn es noch nicht erreicht ist, können Sie versuchen, Ihrem Gastgeberteam - sehr höflich - eine Verbesserung vorzuschlagen. Manchmal entsteht der Status quo aus reinem Zufall und bleibt so, weil niemand eine andere Idee hatte oder sich genug dafür interessierte. In solchen Fällen können Verbesserungsvorschläge willkommen sein. Es ist für beide Seiten nicht gut, wenn Sie sich ewig mit einem Problem herumschlagen, das in einem kurzen Gespräch mit jemandem, der sich mit dem Projekt besser auskennt, gelöst werden könnte. Es ist in Ordnung, um Hilfe zu bitten.

Es gibt jedoch einen entscheidenden Unterschied, der Ihnen und anderen Personen in der Zukunft Vorteile bringt: In fast allen Fällen sollten Sie die offiziellen Kommunikationskanäle des Projekts bevorzugen. Das kann eine Mailingliste, ein Chatroom, ein Issue Tracker oder etwas ähnliches sein, je nachdem ob eine eher synchrone oder asynchrone Art der Interaktion bevorzugt ist, oder sich ändernden Anforderungen der Kommunikation. Allen gemeinsam ist, dass sie textbasiert, archiviert, durchsuchbar und mit stabilen Links versehen sind - das bedeutet, dass Ihre Frage und die Antwort aufgeschrieben werden und die Referenzen, die Sie in diesen Antworten vernetzen, ebenfalls erreichbar bleiben. Auf diese Weise können Sie bei Ihrer Suche von diesem passiv dokumentierten Wissen profitieren UND künftigen Mitwirkenden helfen, denselben Vorteil zu haben. Eine solch erstellte Dokumentation könnte sogar dazu dienen, die "offizielle" Dokumentation zu bereichern, falls sie besonders wertvolle Schätze enthält - wie z.B. wichtige Definitionen, die ad-hoc erstellt wurden.

Wenn Sie bei Ihrer Arbeit auf fehlende (oder veraltete) Dokumentation stoßen, tun Sie dem nächsten Mitwirkenden einen Gefallen und aktualisieren Sie sie mit dem,was Sie entdeckt haben. Projektteams freuen sich oft über Ergänzungen, Aktualisierungen oder Korrekturen ihrer bestehenden Dokumentation - Sie haben gerade eine weitere Gelegenheit gefunden, einen Beitrag zu leisten! (Oder geben Sie ihnen einfach höflich Feedback über Ihre Erfahrungen und was Ihnen geholfen hätte).

Jeder von uns hat seine eigenen Vorlieben und Meinungen über den Stil des Codes, die Einrückung, usw. Das Projekt des Gastteams hat diese ebenfalls. Versuchen Sie sich an die expliziten und impliziten Konventionen des Gastgeberteams zu halten, auch wenn sie nicht in der `CONTRIBUTING.md` des Projekts dokumentiert sind. Wenn Sie unsicher sind, können Sie immer höflich nachfragen. Nichtsdestotrotz ist ein Gastbeitrag für ein Feature oder eine Fehlerbehebung nicht der richtige Zeitpunkt, um eine neue Art der Strukturierung oder Formatierung des Projektcodes einzuführen.

Hier geht es im Wesentlichen darum, den Trusted Committer in die Lage zu versetzen, den Beitrag ohne Ihre Anwesenheit zu validieren und eine einfache Wartbarkeit zu gewährleisten. Stellen Sie sich vor dass Sie eine Funktion entwickelt oder die Performance von existierendem Code verbessert haben und ihr Code ist aber nicht einfach zu verstehen und unnötig kompliziert (oder koennte auf den ersten Blick wie eine adhoc / inkorrekte Loesung erscheinen) . Wenn Sie dies mit einem Test abgedeckt haben - und idealerweise in einem Kommentar ein paar Worte über die Gründe dafür verloren haben - wird ein zukünftiger Leser an den Zweck des Codes erinnert, und der Test (oder die Tests) wird sicherstellen, dass der Wert, den Ihr Code berechnet, erhalten bleibt - selbst in neuen Implementierungen. Um dies zu erreichen, gehen Sie wie folgt vor:

Sie sollten sicherstellen, dass Ihr Pull-Request alle Aktualisierungen der Dokumentation enthält, die für Ihre Änderungen relevant sind. Sollte sich die Dokumentation an einem anderen Ort befinden, fügen Sie sie dort hinzu und verlinken Sie sie in Ihrem Pull Request.

Um die eigentliche Überprüfung des Codes für den Trusted Committer oder andere Personen, die den Code überprüfen, so einfach wie möglich zu machen, versuchen Sie diese Hinweise zu befolgen: