Étiquette de base pour les projets open source

Avant de commencer à contribuer à un projet open source, demandez-vous pourquoi vous voulez le faire. Si la réponse à cette question est simplement « Je m'ennuie et je veux trouver quelque chose de productif à faire avec mon temps », c'est bien, mais vous pouvez probablement aller plus loin.

De meilleures raisons encore peuvent être envisagées :

• J'utilise cet outil en permanence et j'ai trouvé un bogue dans celui-ci/je veux contribuer à son amélioration.
• Je veux aider d'autres personnes à utiliser cet outil avec plus de facilité.
• Je veux aider d'autres personnes à contribuer au projet avec plus de facilité.
• Je veux améliorer mes propres compétences.
• Je veux démontrer publiquement mes propres compétences dans le cadre de mon cursus universitaire ou collégial.
• Je veux démontrer publiquement mes propres compétences pour améliorer mes chances de trouver un emploi.

Si vous passez votre temps à travailler gratuitement sur un projet, il est raisonnable de s'attendre à en retirer quelque chose. En fait, vous êtes beaucoup plus susceptible de rester plus longtemps et de contribuer de manière plus productive au projet. En outre, si vous avez un bon ensemble de raisons de contribuer avant de commencer, il sera plus facile de décider des tâches à entreprendre.

Voici quelques raisons pour lesquelles vous ne devriez pas commencer à contribuer :

• Je veux quelqu'un à qui parler.
• Je veux des gens à troller ou à diriger.
• Je veux montrer à quel point je suis incroyable.

Votre présence sur le projet doit rester productive, et ne pas empêcher les autres d'être productifs.

On pourrait abréger cela en disant « soyez gentil ». C'est le conseil numéro un que nous donnons à toute personne qui se lance dans les contributions open source.

Soyez gentil avec les autres contributeurs du projet, et le projet sera plus agréable et plus productif. Cela inclut :

• Remercier les gens s'ils vous aident.
• Féliciter les personnes lorsque cela est approprié (par exemple, si elles déposent leur toute première demande de révision ou si elles résolvent un bogue particulièrement difficile).
• Toujours répondre respectueusement aux gens, même si vous avez l'impression que la réponse à leur question était un peu évidente, ou qu'ils se répètent.
• Essayer d'aider les gens à faire mieux la prochaine fois, en les soutenant, par exemple lors de l'examen des demandes de modification ou en répondant à leurs questions. Dire « c'est faux » ou « voici la réponse » est loin d'être aussi utile que de dire « c'est correct, mais je pense que ce serait mieux si vous essayiez de faire plus comme ceci, voici un article de blog pour plus d'idées » ou « vous pouvez trouver la réponse ici ; consultez également ce lien pour des réponses plus courantes ».

Vous et les autres contributeurs êtes (ou devriez être) ici parce qu'ils veulent apporter une contribution positive au projet, mais au-delà de cela, vous ne pouvez rien présumer d'eux. Cela inclut leurs :

• Connaissance du projet et des technologies utilisées pour le construire
• Sexe, sexualité, âge, langues parlées, lieu de résidence, opinions politiques, religion ou autres caractéristiques personnelles
• Expérience des projets open source
• Confiance
• Attentes
• Sens de l'humour

Vous devez donc vous en tenir autant que possible au sujet, en évitant les hors-sujets potentiellement controversés comme la religion ou la politique, et en faisant preuve de soutien et de respect même si vous n'êtes pas d'accord avec quelqu'un ou si vous n'aimez pas une décision qu'il a prise.

De même, vous devez vous abstenir de tout juron ou langage offensant sur MDN, même s'il n'est pas dirigé contre quelqu'un en particulier. Ce n'est pas nécessaire pour participer, et certaines personnes y sont vraiment sensibles.

Sachez qu'il existe des règles dans toute bonne OSP pour protéger ses contributeurs afin qu'ils ne se sentent pas mal à l'aise lorsqu'ils contribuent. Ces règles prennent généralement la forme d'un fichier CODE_OF_CONDUCT.md sur GitHub.

Par exemple, les dépôts du MDN sont régis par les vastes Mozilla Community Participation Guidelines. Habituellement, un comportement légèrement offensant sur les dépôts MDN (comme le fait d'être constamment hors sujet/perturbant, ou d'être impoli) sera d'abord répondu par un avertissement sur le dépôt, suivi d'un dernier avertissement, puis d'un bannissement temporaire ou permanent. Les problèmes de comportement plus graves, tels que les discours haineux ou les menaces à l'encontre d'un autre contributeur, ne seront pas tolérés et entraîneront probablement un bannissement immédiat.

Si vous recevez quelque chose qui vous met mal à l'aise, vous devez toujours le signaler en utilisant le mécanisme prévu dans le code de conduite.

Réfléchissez à ce que vous voulez faire sur le projet. Par exemple, nous avons une grande liste de problèmes déposés sur https://github.com/mdn/translated-content/issues, répartis selon diverses étiquettes GitHub en temps estimé de correction, catégories technologiques, et plus encore. Une autre bonne étiquette à rechercher est « good first issue », qui est généralement donnée aux issues qui sont assez simples et bonnes pour les débutants du projet pour commencer. Nous allons bientôt commencer à trier nos problèmes de manière plus approfondie, en ajoutant d'autres étiquettes telles que des indicateurs de priorité. Essayez de choisir quelques problèmes que vous pensez pouvoir gérer correctement avec le temps dont vous disposez, et demandez à y être affecté.

Vous pouvez également contribuer en ouvrant des demandes de triage pour résoudre les problèmes que vous rencontrez en lisant les articles du site MDN.

Une grande partie du travail sur le MDN consiste à rédiger de la documentation et des exemples de code, mais il existe d'autres façons de contribuer :

• Aidez à trier les problèmes qui arrivent.
• Aidez à corriger les fautes de frappe.
• Aider à améliorer la grammaire et à rendre les pages plus compréhensibles.
• Aidez à encadrer les personnes qui essaient de corriger les problèmes.

Chaque correction est utile, aussi petite soit-elle, et nous n'en refuserons aucune. Cela dit, veillez à ce que vos corrections soient productives. Nous vous déconseillons ce genre de contributions :

• Mettre à jour le style du code juste parce que "vous préférez ce style".
• Mettre à jour le style de la langue "juste parce que vous aimez mieux ce style".
• Changer les pages de l'anglais américain à l'anglais britannique.
• Ajouter ou enlever un tas de ponctuation alors qu'il n'y a pas vraiment de problème.
• Changer le cadre de test que nous utilisons pour quelque chose d'autre parce que vous le préférez.

Dans de nombreux cas, les choses sont comme elles sont sur les OSP pour une raison. Vous devriez lire leurs guides de style, s'ils en ont un, et en cas de doute sur la productivité de quelque chose, demandez toujours avant !

Les bons OSP rendront toujours la documentation des contributeurs facilement accessible. Sur les projets GitHub, elle se trouve généralement dans le fichier CONTRIBUTING.md du dépôt, ou parfois dans le fichier README.md du projet. Étant un projet de documentation, le contenu de MDN dispose d'un README et d'un ensemble décent de docs pour les contributeurs sur le site lui-même (voir Contribuer à MDN).

La seule chose à demander ici est de ne pas avoir peur de demander de l'aide, mais de TOUJOURS essayer de trouver la réponse à votre question avant de la poser. De cette façon, vous développez votre connaissance du projet et devenez plus indépendant, et vous n'imposez pas une charge inutile aux autres contributeurs.

Bien sûr, la documentation ne sera pas toujours parfaite. Si vous trouvez quelque chose qui est difficile à trouver ou qui n'est pas très bien expliqué, déposez un ticket ou créez une demande de modification pour essayer de le corriger vous-même.

Cherchez toujours à savoir quel est le meilleur endroit pour poser des questions. Les bons OSP le préciseront toujours dans leur docs (voir Demander de l'aide sur le MDN). Si vous souhaitez poser des questions d'ordre général, utilisez toujours ces canaux. Ne vous contentez pas de déposer un ticket sur GitHub pour chaque question, car cela ajoute du poids au projet (voir "Faites des progrès, pas du bruit" ci-dessous).

Réfléchissez bien à la façon dont vous gérez la communication dans le projet - assurez-vous qu'elle est utile et qu'elle ne complique pas le travail des autres contributeurs. Soumettre des pull requests pour corriger des bogues, c'est bien, mais sont-elles vraiment utiles et faciles à examiner ? Déposer des questions et participer à d'autres conversations, c'est bien, mais vos questions et commentaires sont-ils pertinents ou ne font-ils qu'ajouter du brouhaha ?

En règle générale, faites ceci :

• Discutez d'un seul sujet par question - il est facile de garder les questions ciblées et productives.
• Corrigez un problème par PR - cela peut représenter un peu plus de travail pour vous, mais il est beaucoup plus facile d'examiner une seule correction claire.
• Contribuez à d'autres fils de discussion si vous avez une remarque utile à faire ou si vous pouvez répondre à la question d'une autre personne.
• Posez des questions en utilisant d'autres mécanismes comme les salons de discussion ou les forums si vous n'êtes pas sûr de l'utilité de quelque chose ou si vous avez une question simple.
• Lisez d'abord le guide pour essayer de répondre vous-même à la question avant de la poser.

Et pas :

• Compliquez les choses en essayant de discuter de plusieurs sujets à la fois, ou en faisant des commentaires hors sujet.
• Essayer de regrouper plusieurs corrections dans une seule demande de triage. Cela rend la révision beaucoup plus difficile et éveille les soupçons (certaines personnes pourraient penser que vous essayez de cacher un code malveillant entre les changements valides).
• Ouvrir beaucoup de tickets en posant des questions vagues.
• Posez des questions sans essayer d'abord de résoudre le problème vous-même.

Les OSP sont assez démocratiques - de nombreuses décisions font l'objet d'un vote, et vous êtes largement libre de contribuer comme vous le souhaitez, tant que vous n'empêchez personne d'autre de contribuer.

Cependant, certaines choses seront largement décidées par un petit groupe de contributeurs principaux. Vous êtes libre de vous opposer à toute décision, mais il arrive qu'un modérateur prenne une décision qui va à l'encontre de votre opinion. Vous devez respecter et accepter ces décisions.

Il est utile d'apprendre à connaître les modérateurs d'un projet, afin de savoir à qui demander de l'aide, par exemple dans les fils de discussion des demandes de triage ou des problèmes.

Gardez à l'esprit que de nombreuses personnes travaillant sur des OSP le font sur leur temps libre, sans rémunération, et que toutes les personnes travaillant sur des OSP sont généralement très occupées. Si vous attendez quelque chose comme la révision d'une pull request ou une réponse à une question, soyez patient.

Il est raisonnable d'attendre quelques jours, puis de demander poliment à quelqu'un s'il a eu le temps d'y jeter un coup d'œil, et éventuellement de relancer une semaine plus tard pour demander s'il est trop occupé pour le moment.

Il n'est PAS raisonnable de commencer à exiger des choses, comme si on vous devait une réponse rapide. Ce n'est pas le cas.

Si quelqu'un attend que vous fassiez quelque chose pour lui, vous devez faire preuve de la même courtoisie, mais en même temps, essayez de répondre aussi rapidement que possible. Si vous ne pouvez vraiment pas trouver le temps, faites-le savoir et demandez aux responsables de vous aider à trouver quelqu'un d'autre pour effectuer cette tâche.

• Comment contribuer à l'Open Source
• Liste plus générale de freeCodeCamp « Comment contribuer à l'open source ».
• Commencer à contribuer à l'open source