Commençons par la responsabilité la plus souvent associée au rôle de Trusted Committer: garantir la qualité des produits.
Dans une communauté InnerSource, les Trusted Committers sont propriétaires de toutes les décisions liées à la technologie, en particulier celles liées à la qualité des produits. La propriété implique la nécessité de s’assurer que les décisions en place sont suivies. Cela comprend la communication et, si nécessaire, la défense de ces décisions, à l’intérieur et à l’extérieur de la communauté. Mais les Trusted Committers ne prennent pas nécessairement toutes les décisions liées à la technologie eux-mêmes ou ne font pas tout le travail pour les mettre en œuvre.
Le travail du Trusted Committer consiste à communiquer et à clarifier les normes de qualité dans leur communauté et à les formuler d’une manière compréhensible et exploitable par leurs https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ]. Cela comprend la documentation écrite, bien sûr, mais le moyen le plus efficace pour les Trusted Committers de communiquer ces normes de qualité est donné l’exemple. Nous pensons que cela peut être un objectif valable pour une communauté InnerSource d’essayer de se distinguer des projets de développement de logiciels traditionnels non seulement dans la façon dont ils organisent le développement, mais aussi dans la qualité du logiciel qu’ils produisent. Un niveau élevé de qualité des logiciels est essentiel pour établir et maintenir la confiance dans la communauté InnerSource de la part de leurs utilisateurs et de leur direction. Nous savons tous comment une mauvaise sortie peut briser cette confiance en un instant.
Les Trusted Committers s’assurent également que la communauté dispose de l’infrastructure et des outils dont elle a besoin pour produire des logiciels de qualité. L’examen par les pairs, généralement effectué dans le cadre de pull requests (PR), est le plus souvent utilisé pour assurer la qualité. Alors que tout le monde peut généralement commencer et participer à des pull requests en signalant les améliorations nécessaires, ce n’est généralement que le Trusted Committer qui peut finalement accepter et fusionner ou rejeter une contribution. C’est ce que nous avons voulu dire plus tôt lorsque nous avons dit: "Les Trusted Committers peuvent poussée le code proche de la production". Les Trusted Committers devraient également aider les Contributors lors d’une PR pour que leurs contributions franchissent la ligne d’arrivée.
Cela dit, c’est au bout du compte le travail du contributeur de faire en sorte que cela se produise. Le travail d’un Trusted Committer n’est pas d’accepter toutes les contributions par défaut, mais d’accepter uniquement celles qui répondent aux critères définis en termes de qualité et de portée. Et les Trusted Committers devraient éviter de réécrire le code d’un contributeur pour le rendre "adapté" autant que possible, même si cela signifie passer plus de temps à soutenir Contributors lors d’une PR. Les Trusted Committers adoptent une perspective à long terme et comprennent que ce type de soutien est un investissement dans la longévité de la communauté, et qu’il augmentera la vitesse de développement de la communauté à long terme.
Parfois, les exigences ou les limitations du projet ne sont pas connues à l’avance et sont plutôt découvertes lors du développement. Les Trusted Committers sont également chargés de s’assurer que ces résultats sont saisis et documentés à la fois pour les Product Owners et pour les https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
Mais la compétence du Trusted Committer en matière de qualité va au-delà des pull requests. Les Trusted Committers pensent à la qualité à un niveau stratégique et assurent la longévité du logiciel en cours de construction. Cela implique des responsabilités axées sur le code, allant de la garantie de la propreté du code au maintien de l’intégrité conceptuelle du logiciel. Il implique également des tâches axées sur la gestion, telles que s’assurer que la communauté dispose de suffisamment de temps pour restructurer son logiciel ou déplacer une date de sortie en faveur d’améliorations de la qualité, si nécessaire. L’efficacité du Trusted Committer est fortement liée à la santé du code.
En l’absence de ce dernier, les Trusted Committers devront consacrer une grande partie de leur temps précieux à la validation et à la documentation des solutions palliatives aux bogues ou à une architecture fragile et n’auront pas assez de temps à consacrer à l’intégration et au mentorat https://innersourcecommons.org/learn/learning-path/contributor [ Contributeurs ].
En conclusion, la garantie de la qualité des produits est une responsabilité essentielle des Trusted Committers. Ils établissent des normes de qualité et donnent l’exemple. Ils participent aux pull requests et aident les Contributors à respecter les normes de qualité. Ils assument également la responsabilité de la santé à long terme du logiciel.
