Note du traducteur
C'est la traduction du fichier contributing.md. Voici un lien vers les différences avec le master de AVA (Si en cliquant sur le lien, vous ne trouvez pas le fichier contributing.md parmi les fichiers modifiés, vous pouvez donc en déduire que la traduction est à jour).
✨ Merci pour votre contribution à AVA ! ✨
Veuillez noter que ce projet est publié avec un Code de conduite du contributeur. En participant à ce projet, vous vous engagez à respecter ses termes.
Traductions : English, Español, Italiano, 日本語, Português, Русский, 简体中文
En tant qu'utilisateur de AVA, vous êtes le candidat idéal pour nous aider à améliorer notre documentation : corrections de typo, corrections d'erreur, de meilleures explications, plus d'exemples, etc. Ouvrez des issues pour des choses qui pourraient être améliorées. Aidez à traduire nos docs. N'importe quoi. Même les améliorations apportées à ce document.
Utilisez l'étiquette scope:documentation pour trouver des suggestions, sur ce que nous aimerions voir en plus dans la documentation.
Certaines issues sont créées avec des informations manquantes, non reproductibles, ou simplement invalides. Aidez nous à rendre leur résolution plus facile. La gestion des issues prend beaucoup de temps, grâce à votre aide, nous pouvons consacrer plus de temps à la correction de bugs et l'ajout de fonctionnalités.
Nous sommes toujours intéressés par d'autres avis dans les discussions des issues. C'est une bonne occasion d'influencer l'orientation future de AVA.
Les étiquettes needs triage et question sont les bons endroits pour trouver des discussions en cours.
Vous pouvez utiliser les étiquettes pour découvrir les issues où vous pourriez aider :
blockedoù nous avons besoin d'aide pour débloquer la situationbugpour les bugs connus que nous aimerions corrigerenhancementsont des fonctionnalités à ajouterperformancepropose des idées sur la façon d'améliorer les performances de AVA
Les étiquettes help wanted (aide demandée) et good for beginner (bon pour les débutants) sont particulièrement utiles.
Vous trouverez peut-être une issue qui est attribuée. Veuillez vérifier avant de commencer sur cette issue parce que quelqu'un d'autre est probablement en train de travailler dessus.
Nous aimerions corriger les issues priority (prioritaires) en premier. Nous aimerions aussi voir des avancées sur les issues low-priority (de faible priorité). Les issues future sont celles que nous aimerions avoir, mais pas tout de suite. Veuillez vérifier avant de travailler sur celles-ci, car nous voulons peut-être pas pour l'instant assumer la charge de ces fonctionnalités.
Vous trouverez ci-dessous des conseils pour contribuer au code.
Nous utilisons GitHub Discussions. Allez-y pour observer, nous parler et aider les autres.
Lorsque vous trouvez une issue sur laquelle vous aimeriez travailler, laissez un commentaire pour que les autres soient au courant. Nous vous affecterons alors l'issue.
Bien sûr, vous pouvez travailler sur des choses qui n'ont pas encore d'issue. Cependant, si vous comptez fournir un effort important, il est préférable d'en discuter avant.
Lorsque vous êtes prêt à recevoir des commentaires sur votre travail, ouvrez une draft pull request. Ce n'est pas grave si le travail n'est pas encore terminé, mais faites-nous savoir ce qu'il reste à faire. Les relecteurs sauront ainsi qu'il ne faut pas pinailler sur les petits détails ou signaler les améliorations que vous savez déjà devoir apporter.
La relecture de pull request importantes peut prendre beaucoup de temps. Un temps qui n'est pas toujours disponible. Les demandes plus petites peuvent être traitées plus rapidement. Si vous introduisez une nouvelle fonctionnalité, réfléchissez à la manière dont elle pourrait être décomposée. Il n'y a pas de mal à introduire des fonctionnalités comme expérimentales. Celles-ci nécessitent moins de documentation et de couverture de test.
Essayez d'éviter d'apporter des modifications de ruptures (breaking changes). Celles-ci sont plus longues à livrer. Au lieu de cela, faites en sorte que le nouveau comportement soit expérimental. De cette façon, votre fonctionnalité peut être livrée, et vous pouvez l'utiliser, selon son propre échéancier.
Les fonctionnalités non expérimentales doivent être accompagnées de tests et de documentation.
N'incluez pas de modifications sans rapport avec la fonctionnalité dans votre pull request. Assurez-vous que les tests passent sur votre machine en exécutant npm test. Vous pouvez également lancer des fichiers de test spécifiques en utilisant npx tap test-tap/{file}.js or npx test-ava test/{file}.js.
Lorsque vous faites une pull request, veuillez utiliser un titre clair et descriptif. Soyez précis sur ce qui a été modifié et pourquoi.
Assurez-vous que la case Allow edits from maintainers est cochée. De cette façon, nous pourrons apporter nous-mêmes certaines modifications mineures, ce qui permettra de fusionner votre pull request plus rapidement.
Il se peut que l'on vous demande d'apporter des modifications à votre pull request. Il n'est jamais nécessaire d'ouvrir une autre pull request. Envoyez plus de commits à votre branche existante. Nous les écraserons (squash) lorsque nous fusionnerons le PR.
Les dépendances sont gérées par npm. Ne mettez à jour les dépendances que lorsque cela est nécessaire pour votre pull request. Ne reconstruisez pas le fichier de verrouillage (lockfile).
Et enfin, amusez-vous bien !