[Hacktoberfest] Carnet de voyage : d’utilisateur à contributeur
Avec le mois d’octobre arrive la grand messe de l’open source, le Hacktoberfest, qui depuis 6 ans participe à la promotion des contributions open source afin de soutenir ces projets qui font aujourd’hui parti de notre quotidien de développeur.
Afin de mieux comprendre les possibilités qui s’offrent à chacun et de découvrir les opportunités de faire partie de la communauté open source, laissez moi vous partager mon parcours, d’utilisateur de projet open source à contributeur régulier.
Il n’existe pas de standard qui définisse les types de projet pouvant être open sourcer. On peut ainsi retrouver des projets aussi variés qu’un langage de programmation, un framework, une documentation, un toolkit ou même juste une simple liste de ressources utiles.
Ces projets ont néanmoins comme point commun de pouvoir avoir un impact très important sur la vie d’un développeur, que cela soit au cours de son apprentissage que dans ses besoins professionnels. Cela prend d’autant plus de sens que la nature évolutive de notre métier nous amène à conserver une veille constante sur ses évolutions.
Peu après avoir décroché mon premier emploi en tant que développeur, je décidais donc de m’intéresser aux projets open source de plus près afin d’apporter mon aide.
Ma première contribution
Comment identifier un projet
Une des plus grandes difficultés pour un nouveau contributeur est de savoir comment trouver des projets sur lesquels il puisse intervenir.
Pour une recherche active et non ciblée, des outils de recherche tels que http://issuehub.io/ sont un excellent moyen d’identifier rapidement des besoins en contribution.
Pendant la période d’Hacktoberfest, des labels tels que hacktoberfest, help wanted ou good first issue sont des moyens efficaces pour filtrer sur des besoins en contribution plus abordables. Pour la plupart il s’agit de sujets dont la charge de travail est limitée et sur lesquels l’équipe responsable de la maintenance du projet peut vous soutenir dans la réalisation.
Si ces sujets sont utiles au projet, ils sont également une bonne occasion pour l’équipe en charge du projet de le faire connaître et de le faire découvrir à des personnes qui pourront contribuer plus régulièrement par la suite.
Une autre solution pour identifier ces projets est de tirer profit de sa veille ou de ses usages professionnels : c’est l’occasion d’en apprendre plus sur des outils que vous utilisez au quotidien et de pouvoir les améliorer.
Mon choix fut de m’intéresser à l’ecosystème open source d’Angular pour mes premières contributions. Cela me donna l’opportunité dans un premier temps de :
- améliorer le readme d’un support de cours
- corriger l’affichage d’un moteur de recherche
- ajouter du contenu à une liste de bonnes pratiques
- effectuer une correction syntaxique sur de la documentation
Aucune de ces contributions n’ont requis une connaissance technique approfondie sur le coeur même du projet : soit il s’agissait d’issues en attente d’une prise en charge, soit de bugs découverts lors de l’exploration du projet.
Faire partie de la communauté
Ces expériences précédentes n’ayant pas requis de réel échange avec l’équipe d’un projet, le savoir-faire était alors suffisant. Mais pour participer plus activement à la résolution de bugs ou à la soumission de nouvelles fonctionnalités, il me fallait désormais travailler sur ma capacité à exprimer clairement des concepts que j’utilisais sans avoir à faire l’effort de les expliquer.
Je décidais donc d’orienter mes contributions vers les échanges autour des projets afin de participer à leur adhésion et leur compréhension.
La première solution est de participer aux échanges sur le projet directement. Plus un projet devient important et populaire, plus l’équipe du projet est sollicitée par des demandes de correction de bugs ou des demandes de soutien sur la bonne utilisation du projet.
Il est alors possible de soutenir l’équipe en participant à ces échanges :
- en demandant des informations plus complètes au lanceur d’alerte afin d’accélérer le travail de l’équipe du projet sur sa compréhension du problème
- en tentant d’expérimenter soi-même un problème remonté pour en valider la capacité à le reproduire
- en informant sur les moyens de résoudre un problème quand il n’est pas du fait même du projet
Toutes ces contributions sont grandement appréciées par l’équipe d’un projet car elles permettent de lui libérer du temps pour se concentrer sur le problème directement (c’est ainsi pour cela que Github propose l’intégration de templates afin de formatter la communication pour la rendre plus efficace).
Ma seconde approche à cet effort d’amélioration de ma communication fut d’apporter des réponses à des questions sur des plateformes tierces tels que gitter ou stackoverflow.
En plus d’améliorer sa façon de communiquer, cela permet d’être plus à l’aise avec des notions ou des techniques que l’on utilise de manière plus rarement.
Participer à Hacktoberfest
Arriva alors pour moi l’occasion de participer pour la première fois à Hacktoberfest en 2019. Au delà de la promotion que fait l’organisation au travers d’un soutien aux événements liés à l’open source et la production de documentation pour accompagner les contributeurs, Hacktoberfest propose de faire gagner chaque année un tee shirt aux participants, contre la soumission de 4 pull requests pendant le mois d’octobre.
Ayant jusqu’alors focalisé mon attention sur un nombre restreint de projets, l’atteinte de ce challenge me poussa à m’intéresser à d’autres projets, optant cette fois-ci pour une découverte moins intéressée et moins ciblée.
Au cours de l’événement les issues ouvertes sur Github avec les tags hacktoberfest et good first issue sont légion. Il est alors d’autant plus aisé de trouver un projet !
Faire partie d’un project
Dans le cadre de ma veille, je découvris le projet Scully, un générateur de site statique pour des applications Angular, en mars 2020. Alors encore au début de sa phase alpha, il représentait une belle opportunité de suivre le conseil de Dan Abramov (si ce n’est que je n’utilisais pas ce projet activement):
L’idée pour moi était de pouvoir avant tout découvrir l’évolution du projet, tout aussi bien techniquement qu’au travers des issues remontées et des ajouts de fonctionnalités.
Ma première approche du projet fut finalement très rapidement l’occasion d’y contribuer directement : si la documentation fut un très bon moyen de comprendre le projet, elle me permis d’identifier également des moyens de la corriger ou de l’améliorer.
Lorsque l’on pense “contribution” sur un projet open source, on pense souvent plus naturellement à la correction d’un bug ou à l’ajout de nouvelles fonctionnalités. Cependant des contributions sur la documentation d’un projet sont tout aussi importantes car elles participent à la compréhension et à l’adhésion d’un projet.
Cette étape me permis de monter en compétence sur le coeur même du projet, m’ouvrant ainsi des portes vers des corrections de bugs ainsi qu’une vision plus large des lacunes de la documentation à corriger.
Toujours actif sur le projet actuellement, je me consacre principalement aux discussions sur les issues et à la revue de code.
Faire partie d’une organisation
L’étape la plus récente de mon parcours de contributeur intervint en juillet dernier en réponse au tweet de Netanel Basal :
ngneat est une organisation proposant des librairies utilitaires pour des projets Angular. Elle est connue pour des projets comme Transloco (solution pour l’internationalisation) ou Spectator (utilitaires pour les tests).
Ma première tâche au sein de l’organisation fut de créer une librairie à partir d’un ancien article de Netanel Basal. Plus que de simplement reprendre la fonctionnalité présentée pour l’intégrer à l’écosystème technique d’une librairie angular, il s’agissait de l’améliorer afin qu’elle puisse répondre à des besoins qui dépassent l’exercice d’une simple démonstration d’un article de blog.
De plus, là où une fonctionnalité créée pour un projet n’a comme ambition que de répondre aux besoins du dit projet, une fonctionnalité développée pour être mise à disposition du public doit pouvoir non seulement prendre en considération tous les cas d’usage mais doit également s’efforcer de suivre le principe OCP (Open/Closed Principle). C’est-à-dire être ouvert à l’extension mais fermé aux modifications afin de ne pas être esclave des besoins spécifiques d’une multitude de projets, au risque d’intégrer des modifications bloquantes pour des projets utilisant déjà cette librairie.
Ainsi une fois implémentée, la librairie ne devrait être mise à jour que pour corriger une erreur.
Depuis la sortie de cette librairie, j’ai eu l’occasion d’être invité à participer à d’autres projets au sein de l’organisation, poursuivant ainsi mon activité de contributeur.
Conclusion
Entamant ma troisième année d’expérience en tant que développeur suite à une reconversion, cette casquette de contributeur a été un vrai tremplin pour accélérer mon apprentissage et booster mes compétences.
Au travers des projets et des besoins du public, c’est une opportunité d’être confronté à un condensé de réalités et de contraintes métiers diverses et variées, permettant ainsi de plus facilement prendre pied face à de vrais besoins clients.
C’est également l’occasion de côtoyer et d’échanger avec des experts techniques sur leur solution et ainsi de se challenger sur la qualité des contribution que l’on propose : de l’expression écrite à la réalisation technique, en passant par le respect de bonnes pratiques sur l’utilisation de git.
