Parcours d’apprentissage : contributeur

La section Contributor couvre ce que signifie être un contributeur InnerSource, les aspects du comportement qui feront de vous un contributeur réussi, la mécanique de contribution et les avantages de InnerSource pour votre équipe et votre organisation.

Introduction

Avez-vous déjà été bloqué dans votre prochaine tâche de codage parce qu’une autre équipe n’a pas eu le temps d’ajouter une fonctionnalité dans leur système dont vous dépendez ? Peut-être après un certain temps, vous avez même dû faire un travail supplémentaire dans votre projet pour travailler autour de la fonctionnalité manquante. Ce serait bien de ne jamais être bloqué de cette façon ?

Avec des projets qui intègrent les principes InnerSource, vous ne serez jamais bloqué en attendant qu’une autre équipe fournisse une fonctionnalité nécessaire. Si vous n’obtenez pas ce dont vous avez besoin, vous pouvez effectuer le changement dont vous avez besoin directement dans le dépôt de code de l’autre équipe en agissant comme un contributeur InnerSource.

Le rôle du contributeur décrit une personne qui contribue à la mise en pension d’un projet communautaire InnerSource. Cette personne peut ou non faire partie de la communauté ou se voir comme telle. Cependant, pour un certain nombre de personnes, il y a une sorte de voyage que les contributeurs peuvent faire de savoir simplement sur la communauté à utiliser le produit de la communauté pour interagir avec les membres de la communauté et enfin commencer à contribuer. Enfin, certains d’entre eux peuvent devenir Trusted Committers.

En tant que contributeur dans une communauté InnerSource, vous interagirez avec des personnes jouant d’autres rôles de InnerSource, comme Trusted Committer ou responsable produit et éventuellement avec d’autres contributeurs. Parfois, ces rôles peuvent être joués par la même personne, comme Trusted Committer et responsable produit dans de petits projets de style populaire.

Cette section vous donne un aperçu très bref des deux autres rôles, mais nous aimerions vous encourager à lire le article introductif du rôle Trusted Committer, et nous vous avons recommandé de lire Réduction des obstacles à l’entrée article, aussi, avant de vous plonger dans les détails du rôle du contributeur dans cette section. Vous pouvez également regarder les vidéos (introduction, abaissement des barrières à l’entrée) au lieu de lire les articles.

Un Trusted Committer sera votre hôte pour votre séjour dans la communauté d’accueil. Ils sont les gardiens du dépôt de code du projet et vous rapprocheront de la production une fois qu’ils l’auront accepté. C’est leur rôle de vous encadrer sur votre chemin pour contribuer à leur communauté. Ils peuvent vous aider directement ou vous fournir des informations pour vous aider vous-même. Ces renseignements pourraient être des règles internes établies pour les examens, les modèles de proposition pour les changements plus importants, les pointeurs vers la documentation ou les sections de code pertinentes pour votre contribution.

Ils doivent aussi tenir compte de la qualité des produits, de la durabilité et de l’évolution des projets, tant du point de vue technique que général, de la réduction de l’obstacle à la contribution de chacun, ainsi que de la prise en charge de leur communauté en général. Prendre soin de la collectivité consiste à la maintenir en bonne santé, à la mettre à niveau et à faire valoir ses besoins dans leur organisation.

Le rôle du responsable produit a une certaine similitude avec le rôle de propriétaire du produit de votre projet moyen. Cependant, il y a des différences – selon la taille du projet, ce rôle est souvent rempli par la même personne qui agit en tant qu’auteur de confiance. Dans les grands projets, ou dans les équipes qui n’utilisent que partiellement InnerSource comme approche pour combler leurs besoins en acceptant des contributions, ce rôle est probablement rempli par une personne distincte d’un commiteur de confiance.

Votre interaction avec le rôle de propriétaire du produit se concentrera probablement sur l’ajustement de votre contribution au produit général et à sa feuille de route. Vous pourriez travailler avec le rôle de propriétaire du produit pour vous assurer que les aspects généraux de la documentation, ou la cohérence de l’UI/UX, sont maintenus lors de la fusion de votre contribution.

Enfin, une personne agissant en tant que propriétaire de produit aurait pu être impliquée dans le projet, ses avantages et la communauté à votre attention.

Si vous voulez en savoir plus sur ces autres rôles, et nous vous encourageons à le faire, nous avons préparé des sections distinctes sur la Trusted Committer et les responsable produit.

Dans les 5 segments suivants, vous en apprendrez plus en détail sur les différents aspects présentés ici.

Le prochain segment détailleraétat d’esprit et habitudequi créent des possibilités pourdevenir un contributeur InnerSource.

Dans le troisième segment, nous examinerons laethos du contributeur– c’est-à-dire les aspectscomportementqui mènera à un temps agréable et productif pour vous et l’équipe hôte, et pourrait susciter une collaboration plus grande. L’analogie des invités à domicile présentée dans les vidéos d’introduction servira d’exemple vivant.

Le quatrième segment décrit les choses pratiques à faire pour faire de votre contribution un succès – lemécanique de contribution. Nous donnerons des conseils pratiques pour tirer parti lors de la préparation à travailler sur une contribution, pendant le développement, et aussi dans la demande de tirage.

Après avoir abordé les aspects personnels, axés sur l’interaction et les aspects techniques du rôle contributeur, le cinquième segment présente les avantages de faire l’effort de contribuer. Nous montrerons les avantages de différentes perspectives: la vôtre, votre équipe, et la perspective de l’entreprise en général.

Le dernier segment reprendra ce que nous avons appris sur le fait d’être un contributeur InnerSource. Nous allons partager comment vous pouvez continuer votre apprentissage de InnerSource à la fois avec d’autres vidéos et articles en ligne, et par l’implication avec la communauté en ligne InnerSource.

Devenir un contributeur InnerSource

Les contributeurs InnerSource opèrent en dehors des limites régulières de l’équipe, ce sont les liens qui traversent les silos organisationnels. Ils doivent donc être conscients de quelques pratiques communes qui rendent ce travail plus efficace.

Donc – vous implémentez une nouvelle fonctionnalité pour le produit de votre équipe. Vous avez besoin de certaines fonctionnalités pour que cette fonctionnalité fonctionne. Au lieu de sauter droit dans l’implémentation, ralentir un peu : cette fonctionnalité reflète-t-elle un problème général ? Est-ce quelque chose que d’autres équipes de votre organisation rencontrent aussi en raison du domaine commercial partagé ? Cette fonctionnalité est-elle orthogonale dans le domaine de votre projet ? Si cela s’applique, commencez à regarder au-delà de votre propre équipe : y a-t-il une solution partagée que vous pouvez utiliser ou améliorer pour répondre à vos besoins ? Il devrait y en avoir un ?

Il y a un proverbe africain disant que si vous voulez aller vite, allez seul. Si vous voulez aller loin, allez ensemble.

Si vous voulez bouger rapidement, c’est une excellente idée pour briser les dépendances. L’inconvénient à cela peut être dupliqué effort. En particulier, lorsqu’il s’agit de réappliquer la logique fondamentale, le risque de double emploi est très réel, ce qui l’emporte sur le bénéfice de l’indépendance.

Collaborer avec d’autres équipes vous permet de partager les coûts de développement. Tout comme dans les projets Open Source, il peut permettre à votre équipe de construire quelque chose de plus grand que vous seul aurait pu accomplir.

Mais chaque équipe a une feuille de route différente ! J’ai essayé d’utiliser des composants partagés avant – ils ont toujours pris plus de temps à s’intégrer qu’il m’aurait fallu pour les mettre en œuvre de nouveau. Ces composants manquaient toujours d’un aspect ou d’un autre – et mes demandes de fonctionnalités n’ont jamais été prioritaires sur la feuille de route de l’autre équipe!

Contrairement à un projet traditionnel, les projets InnerSource viennent avec le rôle d’un contributeur. Oui, il y aura des moments où vous souhaiterez que la solution partagée ait une nouvelle fonctionnalité. En tant que Contributeur, vous avez la liberté de consulter le code source du composant, de le modifier et d’utiliser la version améliorée qui en résulte.

Oui, il y aura des moments où vous aurez besoin d’urgence d’une correction de bug sur votre timeline qui n’a pas la même priorité dans l’équipe hôte. Devenir Contributeur vous permet d’agir vous-même et de soutenir l’équipe hôte en corrigeant ce bug.

Cette façon de travailler nécessite un changement d’état d’esprit pour beaucoup: au lieu d’attendre que les fonctionnalités soient implémentées ou les bogues corrigés, au lieu de travailler autour des problèmes, il ya maintenant une troisième solution. Dépensez votre temps et votre énergie pour vérifier avec le projet InnerSource ce que sont vos besoins – puis faites le changement directement dans le projet partagé. Ainsi, en plus de vos compétences en codage, vous avez besoin de compétences en communication pour réussir dans un projet InnerSource – afin d’articuler clairement vos besoins et de trouver une solution qui fonctionne à la fois pour votre équipe et l’équipe hôte.

« Mais je pourrais simplement aller et bifurquer le projet, y apporter mes changements et m’épargner de tous ces frais de coordination ! ». Bien sûr. Forger le projet est un moyen de faire votre travail. Sauf à long terme cela signifie qu’il est sur vous de maintenir cette version fourchue pour votre équipe – et de faire avancer vos changements pour toute nouvelle version que l’équipe hôte fait. Contribuer à vos changements à l’équipe hôte signifie également que vous pouvez profiter de leur connaissance approfondie du composant. Ils peuvent repérer des problèmes dans votre patch qui autrement ne seraient devenus évidents dans la production.

Un bon contributeur peut faire un appel confortable pour quand il est à la fois technique et d’affaires sens pour introduire une dépendance et réutiliser un composant au lieu de dupliquer le travail. Ils peuvent parler à la direction pour expliquer les avantages des contributions de InnerSource.

Tout comme l’intérieurSourceseulement à proposSourceCode ? Bien sûr. Si votre équipe dépend d’un composant extérieur, vous voulez vous assurer qu’elle est bien entretenue et bien gérée. En tant que contributeur InnerSource, vous pouvez aider l’équipe hôte de plusieurs façons. Les questions de déclaration que vous voyez lorsque vous utilisez le composant sont une contribution précieuse. Créer ou corriger des cas de test qui montrent que le code ne fonctionne pas comme prévu est précieux. Il en va de même pour l’amélioration de la documentation, de sorte que les autres passent moins de temps à l’utiliser et à y contribuer. Aider les autres utilisateurs à trier les bogues peut être une contribution précieuse. Améliorer les constructions est un autre exemple d’une contribution précieuse.

Pour résumer, aucune contribution n’est trop faible pour contribuer. Voici un que j’ai fait àtensorflow/modèles. Un simple changement d’étiquette dans un graphique.

Dans cet article, vous avez appris ce qu’il faut pour devenir un contributeur. Nous avons examiné l’état d’esprit partagé. Nous avons plongé profondément dans les avantages des solutions de partage. Enfin, nous avons examiné à quoi ressemble généralement la portée des contributions InnerSource.

Ethos contributeur

Dans le dernier segment, nous avons expliqué pourquoi vous voudriez réutiliser des composants et devenir actif en tant que contributeur. Cet article partage les meilleures pratiques sur la façon de contribuer avec succès à vos changements à la base de codes de l’équipe hôte.

Un contributeur InnerSource essayant de contribuer à l’équipe hôte est essentiellement un invité chez lui. En général, un bon client doit se comporter d’une certaine manière :

• Ils frappent à la porte.
• Ils anticipent et suivent les règles de la maison.
• Ils comprennent qu’ils ne sont pas le propriétaire de la maison et agissent en conséquence.

Comment ces attentes s’appliquent-elles aux projets InnerSource?

Lorsque vous visitez vos voisins, vous n’entrerez probablement pas dans leur maison sans frapper ou sonner la cloche de la porte même si la porte est ouverte. De même dans InnerSource en tant que visiteur, vous n’avez pas été en mesure (ou invité) de vous engager directement dans n’importe quel dépôt de code.

Au lieu de cela, après avoir apporté vos modifications à la base de code, vous les soumettez comme une demande de tirage. Tout comme vous n’iriez pas faire de grands changements et ce que vous considérez des améliorations à votre maison voisin, dans InnerSource vous anticiperz et suivez les lignes directrices de collaboration du projet. En retour, vos hôtes vous montreront le chemin – dans InnerSource qui se traduit par des engagés de confiance existants passer leur temps à mentor invités.

Et ces belles fêtes d’été ? Il y a généralement une certaine planification à l’avance pour choisir la bonne date et l’heure, pour préparer suffisamment de nourriture, ou pour le faire contribuer par les invités. Il en va de même pour les changements plus importants dans les projets InnerSource : un projet vous demandera probablement de soumettre une question décrivant votre besoin et votre solution proposée avant de procéder à une modification importante. Passer du temps sur la conception initiale au lieu de sauter droit dans l’implémentation sauve les contributeurs d’avoir à refaire beaucoup de leur travail. Partager les progrès tôt – même quand il n’est pas encore terminé – aide l’équipe d’accueil à encadrer le contributeur vers une meilleure solution. CommeLoi de Yonik de patchs inachevésexplique : « Un patch à moitié cuit en Jira, sans documentation, sans tests et sans compatibilité en arrière, vaut mieux qu’aucun patch du tout. »

Cela signifie-t-il que les projets InnerSource ne placent aucune valeur sur la communication face à face? Pas tout à fait: il y a de la valeur à rencontrer les participants face à face. Rappelez-vous que toute communication écrite manque beaucoup de bande passante par rapport à la rencontre en personne : il n’y a pas de gestes, pas d’imites, pas même le ton de la voix pour aider à la compréhension. Les réunions en personne sont particulièrement utiles pour résoudre les problèmes interpersonnels, résoudre les conflits et les malentendus. Cependant, la communication sur les décisions de projet doit être maintenue par écrit, afin que d’autres puissent suivre et influencer le projet, et même des années plus tard, il est possible de trouver pourquoi une certaine décision a été prise.

Voici ma règle générale de pouce: n’hésitez pas à vous rencontrer sur le café. Souvent cela aide à construire une équipe plus forte, surtout lorsque l’équipe est divisée en plusieurs emplacements physiques. Assurez-vous toutefois que toutes les décisions sont prises de manière transparente et asynchrone afin que tous – y compris ceuxPlongéedans votre conversation – peut sauter dedans et devenir des contributeurs actifs. Un exemple de la mesure dans laquelle on peut prendre une décision ouverte est expliqué dans plusieurs exercicesManuel d’organisation ouvert.

Maintenant, comment voyez-vous où un projet InnerSource aimerait discuter des changements et de l’orientation future du projet? De nombreux projets InnerSource décrivent comment ils aiment être approchés par des contributeurs potentiels dans leur README.md. Si ce document devient trop grand pour être traité, les lignes directrices de contribution ont tendance à être divisées dans un fichier nommé CONTRIBUTING.md files. Suivre ces recommandations aide grandement les contributeurs à vendre leur offre.

Dans toutes ces interactions, soyez prêt à « vendre » votre contribution à l’équipe hôte. Préciser la valeur que la contribution apportera à leur écosystème.

L’équipe hôte sera celle qui prendra en charge la maintenance de vos changements. Il est logique d’offrir de réaliserGarantie de 30 jourssur votre soumission. Cela peut atténuer la peur de l’équipe hôte des Contributeurs ne pas être disponible pour le support avec la correction des bugs après le temps sur la contribution.

Lorsque vous visitez vos voisins, ils vous aideront probablement dans leur appartement : ils vous montreront le chemin vers leur salon et où se trouvent les toilettes. Si vous restez plus longtemps, ils vous donneront probablement plus de détails: dans mon cas, un exemple serait d’éviter d’allumer le lave-vaisselle et la bouilloire électrique en même temps pour éviter de souffler le fusible.

De même, chaque système logiciel est livré avec ses propres quirks et subtilités. Souvent, les plus évidentes sont bien documentées. Dans les petits projets, cette documentation se trouve dans le README.md. Dans les plus grandes, la documentation spécifique à la contribution se trouve souvent dans le document CONTRIBUTING.md.

Dans ces fichiers, vous pouvez vous attendre à trouver des informations sur comment vérifier et construire le projet, comment exécuter la suite de test, comment soumettre des modifications au projet. Il peut vous indiquer d’autres documents s’il s’écarte largement de l’outillage standard – ou s’il y a des choses que vous devriez garder à l’esprit lors de l’apport de changements.

Passer par cette documentation s’avère généralement être un épargnant de temps énorme car il vous empêche de descendre le mauvais chemin et vous avertit des impasses. Si vous constatez que des choses lui manquent en fonction de votre expérience – les correctifs à cette documentation sont généralement très bienvenus : il n’y a personne de mieux adapté pour l’améliorer qu’un nouveau contributeur qui voit le projet pour la première fois.

Essayez de comprendre avec le projet dans leur canal de communication préféré si les changements que vous avez à l’esprit ont un sens global. Au début, il peut être effrayant d’avoir ces conversations dans un support public d’entreprise qui est archivé et consultable. L’avantage ici est avec d’autres venant après vous avec des propositions similaires: au lieu de marcher à nouveau exactement le même chemin, ils peuvent apprendre ce qui a déjà été discuté, et commencer à partir de là.

Être un contributeur signifie essentiellement être plus proche de l’équipe hôte que quelqu’un qui demande simplement une fonctionnalité. Néanmoins, les contributeurs ne sont pas responsables du projet logiciel auquel ils contribuent.

En conséquence, l’appel final sur ce que la contribution doit ressembler est avec l’équipe hôte. Il aide à approcher l’équipe d’accueil avec un état d’esprit humble, en supposant que tous collaborent à l’objectif de l’organisation partagée. Elle contribue à être ouverte et transparente – non seulement sur ce qui a été mis en œuvre et comment, mais aussi pourquoi le changement était nécessaire.

Traitez n’importe quel feedback comme un cadeau: d’autres essaient d’améliorer votre solution, en vous épargnant des problèmes plus loin sur la route.

Il y a une chance que l’équipe hôte n’accepte pas votre contribution du tout. Dans ce cas, il aide à travailler avec l’équipe, déterminer s’il y a un sous-aspect de votre besoin qui peut être résolu dans leur projet. Collaborer sur ce sous-aspect, puis trouver un autre moyen de résoudre les questions restantes à votre fin.

Dans ce segment, nous avons appris comment aborder au mieux un projet InnerSource en tant que contributeur. Nous avons également examiné comment mieux communiquer notre besoin de changement et travailler sur la solution avec l’équipe hôte.

Mécanismes de contribution

Êtes-vous prêt à contribuer à d’autres projets/repos d’équipes? Avez-vous hâte de réduire vos bloqueurs non par l’escalade de la gestion, mais par la collaboration? Cette section donne des conseils pratiques et des faits saillants à retenir lors d’une contribution InnerSource. Il vous permet ainsi que l’équipe hôte d’avoir une expérience aussi agréable que possible, en établissant les bases pour plus de contributions et une grande collaboration.

Cet article est séparé dans les trois étapes que vous aurez probablement

• Solicitoring your contribution opportunity and preparing to work on it
• Créer la contribution
• Polissage et emballage agréablement le cadeau et le présenter à l’équipe hôte.

Si votre contribution est plus importante, vous passerez peut-être par (certaines) de ces étapes à plusieurs reprises alors que vous vous dirigez vers votre objectif commun. Il est très probable que, comme vous le faites, tout se sentira de plus en plus naturel – peut-être vous vous demandez même pourquoi vous faisiez autre chose avant.

Une différence clé est le délai d’exécution. Avec chaque première contribution, vous venez dans une nouvelle équipe (hôte). Par conséquent, vous devrez apprendre à connaître leur base de code, les technologies utilisées, et aussi leur environnement de développement préféré (penser cadre de test, construire système). Même dans les cas où ce type d’outillage est normalisé, chaque équipe aura développé certaines particularités individuelles. En plus du côté technique, vous pouvez être confronté à des différences dans la communication (penser des révisions de code). Même si vous revenez au bout d’un moment, les méthodes et les membres des équipes auraient peut-être changé. Prenez votre temps comme vous le feriez pour rattraper un ami que vous n’avez pas vu depuis un moment et que vous visitez maintenant.

Donne-toi assez de temps d’avance. Commencez assez tôt, de sorte que votre travail est disponible pour vous de tirer parti au moment où vous en avez besoin. Il est préférable d’ajouter plus de temps de relâche au départ – vous aurez un sentiment sur les délais d’exécution une fois que vous travaillez avec l’équipe hôte. Souvent, vous remarquerez une réduction du temps d’exécution par équipe hôte après avoir fait quelques contributions réussies à cette équipe hôte. Cet effet peut également être observé avec Open Source, vous pouvez en lire plus ici.

Dans vos équipes classiques, tout le monde avait une idée des délais prévus. Dans un contexte InnerSource, cela pourrait ne pas être le cas, non plus en raison de grandes différences de fuseau horaire (p. ex. Seattle, États-Unis avec PDT vs Berlin, Allemagne avec CEST) ou vous n’êtes pas disponible à temps plein comme avec votre équipe d’origine, même s’ils sont dans le même emplacement physique que vous êtes. Ainsi, pour éviter la frustration des deux côtés, l’impatience et d’autres effets non-trust-building, vous devrez explicitement faire la gestion des attentes en ce qui concerne votre temps de réaction attendu. L’une des approches consiste à réagir rapidement avec un « J’y jetterai un coup d’œil, je n’y arriverai pas dans les prochains jours ». Trusted Committer-S feedback si vous savez que vous ne pourrez revenir à eux que dans quelques jours. Idéalement, vous pouvez leur fournir une estimation approximative quand vous aurez probablement le temps de jeter un coup d’œil à leurs commentaires. Cela renforce la confiance par la fiabilité, même sur des contacts non physiques, une distance plus longue ou d’autres médias asynchrones. La confiance établie vous permettra de surmonter les obstacles à l’incertitude dans la voie de collaboration qui vous attend.

InnerSource accorde une grande importance à la communication écrite – en particulier en ce qui concerne les décisions de projet. Cela signifie-t-il que la communication en personne est interdite?

Clairement non : alors que la communication écrite brille quand il s’agit d’archivage et de recherche, la communication en personne brille quand il s’agit de bande passante de communication. Essayez de prendre le temps de rencontrer des gens derrière les noms. Si possible, essayez de les rencontrer sur votre boisson préférée ou certains aliments. Quand vous serez capable d’entendre les gens parler, quand vous connaissez leurs idiosyncrasies, la collaboration à distance deviendra plus facile.

Avez-vous une grande fonctionnalité que vous voulez contribuer? Parfait ! Ce serait horrible si tout votre travail était gaspillé ? Cela peut arriver lorsque l’équipe d’accueil construit déjà quelque chose de très similaire, prévoit déprécier le logiciel, ou ne voit pas ce que vous proposez d’être un bon pour leur projet. Ce défi est fréquent, et de nombreuses relations d’équipe ont souffert de ne pas convenir à l’avance qu’une contribution est un bon ajustement.

Faites plaisir à vous et à l’équipe hôte (et peut-être économiser du travail) en obtenant l’accord de l’équipe hôte sur la conception utilisateur/technique de la contribution avant travailler sur les modifications et soumettre une demande de tirage. Vous devrez comprendre comment l’équipe hôte aimerait que vous vous y mettiez. C’est mieux de demander un Trusted Committer comment mieux discuter de votre proposition.

Il est temps-et-de nouveau-prouvez la sagesse de l’arène Open Source que, si vous pouvez choisir comment discuter de votre proposition, vous devriez essayer de choisir une manière écrite. Idéalement, choisissez la façon dont les artefacts sont publics, consultables et perma-lienables pour permettre de faire référence à votre proposition dans des discussions ultérieures sur cette contribution future ou d’autres contributions à venir – par vous ou d’autres.

Ce type d’accord initial de haut niveau vous fera gagner du temps en retravaillant ou en rejetant votre demande de tirage.

Super, vous vous êtes familiarisé avec l’approche de l’équipe hôte, et ils sont impatients de recevoir votre demande de tirage. Qui vous attend ?

Premièrement, vous serez en contact moins direct avec eux. Deuxièmement, vous n’êtes pas censé être aussi compétent et compétent que vous pourriez être sur les projets à temps plein que votre équipe possède. Comment peux-tu gérer ça ?

Essayez de consulter leur documentation, les archives de conversation et les artefacts de code de l’équipe hôte pour vous débloquer. Ceci est similaire à la situation dans laquelle vous et probablement la plupart des gens vous trouvez dans lors de l’utilisation d’un des projets OSS populaires.

Tout comme dans les projets Open Source, demandez à l’équipe hôte si les choses ne vont nulle part même après avoir essayé de vous débloquer. Les questions que vous posez et les réponses que vous recevez aideront d’autres personnes après avoir résolu les mêmes problèmes. Assurez-vous que votre communication se retrouve dans une archive consultable qui est étroitement liée au projet lui-même. Si vous voyez des possibilités d’amélioration facile pour atteindre cet objectif si celui-ci n’est pas encore atteint, vous pourriez essayer – très poliment – de suggérer une amélioration à votre équipe hôte. Parfois, le statu quo résulte d’une pure coïncidence et reste ainsi parce que personne n’avait une idée différente ou n’avait assez de souci. Des suggestions d’amélioration pourraient être les bienvenues dans de tels cas. Il ne fait pas les deux côtés n’importe quel bon pour vous de tourner pour toujours sur un problème qui pourrait être résolu en quelques minutes conversation avec quelqu’un plus au courant du projet. C’est bon de demander de l’aide.

Il y a cependant une différence clé, apportant un avantage pour vous et d’autres personnes à l’avenir: Dans presque tous les cas, vous devriez préférer les canaux de communication officiels des projets – il peut s’agir d’une liste de diffusion, d’une salle de discussion, d’un traqueur de problèmes ou quelque chose de similaire, selon le but d’avoir une manière plus synchrone ou asynchrone d’interagir, ou les besoins variables de structure dans la communication. Tous ceux qui ont généralement en commun qu’ils sont basés sur le texte, archivés, consultables et viennent avec des liens stables – cela signifie que votre question et la réponse seront écrites, et les références que vous lierez dans ces réponses seront également accessibles. De cette façon, vous pouvez bénéficier de cette connaissance documentée passivement dans votre recherche ET aider les futurs contributeurs à avoir le même avantage. Une telle documentation passive pourrait même servir à enrichir la documentation « officielle », si elle contenait des pierres précieuses particulièrement précieuses, telles que des définitions importantes qui ont été créées ad-hoc.

Lorsque vous travaillez, si vous trouvez la documentation manquante (ou périmée), faites une faveur au prochain Contributeur et mettez-la à jour avec ce que vous avez découvert. Les équipes de projet sont souvent heureuses de recevoir des ajouts, des mises à jour ou des corrections pour leur documentation existante – vous venez de trouver une autre occasion de contribuer! (Ou tout simplement leur fournir poliment une rétroaction sur votre expérience, et ce qui vous aurait aidé.)

Nous avons tous nos préférences et nos opinions sur le style de code, l’indentation, etc. Le projet de l’équipe hôte les a aussi. Essayez d’adapter et de correspondre à ces préférences même si ce n’est pas ce que vous feriez normalement, et même si ce n’est pas spécifié dans les projets». « CONTRIBUTION.md ». Si vous n’êtes pas sûr, vous pouvez toujours demander poliment. Néanmoins, une contribution d’invité pour une fonctionnalité ou une correction de bug n’est pas le moment d’introduire une nouvelle façon de structurer ou de formater le code de projet.

Vous avez terminé tout le travail essentiel, a compris toutes les angoisses du problème et le projet auquel vous contribuez, le temps que vous avez prévu pour que la nouvelle fonctionnalité soit utilisée approche, et vous voulez vous assurer que votre contribution se fusionne le plus rapidement possible.

Voici ce que vous pouvez faire pour rendre l’examen et la fusion aussi facile que possible pour le Trusted Committer et l’équipe hôte. Cela pourrait en fait être assez semblable à ce que vous pourriez déjà faire sur votre propre projet pour obtenir vos changements acceptés. Si c’est le cas – génial, ça va vous arriver naturellement !

Le point fondamental ici est de permettre aux Trusted Committer valider la contribution sans votre présence et assurer une maintenance facile. Imaginez que vous ayez construit une fonctionnalité ou la manipulation d’un quirk insolvable, ou une modification importante de la performance, et votre code n’est pas tout à fait évident (ou pourrait même sembler pirate / faux au premier coup d’oeil). Si vous avez couvert cela avec un test – et idéalement avoir versé quelques mots sur la raison d’être de celui-ci dans un commentaire – un futur éditeur se fera rappeler sur le but du code, et le(s) test(s) assurera que la valeur que votre code réalise sera conservée, même dans les nouvelles implémentations. Pour ce faire, il faut :

• Ajoutez des tests pour votre contribution de code, de sorte que la validation de la fonction de votre contribution par d’autres fonctionne bien, même après un certain temps, lorsque vous travaillez dans d’autres projets ou peut avoir cessé de contribuer à ce projet.
  • Souvent, les projets auront des contrôles automatisés contre les demandes de tirage en utilisant ces tests et le niveau de couverture du code. Essayez de répondre aux critères que ces tests imposent.
• De nombreux projets fourniront des scripts de construction et de validation de projets qui vous permettent de tester localement vos modifications.
  • Utilisez-les pour vous assurer que votre contribution fonctionne aussi bien que possible avant d’ouvrir une demande de tirage.
  • Avoir à examiner les requêtes de traction défectueuses avec des erreurs faciles à corriger souvent bugs de confiance committers. Ils ne corrigeront pas votre code, mais vous demanderont de le faire. Cela pourrait créer plus de voyages aller-retour et ralentir la fusion.
  • Mais personne n’est parfait. Faites de votre mieux, utilisez des scripts de validation préparés s’il y en a, et donnez-lui votre meilleur coup avec une demande de tirage!
  • Si votre demande de tirage continue de casser les tests, et vous ne pouvez pas savoir pourquoi après lui donner votre meilleur coup: essayez de mettre en évidence ces tests dans le commentaire de la demande de tirage, illustrez votre compréhension actuelle du problème et demandez de l’aide sur elle.
• Ne pas oublier votre propre projet qui a déclenché votre contribution en premier lieu. Créez une construction modifiée du projet partagé avec vos changements et essayez-le dans votre propre projet qui le consomme.

Vous voulez vous assurer que votre demande de tirage inclut toute mise à jour de la documentation pertinente à vos changements. Si la documentation vit dans un autre endroit, assurez-vous de les y ajouter et de les lier dans votre demande de tirage.

Pour rendre la révision du code aussi facile que possible pour le commiteur de confiance ou d’autres personnes qui l’examinent, essayez de suivre ces conseils :

• Assurez-vous que votre demande de tirage ne comprend que les modifications pertinentes pour le problème que vous remplissez.
• Essayez d’éviter les commits super-large, les commits avec des messages de commit flous, des gazillions de fichiers, des changements incohérents (par exemple toucher plusieurs sujets).
• Fournir une description claire de ce que cette demande d’attraction modifie, de la raison pour laquelle elle le fait, et de quels documents d’émission et de conception (s’il y en avait) elle fait référence.
• S’il y a quelque chose d’inhabituel ou inattendu dans la demande de tirage, le mettre en valeur et fournir l’explication. Ainsi, il sera plus facile de raisonner et de résoudre les questions de blocage qu’un examinateur pourrait avoir au cours de l’examen.
  • Il en va de même pour le scénario où vous n’étiez pas sûr de la mise en œuvre ou de votre approche – le mettre en évidence et demander un aperçu.
  • Soyez civil et attendez la civilité de la Trusted Committer-S examen.
• Faire des demandes de tirage trop larges et grandes les rend plus difficiles à examiner, donc il faudra beaucoup plus de temps avant qu’elles ne soient acceptées.
  • Si vous avez une fonctionnalité plus grande que vous contribuez, elle aide souvent à la diviser en plusieurs requêtes de tirage qui sont soumises, examinées et acceptées successivement. Vous pouvez toujours les lier avec un problème auquel vous faites référence.
    • Certains outils ont aussi la fonctionnalité de demande de tirage d’ébauche / WIP que vous pouvez utiliser pour marquer explicitement le travail inachevé et non poli et toujours obtenir la rétroaction précoce de votre équipe hôte. Trusted Committers.
    • Cela vous permet de vous assurer que vous descendez un chemin que votre équipe hôte est heureuse de fusionner une fois qu’il a fait, en adhérant à l’idée « release hâtive, release souvent » d’une certaine manière.
    • La responsabilité de l’équipe d’accueil est de créer une atmosphère où le partage et la discussion d’un travail non entièrement poli sont possibles et bienvenues. Si vous ne pouvez pas échouer en toute sécurité, vous ne pouvez pas innover, et la collaboration devient très difficile.
    • Essayez d’établir un équilibre entre demander un examen précoce et apporter des changements significatifs à l’examen.

Certaines de ces ressources pourraient être cachées derrière des murs de paie. Parfois, votre employeur a un abonnement permettant l’accès, sinon les bibliothèques universitaires publiques permettent souvent l’accès pour les invités, aussi.

Avantages de devenir un contributeur InnerSource

Les contributeurs sont le sang de vie des projets InnerSource. Chaque projet exécuté en tant que projet InnerSource a à la fois la promesse et l’objectif ultime d’étendre leur équipe de développement au-delà des fondateurs originaux, en exploitant le potentiel d’autres collaborateurs parmi les utilisateurs (également parfois appelés clients dans les sociétés) de ce projet.

Cependant, qu’est-ce qui motiverait un promoteur à consacrer du temps à un projet qui n’est pas sous la direction de son gestionnaire? Qu’est-ce qui motiverait un gestionnaire à consacrer du temps à leurs développeurs pour améliorer des projets qui ne relèvent pas de leur compétence à 100 %?

La motivation la plus évidente est ce qui attire généralement les premiers contributeurs dans open source aussi bien.

Tu te souviens de ce bestiole que tu as travaillé si longtemps ? Le temps et l’énergie qui maintiennent ces coûts de contournement? Et si au lieu d’attendre que l’équipe en amont règle ce problème à l’avenir, vous pourriez aller de l’avant et le réparer vous-même ? Dans cette situation de « gratter votre propre démangeaison » les contributeurs commencent souvent à résoudre les problèmes dans les projets dont ils dépendent pour leur travail quotidien afin de réduire le nombre de solutions de rechange dans leur propre base de codes.

Lorsque vous décidez de créer et de contribuer une solution au lieu de maintenir votre propre solution, pensez aux avantages que la contribution apportera à la qualité de vos propres changements. Au lieu de travailler isolément, ceux qui travaillent sur le projet en amont pourront non seulement examiner mais aussi améliorer votre solution. Vous obtenez un soutien et un mentorat qui accélèrent grandement votre propre effort de développement.

Passer plus de temps avec les autres signifie qu’au fil du temps, vous apprendrez comment l’équipe fonctionne, comment elle s’organise elle-même, ce qui l’aide à construire son projet. Souvent, vos propres projets profiteront de cette expérience : au lieu de seulement lire sur une nouvelle bibliothèque ou un nouveau système de construction, vous pourrez acquérir une expérience pratique avec elle avant de l’introduire dans vos propres projets. En travaillant sur plus d’un projet de base, vous serez exposé à un écosystème plus vaste pour tirer les meilleures pratiques et les solutions aux défis.

Un bel effet secondaire de pouvoir passer une partie de votre temps dans d’autres équipes est que votre réputation et votre impact élargissent les limites de votre propre équipe. Ainsi, en plus d’apprendre des autres et de grandir vous-même, vous pouvez influencer les projets. Vous influencez directement via vos propres contributions et en partageant votre expérience et vos connaissances sur l’outillage et la configuration des projets. Ce partage pourrait aider le projet en amont à améliorer et à accélérer les cycles de développement.

Outre tous ces critères objectifs, il y a une composante qui est très difficile à mesurer, mais qui a été signalée à la fois dans InnerSource et dans les projets Open Source : les gens participent parce qu’ils trouvent du travail sur ces projets personnellement accompli et amusant. Très probablement, l’aspect d’être en mesure de vraiment choisir soi-même les tâches à travailler joue un rôle important. Cette auto-sélection conduit généralement aussi à accueillir des projets très accueillants et encourageants dans leurs efforts pour garder les contributeurs motivés.

Tu te souviens du bug ennuyeux qui a finalement été corrigé en amont ? Pourquoi votre équipe devrait-elle dépenser un effort supplémentaire pour contribuer à la réparation du projet en amont?

D’une part, cela signifie que le coût et le temps d’entretien sont maintenant liés au projet en amont. Pour chaque nouvelle version il est sur eux au lieu de sur votre équipe pour s’assurer qu’il continue à travailler avec vos modifications et exigences.

Avoir des membres de l’équipe comme contributeurs actifs dans les projets de votre équipe dépend des moyens qu’ils peuvent avoir leur mot à dire dans l’orientation du projet et les délais, ce qui peut être bénéfique pour votre équipe.

En utilisant InnerSource les équipes peuvent établir un chemin intermédiaire entre « être indépendant et construire votre propre » (y compris n’importe quel nombre de nouveaux bogues que vous possédez) et « sauver le temps et l’argent en s’appuyant sur des implémentations existantes » (au prix de créer des dépendances à long terme qui ne peuvent être influencées que de manière limitée). De cette façon, il devient plus facile d’équilibrer la mise en œuvre et la réutilisation.

Rappelez-vous cette fonctionnalité qui est spécifique à votre domaine d’entreprise – mais qui est maintenue dans plusieurs implémentations dans toute l’entreprise? Et s’il y avait un moyen d’éviter une douzaine d’implémentations buggy et de les fusionner en un actif partagé ? Que se passe-t-il si le processus de développement de cet actif partagé s’est déroulé sans la fuite habituelle d’énergie que les dépendances centrales apportent à la table? De nombreux projets open source sont utilisés par un grand nombre d’acteurs, dont certains participent à leur conception et à leur développement. Encourager la collaboration intersectorielle dans les projets InnerSource au niveau de l’entreprise signifie que vous pouvez stimuler l’innovation centrale à partir des bords de votre organisation.

En général, il est bien entendu que les projetsfacteur busd’une ou deux personnes présentent un risque pour l’organisation – d’autant plus que ce projet s’avère central dans l’objectif de l’entreprise. InnerSource aide non seulement à rendre ces projets transparents, mais fournit également des outils pour améliorer cette situation en mettant l’accent sur le mentorat et l’élargissement de la base de contributeurs.

Bien que la collaboration entre les équipes rende difficile l’évaluation des contributions individuelles, elle permet également l’apprentissage et le partage des connaissances au sein de l’organisation. Par conséquent, l’impact des individus s’améliorera. Les meilleures pratiques et l’innovation positive se répandront plus facilement dans toute l’organisation. En parallèle, les améliorations apportées au milieu de travail se propageront plus facilement dans l’ensemble de l’organisation, ce qui aidera à retenir les employés.

Du côté technologique, avoir plus d’yeux avec un contexte plus diversifié implique que les changements de code seront soumis à beaucoup plus de contrôle, ce qui permettra d’améliorer la qualité et la sécurité globales.

Enfin, l’accent mis sur la possibilité pour les utilisateurs et les clients de participer au développement offre une incitation très claire à faciliter le démarrage de ces projets : sur la base d’outils standard, faciles à comprendre, faciles à réutiliser et, par conséquent, plus modulaires et remplaçables.

Comme nous l’avons vu dans cet article, bon nombre des raisons pour lesquelles des particuliers et des sociétés peuvent être actifs dans Open Source s’appliquent également aux projets InnerSource. Nous avons également vu qu’il est non seulement des raisons altruistes qui poussent les gens à collaborer dans les projets InnerSource – souvent il est facile d’identifier des raisons d’affaires pour quand une telle collaboration a beaucoup de sens.

Conclusion

Merci d’avoir examiné le segment Contributeurs du Sentier d’apprentissage InnerSource Commons. Avec cette section, vous avez appris le rôle du contributeur – le sang de vie des projets InnerSource. Les contributeurs sont externes à l’équipe des propriétaires de composants et apportent une contribution précieuse supplémentaire au projet.

Dans cette section, vous avez appris comment devenir un contributeur en trouvant des occasions de contribuer. Nous avons examiné l’état d’esprit et les habitudes nécessaires pour trouver ou créer de telles possibilités. Nous avons également discuté de l’éthique du rôle et d’une approche suggérée qui pourrait mener à des contributions fructueuses.

Étant donné l’état d’esprit, les habitudes et l’éthique, il y a encore quelques détails qui pourraient vous empêcher de contribuer avec succès – par conséquent, nous avons discuté de ces écrous et boulons dans plus de détails.

Enfin, convaincre vos coéquipiers et votre organisation à différents niveaux peut être difficile, nous avons donc discuté des avantages de la contribution de différentes perspectives pour vous faciliter ce processus.

Nous espérons que vous avez aimé regarder les vidéos, et/ou lire les articles, et serez en mesure de retirer quelques nouvelles perspectives intéressantes pour votre voyage vers InnerSource et être un bon contributeur.

Si vous ne l’avez pas déjà fait, nous vous invitons à en apprendre davantage sur les autres aspects de InnerSource dans notre parcours d’apprentissage InnerSource : http://innersourcecommons.org/learningpath/

Nous vous invitons à consulter le groupe InnerSource InnerSource Commons en ligne – n’hésitez pas à participer à la discussion et à partager vos expériences et leçons apprises dans votre organisation.

Vivez longtemps et avez des projets prospères!

Manuel

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

1. Je peux m’assurer que d’autres doivent suivre mes suggestions pour améliorer le projet.
2. L’équipe hôte maintiendra les fonctionnalités que j’ajoute au nom de mon équipe.
3. Je peux façonner la solution pour mieux répondre aux besoins de mon équipe.
4. Je peux aider à façonner tous les aspects du projet au-delà du code lui-même (par exemple, examen GitHub, triage de bogues, tests, documentation).

Pourquoi 1 est incorrect : les communautés ouvertes ne sont pas une dictature. En tant que contributeur, vous faites partie d’une communauté qui contribue à la solution pour grandir et prospérer. Il peut s’agir de compromis parfois, mais vous et la collectivité en bénéficierez à plus long terme.

Pourquoi 2 est incorrect: Réduire la quantité de travail nécessaire pour mettre en œuvre une fonctionnalité client est l’une des principales raisons pour InnerSource. Il est exact que la contribution aux projets d’accueil signifie que l’équipe d’accueil prend conscience du changement et en tiendra compte dans tout refactoring qu’elle effectue à l’avenir. Ainsi, le travail que vous avez à faire en tant que contributeur pour vous adapter aux nouvelles versions est considérablement réduit. Cela n’implique pas que l’équipe d’accueil soit, lors de l’acceptation, la seule personne responsable de s’assurer que le changement que vous avez soumis fonctionne comme prévu : Le modèle de garantie de 30 jours fournit un moyen formel de définir combien de temps les contributeurs sont responsables de résoudre les problèmes dans la modification qu’ils ont soumise. Dans la pratique, les contributeurs se rapprochent souvent de l’équipe hôte et fournissent leur expertise à l’avenir.

Pourquoi 3 est correct : des solutions partagées se développent à partir des contributions des parties intéressées. Devenir contributeur vous permet de façonner la solution, toujours en consultation et en collaboration avec d’autres membres de la communauté.

Pourquoi 4 est correct : les contributions vont au-delà du simple code. Il y a beaucoup d’aspects qui aident à maintenir une solution saine et ainsi la faire réussir, différents aspects nécessitent des compétences différentes, bien que ne rendent pas l’un plus important que l’autre. Si le code est la machine, alors pensez à ces domaines de contributions comme la graisse qui maintient la machine fonctionne en douceur.

1. Les besoins qui sont partagés dans toute l’entreprise sont de bons candidats pour InnerSource.
2. Mon projet sera le plus rapide si j’ai le moins de dépendances possible.
3. L’équipe d’accueil mettra en œuvre les fonctionnalités dont j’ai besoin.
4. Je ne devrais travailler que sur les caractéristiques nécessaires à mon équipe.

Pourquoi 1 est correct : lorsque de nombreuses équipes à travers l’entreprise ont le même besoin, un projet InnerSource est un excellent moyen de répondre à ces besoins à l’échelle sans travail en double.

Pourquoi 2 est incorrect : si vous sautez la chance de mettre le code de levier qui est déjà écrit, vous perdrez du temps à coder des solutions à des problèmes déjà résolus plutôt que d’ajouter une valeur unique dans votre équipe.

Pourquoi 3 est incorrect : vous pouvez demander, mais il peut y avoir des moments où le prochain besoin que vous avez dans le projet n’est pas la prochaine priorité pour l’équipe hôte de travailler. Dans ces cas, vous pouvez toujours obtenir ce dont vous avez besoin en faisant une contribution InnerSource au projet.

Pourquoi 4 est incorrect: Travailler sur d’autres fonctionnalités d’un projet, ou faire des travaux de fond tels que la réorganisation du code ou de la documentation, peut indirectement contribuer au succès de votre équipe, il est donc légitime pour vous d’investir du temps sur ces choses.

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

1. Mon travail d’équipe est crucial pour le succès de l’entreprise, donc ma voix d’équipe a plus de poids dans une communauté de solutions partagées que les autres.
2. Comme je suis invité au projet, j’ai droit à des réponses rapides et complètes à mes questions de l’équipe hôte.
3. En tant qu’invité du projet, je dois m’assurer de comprendre et de respecter les règles et les lignes directrices décrites dans la documentation connexe (en commençant par les fichiers README.md et CONTRIBUTING.md, mais sans s’y limiter) et de poser des questions respectueusement après pour obtenir des éclaircissements ou de l’aide.
4. Mon engagement est envers le changement que j’apporte. Une fois ma contribution acceptée, mon travail est terminé et je peux me concentrer à nouveau sur le cœur de mon propre projet.

Pourquoi 1 est incorrect : même si votre équipe peut jouer un rôle plus central dans l’entreprise, vous êtes toujours l’invité lors de l’interaction avec un projet InnerSource. La responsabilité ultime des décisions prises au sujet du projet incombe à ses responsables de confiance.

Pourquoi 2 est incorrect : Il n’y a rien de mal à poser de bonnes questions, et il faut y répondre rapidement. Cependant, vous êtes invité et vous devez respecter le temps et les efforts des autres membres de la communauté. Par conséquent, assurez-vous de lire et de comprendre toute la documentation disponible avant de poser des questions et d’être préparé pour les réponses de n’importe quel membre instruit du projet, pas seulement les chefs d’équipe hôte. Cela aide votre statut dans la communauté et évite la randomisation.

Pourquoi 3 est correct : InnerSource met l’accent sur la création de la documentation, à la fois comme arrière-plan du travail (par exemple, README.md et CONTRIBUTING.md, et pour justifier des décisions individuelles et des changements de code. La raison d’une culture de documentation est de vous fournir, en tant que contributeur, les antécédents dont vous avez besoin pour adapter votre changement avec succès au projet.

Pourquoi 4 est incorrect : L’acceptation de votre contribution est une réalisation à célébrer. Cependant, votre participation ne s’arrête pas là. Vous devriez prévoir d’être disponible au minimum pour remplir unGarantie de 30 jourssur vos changements (et leur impact), ou encore mieux : restez près de la collectivité et aidez-la avec des contributions supplémentaires.

1. Les propriétaires et les évaluateurs de la solution dépendent des contributions, donc j’aide le projet en affichant un changement de code (comme une correction à un bug que j’ai découvert ou une nouvelle fonctionnalité dont j’ai besoin) tout de suite. L’examen du code ébranlera ensuite tout problème.
2. Je suis convaincu que ma contribution ne sera pas rejetée, car cela constituerait un comportement hostile envers les contributeurs.
3. Je reste engagé et disponible pour le projet pour soutenir mes changements et aider à faire avancer le projet.
4. Je ne travaille qu’avec des gens avec qui je suis habitué à travailler, car cela rend la collaboration plus efficace.

Pourquoi 1 est incorrect : Avant de contribuer, vous devez communiquer votre intention aux autres membres du projet. Les surprises dans les projets créent une grande confusion, un gaspillage d’efforts et une irritation. Une communication précoce et ouverte enverra un message clair d’intention et augmentera les chances d’une expérience de contribution en douceur.

Pourquoi 2 est incorrect : De grandes contributions sont valorisées dans des solutions ouvertes et partagées, mais gardez à l’esprit que vous êtes un invité. Les modifications proposées au code peuvent être rejetées pour de nombreuses raisons : parce qu’elles vont à l’encontre de l’intention de la solution, ne répondent pas aux normes de codage, etc. Ce n’est pas une réflexion personnelle sur vous, mais une décision professionnelle. Pour ce faire, comprendre les exigences énoncées dans la documentation du projet (README.md, CONTRIBUTING.md, etc.) et les plans du projet pour l’avenir. Si la documentation manque, demandez des renseignements sur les normes, les attentes et les plans du projet. Votre première contribution peut bien être d’écrire ou d’examiner la documentation manquante.

Pourquoi 3 est correct : les projets ont besoin de gens pour être engagés et rester au-dessus des questions ouvertes, aider à résoudre les problèmes, et peser sur les plans. Rester engagé vous aidera à bâtir une réputation positive et vous donnera l’occasion d’en apprendre davantage sur l’espace de problème du projet.

Pourquoi 4 est incorrect : Lorsque vous engagez, vous devriez vous engager avec la communauté dans son ensemble (tous les invités ainsi que l’hôte dans notre métaphore) et travailler en plein air. L’emplacement physique ou organisationnel ne devrait pas jouer un rôle dans la façon dont vous engagez ou avec qui vous engagez. Après tout, InnerSource est sur le point de travailler ensemble au-delà des frontières pour le succès de tout le monde.

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

1. Je comprends que les contributions à un bon projet InnerSource prennent à peu près le même temps que les contributions à mon projet d’équipe.
2. Je communique mon intention de contribuer à l’équipe d’accueil tôt et j’assure un accord sur la portée et le calendrier.
3. J’ai l’intention de refactorer le code que je rencontre pendant mon travail de contribution à mon style de code afin qu’il soit homogène dans le style et facile à comprendre.
4. Je prévois que mes demandes de tirage soient restreintes afin de les rendre plus faciles à comprendre, à examiner et à intégrer.

Pourquoi 1 est incorrect : Pour de nombreuses raisons, les contributions à une solution ouverte et partagée prendront probablement plus de temps que les changements à un projet à équipe unique fermé. Par exemple, la coordination avec l’hôte peut ne pas être simple comme elle l’est avec votre équipe immédiate. Vos intérêts et les intérêts des hôtes peuvent ne pas s’aligner facilement, et des compromis peuvent devoir être trouvés. La logistique peut également ajouter des frais généraux, comme simplement travailler dans différents fuseaux horaires. Pour atténuer ces retards, planifiez-vous avec plus de temps. Cela atténuera le stress et la tension et augmentera vos chances d’un engagement réussi.

Pourquoi 2 est correct : Grâce à la communication, vous laissez chacun comprendre votre intention et donner des conseils lorsque nécessaire. La communication vous assure de comprendre les plans et les objectifs des autres et de travailler ensemble de façon optimale pour le plus grand impact.

Pourquoi 3 est incorrect : Contribuer à une fonctionnalité ou à un bug n’est pas le moment d’introduire un style de codage ou de documentation différent. Changer les styles de codage et les conventions dans un projet est une grande entreprise, donc vous devriez plutôt aligner vos changements sur les styles de codage et de documentation dans le projet. Si un style de code différent est nécessaire, posez-le comme un problème et discutez avec l’équipe d’accueil et les autres participants en dehors de votre contribution actuelle.

Pourquoi 4 est correct : Les changements à petite échelle sont plus faciles à comprendre, non seulement dans le code impliqué dans l’examen, mais aussi en ce qui concerne l’impact que le changement suggéré peut avoir sur le reste de la solution. Les discussions à portée limitée permettront d’accepter plus rapidement les changements et donc d’en tirer un avantage plus immédiat.

1. Si je suis coincé, j’examine la documentation et le code pour recommencer. Si cela échoue, je demande des éclaircissements ou de l’aide dans les canaux publics du projet.
2. Mon code a des tests pour les changements que je contribue, j’ai testé et vérifié mes changements avant de contribuer, et les tests sont intégrés dans le pipeline CD/CI pour le projet.
3. J’ai mis à jour la documentation et les tests pour m’aligner sur les changements de code que j’apporte.
4. Ma contribution correspond au style du projet.

Pourquoi 1 est correct : Vous devriez explorer la documentation fournie pour répondre à vos questions. Lorsque vous reconnaissez que votre réponse est manquante dans la documentation, ou n’est pas suffisamment expliquée, poser une question au projet est la prochaine étape. Non seulement une clarification vous fera bouger à nouveau, elle aidera les futurs contributeurs.

Pourquoi 2 est correct : avoir des tests appropriés pour le code que vous écrivez est une bonne pratique d’ingénierie générale pour s’assurer que le code est robuste et durable. Dans un projet InnerSource, les tests aident également à renforcer la confiance en vous en tant que contributeur. Automatiser les tests dans le cadre d’un processus d’intégration de code permet également aux projets InnerSource de diffuser la maintenance sur tous les porteurs de projet de confiance, indépendamment de leur statut d’adhésion à l’équipe dont émane le projet InnerSource. Ainsi, l’intégration continue et la livraison continue (CI/CD) sont précieuses en InnerSource.

Pourquoi 3 est correct : vérifier les tests et la documentation pour tout changement nécessaire fait partie d’une contribution solide et aidera à guider les futurs contributeurs vers les bons chemins.

Pourquoi 4 est correct : des conventions de code ont été mises en place pour permettre à tous les participants de comprendre le code rapidement. Vos changements doivent s’intégrer aux styles et conventions de codes actuels pour s’assurer que votre contribution est également facile à examiner et à maintenir par tous les autres.

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

1. Je peux mettre en œuvre une solution que j’aime sans les contraintes de l’équipe.
2. Je partage l’effort de développement avec d’autres et j’aurais donc besoin de fonctionnalités pour mettre en œuvre et maintenir par moi-même.
3. Je développe ma réputation au sein de l’entreprise.
4. Je peux devenir un meilleur ingénieur.

Pourquoi 1 est incorrect : Vous devez travailler dans les limites du projet partagé. À cet égard, InnerSource n’est vraiment pas très différent de travailler au sein d’une équipe saine.

Pourquoi 2 est correct : Dans les projets partagés, vous regroupez efficacement vos ressources, multipliant ainsi votre impact et la vitesse à laquelle les fonctionnalités peuvent se déployer.

Pourquoi 3 est correct : Comme vous interagissez avec des personnes en dehors de votre équipe immédiate, plus de personnes apprendront à vous connaître, votre style de travail et vos capacités, contribuant ainsi à bâtir votre réputation.

Pourquoi 4 est correct: Interagir avec d’autres ingénieurs de différentes équipes élargira vos connaissances et votre portée, vous aidant ainsi à concevoir et à construire un meilleur code.

1. Une contribution à une autre base de code d’équipe nécessite généralement moins d’entretien de votre part qu’un changement à votre propre base de code.
2. Une diffusion plus large des connaissances clés réduit le risque de perdre la mémoire organisationnelle à mesure que les gens partent.
3. Parce que les autres dépendent de vos contributions, vous pouvez vous assurer que les équipes dépendantes soutiennent votre mission.
4. Vous pouvez influencer et aider à diriger des projets partagés à l’appui de vos scénarios d’utilisation.

Pourquoi 1 est correct : une fois la contribution intégrée dans un autre projet d’équipe, elle en fait partie intégrante. Le contributeur conserve généralement la responsabilité de la nouvelle fonctionnalité pour une période de grâce convenue, après quoi l’équipe d’accueil maintient le code comme le reste du projet. Cependant, votre équipe devrait rester engagée, car vous dépendez du code et le connaissez bien. Cela aidera à maintenir votre influence et éviter les surprises sur la route.

Pourquoi 2 est correct : Les changements organisationnels sont un fait de la vie. Les gens changent d’emploi, les organisations doivent s’adapter aux nouvelles orientations de l’entreprise, etc. Lorsque les connaissances clés sont limitées à une seule personne ou à une seule équipe, elles peuvent se perdre assez rapidement. Lorsque les connaissances se propagent dans la communauté à l’aide de la base de codes partagés, il devrait toujours y avoir quelqu’un qui possède suffisamment de connaissances pour aider à faire avancer le projet ou la solution de façon cohérente.

Pourquoi 3 est incorrect : Les contributions ne sont pas un moyen d’obtenir un effet de levier sur les autres. Ils sont un moyen de partager un chemin commun au profit de tous les participants. La tentative d’utiliser les contributions comme levier pour obtenir un avantage se heurte souvent à de sévères critiques, même en déclenchant une division dans la communauté et une fourche du code, qui dans ce cas est malsain et indésirable.

Pourquoi 4 est correct : contribuer à un projet InnerSource vous donne la meilleure chance de vous assurer que le projet partagé possède les fonctionnalités nécessaires à vos scénarios. Non seulement vous pouvez contribuer code pour accomplir ce que vous voulez, mais le processus InnerSource crée des canaux de communication et des procédures de prise de décision qui tiennent compte de vos vues.

1. Moins de développeurs sont nécessaires pour terminer les projets à temps.
2. Une documentation accrue vous aide à déterminer par la suite pourquoi les décisions ont été prises et aide les nouveaux développeurs à s’accélérer.
3. Une diffusion plus large des connaissances encourage l’apprentissage en dehors du domaine de travail immédiat et élimine les cloisonnements d’experts sur des projets importants.
4. Les projets partagés conduisent à une meilleure alignement général entre les équipes et la collaboration croisée à l’échelle de l’entreprise.

Pourquoi 1 est incorrect : InnerSource devrait être adopté afin d’aligner le développement sur les objectifs de chaque équipe, mais pas pour des économies de coûts ou une réduction du personnel. Les projets InnerSource nécessitent autant de codage (et un peu plus de communication) que les projets siloés. Toutefois, la satisfaction devrait être plus élevée à la fin parmi les équipes et les clients.

Pourquoi 2 est correct : InnerSource adopte, à partir du modèle open source, le principe que toutes les discussions et décisions doivent être écrites et conservées. Grâce à des listes de diffusion et des forums, des commentaires dans le dépôt de contrôle de version et des rapports de bogues, l’organisation conserve des informations sur les objectifs du projet et les développeurs de compromis ont fait. Cela est utile plus tard à de nombreuses fins.

Pourquoi 3 est correct : les pratiques InnerSource connectent les développeurs à la fois au code et aux personnes avec lesquelles ils n’interagissent normalement pas. Ces liens diffusent des connaissances techniques sur des projets spécifiques et créent de nouvelles voies sociales où les connaissances circulent plus facilement à l’avenir. Ces deux aspects ont pour résultat de réduire les connaissances siloed dans l’entreprise.

Pourquoi 4 est correct : Comme les projets sont partagés plus largement, les équipes qui les utilisent ont tendance à se rapprocher comme une nécessité d’utiliser la même base de code partagée. Cette vision commune réduit les doubles emplois et constitue un avantage global pour l’entreprise.