Article original : Practical Skills for Open Source Maintainers – How to Effectively Maintain OSS
Par Njong Emy
Les logiciels open source sont utilisés par des organisations de toutes tailles à travers le monde. Et ils sont devenus très populaires dans l'industrie technologique.
Beaucoup de gens veulent s'impliquer dans cet aspect ouvert de la technologie, et heureusement, il existe de nombreuses façons différentes de contribuer.
Néanmoins, l'open source peut sembler intimidant au premier abord. Ma première contribution officielle a eu lieu pendant le Hacktoberfest 2021, et même après cela, il m'a fallu un certain temps pour me sentir vraiment à l'aise.
La communauté open source m'a énormément aidé, et c'est la voie que je conseillerais à tout nouveau technicien de suivre : s'impliquer dans la communauté autour d'un projet qui vous tient à cœur.
En plus d'être un contributeur – en apportant des mises à jour aux bases de code open source, en mettant à jour la documentation, etc. – vous pouvez également devenir un mainteneur de projet. Les mainteneurs sont responsables de l'excitation que vous ressentez lorsque vos pull requests sont fusionnées.
Devenir contributeur pour la première fois peut être intimidant, mais devenir mainteneur pour la première fois peut l'être tout autant. Dans cet article, je vais donc discuter de certaines des compétences non techniques que les mainteneurs de projets devraient cultiver pour réussir.
Un peu de contexte
Après avoir ouvert le code source d'un projet qui me tient particulièrement à cœur, j'ai eu la chance de gagner une expérience très nécessaire. J'ai également organisé un espace Twitter avec des personnes formidables, et elles avaient beaucoup à partager également. D'où cet article.
Je ne dirai pas que je suis un expert, mais pour réussir à développer un projet open source, quelle que soit sa taille, il y a certaines compétences que vous devez avoir. Et certaines de ces compétences, je ne les ai acquises qu'après avoir été mainteneur pendant un certain temps.
Compétences nécessaires pour maintenir un projet open source
Développer de bonnes compétences en gestion du temps
Le premier jour de la publication du projet, ma boîte mail a été inondée de notifications GitHub.
J'étais heureux que les gens s'intéressent au projet, mais c'était trop pour moi à gérer. Je reportais mon travail pour m'occuper des problèmes, assigner, étiqueter, fusionner les pull requests, résoudre les conflits... Cela est rapidement devenu trop difficile à gérer. J'avais besoin d'allouer du temps et de fixer des limites.
Si vous gérez un grand projet, les notifications ne sont probablement pas nouvelles pour vous. Si vous gérez le projet seul (comme je le faisais à ce moment-là), c'est bien pire.
Mettre de côté un temps spécifique pour s'occuper des tâches GitHub était la meilleure solution. Cela peut être le matin avant le travail, ou après le travail, ou seulement le week-end, selon ce qui fonctionne pour vous et pour le projet.
Soyez patient
J'entends souvent des gens conseiller aux contributeurs de ne pas spammer les mainteneurs si ces derniers ne peuvent pas s'occuper de leurs problèmes ou de leurs pull requests à temps. Ce niveau de compréhension doit être réciproque.
Les contributeurs ont aussi une vie. Si un contributeur revendique un problème, il est important de lui laisser le temps de soumettre une pull request. L'open source est amusant (nous en avons déjà convenu, mais juste pour insister), mais certaines personnes ne peuvent contribuer que pendant leur temps libre.
Si un problème revendiqué prend trop de temps à être résolu, un rappel subtil est acceptable. Rappelez constamment à un contributeur qu'il doit soumettre une pull request peut être décourageant, et ce n'est pas une bonne image pour vous ou votre projet.
Cependant, sur certains projets plutôt grands, un délai est donné aux contributeurs qui revendiquent des problèmes. J'ai vu des cas où un contributeur a environ sept jours pour soumettre une pull request. Bien que cela soit compréhensible en raison de la nature rapide de ces projets, je pense personnellement que c'est trop de pression, surtout pour les nouveaux contributeurs.
Soyez empathique
Pour moi, c'est la compétence la plus importante. Je me souviens de ma première contribution open source. La joie que j'ai ressentie lorsque ma pull request a été fusionnée et le soutien immense de la communauté étaient merveilleux.
Pensez à cela lorsque vous fusionnez des pull requests. Cela pourrait être la première fois du contributeur aussi. J'essaie de clore les pull requests avec un message autre que simplement 'LGTM'. Cela peut être aussi simple que d'ajouter un emoji de bombe et de les remercier.
Les gens reviennent dans un endroit où ils se sentent les bienvenus.
Soyez ferme
Cela peut être difficile, mais c'est aussi important. Vous ne fusionnerez pas toutes les pull requests qui sont ouvertes, et c'est un fait. Mais fermer abruptement une pull request sans justification n'est pas non plus une bonne pratique.
Si une pull request est trop grande, ou si elle n'ajoute pas au projet comme vous l'auriez souhaité, il est acceptable de la fermer. Mais n'ayez pas peur d'expliquer gentiment au contributeur pourquoi elle ne peut pas être fusionnée. Ne laissez pas une pull request ouverte indéfiniment parce que vous vous sentez coupable de la fermer.
Les gens peuvent être plus compréhensifs que vous ne le pensez si vous leur donnez une simple courtoisie commune.
Travaillez sur vos compétences en communication
La collaboration est la base fondamentale de l'open source dans son ensemble. Et pour collaborer efficacement, vous devez être un bon communicateur.
Avoir des gens qui viennent travailler avec vous sur votre projet est génial et tout – mais si vous ne pouvez pas communiquer correctement avec ces personnes, vous vous retrouverez avec un projet open source fermé (si cela a du sens).
La collaboration ne doit pas nécessairement consister à créer un énorme serveur Discord pour le projet. Cela peut simplement consister à partager des messages dans vos revues de code.
Si les sections de commentaires sous vos problèmes sont trop petites, GitHub dispose d'un onglet de discussion pour chaque dépôt. C'est un excellent endroit pour lancer de nouvelles idées et établir des connexions formidables.
Vous ne savez jamais qui vous pourriez rencontrer !
Écoutez et apprenez
Après avoir ouvert le code source de mon application, j'ai probablement appris plus sur React que si j'avais regardé des tutoriels et construit en privé.
Des personnes intelligentes viendront et vous ouvriront les yeux sur des idées que vous n'auriez pas pu imaginer seul. Mon projet s'est tellement amélioré, principalement parce que je n'avais pas peur d'essayer de nouvelles choses.
La communauté veut aider – alors laissez-les faire.
Cultivez un esprit communautaire
Quelqu'un m'a récemment contacté, disant qu'il voulait s'impliquer dans la révision des pull requests parce que c'était amusant. Ils ne sont pas officiellement un mainteneur, mais j'aimerais penser qu'ils aiment faire partie du projet.
Construire un projet open source est un effort communautaire. Et en tant que mainteneur, vous aurez besoin de cet esprit communautaire.
Vous devez être enthousiaste par ce que vous faites. La collaboration devrait être amusante. Vous êtes heureux que le contributeur ait ajouté quelque chose, mais laissez-le aussi être heureux d'avoir contribué.
Les gens aiment les retours honnêtes et bons. Et cela vous aide également à construire votre petite communauté.
Soyez responsable
Si le projet open source est votre idée, alors vous êtes le pionnier. Si vous décidez d'être le mainteneur principal, soyez le mainteneur principal. Soyez fiable, et surtout, soyez présent.
Même si vous êtes un mainteneur de soutien pour un grand projet, il est bon de montrer que vous savez ce que vous faites et que vous êtes engagé dans le projet.
Certains projets deviennent obsolètes parce que les mainteneurs cessent de répondre aux problèmes et aux pull requests. Il est vrai que la vie nous rattrape parfois. Si vous décidez de vous engager dans un projet, il est important de toujours montrer que le projet est vivant.
Mais comment ? Eh bien, tout revient à la collaboration. Gardez vos collaborateurs impliqués et ils vous aideront.
Soyez gentil et accueillant
Les gens viennent de différents horizons pour découvrir votre projet. Qui qu'ils soient, ils ne reviendront pas si leur première expérience a été un mainteneur méchant, dont le projet avait une documentation médiocre.
Peu importe à quel point vous simplifiez les choses, attendez-vous à des questions. Soyez prêt à répondre à ces questions. Orientez les gens vers les bonnes ressources, peu importe à quel point la solution pourrait être évidente.
Si un contributeur a du mal, vérifiez votre documentation. La plupart du temps, ce n'est pas eux, c'est nous (jeu de mots intentionnel). Le README a peut-être sauté quelques étapes, ou une capture d'écran n'était pas assez claire. Au lieu de les réprimander, orientez-les dans la bonne direction et mettez à jour votre documentation si nécessaire.
Conclusion
En fin de compte, être un mainteneur est un travail difficile. Que vous soyez seul sur votre projet ou que vous travailliez avec d'autres mainteneurs, l'objectif est le même : collaborer pour construire de grands produits.
Les projets avec une gestion et des réponses mal structurées sont l'une des principales raisons pour lesquelles certaines personnes se sentent découragées lorsqu'il s'agit de contribuer à l'open source.
Les compétences que j'ai abordées ici sont principalement basées sur mon expérience personnelle, mais j'espère qu'elles aideront toute personne maintenant un projet ou envisageant de devenir un mainteneur open source.
Si vous souhaitez découvrir mon projet open source, vous pouvez le faire ici.