Démystifier la contribution Open Source
Temps de lecture : 4 minutes
Publié le 24 janvier 2020
WASSIM CHEGHAM
Senior Cloud Advocate
Ce guide d’apprentissage s’adresse avant tout aux personnes qui contribuent ou envisagent de contribuer pour la première fois aux projets Open Source. Il vous apprendra pas à pas comment participer à ces projets en apportant des actions correctives.
Pourquoi contribuer selon Wissam Chegham :
En tant qu’auteur et responsable de la maintenance (« maintainer ») de plusieurs projets Open Source, je suis toujours ravi d’apprendre ou de constater que mes projets sont utilisés par d’autres développeurs. Et j’apprécie vraiment que ces développeurs proposent d’apporter des corrections ou des améliorations à ces projets.
Les différentes étapes pour contribuer
Identifiez le projet sur lequel vous souhaitez travailler
Il faut commencer par identifier un projet qui vous intéresse particulièrement ou qui semble correspondre à vos compétences. Les personnes qui débutent devraient commencer par un projet portant sur les outils qu’ils utilisent au quotidien, dans leur travail. Vous connaissez déjà ces outils, et vous avez peut-être déjà constaté des problèmes à corriger ou des fonctionnalités à améliorer.
Vous n’avez pas besoin d’une raison particulière pour sélectionner un projet. Certains choisissent un projet en fonction de la technologie qu’ils utilisent, d’autres pour s’amuser.
Dupliquer le projet
Avant toute chose, il faut dupliquer (« fork ») le projet dans son compte GitHub (si GitHub est utilisé). Cette opération consiste à copier le projet d’origine dans ses propres projets GitHub. Il sera ainsi possible de travailler sur une copie.
Cloner et installer les dépendances
L’étape suivante consiste à cloner (ou télécharger) le projet, qui vient d’être copié (fork), sur l’ordinateur pour commencer à travailler.
Si votre travail est essentiellement sur la documentation, la traduction ou la correction des fautes de frappe, faite le directement depuis votre navigateur. Inutile de cloner le projet sur son ordinateur. En revanche, si vous devez exécuter une étape de génération (« build ») ou un processus de formatage (« lint ») sur la documentation avant de publier vos modifications, vous devrez cloner le projet sur votre poste et installer les dépendances requises.
Une fois le projet cloné, il faut attentivement lire le fichier CONTRIBUTING.md, README.md , ou tout autre fichier qui décrit les étapes nécessaires pour exécuter et générer le projet localement. Si vous êtes bloqué, les mainteneurs du projet pourront vous aider si vous les contactez.
Comment contribuer?
Les nouveaux contributeurs sont souvent déconcertés par cette étape. Commençons par expliquer ce qu’est une « contribution ».
Contribuer à un projet Open Source, ça ne se limite pas à rédiger du code et à corriger des problèmes techniques. En fait, le champ des contributions est quasi illimité.
Quelques exemples (des tâches les plus rapides aux plus prenantes) :
- Remercier l’équipe qui travaille sur un outil que l’on utilise
- Faire connaître le projet lors de manifestations ou en ligne
- Aider à répondre aux questions
- Corriger les fautes de frappe dans la documentation
- Rédiger ou traduire la documentation
- Aider à reproduire les bogues et les problèmes signalés
- Refactoriser le code existant
- Corriger les bogues techniques
- Écrire des tests unitaires
- Intégrer de nouvelles fonctionnalités
- Remettre en question la conception de l’architecture centrale
- Et plein d’autres…
Une contribution concerne tout ce qui peut améliorer un projet.
Identifier un « correctif » à apporter
Un correctif et une aide que vous apportez. Un conseil pour les débutants est de ne pas être trop ambitieux. Choisissez un point facile et rapide à corriger. Les fautes de frappe dans la documentation, par exemple. Cela vous permettra de lire toute la documentation et de vous familiariser avec le projet, idéal pour vous en faire une idée précise.
La rédaction ou la correction des tests unitaires sont également de bons choix pour une première contribution. Les tests unitaires permettent de se plonger progressivement, à son rythme, dans l’implémentation précise d’une fonctionnalité. Si des tests d’intégration sont prévus, commencez par là avant de vous attaquer aux tests unitaires. Vous aurez ainsi une bonne idée de l’architecture générale, sans avoir à vous plonger dans les détails de l’implémentation.
Pensez à indiquer aux autres contributeurs du projet sur quel point vous travaillez, en postant un commentaire dans le fil correspondant, sur la page du dépôt Github.
Application du « correctif »
Cette étape dépend surtout du type de problème sur lequel vous travaillez. Lisez attentivement les consignes applicables aux contributions au projet, et à les respecter. La plupart des projets Open Source populaires s’accompagnent de consignes et de règles de formatage strictes qui doivent être suivies par tous les contributeurs.
N’hésitez pas à vous adresser au mainteneur ou à d’autres contributeurs si vous êtes bloqué ou si vous avez la moindre question.
Valider et publier des modifications
Une fois le correctif prêt, il faut maintenant valider (commit) les modifications et les publier (push) sur votre propre copie du projet, celle que vous avez dupliquée.
Encore une fois, vous devez lire attentivement les consignes pour savoir comment formater vos messages de validation et les noms des branches. Chaque projet a ses propres conventions. Une bonne pratique consiste à publier les modifications (correctifs) dans une branche autre que la branche « master » ou « develop », pour pouvoir facilement fusionner ou « rebaser » les modifications par la suite, si c’est nécessaire.
Il est généralement demandé, et parfois exigé, de fournir une description détaillée des modifications/correctifs/implémentations dans le corps de l’objet « commit ». Cela permet aux autres de connaître immédiatement les modifications apportées par cet objet.
Envoyer une Pull Request
Une fois prêt à envoyer vos modifications au projet d’origine ou amont (« upstream »), ouvrez une pull request et envoyez la.
Une fois votre demande reçue, les mainteneurs du projet peuvent vous demander de mettre à jour ou de revoir vos modifications avant de pouvoir fusionner votre pull request.
Si, pour une raison ou une autre (généralement d’ordre technique) les mainteneurs sont dans l’incapacité de fusionner votre pull request, ce n’est ni leur faute, ni la vôtre; Vous pourrez refaire une tentative ou passez à autre chose en attaquant un nouveau correctif.
*Ce guide a été écrit en prenant l’hypothèse que vous connaissez déjà Git.
Lire aussi Cloud : Innovation, modernisation de l’IT
