Parcours d’apprentissage : Trusted Committer

La section Trusted Committer couvre ce que signifie être un InnerSource Trusted Committer et comment prendre en charge vos contributeurs.

Présentation du rôle Trusted Committer

Le rôle Trusted Committer (TC) est l’un des rôles clés d’une communauté InnerSource. Pensez à Trusted Committers comme les gens d’une communauté que vous avez confiance avec des décisions techniques importantes et avec les contributeurs de mentorat pour finalement obtenir des contributions sur la ligne d’arrivée. Le rôle Trusted Committer est à la fois exigeant et gratifiant. C’est plus que d’être un gardien d’accès opinionné et est instrumental pour le succès de toute communauté InnerSource.

De manière générale, le rôle de Trusted Committer est défini par ses responsabilités plutôt que par ses privilèges. À un niveau très élevé, Trusted Committers représente les intérêts de sa communauté InnerSource et les produits qu’elle construit. Ils se préoccupent de la santé de la communauté et du produit. Donc en tant que Trusted Committer, vous aurez à la fois des responsabilités technologiques et communautaires. Nous allons explorer ces deux dimensions dans les sections suivantes.

Avant d’entrer dans les détails de ce qu’un Trusted Committer fait réellement, laissez-nous passer un certain temps à confronter le rôle Trusted Committer avec d’autres rôles dans InnerSource à un haut niveau d’abstraction et expliquer pourquoi nous pensons que le nom est à la fois apt et important. Commençons par le Contributeur rôle. A Contributeur — comme son nom l’indique — apporte des contributions à une communauté InnerSource. Ces contributions peuvent être des artefacts codés ou non codés, comme les rapports de bogues, les requêtes de fonctionnalités ou la documentation.

Contributeurspeut ou non faire partie de la communauté. Ils pourraient être envoyés par une autre équipe pour développer une fonctionnalité dont l’équipe a besoin. C’est pourquoi nous nous référons parfois aussi àContributeurscommeInvitésou dans le cadreÉquipe invitée. LesContributeurest responsable de « s’adapter » et de se conformer aux attentes et aux processus de la collectivité.

LesTrusted Committerest toujours membre de la communauté InnerSource, qui est parfois appeléeÉquipe hôte. Dans cette analogie, le Trusted Committer est responsable à la fois de construire la maison et de fixer les règles de la maison pour s’assurer que leurs invités sont confortables et peuvent travailler ensemble efficacement. Par rapport aux contributeurs, Trusted Committers a gagné la responsabilité de pousser le code plus près de la production et est généralement autorisé à exécuter des tâches qui ont un niveau de risque plus élevé associé à eux.

Les responsable produit (PO) est le troisième rôle de InnerSource. Tout comme les processus agiles, le BP est chargé de définir et de hiérarchiser les exigences et les histoires que la collectivité doit mettre en oeuvre. Le PO interagit souvent avec le Trusted Committer (par exemple, pour s’assurer qu’une fonction demandée ou fournie appartient réellement au produit). En particulier dans les communautés InnerSource de base, le Trusted Committer agit généralement comme un PO. Regardez notre responsable produit Segment Chemin d’apprentissage pour des informations plus détaillées.

Le rôle du Trusted Committer est présent dans toutes les communautés de InnerSource, mais pas dans toutes les communautés. Certaines communautés utilisent le terme Maintainer, mais ce terme est en conflit avec d’autres rôles techniques comme le rôle « Maintainer » défini par GitHub, par exemple. Apache utilise le termeCommutateur, mais ils attachent de moins en moins et surtout des responsabilités technologiques à ce rôle. Avec ses responsabilités communautaires supplémentaires, le rôle de Trusted Committer va au-delà. La «fiducie» de Trusted Committer signifie que cette personne est fiable et donc habilitée par sa direction et sa communauté à faire son travail. En favorisant l’ouverture et la transparence, Trusted Committers renforce la confiance dans le processus et dans le produit en cours de construction.

Comme dans le cas des logiciels d’écriture, le fait de choisir les bons noms pour les rôles et de le faire garantit que chacun a la même compréhension des rôles joués dans la communauté.

Maintenant que vous avez une compréhension de base du rôle, pourquoi utiliser le terme Trusted Committer est approprié, et savoir comment un Trusted Committer peut interagir avec d’autres rôles communs dans un projet logiciel, laissez-nous examiner rapidement les responsabilités d’un Trusted Committer.

Trusted Committers a diverses responsabilités, notamment :

• Assurer la qualité des produits
• Maintenir la santé de la collectivité
• Réduire les obstacles à l’apport de contributions
• Amélioration de la communauté
• Promouvoir les besoins de la communauté

Nous examinerons ces responsabilités plus en profondeur dans les pages suivantes et explorerons également la voie à suivre pour devenir un Trusted Committer à la fin de cet article.

Assurer la qualité des produits

Commençons par la responsabilité la plus souvent associée au rôle Trusted Committer : assurer la qualité du produit.

Dans une communauté InnerSource, le Trusted Committersproprestoutes les décisions liées à la technologie, en particulier celles relatives à 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, au besoin, la défense de ces décisions, à l’intérieur et à l’extérieur de la collectivité. Mais Trusted Committers ne fait pas nécessairement toutes les décisions liées à la technologie eux-mêmes ou fait tout le travail pour les mettre en œuvre.

C’est la mission de Trusted Committer.S de communiquer et de clarifier les normes de qualité dans leur communauté et de les formuler d’une manière compréhensible et réalisable par leur Contributeurs. Cela inclut la documentation écrite, bien sûr, mais la façon la plus efficace pour Trusted Committers de communiquer ces normes de qualité est par exemple. Nous pensons qu’il peut être utile pour une communauté InnerSource d’essayer de se distinguer des projets traditionnels de développement de logiciels 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 gestion. Nous savons tous comment une mauvaise libération peut briser cette confiance en un instant.

Trusted Committers s’assure également que la communauté dispose de l’infrastructure et des outils nécessaires pour produire des logiciels de qualité. L’examen par les pairs, habituellement effectué dans le cadre des demandes de tirage, est le plus souvent utilisé pour assurer la qualité. Alors que tout le monde peut habituellement commencer et participer aux demandes de tirage en soulignant 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 voulions dire plus tôt en affirmant que « Trusted Committers peut rapprocher le code de la mise en production ». Trusted Committers devrait également aider Contributeurs lors d’un PR pour obtenir leurs contributions sur la ligne d’arrivée.

Cela dit, c’est en fin de compte le travail du contributeur de faire cela. Le travail d’un Trusted Committer n’est pas d’accepter toutes les contributions par défaut, mais seulement celles qui répondent aux critères définis en termes de qualité et de portée. Et Trusted Committers devrait éviter de réécrire un code contributeur pour le rendre « adapté » autant que possible, même si cela signifie passer plus de temps à soutenir Contributeurs dans un PR. Trusted Committers prend une perspective à long terme et comprend que ce type de soutien est un investissement dans la longévité de la communauté, et il augmentera la vitesse de développement de la communauté à long terme.

Parfois, les exigences ou les limites du projet ne sont pas connues à l’avance et sont plutôt découvertes pendant le développement. Trusted Committers est également responsable de s’assurer que ces résultats sont capturés et documentés pour les deux Propriétaires de produits et les Contributeurs.

Mais la compétence de Trusted Committer.S en matière de qualité va au-delà des demandes de tirage. Trusted Committers pense à la qualité au niveau stratégique et assure la longévité du logiciel en cours de construction. Cela implique des responsabilités axées sur le code, qui consistent à assurer la propreté du code et à maintenir l’intégrité conceptuelle de l’ensemble du logiciel. Il implique également des tâches de gestion telles que s’assurer que la communauté dispose de suffisamment de temps pour refactorer son logiciel ou déplacer une date de sortie en faveur d’améliorations de qualité, si nécessaire. L’efficacité du Trusted Committer est fortement liée au code santé.

En l’absence de ce dernier, Trusted Committers devra consacrer une grande partie de son temps précieux à valider et documenter les solutions de rechange pour les bugs ou une architecture fragile et n’aura pas assez de temps pour passer à bord et au mentorat. Contributeurs.

En conclusion, assurer la qualité des produits est une responsabilité clé de Trusted Committers. Ils fixent des normes de qualité et donnent l’exemple. Ils participent aux demandes de tirage et d’aide Contributeurs satisfaire aux normes de qualité. Ils assument également la responsabilité de la santé à long terme du logiciel.

Assurer la santé de la collectivité

L’introduction souligne que Trusted Committers a des responsabilités à la fois technologiques et communautaires. Il ne suffit pas de se concentrer uniquement sur le code et le code santé. Pour assurer le succès à long terme, Trusted Committers devrait s’efforcer de maintenir la communauté en bonne santé. Pour cette raison, ils doivent trouver un bon équilibre entre la qualité des produits et la croissance d’une collectivité saine.

À quoi ressemble une communauté saine? Tout simplement, dans une communauté saine, Contributeurs tendance à rester autour, peut passer la plupart de leur temps à développer des logiciels, et sont en mesure de mettre à niveau leurs capacités. Par conséquent, une collectivité en bonne santé augmentera continuellement.

Pourquoi faire Contributeurs Se joindre et rester dans une communauté ? Certains le font parce qu’ils souscrivent au but ou à la mission de la communauté. C’est le travail de Trusted Committer=S de définir clairement et de promouvoir cet objectif. L’importance de cela n’est souvent pas reconnue, mais la commercialisation d’une communauté et de ses produits est vraiment essentielle.

Une autre raison plus évidente pour les gens de rester dans le coin est qu’ils aiment travailler avec d’autres membres de la communauté, y compris le Trusted Committers. Une communauté prospère est une communauté où les membres traitent et communiquent entre eux avec le plus grand respect. Les contributions sont traitées comme des dons ou des dons plutôt que des distractions, et d’excellentes contributions (surtout en premier) sont saluées. Dans tout cela, le travail de Trusted Committer.S est principalement destiné à donner l’exemple à d’autres, comme pour donner l’exemple pour le niveau de qualité du logiciel attendu. Si nécessaire, le Trusted Committers est celui qui devrait créer et promulguer un code de conduite pour la communauté. S’il y a des membres de la communauté dont le comportement est préjudiciable ou toxique pour la santé de la communauté, il incombe à Trusted Committer. Trusted Committers devrait permettre aux gens de se réunir régulièrement (en personne ou virtuellement), de se connaître personnellement et de résoudre pacifiquement les conflits à mesure qu’ils surgissent.

Les gens ont également tendance à rester dans le coin parce que travailler dans une communauté InnerSource est une excellente occasion d’acquérir de nouvelles compétences et de grandir personnellement. C’est là encore que le rôle du Trusted Committer est vraiment important. Trusted Committers devient souvent des mentors pour les développeurs juniors, et passe explicitement du temps pendant les demandes de tirage non seulement en soulignant les domaines à améliorer, mais aussi en expliquant en détail pourquoi quelque chose doit être amélioré et comment le faire. Ils fournissent la théorie ou l’expérience derrière le changement et proposent les meilleures façons de le mettre en œuvre. Ce faisant, Trusted Committers peut accélérer l’apprentissage dans leurs communautés bien au-delà de celui des projets de développement de logiciels traditionnels.

Nous croyons que Trusted Committers devrait prioriser l’embarquement et le mentorat pendant les demandes de retrait avant d’atteindre les dates de sortie communiquées, à moins qu’il n’y ait une très bonne raison de ne pas le faire. Un bon mentorat pendant les demandes de tirage entraîne un niveau de confiance et d’engagement plus élevé Contributeurs, ce qui entraîne à son tour davantage de contributions. Nous en discuterons davantage dans « Mise à niveau de la Communauté ».

Enfin, certaines personnes restent dans les communautés InnerSource parce qu’elles peuvent se concentrer sur le développement de logiciels au lieu d’activités considérées comme des frais généraux ou des déchets, en particulier dans les grandes entreprises qui mettent fortement l’accent sur les processus. Dans ce contexte, l’emploi de Trusted Committer Contributeurs peuvent en fait se concentrer sur leurs projets en communiquant et en adoptant des directives de contribution utiles.

Un aspect important de ces lignes directrices est d’expliquer ce que nous appelonssignalisationdans les requêtes de tirage: à quoi devrait ressembler un commentaire? Qu’est-ce que ça veut dire si jecommeou+1un commentaire? Comment @mentioning quelqu’un avec un préfixe /CC différent de l’utilisation d’un préfixe /FYI ? De façon générale, Trusted Committers doit s’assurer que le processus de contribution ne crée pas plus de problèmes, mais aide plutôt la communauté à identifier et à résoudre les problèmes. En fin de compte, Trusted Committers devrait permettre à sa communauté de trouver des problèmes liés aux processus et de les adapter et de les améliorer autant que possible.

Pour que Trusted Committers puisse s’acquitter de toutes ces responsabilités, il est important qu’elle communique régulièrement avec les membres de la collectivité et qu’elle garde l’oreille au sol. Nous allons entrer plus en détail à ce sujet dans la section intitulée « Promouvoir les besoins de la communauté ».

En résumé, Trusted Committers devrait s’efforcer de créer un environnement accueillant et reconnaissant pour leur Contributeurs qui leur permet de se concentrer sur l’écriture de logiciels et la croissance personnelle en créant des occasions d’apprendre des autres membres de la communauté.

Haut niveau des membres de la Communauté

Il y a un continuum de participation dans une communauté InnerSource. Il y a des gens qui ne connaissent pas la communauté. Nouveaux arrivants pourrait s’intéresser à la communauté et à son produit, mais ne l’ont pas encore utilisé. Consommateurs utiliser le logiciel mais n’avoir peut-être pas contribué. Alors il y a le Contributeurs qui ont fait au moins une contribution, et enfin Trusted Committers, qui prennent la responsabilité du logiciel et de la communauté. En tant que Trusted Committer, vous êtes responsable du déplacement des individus dans ce continuum et du renforcement de leur capacité de contribuer. En ce sens, Trusted Committers agit comme multiplicateurs de force dans leur communauté.

Il est important que Trusted Committers commercialise ses produits et ses collectivités pour augmenter le nombre de nouveaux arrivants et de consommateurs. Ils devraient également communiquer les possibilités d’apporter des contributions aux consommateurs et essayer de susciter et d’aligner les intérêts des consommateurs potentiels. Contributeurs avec celle de la communauté. Ce qui fonctionne souvent bien, c’est que Contributeurs sont en mesure de travailler sur quelque chose qui profite à leur département ou à leur rôle dans l’entreprise. Les outils de développement et l’automatisation en sont de bons exemples.

Enfin, il est de la responsabilité de Trusted Committer Contributeurs en les encourageant à s’attaquer à des tâches difficiles et à les orienter vers l’achèvement. C’est, à notre avis, une responsabilité la plus noble de Trusted Committer, et elle est gratifiante tant pour Trusted Committer que pour le contributeur. Nous avons entendu Trusted Committers dire que le mentorat et le fait de voir les gens augmenter leurs capacités plus que compenser le fait qu’ils ont moins de temps pour passer réellement des logiciels d’écriture.

Comme mentionné dans la section précédente, l’apprentissage et la croissance personnelle sont des raisons pour lesquelles les gens se joignent et restent dans une communauté InnerSource. Mise à niveau de leurs Contributeurs est l’un des outils les plus puissants dont Trusted Committers dispose pour augmenter la vitesse, la production et la longévité de leurs communautés. C’est également l’un des arguments clés pour convaincre la direction de permettre à ses employés de participer à une communauté InnerSource, car cela rendra leurs employés plus précieux pour l’entreprise dans son ensemble et les aidera à conserver les meilleurs talents.

En résumé, Trusted Committers doit attirer Contributeurs et de renforcer leur capacité de contribuer. Cette activité finit par augmenter la capacité de la communauté à créer de meilleurs logiciels plus rapidement. Ils le font en communiquant des occasions de faire des contributions et en aidant et en guidant les contributeurs qui leur permettent de croître.

Réduire les obstacles à l’entrée

Solicitoring contributions in a InnerSource community est plus difficile que dans une communauté Open Source pour un certain nombre de raisons:

• Le seul nombre de potentiels Contributeurs est plus faible dans les communautés InnerSource.
• Les cotisants voudront contribuer pendant leur temps de travail, ce qui signifie qu’ils sont plus limités dans le temps.
• Le travail en InnerSource pourrait ne pas nécessairement faire partie des objectifs de performance officiels des contributeurs, de sorte que le temps passé à travailler sur InnerSource peut sembler nuire à la réalisation de ces objectifs.

C’est pourquoi il est important pour Trusted Committers de faire les processus pour faire des contributions et à bord Contributeurs autant que possible. Un certain nombre de choses peuvent aider :

• Avoir un bon README.md dans chaque dépôt de code. Un bon README.md explique ce qui se trouve dans le dépôt et à quoi il peut être utilisé. En outre, il devrait fournir des instructions détaillées sur la façon d’obtenir, de construire, de tester et d’utiliser le logiciel dans le dépôt, y compris des informations sur la licence.
• Avoir un bon CONTRIBUTING.md qui décrit ce qui est attendu du Contributeur. Il devrait répondre à des questions communes, telles que :
  • Comment soumettre un rapport de bogue ou une requête de fonctionnalité ?
  • Qui puis-je contacter si j’ai des questions?
  • Quelles sont les conventions pour le style de code, la branchement ou le commit des messages?
  • Quelle est la définition de « fait » pour une contribution?
  • Quelles sont les étapes du processus qui régissent les contributions?
  • Qu’attend-on de moi pour appuyer le code de contribution après que la contribution ait été acceptée?
  • Quel est le code de conduite et quelles sont les lignes directrices sur le fonctionnement de la collectivité?

Si vous avez une licence interne attachée au logiciel, qui dans certaines entreprises est une condition préalable au partage de logiciels entre personnes morales, inclure une copie de cette licenceetune explication des droits et obligations en termes de laïques.

En plus de ces tâches documentaires, comme le développement de logiciels Open Source, il devrait être facile et simple d’exécuter et de tester le logiciel développé localement par potentiel Contributeurs, afin qu’ils puissent commencer à mettre en œuvre et à valider leur contribution avec le moins d’efforts possible.

Il existe deux modèles communs de contribution: dépôt partagé et fourche et joignez-vous. Les deux ont des avantages, et en tant que Trusted Committer, vous voulez soutenir les deux modèles pour répondre à différents besoins de votre potentiel et actuel Contributeurs. Vos collaborateurs auront souvent des questions sur le processus de contribution ou sur la communauté elle-même, et quelqu’un doit être disponible pour répondre à ces questions. Il est donc important que toute communauté InnerSource ait une ou plusieurs personnes-ressources disponibles pour répondre à ces questions. Une personne du groupe de Trusted Committers est habituellement cette personne-ressource, ou bien elle doit s’assurer qu’il y a un membre de la communauté « sur appel ».

Il est également important d’aider le potentiel Contributeurs déterminer quelles contributions sont nécessaires. Il peut s’agir de contributions codées mais aussi de contributions non codées, comme la rédaction de documents, la création d’oeuvres d’art ou l’organisation d’événements. Une façon courante de le faire est d’étiqueter les « tâches des nouveaux arrivants » dans le tracker utilisé par la communauté ou de mettre en place un marché pour les tâches ouvertes Les intervenants peuvent utiliser.

En résumé, il est extrêmement important pour les communautés InnerSource dans un environnement d’entreprise de maintenir les obstacles à la contribution aussi faible que possible pour permettre au plus grand nombre possible de personnes de contribuer. Cela signifie donner accès à la documentation utile et aux gens de la collectivité pour répondre à toutes les questions et encourager la collaboration. En résumé, Trusted Committers devrait s’assurer que l’embarquement et la contribution sont des expériences positives.

La promotion des besoins de la Communauté

Les communautés InnerSource existent dans un contexte d’entreprise et sont donc plus limitées que les communautés Open Source. Parfois, les intérêts de l’unité commerciale sont en conflit avec ceux de la communauté. Trusted Committers prend une perspective à long terme sur leur projet. Ils comprennent qu’une communauté saine est une condition préalable à un code sain. C’est pourquoi de nombreuses initiatives InnerSource ont été modélisées dans la Voie Apache avec« Communauté sur code »devise. D’autre part, les unités commerciales sont naturellement plus concernées par les produits produits par une communauté InnerSource. Ils préfèrent voir des résultats à court et à moyen terme qui contribuent au résultat final.

C’est dans cette zone de conflit potentielle que le Trusted Committer joue un rôle vital. Trusted Committers construit la confiance avec l’organisation et, en s’appuyant sur cette confiance, agit comme défenseurs des intérêts de la communauté et de la santé à long terme du logiciel dans l’entreprise. Ils sont responsables de la communication des risques techniques et communautaires à la gestion. En même temps, Trusted Committers doit être stratégique et travailler dans les limites de la liberté accordée par ses entreprises.

Trusted Committers doit également s’assurer que la communauté et l’individu contributeurs obtenir le crédit public pour leur travail. Le crédit public est la monnaie avec laquelle les contributeurs sont payés, en particulier ceux qui contribuent volontairement. C’est une bonne pratique de féliciter publiquement les contributeurs précieux et de s’assurer que leurs gestionnaires sont au courant de leurs contributions. Ne pas donner de crédit peut être frustrant pour les contributeurs individuels et nuire à la santé de la communauté. Cela peut se produire dans les entreprises non encore habituées au modèle de travail InnerSource, ou lorsque le logiciel en cours de développement par la communauté InnerSource fonctionne dans les coulisses et les gestionnaires ne connaissaient tout simplement pas la contribution de la collectivité. Un bon Trusted Committer collaborera avec la direction et plaidera en faveur du crédit public. Ne pas donner le crédit est presque jamais fait de mauvaise foi et est facile à réparer.

Un autre cas courant appelant à la défense des intérêts de Trusted Committer contributeurs n’ont pas le temps ou la permission de contribuer. Cela peut se produire lorsque la communauté travaille sur un produit à l’extérieur du département contributeur et donc pas pertinent pour les objectifs de leur gestionnaire. Dans ce cas, le Trusted Committer devrait engager une discussion avec le gestionnaire des contributeurs et le lobby pour une autre décision.

En résumé, il y a de nombreuses situations où Trusted Committers doit défendre les intérêts des individus contributeurs et pour l’ensemble de la communauté. Trusted Committers comprend que la valeur que la communauté peut apporter à l’organisation dépend de la santé et de la longévité de la communauté et, en fin de compte, d’une relation de confiance entre les deux.

Devenir un Trusted Committer

Le rôle Trusted Committer est un rôle exigeant mais accompli. Si ce chemin d’apprentissage vous intéresse, vous pourriez vous demander comment devenir un Trusted Committer et si vous êtes la bonne personne pour le travail.

Les communautés InnerSource suivent les mêmes principes que les communautés Open Source, dont l’une est la méritocratie. Dans une méritocratie, le pouvoir est dévolu aux individus en fonction du talent, des efforts et des réalisations. Cela signifie que le pouvoir et les privilèges qui viennent avec le rôle Trusted Committer doivent être gagnés. La transparence, une autre valeur de l’Open Source, joue également un rôle vital en ce sens qu’elle rend visible le talent, les efforts et les réalisations de toute la communauté.

Le processus de devenir officiellement un Trusted Committer diffère de communauté en communauté, dépend de l’endroit où vous êtes dans votre voyage InnerSource et pourrait évoluer au fil du temps. Dans les communautés populaires, les fondateurs assument souvent le rôle du Trusted Committer. Au fur et à mesure qu’une collectivité grandit, ou dans les grandes collectivités, Trusted Committers est habituellement nommé ou voté par la collectivité. contributeurs. Mais le rôle de Trusted Committer devrait être assumé volontairement, car il nécessite énormément de temps et de dévouement pour y parvenir.

Quels sont les critères à appliquer pour présenter une candidature? contributeurs pour un rôle Trusted Committer ? Que faut-il pour remplir avec succès le rôle d’un Trusted Committer? Tout d’abord, le potentiel Trusted Committers doit avoir fait preuve d’une profonde compétence technique durant son travail dans la communauté. En outre, ils doivent avoir prouvé leur capacité à communiquer efficacement avec leurs pairs dans la collectivité et, idéalement, avec les propriétaires de produits et la direction.

Dans le même ordre d’idées, ils doivent avoir fait preuve de la volonté et de la patience d’utiliser leurs compétences et de passer du temps intentionnellement à améliorer les contributeurs. Enfin, pour remplir le rôle Trusted Committer, il faut une certaine maturité émotionnelle pour faire face à des situations sociales stressantes, qui ne manqueront pas de venir de temps en temps. Selon nous, les contributeurs qui satisfont à ces critères seront de bons potentiels Trusted Committers.

Le rôle Trusted Committer n’apparaît peut-être pas tout aussi attrayant pour certains contributeurs car il signifie passer moins de temps à coder. La nomination au rôle Trusted Committer pourrait même être perçue par certains comme une rétrogradation ou une rétroaction négative sur leurs compétences en codage. Mais le contraire est vrai. Être nominé pour le rôle Trusted Committer signifie généralement que quelqu’un a reconnu vos précieuses contributions et voit en vous le potentiel de grandir et de diriger. Le rôle Trusted Committer vous donnera plus d’influence sur l’évolution de la base de code et vous fera finalement un développeur plus complet. Expliquer aux contributeurs comment le logiciel fonctionne le plus souvent mène à de nouvelles idées sur une partie du Trusted Committer et aidera à identifier les possibilités d’améliorer le logiciel.

Que vous ayez un ou plusieurs Trusted Committers dépend de la taille et du risque associés au logiciel développé par la communauté InnerSource. Le rôle de Trusted Committer prend du temps, et tout le monde n’est pas disposé ou capable de faire ce type d’engagement. Pour cette raison, certaines entreprises utilisentRotation Trusted Committersystème où plusieurs Trusted Committers partagent la charge de travail du rôle Trusted Committer, et le Trusted Committers qui ne sont pasen douanepeut se concentrer exclusivement sur le travail axé sur la technologie. Avoir plus d’un Trusted Committer rend également plus facile quand quelqu’un quitte l’entreprise ou passe du rôle à faire autre chose. Dans ce cas, il est important qu’il y ait d’autres Trusted Committers déjà en place, qui peuvent prendre le relais et assurer la continuité dans la communauté.

En résumé, le rôle de Trusted Committer doit être gagné en apportant des contributions précieuses – tant techniques que sociales – au bénéfice de la communauté. Dans une communauté en santé, vous aurez votre collègue Trusted Committers à vos côtés. En tant que Trusted Committer, vous aurez moins de temps pour coder, mais en agissant comme un multiplicateur de force, vous serez finalement en mesure de stimuler votre contribution de valeur à la communauté et d’accélérer votre propre croissance.

Conclusion

Dans les chapitres précédents, nous avons appris les responsabilités de Trusted Committers. Parmi ces responsabilités, mentionnons l’assurance de la qualité des produits, le maintien de la santé de la collectivité, la réduction des obstacles à la contribution, le relèvement de la collectivité et la défense de ses besoins au sein de l’organisation. Nous avons également parlé de la façon de devenir un Trusted Committer et de ce qu’il faut pour remplir ce rôle. Travailler comme Trusted Committer est exigeant, mais va finalement amplifier votre contribution de valeur dans votre entreprise.

Nous espérons que nous vous avons inspiré à partir sur un chemin pour devenir un Trusted Committer. Nous espérons également que nous avons aidé votre organisation à comprendre l’importance d’avoir une Trusted Committers capable pour le succès de toute initiative InnerSource et le niveau d’autonomisation requis par ce rôle.

Nous aimerions vous inviter à en savoir plus sur InnerSource en explorant les autres articles et vidéos du InnerSource Learning Path. Et bien sûr, nous serions ravis de vous accueillir la communauté InnerSource Commons.

Que la source soit avec vous.

Manuel

1. Ils sont les seuls à avoir confiance pour s’engager dans le projet.
2. Ils ont confiance pour garder le logiciel et la communauté qui le développe en bonne santé.
3. C’est le nom de rôle utilisé par Apache et GitHub.
4. Ils sont fiables par le propriétaire du produit pour engager les caractéristiques les plus importantes.

Pourquoi 1 est incorrect : Un bon projet InnerSource a une communauté de personnes qui soumettent des engagements au projet. La nature de confiance du commiteur de confiance va au-delà de l’activité de codage brut.

Pourquoi 2 est correct : Le rôle du commiteur de confiance est large et englobe des interactions humaines subtiles. Après avoir été choisis pour leurs compétences techniques et interpersonnelles, les intervenants de confiance emploient un large éventail de pratiques pour obtenir des contributions, renforcer la confiance et les compétences des intervenants et assurer des interactions positives dans l’ensemble de la collectivité. Il n’y a pas de spécifications pour ces travaux. Il implique la confiance de la communauté et des propriétaires de produits.

Pourquoi 3 est incorrect : Apache et GitHub ont des noms différents pour les rôles qui englobent certaines des responsabilités du commiteur de confiance, mais pas l’ensemble complet. Le nom de rôle du committer de confiance est intentionnellement unique à InnerSource.

Pourquoi 4 est incorrect: Les propriétaires de produits ne jouent pas les favoris quant à qui implémente des histoires pour la communauté.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Veiller à ce qu’une contribution reflète les besoins de l’utilisateur final
2. Assurer une qualité de code élevée dans leurs propres soumissions et celles des autres contributeurs
3. Défendre les normes de codage et de participation de la communauté
4. Documenter ces normes

Pourquoi 1 est incorrect : un contributeur décide habituellement de rejoindre un projet afin de s’assurer que le code répond à un besoin perçu de l’utilisateur final. Ainsi, ce sont les contributeurs (ou leurs gestionnaires) qui sont responsables de la détermination des besoins des utilisateurs finaux, et l’auteur de l’engagement de confiance suppose que toute contribution est faite pour une bonne raison.

Pourquoi 2 est correct : quels que soient les avantages que InnerSource offre aux contributeurs et à leur communauté, il doit finalement produire des applications de haute qualité pour être viable. Tel est l’objectif ultime du processus.

Pourquoi 3 est correct: Code sera buggy et difficile à maintenir si les contributeurs ne respectent pas les normes de style et de qualité. Le commiteur de confiance s’assure qu’ils le font.

Pourquoi 4 est correct : les contributeurs potentiels ont le droit de consulter des normes explicites avant d’essayer de soumettre des contributions. La documentation est essentielle, et les commiteurs de confiance devraient soit écrire la documentation ou recruter d’autres personnes compétentes pour le faire.

1. Suivre les dates de sortie et recommander des modifications à ces dates au besoin
2. Calendrier du temps des autres contributeurs
3. Recrutement de collaborateurs extérieurs
4. Recommander des promotions pour les contributeurs

Pourquoi 1 est correct : les commiteurs de confiance savent mieux dans quel état le code est, à quel point il est robuste et jusqu’où ils sont parvenus à répondre aux exigences des utilisateurs. Ainsi, ils peuvent reconnaître plus tôt que quiconque lorsqu’une date de sortie est déraisonnable. Il leur incombe de communiquer la nécessité d’un changement de direction.

Pourquoi 2 est incorrect : les contributeurs de l’extérieur de l’équipe hôte sont des bénévoles et se joignent à un projet parce qu’ils ont leurs propres motivations pour voir les projets se réaliser. Ni les contributeurs externes ni leurs gestionnaires ne toléreront qu’on leur explique comment passer leur temps.

Pourquoi 3 est correct : bien que InnerSource soit souvent conduite par des étrangers qui frappent aux portes d’une équipe hôte pour être laissé entrer, l’équipe peut également profiter de la communication et trouver des étrangers qui peuvent aider. L’auteur de l’engagement de confiance peut expliquer aux contributeurs potentiels comment ils et leurs équipes pourraient bénéficier de la participation.

Pourquoi 4 est incorrect : Les promotions, comme les autres questions de personnel, sont toujours traitées par les gestionnaires d’équipe lorsque InnerSource est en place. InnerSource consiste à bâtir une communauté productive et à éduquer ses membres, et non des récompenses formelles. Un commiteur de confiance peut informer un gestionnaire de contributeurs de la valeur et de l’expertise du contributeur, mais recommander des récompenses reste en dehors du rôle de commiteur de confiance.

1. Modèles pour leur propre comportement
2. Une couche de la structure de gestion pour approuver les changements de code
3. Sources d’information sur la façon d’écrire les contributions réussies
4. Des codeurs experts qui implémentent les suggestions des contributeurs

Pourquoi 1 est correct : Les commiteurs de confiance devraient incarner tous les traits d’un bon membre de la communauté, tant dans leurs compétences de codage que dans leurs interactions. Par conséquent, les contributeurs sont susceptibles d’imiter le comportement de committers de confiance et espérons devenir eux-mêmes des committers de confiance.

Pourquoi 2 est incorrect : InnerSource, fait correctement, met la responsabilité sur les contributeurs pour décider quel code doit changer et comment le modifier. Les commiteurs de confiance peuvent s’assurer que le code suit les directives de style et ne casse rien d’autre. Cependant, l’engagement de confiance ne fait pas partie de la gestion. InnerSource réduit la nécessité pour les gestionnaires de diriger les projets à un niveau détaillé.

Pourquoi 3 est correct : un contributeur veut obtenir son code ou d’autres contributions dans la base de code de l’équipe hôte; le commiteur de confiance est quelqu’un qui a fait cela et peut expliquer comment.

Pourquoi 4 est incorrect : Les contributeurs assument la responsabilité du code dans InnerSource. Les engagés de confiance doivent résister à la tentation de ranger le travail des contributeurs. Les acteurs de confiance peuvent offrir des conseils, mais le contributeur met en œuvre les idées.

1. Examen des demandes de tirage.
2. Documenter les normes communautaires.
3. Veiller à ce que les décisions communautaires soient de haute qualité.
4. Le code de rédaction fait partie de chaque contribution.

Pourquoi 1 est correct : Une demande de tirage donne à un contributeur son bac à sable personnel pour travailler; le contributeur offre ensuite les résultats à l’équipe hôte. La contribution qui en résulte peut nécessiter plusieurs itérations pour atteindre la qualité nécessaire, et l’obtention de ce résultat nécessite la rétroaction de la part des intervenants de confiance.

Pourquoi 2 est correct : la documentation aide tous les contributeurs à s’entendre sur ce qu’ils doivent faire. Il est utile pour les contributeurs de lire la documentation avant de commencer leurs contributions, et pour les commiteurs de confiance de pointer à cette documentation lors de la demande de modification d’une contribution.

Pourquoi 3 est correct : la communication et l’interaction prennent une plus grande importance dans InnerSource. Les intervenants ont des opinions sur ce que le code devrait faire et sur la façon de le faire fonctionner, de sorte que l’engagement de confiance aide les collectivités à prendre des décisions qui répondent à tous les besoins.

Pourquoi 4 est incorrect: Les projets les plus sains ont beaucoup de personnes travaillant indépendamment. Si les contributeurs peuvent assumer l’entière responsabilité de leur code, ils en apprennent davantage et peuvent y contribuer davantage. Dans la mesure du possible, les intervenants de confiance évitent de traiter les contributions dont les autres contributeurs ont pris la responsabilité.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Rendre la participation amusante et engageante
2. Dire aux contributeurs sur quoi travailler
3. Réunir les membres difficiles ou perturbateurs de la communauté
4. Faire un contributeur se sentir bien juste pour faire une soumission

Pourquoi 1 est correct : une atmosphère positive apporte plus de contributions que celles qui sont tendues ou humiliantes. En fait, les projets tendus et humiliants tendent à s’effondrer. Et en tout cas, une équipe doit à ses contributeurs une expérience édifiante et affirmée. Les commiteurs de confiance sont la première ligne de défense contre la négativité, bien que la gestion devrait également créer une culture de soutien descendante.

Pourquoi 2 est incorrect : les contributeurs doivent avoir leurs propres motivations pour changer de code. Ils ne sont pas des employés de l’engagement de confiance. Le commiteur de confiance peut suggérer qu’un contributeur travaille sur une requête de modification ou un bug particulier, soit parce que le projet a besoin d’aide, soit parce que la tâche serait une bonne expérience d’apprentissage, mais le contributeur prend la décision finale.

Pourquoi 3 est correct: Les gens peuvent temporairement, ou à cause de leur disposition, blesser les autres psychologiquement. Une seule interaction négative peut gravement endommager toute une communauté. Les intervenants confiants ont appris à créer une atmosphère positive, et ils doivent intervenir rapidement pour mettre fin aux échanges négatifs et guider explicitement les autres sur la façon de se comporter.

Pourquoi 4 est correct : certains contributeurs n’ont pas les compétences nécessaires pour établir le code de la qualité requise par une équipe, ou peuvent être limités par d’autres facteurs comme le temps. Mais InnerSource prospère grâce à des contributeurs extérieurs, donc tout le monde devrait être encouragé à essayer. L’encouragement motive un contributeur à écouter les conseils et à réessayer jusqu’à ce que la contribution fonctionne.

1. Une communauté respectueuse et agréable
2. Possibilités d’apprendre et d’améliorer les compétences
3. Processus de planification plus ouvert
4. Mise en œuvre plus rapide des fonctionnalités requises par leurs équipes

Pourquoi 1 est correct : personne ne veut être dans un groupe désagréable de personnes. Une bonne communauté attire ceux qui peuvent faire des contributions fructueuses.

Pourquoi 2 est correct : la formation formelle a une valeur limitée jusqu’à ce que l’apprenant tente d’appliquer les compétences dans la vie réelle. Une contribution à un autre projet est une excellente façon d’apprendre de l’expérience et de fournir des dimensions supplémentaires à la formation.

Pourquoi 3 est correct : au moins dans la perspective conventionnelle de la planification organisationnelle, les questions noueuses des ensembles de caractéristiques et des priorités émergent des réunions de gestion de haut niveau. Sous InnerSource, une équipe ou même un individu peut décider que quelque chose doit être fait et ensuite le mettre en œuvre, avec les conseils d’un commiteur de confiance. Les gens finissent par travailler sur des choses importantes parce qu’ils veulent, et les priorités émergent de discussions ouvertes et documentées.

Pourquoi 4 est correct : au lieu d’attendre qu’une autre équipe implémente une fonctionnalité nécessaire, les contributeurs peuvent étudier le code et écrire la fonctionnalité lorsque leur propre équipe en a besoin.Cela n’est pas fait isolément, mais en discussion et collaboration avec l’équipe hôte.

1. Restez hors du chemin des contributeurs.
2. Laud première fois et d’excellentes contributions.
3. Privilégier l’embarquement et le mentorat sur les jalons.
4. Lorsque vous offrez des corrections, expliquez la théorie derrière le changement suggéré.

Pourquoi 1 n’est pas correct : La facilitation et le mentorat continus de l’engagement de confiance aux contributeurs améliore réellement la santé communautaire.

Pourquoi 2 est correct : La transparence est l’une des vertus de InnerSource. Lorsque les gens contribuent, les gestionnaires de la communauté et de l’organisation devraient en être informés.

Pourquoi 3 est correct : les commiteurs de confiance pensent à long terme. Bien qu’il soit important de faire chaque fonction, ils savent que le recrutement et la formation paieront dans les années à venir avec plus de contributions. Ainsi, l’auteur de l’engagement de confiance peut consacrer du temps au recrutement ou au mentorat d’un contributeur pour certaines petites contributions, peut-être plus de temps que la contribution individuelle ne vaut la peine. Le fait d’être mentoré et traité avec respect augmente la probabilité que le donateur revienne pour en obtenir plus.

Pourquoi 4 est correct : Bien que l’examen soit une tâche clé pour préserver la qualité de la base de code, le commiteur de confiance pense à long terme pendant la tâche. L’auteur de l’engagement de confiance veut que le contributeur tire les leçons de cette expérience et applique les leçons aux contributions futures.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Établir de nouveaux objectifs pour la communauté à intervalles réguliers
2. Faire connaître la communauté aux étrangers et ce qu’elle offre
3. Encourager les contributeurs à assumer des tâches plus importantes
4. Encourager les membres à ignorer les commentaires perturbateurs

Pourquoi 1 est incorrect : les objectifs sont fixés par la direction. Des intervenants fiables facilitent le travail des autres, mais ne fixent pas les objectifs.

Pourquoi 2 est correct : De nombreux employés n’apprécient pas les objectifs et les avantages de InnerSource, particulièrement lorsqu’ils n’ont pas été exposés à ses idées. Les engagés de confiance sont des évangélistes pour InnerSource en général et pour leurs équipes en particulier. Ils vont jusqu’à tenir des réunions spéciales ou des séances de déjeuner pour jouer leurs efforts InnerSource.

Pourquoi 3 est correct: Nous voulons que chaque personne grandisse dans le travail. Les cotisants commencent généralement à être de petite taille, mais ils sont capables de verser des contributions plus importantes. Les intervenants dignes de confiance peuvent les encourager à entreprendre un travail à impact plus élevé au fur et à mesure qu’ils le font, et les encadrer pour qu’ils y parviennent. Le résultat final est une base de codes avec une applicabilité plus large, une qualité supérieure et potentiellement plus de fonctionnalités.

Pourquoi 4 est incorrect : une personne perturbatrice peut être très dommageable pour la communauté. Il ne faut pas tolérer les commentaires hostiles, humiliants ou tout simplement distrayants. Le commiteur de confiance n’ignore pas un commentaire perturbateur ou n’en dit pas aux autres. Il ou elle annonce à la communauté que le commentaire est inapproprié, puis s’engage de manière constructive avec la personne perturbatrice pour s’assurer qu’aucun tel comportement ne se reproduise.

1. Ce n’est pas important – la communauté fera ce dont elle a besoin pour faire son travail.
2. Les membres de la communauté à niveau peuvent commencer à s’entraider, ce qui permet à une communauté plus vaste.
3. Une communauté composée de membres plus matures produira de meilleurs logiciels.
4. Des personnes de niveau supérieur peuvent augmenter la capacité de l’équipe hôte de livrer sa feuille de route.

Pourquoi 1 est incorrect : Une communauté ne se forme pas spontanément, même si elle est nécessaire. Un élément clé du rôle d’engagement de confiance consiste à fournir le lien social et l’encouragement à la communauté et aux membres de celle-ci à travailler ensemble.

Pourquoi 2 est correct : Comme les gens acquièrent des compétences et de la confiance, ils peuvent offrir ces compétences à d’autres. Les intervenants peuvent commencer à agir comme des intervenants de confiance pour préserver les normes communautaires et éduquer les autres membres.

Pourquoi 3 est correct : L’un des objectifs essentiels du mentorat est de permettre à chaque contributeur de faire mieux à chaque fois et d’avoir une plus grande portée dans le projet.

Pourquoi 4 est correct : à mesure que les contributeurs deviennent plus sophistiqués, leur productivité augmente et leurs contributions deviennent plus importantes. De plus, ils peuvent aider à fixer des objectifs qui améliorent la santé globale du projet.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Être trop occupé avec leur travail de jour pour contribuer
2. Un manque de considération pour leurs contributions InnerSource lors de l’examen des employés
3. Difficulté à construire et tester le logiciel dans son propre environnement
4. L’utilisation d’un code contributeur par d’autres équipes

Pourquoi 1 est correct : les développeurs ont généralement une plaque pleine se faisant ce que leurs gestionnaires leur assignent. La promesse de InnerSource est que l’ajout de fonctionnalités dont votre projet a besoin à une autre équipe peut améliorer la productivité de votre propre équipe, ainsi que le code de l’équipe à laquelle vous contribuez. La communication ouverte encouragée par InnerSource rapporte également pour les deux équipes au fil du temps. Un contributeur peut avoir besoin de persuader leur direction que le travail sur une autre base de code de l’équipe aidera l’équipe contributeur et l’entreprise atteindre ses objectifs plus rapidement et plus efficacement.

Pourquoi 2 est correct : tout effort qui profite à une entreprise doit être reconnu et explicitement récompensé; cela encourage les employés à assumer de nouvelles tâches importantes. Au début InnerSource n’est pas intégré dans la compréhension fondamentale d’une entreprise de ses tâches, de sorte que les gestionnaires ne reconnaîtront pas la contribution de leurs employés à d’autres projets. Jusqu’à ce que la direction comprenne et apprécie InnerSource, les employés auront du mal à y participer.

Pourquoi 3 est correct : chaque équipe peut utiliser différents outils et dépôts. Un dépôt partagé entre les équipes facilite le travail sur le code partagé. Les processus connexes, tels que la gestion des compilations de versions, les rapports de bogues, les demandes de changement et les tests, devraient être conçus de façon à ce que les gens d’autres équipes puissent travailler de façon qu’ils se familiarisent. Ajouter des documents utiles tels qu’un fichier CONTRIBUTING.md expliquant les coutumes locales des communautés et décrivant la façon de mettre en place le logiciel dans le propre environnement du contributeur peut aider à faire que les gens d’autres équipes se sentent à la maison plus rapidement et est beaucoup recommandé.

Pourquoi 4 est incorrect : L’un des grands avantages de InnerSource est la capacité de toutes les équipes à utiliser les fonctionnalités conçues et codées par d’autres équipes. Les entreprises adoptent largement InnerSource afin de maximiser la valeur de chaque contribution de code en donnant accès au code à chaque utilisateur pertinent.

1. Le fichier README
2. Le fichier CONTRIBUTION
3. Décrire le processus de contribution étape par étape
4. Réponse aux questions des contributeurs potentiels

Pourquoi 1 et 2 sont corrects; ces deux fichiers devraient être lus par les contributeurs avant de commencer la participation, et les deux sont de bons endroits pour les lignes directrices de l’équipe.

Pourquoi 3 est correct : les procédures étape par étape, où elles peuvent être définies, aident à transformer l’abstrait en concret. Il est plus facile de suivre une procédure claire que d’appliquer des principes généraux.

Pourquoi 4 est correct : le commiteur de confiance offre des conseils personnels aux contributeurs. Il est utile de préserver ces interactions sous forme écrite quelque part où d’autres contributeurs peuvent lire et, espérons-le, en apprendre.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Assurez-vous que le travail d’un contributeur est directement pertinent pour ses propres objectifs d’équipe
2. Obtenir la reconnaissance des contributeurs
3. Montrez aux contributeurs potentiels et à leurs gestionnaires pourquoi il leur est avantageux de contribuer
4. Encourager les contributeurs à assumer davantage de responsabilités

Pourquoi 1 est incorrect : Les contributeurs travaillent sur un autre code d’équipes afin de répondre aux besoins de l’équipe de contributeurs. La contribution ne doit rien casser, bien sûr, de sorte qu’elle ne doit pas être en contradiction directe avec les objectifs de l’équipe de committers de confiance. Mais la pertinence s’applique à l’équipe de contributeurs, pas à l’équipe de committers de confiance.

Pourquoi 2 est correct : la reconnaissance est à la fois personnellement satisfaisante et potentiellement une étape vers des récompenses formelles telles que les bonus et les promotions. Des outils tels que le contrôle des versions et les bases de données de rapports de bogues contiennent des enregistrements historiques des contributions, mais les commiteurs de confiance devraient également reconnaître les contributions clés dans les canaux de communication du projet.

Pourquoi 3 et 4 sont exacts : Les contributeurs sont plus susceptibles d’investir du temps et des efforts lorsqu’ils constatent que le projet les profite et qu’il est apprécié dans l’ensemble de l’organisation.

CONSEIL: Plusieurs réponses peuvent être correctes dans certaines questions.

1. Travailler avec un éventail restreint de contributions
2. Passez plus de temps à coder
3. Gérer les situations stressantes sur un projet
4. Laissez la communauté examiner votre comportement

Pourquoi 1 n’est pas correct : les commiteurs de confiance ont tendance à élargir la portée de leur travail, et non à en restreindre la portée. En tant que commiteur de confiance, vous travaillerez avec une variété de personnes de différentes équipes.

Pourquoi 2 est incorrect: Le temps doit venir de quelque part. Les commiteurs de confiance devront renoncer à un certain temps de codage afin de vérifier le code d’autres contributeurs, de guider les contributeurs et d’effectuer la planification. Cependant, les commiteurs de confiance devraient faire un certain codage afin de maintenir leurs propres compétences et de maintenir leurs connaissances de leur base de codes d’équipe. Certaines personnes adoptent le rôle de commiteur de confiance pour des périodes limitées de temps, et retournent au codage à temps plein.

Pourquoi 3 est correct : Un engageur de confiance assume la responsabilité personnelle de la santé de la communauté, et toutes les communautés subissent le stress. Ce stress peut provenir de désaccords personnels, de conflits de priorités, de contraintes de temps et de ressources, ou bien d’autres sources. L’auteur de la confiance doit garder le calme et traiter ces problèmes.

Pourquoi 4 est correct : Un commiteur de confiance n’est pas seulement un expert technique mais un modèle de comportement. Ainsi, vous devriez être transparent dans votre comportement et prêt à recevoir les commentaires des participants au projet.

1. Reconnaître la valeur des commiteurs de confiance en tant que communicateurs
2. Restreindre chaque équipe à quelques commiteurs de confiance
3. Garder les meilleurs programmeurs sur les tâches de codage au lieu de leur faire confiance
4. Respect de tous les délais fixés par la direction

Pourquoi 1 est correct: De nombreux projets techniques accordent une grande valeur aux compétences techniques — qui sont certainement nécessaires — mais sous-estiment ce qu’ils appellent dédaigneusement des compétences comme la communication, la résolution de problèmes et la formation. InnerSource est une collectivité, et les collectivités ont besoin de ces compétences supplémentaires. L’engagement de confiance est choisi et reconnu pour l’ensemble des compétences nécessaires pour induire des contributions.

Pourquoi 2 est incorrect : InnerSource prospère lorsque de nombreuses personnes partagent des rôles. Des équipes saines encouragent de nombreux développeurs qualifiés à devenir des acteurs de confiance. Les gens peuvent aussi entrer et sortir du rôle de commiteur de confiance, le partager avec d’autres membres de l’équipe. Cela améliore les compétences de chacun.

Pourquoi 3 est incorrect : Parce que les commiteurs de confiance ont vérifié le code d’autres contributeurs et les mentorent, les gestionnaires devraient vouloir que leurs meilleurs développeurs deviennent des commiteurs de confiance au moins une partie du temps.

Pourquoi 4 est incorrect : InnerSource se concentre sur le code de qualité et le renforcement communautaire, et non sur les délais. InnerSource peut parfois aider une équipe à respecter ses échéances, car elle peut recruter temporairement des personnes d’autres équipes pour des tâches critiques. Cependant, à d’autres moments, les entreprises de confiance demandent des prolongations des délais afin d’assurer la qualité.

1. Déjà apporté des contributions fructueuses au projet.
2. Est dans l’équipe hôte pour le projet.
3. Aide activement les autres membres de la communauté à poser des questions.
4. Participer à des conversations sur la feuille de route et la gestion du projet.

Pourquoi 1 est correct : L’une des principales responsabilités d’un commiteur de confiance est d’aider les autres à contribuer avec succès au projet. Un engageur de confiance doit avoir une histoire de le faire lui-même afin d’être qualifié pour aider les autres à faire de même.

Pourquoi 2 est incorrecte : Ceci n’a jamais été cité comme une exigence. Bien que l’équipe hôte fournira probablement des commiteurs de confiance lorsque le projet sera offert pour la première fois à la communauté InnerSource, elle peut recruter des commiteurs de confiance d’autres équipes qui s’intéressent intensément au projet. Quelle que soit l’équipe qui emploie les agents de confiance, ils devraient disposer du temps et des ressources nécessaires pour participer avec leurs gestionnaires et agir en tant que représentants du projet auprès de la collectivité et de l’organisation dans son ensemble.

Pourquoi 3 est correct: Une grande partie des responsabilités d’un committer de confiance implique le soutien social aux contributeurs. Un bon candidat aura déjà exposé une partie de ce comportement social avant même la désignation officielle en tant qu’auteur de confiance.

Pourquoi 4 est juste : La confiance placée dans un commiteur de confiance va au-delà de considérations purement techniques. Les intervenants fiables communiquent également avec le propriétaire et la direction du produit. L’intérêt pour ces domaines indique que quelqu’un peut être un engageur de confiance.

1. En assumant des responsabilités supplémentaires dans un projet vous prépare à un leadership élargi dans l’entreprise.
2. Être en position d’enseigner aux autres vous aide à mieux comprendre le projet et à mieux vous coder.
3. Vous pouvez vous attendre à une augmentation de la rémunération monétaire au moment d’assumer les responsabilités de Trusted Committer.
4. Votre impact sur le projet s’étend alors que vous aidez au berger et guidez plus de contributions que vous auriez le temps de vous écrire.

Pourquoi 1 est correct : agir en tant qu’agent de confiance est un grand rôle pour développer les mêmes compétences en leadership qui seront nécessaires si vous décidez de jouer un rôle de leadership à temps plein plus tard.

Pourquoi 2 est correct: Dans tous les domaines, enseigner quelque chose aux autres exige que vous le sachiez mieux vous-même. Cela est vrai en étant un engageur de confiance. Enseigner d’autres vous donnera plus de maîtrise sur le projet et le code sur lequel vous travaillez.

Pourquoi 3 est incorrect: Il n’est pas courant qu’une augmentation monétaire immédiate soit directement liée au rôle de l’engagement de confiance. Cependant, les compétences requises pour devenir un engagement de confiance et celles qui sont développées en étant un ont tendance à être très précieuses pour les entreprises. À cause de cela, devenir un engagement de confiance tend à être un bon mouvement de carrière dans le renforcement des compétences qui font de vous un leader plus précieux.

Pourquoi 4 est correct : Être un commiteur de confiance est un multiplicateur de force sur votre impact au sein du projet. En tant que mentor et contributeurs de niveau supérieur, chacune de leurs contributions portera votre marque et votre influence avec eux. Cet effet vous permet d’améliorer et d’ajouter au projet plusieurs fois plus rapidement que vous ne le pouviez simplement en codant par vous-même.

1. La direction de l’entreprise déplace la personne qu’elle veut diriger le projet dans son rôle.
2. La communauté ou son leadership nomme de nouveaux intervenants de confiance.
3. Quiconque s’intéresse aux bénévoles.
4. Le fondateur du projet assume le rôle.

Pourquoi 1 est incorrect : Le principe de la méritocratie enseigne que le committership est gagné, non assigné. Il s’agit également du cas où le Trusted Committer devrait accepter volontairement une invitation à servir plutôt que d’être conscrit dans le rôle.

Pourquoi 2 est correct : La communauté est la mieux placée pour évaluer laquelle de ses membres a démontré l’intérêt et les aptitudes à servir comme Trusted Committer.

Pourquoi 3 est incorrect: L’intérêt seul n’est pas la seule condition préalable pour le committership fiable. Le principe de la méritocratie enseigne le Committorship Trusted est gagné par une activité positive démontrée dans la communauté.

Pourquoi 4 est correct : Au début, sans communauté et sans histoire, le fondateur du projet assume souvent le rôle de Trusted Committer pour construire une communauté initiale. Cette personne, en plus de développer le projet, développe également un nouveau potentiel Trusted Committers en interaction avec les membres de la communauté.