Une contribution à un projet que vous ne possédez pas se lit comme un travail crédible sur un CV quand l'entrée nomme précisément ce que vous avez réellement fait : une pull request précise qui a été fusionnée, un bug que vous avez traqué et corrigé, une revue de code que vous avez menée et qui a influencé le changement d'une autre personne, ou un rôle de mainteneur que vous occupez dans le projet, plutôt qu'un simple nom de dépôt à côté d'un lien. Le travail open source diffère d'un projet que vous avez construit vous-même sur un point important : votre nom figure dans l'historique des commits aux côtés de ceux d'autres contributeurs, sur un projet qui avait déjà ses propres mainteneurs avant votre arrivée et qui a continué à fonctionner après l'intégration de votre changement, si bien que l'entrée doit préciser exactement votre part plutôt que de laisser le lecteur supposer que vous possédez l'ensemble du projet.
Pourquoi une ligne open source demande une formulation différente d'un projet que vous possédez
Pour un projet que vous avez construit et que vous contrôlez entièrement, présenter des projets personnels sur un CV d'ingénieur logiciel explique comment décrire ce qu'il fait, avec quoi vous l'avez construit et ce qui a changé parce que vous l'avez construit. Une contribution open source pose d'abord une question différente, pas ce que fait le projet, puisque le lecteur peut souvent le vérifier en quelques secondes si le projet est connu, mais ce que vous avez fait spécifiquement à l'intérieur d'un projet qui existait déjà et avait déjà sa propre direction. Une ligne vague à côté du nom d'un projet connu, sans aucune description de votre implication réelle, peut se lire comme une tentative d'emprunter la réputation de ce projet plutôt que de décrire un travail réel, ce qui est exactement le contraire de ce que la ligne est censée accomplir.
Les types de contribution à nommer précisément
Une pull request fusionnée est l'unité de contribution la plus claire à nommer, et préciser ce qu'elle a changé compte plus que de simplement signaler son existence : une correction de bug précise, une nouvelle fonctionnalité, une amélioration de performance, ou un morceau de documentation manquant. La revue de code est un travail réel et précieux sur un projet actif, et mérite une ligne à part de vos propres changements fusionnés lorsque vous en avez fait suffisamment pour que cela compte, en particulier sur un projet où la qualité des revues fait partie de la façon dont les mainteneurs jugent la position d'un contributeur. Un rôle de mainteneur ou de tri, où vous avez un accès en écriture, où vous relisez les pull requests d'autres personnes ou où vous gérez les tickets d'un projet, mérite sa propre ligne plutôt que d'être fondu dans une mention générique de « contributeur », car cela dit quelque chose qu'un simple correctif fusionné ne dit pas : que d'autres mainteneurs font confiance à votre jugement de façon continue. Des contributions récurrentes au même projet sur plusieurs mois méritent aussi d'être décrites comme un schéma plutôt que de ne lister que le changement fusionné le plus impressionnant, car un schéma se lit comme un engagement soutenu plutôt qu'un événement ponctuel.
Exemple illustratif : une ligne de contribution open source
Exemple illustratif, du vague au précis. Vague : « Contributeur, projet open source (github.com/example/project). » Précis : « Contributeur, un outil en ligne de commande open source utilisé pour les environnements de développement locaux. A corrigé un bug qui bloquait l'outil sur les fichiers de configuration volumineux, et a relu plusieurs pull requests d'autres contributeurs du même dépôt sur une période de six mois. » La version précise nomme l'objectif du projet en une phrase, indique exactement ce que le changement fusionné a réellement corrigé, et sépare le travail de revue de la correction elle-même, plutôt que de laisser entendre que toute la ligne décrit une seule et même contribution.
Créditer un travail partagé sans s'attribuer trop de mérite
La plupart des changements fusionnés sur un projet open source actif sont généralement passés par la revue d'une autre personne avant d'être intégrés, et une entrée de CV qui laisse entendre que vous êtes le seul auteur d'une fonctionnalité qui a en réalité été façonnée par plusieurs mainteneurs ensemble se lit comme une exagération dès que quelqu'un vérifie l'historique des commits, ce qui ne prend que quelques secondes pour un dépôt public. Nommer votre contribution précise, un correctif, une fonctionnalité, un domaine que vous relisez régulièrement, plutôt que de décrire toute la fonctionnalité du projet comme si vous l'aviez construite seul, garde la ligne à la fois honnête et, dans la plupart des cas, plus précise et plus crédible qu'une affirmation plus large. Lorsque plusieurs de vos contributions se concentrent sur un domaine du projet, comme son outillage de build ou sa suite de tests, nommer ce domaine informe souvent davantage le lecteur que de lister individuellement plusieurs petites pull requests.
En quoi cela diffère d'un projet que vous possédez entièrement
Un projet personnel que vous avez construit à partir de rien mérite une ligne décrivant son objectif et son résultat, parce que vous avez pris chaque décision sur ce qu'il fait et comment. Une contribution open source mérite une ligne décrivant votre part précise à l'intérieur des décisions de quelqu'un d'autre, car la direction générale, l'architecture et le périmètre du projet ont généralement été fixés bien avant votre arrivée. Les deux constituent un travail technique légitime qui mérite une place sur un CV, mais confondre les deux, décrire une contribution open source comme vous décririez votre propre projet, tend soit à exagérer votre rôle dans le projet partagé, soit à minimiser le travail réel et précis que vous avez effectivement accompli.
Où la placer sur le CV
Une contribution open source significative, ou un rôle de mainteneur occupé dans la durée, mérite généralement sa propre ligne dans une section projets, aux côtés des projets personnels, puisque les deux décrivent un travail technique en dehors d'un poste rémunéré. Plusieurs contributions plus modestes à différents projets se regroupent souvent mieux sous un même intitulé, par exemple « Contributions open source », en nommant brièvement chaque projet plutôt que de donner à quatre lignes minces et quasi identiques le même poids visuel qu'une entrée bien décrite. Le modèle Developer est construit avec un espace projets à côté du parcours professionnel, ce qui convient à ce type d'entrée, qu'elle soit issue d'un poste ou totalement indépendante.
Ajoutez-la à votre CV
Une contribution open source, décrite précisément et créditée honnêtement, constitue une preuve réelle de jugement technique que le lecteur peut souvent vérifier directement. Partez d'un modèle conçu pour le travail d'ingénierie et ajoutez vos contributions dans l'éditeur, où vous pourrez continuer à affiner la formulation au fur et à mesure que de nouvelles contributions arrivent.