Débutant complet
Commencez avec les outils, le vocabulaire et un changement uniquement documentaire. Votre but est de terminer une boucle sûre.
Guide contributeur
Le chemin fiable le plus court entre une issue adaptée aux débutants et une pull request prête pour les mainteneurs.
Commencer ici
Utilisez ces cartes comme sélecteur statique. Choisissez celle qui correspond à votre situation, puis suivez les mêmes phases ci-dessous.
Commencez avec les outils, le vocabulaire et un changement uniquement documentaire. Votre but est de terminer une boucle sûre.
Choisissez une issue minuscule et récente, puis gardez le diff ciblé. Demandez confirmation avant de coder.
Utilisez le playbook comme checklist, puis consacrez l'essentiel de votre énergie à reproduire et tester la correction.
Phase 0
Il vous faut seulement assez d'outils locaux pour cloner le dépôt, créer une branche, lancer les vérifications du projet et pousser votre travail.
Git suit votre travail et permet aux mainteneurs de relire exactement ce qui a changé.
git --versionGitHub CLI vous aide à fork, cloner, vous authentifier et ouvrir des pull requests sans quitter le terminal.
gh auth login
gh repo fork OWNER/REPO --clone --remoteUtilisez un éditeur capable de chercher dans tout le dépôt, lancer les formatters et afficher clairement les fichiers modifiés.
code .Phase 1
Une bonne first issue n'est pas seulement petite. Elle est actuelle, compréhensible et reviewable par quelqu'un qui maintient déjà le projet.
Laissez un court commentaire qui nomme l'issue exacte et demande si le périmètre a toujours du sens.
Lisez CONTRIBUTING, le README, les pull requests ouvertes, les commandes de test et les notes de style avant de changer le code.
Créez votre propre copie et travaillez sur une branche nommée d'après la tâche, pas sur main.
Installez les dépendances, reproduisez le problème et notez la commande ou l'écran où vous l'avez vu.
Changez le minimum de code nécessaire. Évitez les refactors opportunistes, upgrades de dépendances et formatages sans rapport.
Expliquez ce qui a changé, comment vous l'avez testé et les limites. Rendez la première lecture du reviewer simple.
Points de pause
S'arrêter tôt vaut mieux que forcer une pull request impossible à relire.
Vous ne pouvez pas lancer le projet localement après avoir suivi la configuration documentée.
La correction demande de deviner un comportement produit sans avis mainteneur.
L'issue demande une grande fonctionnalité, une refonte, une migration ou une décision d'architecture.
Un mainteneur a demandé aux premiers contributeurs de ne pas travailler sur cette zone.
Référence
FAQ
Publiez un suivi concis avec votre état actuel et une question directe. S'il n'y a toujours pas de réponse, choisissez une autre issue plutôt que d'attendre indéfiniment.
Dites ce que vous avez essayé, collez l'erreur exacte, indiquez votre système d'exploitation et les versions des outils, puis demandez la prochaine étape de debug.
Oui, si le dépôt accueille les changements de documentation. Des docs claires, des exemples, des typos et des liens cassés sont de vraies contributions.