Conseils pour les nouveaux contributeurs

Nouveau contributeur et vous ne savez pas que faire ? Vous souhaitez aider mais ne savez pas par où commencer ? Cette section est pour vous.

Se mettre à l’ouvrage

Si vous débutez dans la contribution à Django, le tutoriel Écriture de votre première contribution à Django vous donne une introduction aux outils et au flux de travail.

Cette page contient des conseils plus généraux sur les manières de contribuer à Django, et comment entamer ces démarches.

Si vous cherchez une référence sur la façon de contribuer au code de Django, consultez la documentation Contribution au code.

Premiers pas

Commencez par ces étapes pour découvrir le processus de développement de Django.

Triage tickets

Si un ticket avec l’état unreviewed (non révisé) signale une anomalie, essayez de la reproduire. Si vous y arrivez et que le problème semble donc réel, écrivez une note que vous avez pu confirmer l’anomalie et acceptez le ticket. Vérifiez que le ticket soit classé dans le bon composant (« Component »). Envisagez la possibilité d’écrire un correctif qui ajoute un test relatif au comportement problématique, même si vous ne corrigez pas l’anomalie elle-même. Apprenez-en davantage à Commet puis-je aider à trier les tickets ?.

Review patches of accepted tickets

This will help you build familiarity with the codebase and processes. Mark the appropriate flags if a patch needs docs or tests. Look through the changes a patch makes, and keep an eye out for syntax that is incompatible with older but still supported versions of Python. Run the tests and make sure they pass. Where possible and relevant, try them out on a database other than SQLite. Leave comments and feedback!

Keep old patches up-to-date

Il arrive fréquemment que la base de code change entre le moment de la soumission du correctif et le moment de sa relecture. Vérifiez qu’il s’applique toujours proprement et qu’il fonctionne encore comme espéré. La mise à jour d’un correctif est à la fois utile et important ! Plus de détails sur la page Soumission de contributions.

Write some documentation

La documentation de Django est bien faite mais elle peut toujours être améliorée. Avez-vous trouvé une faute d’orthographe ? Pensez-vous que quelque chose devrait être clarifié ? Lancez-vous et proposez un correctif de la documentation ! Voir aussi le guide sur Écrire la documentation.

Note

La page des rapports contient des liens vers de nombreuses requêtes Trac utiles, y compris certaines orientées sur le triage des tickets et la relecture de correctifs comme suggéré ci-dessus.

Sign the Contributor License Agreement

Le code que vous écrivez vous appartient ou il appartient à votre employeur. Si votre contribution dépasse une ou deux lignes de code, vous devez signer le CLA. Voir la FAQ sur l’accord de licence de contribution pour une explication plus complète.

Lignes de conduite

En tant que nouveau venu dans un vaste projet, on peut facilement ressentir de la frustration. Voici quelques conseils pour que votre contribution à Django soit la plus utile et gratifiante possible.

Pick a subject area

This should be something that you care about, that you are familiar with or that you want to learn about. You don’t already have to be an expert on the area you want to work on; you become an expert through your ongoing contributions to the code.

Analyze tickets” context and history

Trac n’est pas un absolu ; le contexte est tout aussi important que les mots. En lisant Trac, vous devez tenir compte de la personne qui parle et du moment où ça a été écrit. Du soutien pour une idée d’il y a deux ans ne signifie pas forcément que l’idée est toujours soutenue. Vous devez aussi tenir compte de qui ne s’est pas exprimé. Par exemple, si un contributeur expérimenté n’a pas été impliqué récemment dans une discussion, le ticket en question n’a peut-être pas encore le soutien nécessaire pour son application dans Django.

Start small

Il est plus facile de recevoir des retours sur de petits problèmes que sur des sujets plus vastes. Voir les tickets marqués comme easy pickings (résolution facile).

Confirm support before engaging in a big task

Cela signifie que quelqu’un d’autre doit confirmer que le bogue est réel avant de commencer à corriger l’erreur, et de s’assurer qu’il y a consensus autour d’une fonctionnalité proposée avant de se mettre à l’implémenter.

Be bold! Leave feedback!

Il peut parfois paraître effrayant d’exprimer publiquement son opinion et de dire « ce ticket est correct » ou « ce correctif doit être retravaillé », mais c’est la seule façon de faire avancer le projet. Les contributions de la communauté Django au sens large ont au final un bien plus grand impact que ce qu’un individu seul pourrait faire. Nous ne pourrons pas le faire sans vous !

Be cautious when marking things « Ready For Check-in »

If you’re really not certain if a ticket is ready, don’t mark it as such. Leave a comment instead, letting others know your thoughts. If you’re mostly certain, but not completely certain, you might also try asking on the #contributing-getting-started channel in the Django Discord server to see if someone else can confirm your suspicions.

Wait for feedback, and respond to feedback that you receive

Concentrez-vous sur un ou deux tickets et suivez-les du début à leur fin, puis passez à la suite. L’approche coup de fusil de commencer de travailler sur de nombreux tickets, puis d’en laisser certains de côté fait plus de tort que de bien.

Be rigorous

When we say « PEP 8, and must have docs and tests », we mean it. If a patch doesn’t have docs and tests, there had better be a good reason. Arguments like « I couldn’t find any existing tests of this feature » don’t carry much weight. While it may be true, that means you have the extra-important job of writing the very first tests for that feature, not that you get a pass from writing tests altogether.

Be patient

Il n’est pas toujours évident qu’un ticket ou un correctif puisse être examiné rapidement. Cela n’a rien de personnel. Il y a beaucoup de tickets et de requêtes de contribution à traiter.

Le maintien à jour de votre correctif est important. Examinez le ticket sur Trac pour vous assurer que les coches Needs tests, Needs documentation et Patch needs improvement soient décochées après avoir mise en œuvre tous les commentaires de la révision.

Rappelez-vous que le cycle de publication de Django dure 8 mois, ce qui signifie qu’il y a assez de temps pour relire votre correctif.

Enfin, un rappel à un temps opportun peut aider. Consultez la FAQ de contribution au code pour des idées à ce sujet.