Lasst uns mit der wohl am häufigsten mit der Rolle des Trusted Committers in Verbindung gebrachten Verantwortung beginnen: Sicherung der Produktqualität
In einer InnerSource-Community sind die Trusted Committer verantwortlich für alle technologisch basierten Entscheidungen, speziell diejenigen, die Einfluss auf die Produktqualität haben. Ownership bedeutet hier, sicherzustellen, dass getroffene Entscheidungen umgesetzt werden. Das schließt die Kommunikation dieser Entscheidungen und - falls notwendig - deren wirksame Vertretung innerhalb und außerhalb der Community mit ein. Das bedeutet aber nicht, dass alle technischen Entscheidungen von den Trusted Committer getroffen werden müssen, noch dass diese die komplette Implementierungsarbeit erledigen.
Die Aufgabe eines Trusted Committer ist es, die Qualitätsstandards innerhalb ihrer Community zu kommunizieren und zu erläutern, vor allem sie so zu formulieren, dass sie für ihre Contributors verständlich und anwendbar sind. Dies beinhaltet natürlich auch die schriftliche Dokumentation, dies ist für eine InnerSource-Community der effektivste Weg diese Standards vorzuleben und Beispiele zu geben.
Wir glauben, dass es ein erstrebenswertes Ziel für eine InnerSource-Community sein sollte, sich nicht nur in der Arbeitsorganisation von klassischen Entwicklungsprojekten zu unterscheiden, sondern auch in der Qualität der Software, die sie entwickelt. Softwarequalität auf höchstem Niveau ist eine Grundvoraussetzung, um Vertrauen seitens des Managements und der Benutzer in eine InnerSource-Community aufzubauen und aufrecht zu erhalten. Wir alle wissen, wie schnell dieses Vertrauen durch ein einziges fehlerhaftes Release erschüttert werden kann.
Trusted Committer stellen außerdem sicher, das in der Community die notwendige Infrastruktur und die notwendigen Tools zur Verfügung stehen, welche zur Entwicklung qualitativ hochwertiger Software benötigt werden. Zur Sicherstellung der Qualität wird am häufigsten das Peer Review genutzt, welches normalerweise Bestandteil der Pull Requests (PR’s) ist. Während für gewöhnlich jedermann Pull Requests starten und daran teilnehmen kann indem er auf notwendige Verbesserungen hinweist, ist es normalerweise nur dem Trusted Committer möglich Beiträge zu akzeptieren oder abzulehnen. Das ist es, was wir an anderer Stelle damit gemeint haben, wenn wir davon sprachen, dass "Trusted Committer Code in Produktion bringen können". Trusted Committer sollten den Contributors auch während eines PR’s helfen ihre Beiträge fertig zu stellen.
Dennoch ist es letztendlich die Aufgabe des Contributors, dies zu erreichen. Es ist nicht Aufgabe eines Trusted Committer, alle Beiträge grundsätzlich zu akzeptieren, sondern nur diejenigen, die die definierten Kriterien bezüglich Qualität, Umfang und Projektausrichtung erfüllen. Trusted Committer sollten vermeiden, den Code eines Contributors selbst umzuschreiben, um ihn passend zu machen, selbst wenn dadurch ein höherer Aufwand bei der Unterstützung des Contributors bei einem PR anfällt. Trusted Committer nehmen eine längerfristige Perspektive ein und verstehen, dass diese Art der Unterstützung eine Investition in die Langlebigkeit der Community darstellt und dies langfristig die Entwicklungsgeschwindigkeit der Community erhöht.
Manchmal sind Anforderungen und Einschränkungen des Projekts nicht von vorne herein bekannt, sondern werden erst während der Entwicklung erkannt. Trusted Committer sind auch dafür verantwortlich, dass diese Ergebnisse erfasst und dokumentiert werden, so dass diese sowohl den Product Owners als auch den Contributors zugänglich sind.
Der Aufgabenbereich des Trusted Committer in Bezug auf Qualität geht über Pull Requests hinaus. Trusted Committer betrachten Qualität als strategische Komponente und stellen die Langlebigkeit der zu erstellenden Software sicher. Dies beinhaltet codeorientierte Verantwortlichkeiten im Sinne von Verständlichkeit des Quellcodes bis hin zur Wahrung der konzeptionellen Integrität der gesamten Software. Dazu gehören auch managementorientierte Aufgaben wie zum Beispiel sicherzustellen, dass die Community genügend Zeit für Refaktorierung der Software hat, oder wenn nötig, die Verschiebung von Releaseterminen zugunsten der Verbesserung der Softwarequalität zu veranlassen. Die Effektivität des Trusted Committers hängt stark von der Wartbarkeit des Codes ab.
Fehlt letzteres, müssen die Trusted Committer viel ihrer wertvollen Zeit investieren um Workarounds für Fehler oder anfällige Architektur zu validieren und zu dokumentieren. Dadurch haben sie nicht ausreichend Zeit, um Contributors mit Onboarding und Mentoring zu unterstützen.
Zusammengefasst ist das Sicherstellen der Produktqualität eine Schlüsselverantwortung der Trusted Committer. Sie bestimmen die Qualitätsstandards und gehen mit gutem Vorbild voran. Sie unterstützen bei Pull Requests und helfen den Contributors die Qualitätsstandards zu erfüllen. Weiterhin übernehmen sie auch die Verantwortung für die langfristige Wartbarkeit und Qualität der Software.
