Une fois que vous avez identifié un domaine dans lequel vous pouvez contribuer, l’étape suivante consiste à préparer votre contribution. Nous allons revoir ici comment vous pouvez communiquer votre intention de participer à un projet, créer une pull request, et augmenter vos chances qu’elle soit acceptée.

Lorsqu’il s’agit de contribuer à un projet open source, la communication est un facteur clé de réussite. Il se peut que vous soyez mal à l’aise à l’idée de discuter avec d’autres personnes à propos des changements ou améliorations que vous proposez. Souvent, ce dialogue mènera à des discussions et des compromis sur votre idée initiale.

Éviter de communiquer activement avec les autres personnes impliquées dans un projet open source signifie que vous risquez de passer du temps à travailler sur des tâches que quelqu’un d’autre est déjà en train de faire. Ou bien, vous pourriez travailler sur des fonctionnalités ou des améliorations qui ne sont pas en accord avec les valeurs ou les bonnes pratiques du projet. Dans les deux cas, le temps de chacun est perdu. À l’inverse, s’engager dans une communication active garantit que votre travail sera bien accueilli et aura de l’impact.

Comment s’assurer de réussir sa communication avec les membres d’un projet à propos de nouvelles fonctionnalités ou de changements ? Commencez par garder l’esprit ouvert. Soyez réceptif aux retours et faites preuve de patience. Les mainteneurs de projets open source ont très probablement un emploi à temps plein et une vie privée à gérer. Si vous ne recevez pas de réponse immédiatement, attendez un peu plus longtemps avant de relancer les mainteneurs.

Communiquez votre intention aux mainteneurs
Vous devez toujours commencer par faire part de votre intention de contribuer avant de commencer à travailler. Sauf indication contraire dans le fichier README, le issue tracker est généralement l’endroit idéal pour cela.

Si vous souhaitez travailler sur un problème existant, vérifiez que personne n’y est déjà assigné en consultant la section Assignees. Vérifiez également la section Linked pull requests. Une pull request liée signifie que quelqu’un travaille déjà dessus. Parcourez les commentaires pour voir si quelqu’un a exprimé son intérêt pour ce problème. Si tout est clair, publiez un commentaire sur le problème pour indiquer votre intention de le prendre en charge. De cette façon, vous informez les autres personnes intéressées que quelqu’un travaille déjà dessus. De plus, si nécessaire, les mainteneurs peuvent vous répondre avec des conseils et des orientations.

Contribuer à une nouvelle fonctionnalité ou corriger un bug

Si vous souhaitez travailler sur une nouvelle fonctionnalité ou sur un bug qui n’est pas encore présent dans le issue tracker, créez un nouveau ticket (issue). Assurez-vous de suivre le modèle proposé s’il y en a un, et exprimez clairement votre intention de travailler sur ce ticket. S’il s’agit d’une proposition de nouvelle fonctionnalité ou si le problème nécessite de nombreux changements, assurez-vous d’obtenir l’approbation des mainteneurs avant de passer à l’étape suivante.

Créer une pull request sur un dépôt GitHub

Une fois que vous avez communiqué votre intention d’aider le projet, vous êtes prêt à commencer à travailler sur votre contribution.

Votre contribution prendra la forme d’une pull request (ou PR). Une pull request est un espace spécial sur GitHub qui contient plusieurs éléments :

• Un titre et une description de vos modifications.
• Un ou plusieurs commits qui constituent les changements que vous proposez.
• Des commentaires, où tout le monde peut participer à une discussion sur les modifications.
• Des revues de code, où vous pouvez recevoir des retours détaillés sur vos changements et éventuellement des suggestions de modifications.
• Des vérifications de statut, par exemple issues de tests automatisés mis en place par les mainteneurs. Ces vérifications peuvent avoir différents objectifs : s’assurer que vos modifications respectent les règles du projet ou qu’elles ne cassent pas le code existant.

Une fois la pull request créée, elle peut être mise à jour avec de nouveaux commits, commentaires ou revues de code. Ce processus se poursuit jusqu’à ce que les mainteneurs du projet approuvent et fusionnent la pull request, ou rejettent les modifications et la ferment. Lorsque votre pull request est fusionnée, cela signifie que vos modifications ont été intégrées dans le code du projet.

Créer une pull request étape par étape

1. Ouvrez la page GitHub du projet auquel vous souhaitez contribuer.
2. Cliquez sur le bouton Fork pour créer une copie du dépôt sur votre compte GitHub. Cette étape est nécessaire car, par défaut, vous n’avez pas les permissions pour modifier un dépôt public, sauf s’il s’agit de votre propre copie. En forkant le projet, vous créez une copie sur laquelle vous pouvez effectuer des modifications.

3. Sélectionnez Vos référentiels dans le menu profil de votre compte.

4. Sélectionnez le fork du dépôt.

5. Cliquez sur le bouton Code pour obtenir des informations sur la façon de cloner le dépôt Git sur votre machine locale.

6. Sélectionnez l’icône du Presse-papiers pour copier l’URL du dépôt, puis entrez ceci dans un terminal :

git clone <REPOSITORY_URL>

git clone <REPOSITORY_URL>

Cette commande va créer une copie du dépôt sur votre machine locale.

Alternativement, vous pouvez utiliser GitHub Desktop si vous préférez utiliser une application. Ou bien, vous pouvez utiliser GitHub Codespaces si cette option vous est proposée. Si vous êtes utilisateur de Visual Studio Code, GitHub Codespaces vous semblera familier.

7. Une fois le projet cloné, entrez dans le dossier du projet :

cd <PROJECT_FOLDER>

cd <PROJECT_FOLDER>

8. (Optionnel) Créez une nouvelle branche en utilisant la commande suivante :

git checkout -b <BRANCH_NAME>

git checkout -b <BRANCH_NAME>

Cette étape n’est pas obligatoire, mais elle est fortement recommandée. Avec une nouvelle branche, vous pouvez travailler sur plusieurs contributions séparément, chacune sur une branche différente.

Apportez les modifications souhaitées au projet et validez-les (commit) :

git add .
git commit -m "<COMMIT_MESSAGE>"

git add .
git commit -m "<COMMIT_MESSAGE>"

Ces commandes vont préparer vos modifications pour le commit (staging), puis créer un commit avec le message spécifié. Assurez-vous de décrire précisément vos modifications dans le message de commit. Il est également conseillé de vérifier s’il y a des indications dans le fichier CONTRIBUTING concernant les conventions à suivre pour les messages de commit.

Poussez (push) vos modifications vers le dépôt distant en utilisant la commande suivante :

git push --set-upstream origin <BRANCH_NAME>

git push --set-upstream origin <BRANCH_NAME>

Cette commande crée une nouvelle branche sur le dépôt distant sur GitHub (votre fork), et y pousse tous vos commits.

Si vous n’avez pas créé de branche auparavant, entrez simplement :

Ouvrez ensuite le fork de votre projet sur GitHub, puis cliquez sur le bouton Compare & pull request dans la boîte de suggestion qui s’affiche.

Remplissez le titre et la description, puis sélectionnez Create pull request (Créer une pull request).

S’il existe un modèle (template) pour la description de la pull request, prenez le temps de remplir toutes les informations demandées.
S’il n’y en a pas, assurez-vous de fournir suffisamment de contexte pour que les mainteneurs comprennent les modifications que vous proposez et pourquoi.
Vous devez également faire le lien avec le ticket concerné en mentionnant son numéro en utilisant #<NUMÉRO_DU_TICKET>.
Vous pouvez trouver le numéro du ticket à côté de son titre.

Passer les vérifications de statut

Après avoir créé la pull request, vous verrez peut-être une section avec des vérifications de statut en bas, comme ceci :

Ces vérifications de statut sont des contrôles automatisés mis en place par les mainteneurs pour garantir une qualité constante du projet.

Pour que votre pull request soit acceptée, elle doit réussir toutes les vérifications automatisées. Si l’une d’elles échoue, comme dans la capture d’écran précédente, cliquez sur le bouton Details pour en savoir plus sur l’échec et découvrir ce que vous devez faire pour le corriger.

Si vous ne savez pas quoi faire face à une vérification échouée, vous pouvez toujours utiliser les commentaires pour demander des conseils ou de l’aide aux mainteneurs.

Demander des conseils ou des revues sur les pull requests

Il se peut que vous ayez des doutes sur certaines modifications que vous avez apportées et que vous souhaitiez obtenir l’avis des mainteneurs. Le meilleur moyen de le faire est de commenter directement dans la pull request.
Si vous considérez que vos modifications sont encore en cours de travail (work-in-progress), vous avez aussi la possibilité de créer une pull request en brouillon (draft pull request) pour demander des conseils ou de l’aide à d’autres contributeurs.

Après le passage des mainteneurs du projet sur votre pull request, ils peuvent répondre à la conversation ou examiner directement vos modifications. Plusieurs résultats sont possibles à l’issue d’une revue de pull request :

• Vos modifications sont approuvées. Félicitations !
• Votre pull request nécessite des modifications. Ne vous découragez pas ! Analysez attentivement les retours fournis. Si vous effectuez les changements demandés, il y a de fortes chances que votre pull request soit acceptée. Si vous poussez de nouveaux commits sur votre branche, la pull request sera automatiquement mise à jour avec les nouvelles modifications.
• Le relecteur a laissé des commentaires. Cela signifie généralement qu’il faut plus de détails sur vos modifications ou sur la motivation qui les justifie.

Répondre aux commentaires sur votre pull request

Souvenez-vous de toujours rester respectueux dans tous vos échanges et de suivre le code de conduite. Il est probable qu’avant que vos modifications soient acceptées, une discussion continue ait lieu avec les mainteneurs ou d’autres contributeurs.

Contribuer à l’open source demande de la patience. Parfois, vous ne recevrez pas de retour immédiat. N’essayez pas de contacter les mainteneurs en privé par e-mail, X (anciennement Twitter), ou tout autre moyen dans l’espoir d’obtenir une réponse plus rapide. Ce comportement est considéré comme nuisible.
Discuter publiquement permet aussi à d’autres contributeurs ou visiteurs d’apprendre le processus derrière les modifications et les bonnes pratiques à suivre.