Die Rolle des Trusted Committers (TC) ist eine der Schlüsselrollen einer InnerSource-Organisation. Stell Dir einen Trusted Committer als jemanden im Team vor, auf den Du bei wichtigen technischen Entscheidungen vertraust, und als einen fähigen Betreuer, der dem Committer hilft, dessen Beitrage zielführend in das Produkt integrieren zu können. Die Rolle eines Trusted Committers ist sowohl anspruchsvoll als auch wertgeschätzt. Sie ist mehr als nur ein bürokratischer Pförtner, im Gegenteil, sie ist maßgeblich für den Erfolg jeder InnerSource Organisation.
Allgemein gesagt ist die Rolle des Trusted Committers mehr durch ihre Verantwortlichkeiten als durch ihre Rechte definiert. Auf einer höheren Ebene repräsentieren die Trusted Committers sowohl die Interessen der InnerSource Organisationseinheit als auch die der Produkte, welche von der entsprechenden Organisationseinheit entwickelt werden. Trusted Committers kümmern sich gleichermaßen um eine funktionierende Organisation und ein technisch einwandfreies Produkt. Daher umfasst die Rolle sowohl technik- als auch teamorientierte Verantwortlichkeiten. Wir werden uns die beiden Dimensionen in den folgenden Abschnitten genauer anschauen.
Bevor wir aber in die Details gehen, was die eigentliche Aufgabe eines Trusted Committers ist, wollen wir uns zunächst auf höherer Abtraktionsebene anschauen, wie sich die Rolle des Trusted Committers von den anderen Rollen in der InnerSource unterscheidet und dabei erklären, warum wir glauben, dass die Bezeichnung sowohl passend als auch wichtig ist. Lasst uns beginnen mit der Rolle des Contributors. Ein Contributor — wie schon der Name nahelegt — liefert Beiträge zu einer InnerSource-Organisationseinheit. Diese Beiträge können entweder code oder andere Artefakte wie z.B. Fehlerreports, Änderungsanforderungen oder Dokumentation sein.
Contributors können, müssen aber nicht Teil der Organisation sein, zu der sie Beiträge liefern. Sie können z.B. von einem anderem Team beauftragt werden, ein Feature zu entwickeln, welches das Team benötigt. Deshalb sprechen wir im Fall von Contributors manchmal auch von Guests oder Teilen eines Guest_Teams. Der Contributor ist verantwortlich dafür, dass er sich anpasst und die Erwartungen und Regeln der jeweiligen Organisationseinheit, zu der einen Beitrag liefert, erfüllt und respektiert.
Der Trusted Committer ist immer ein Mitglied der InnerSource-Organisationseinheit (manchmal auch Host Team genannt). In diesem Vergleich wäre der Trusted Committer sowohl für den Bau eines Hauses als auch für die Hausordnung verantwortlich, in deren Umgebung die Gäste sich wohlfühlen und effektiv miteinander arbeiten können. Verglichen mit den Contributors haben Trusted Committers sich die Verantwortlichkeit verdient, näher am produktiven Code zu arbeiten und sind grundsätzlich befugt, Aufgaben auszuführen, die mit einem höheren Riskio verbunden sind.
Der Product Owner (PO) ist die dritte Rolle bei InnerSource. Ähnlich wie bei agilen Prozessen ist der PO verantwortlich für die Definition und Priorisierung von Anforderungen und User Stories, welche die jeweilige Organisationseinheit umsetzen soll. Der PO arbeitet eng mit dem Trusted Committer zusammen, z.B. um sicherzustellen, dass ein angefordertes oder bereitgestelltes Feature tatsächlich Bestandteil des Produkts sein soll. Speziell in kleineren InnerSource-Organisationen kann der Trusted Committer meistens auch die Aufgaben des PO wahrnehmen. Schau Dir für weiterführende Informationen unser Product Owner Learning Path segment an.
Warum Rollennamen von Bedeutung sind
Man findet die Rolle des Trusted Committers in jeder erfolgreichen InnerSource-Organisation, wenngleich die Rolle nicht in jeder Organisation so genannt wird. Manche Organisationen benutzen den Begriff Maintainer, aber diese Bezeichnung überschneidet sich mit anderen technischen Rollen, wie zum Beispiel die in GitHub definierte Role des "Maintainers". Auch Apache nutzt den Begriff des Committers, aber dort wird die Rolle mit weniger und meist technisch orientierten Verantwortlichkeiten verbunden. Durch die zusätzlichen auf die Organisation bezogenen Verantwortlichkeiten geht die hier definierte Rolle des Trusted Committer weit darüber hinaus. Der Begriff "Trusted" in Trusted Committer bezieht sich auf das Vertrauen, das von der Organisation in diese Person gesetzt wird und das aus diesem heraus sowohl vom Management als auch der Arbeitsebene getragenen Mandat, die übertragenen Aufgaben zu erfüllen. Durch Förderung von Offenheit und Transparenz schaffen Trusted Committers Vertrauen in den Prozess und ebenso in das entwickelte Produkt.
So, wie in der Softwarentwicklung Namenskonventionen wichtig sind, stellen eindeutige Namen für Rollen sicher, dass überall ein gleiches Verständnis darüber herrscht, welche Aufgaben die jeweilige Rolle in einer Organisationseinheit wahrnimmt.
Nachdem Du nun ein grundsätzliches Verständnis von der Rolle hast, wieso der Begriff Trusted Committer angemessen ist und Du weißt, wie ein Trusted Committer mit anderen Rollen in einem Software-Projekt interagiert, lass uns einen kurzen Blick auf die Verantwortlichkeiten eines Trusted Committers werfen.
Verantwortlickeiten
Trusted Committers haben verschiedene Verantwortlichkeiten, unter anderem:
Wir werden diese Verantwortlichkeiten in den folgenden Kapiteln weiter vertiefen, bitte schau Dir dazu auch das Kapitel 07 becoming a Trusted Committer am Ende an.
