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 premier correctif pour 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 Écriture du code.

Premiers pas

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

• Trier des 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 ?.

• Recherchez les tickets acceptés et faites des relectures de correctifs pour vous familiariser avec la base de code et les processus

  Cochez les cases appropriées si un correctif a besoin de documentation ou de tests. Parcourez les modifications apportées par le correctif et soyez attentif à la syntaxe qui pourrait être incompatible avec des versions de Python encore prises en charge. :doc:Lancez les tests </internals/contributing/writing-code/unit-tests>` et assurez-vous qu’ils passent. Lorsque c’est possible et adéquat, faites-les passer avec une autre base de données que SQLite. Écrivez vos commentaires et vos expériences !

• Garder les anciens correctifs à jour

  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 correctifs.

• Écrire de la 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.

• Signer l’accord de licence de contribution

  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.

• Choisissez un thème qui vous tient à cœur, qui vous est familier ou sur lequel vous souhaitez en apprendre davantage

  Vous n’avez pas besoin d’être déjà un expert du domaine sur lequel vous souhaitez travailler ; on le devient progressivement au fil des contributions de code.

• Analysez le contexte et l’historique des tickets

  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.

• Commencez petit

  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).

• Si vous êtes sur le point de vous engager dans une grande tâche, assurez-vous d’abord que votre idée a du soutien

  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.

• Soyez courageux ! Écrivez votre expérience !

  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 !

• Privilégiez la prudence avant de marquer un ticket comme « Ready For Check-in »

  Si vous n’êtes pas vraiment certain-e qu’un ticket est prêt, ne le marquez pas comme tel. Écrivez plutôt un commentaire pour faire connaître votre opinion aux autres. Si vous êtes presque sûr-e, mais pas complètement, vous pouvez aussi poser la question sur IRC pour vérifier si quelqu’un d’autre peut confirmer votre idée.

• Attendez les retours et répondez à ceux que vous recevez

  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.

• Soyez rigoureux

  Lorsque nous parlons de « PEP 8, et des tests et de la documentation doivent être présents », nous sommes vraiment sérieux. Si un correctif n’a pas de test ou de documentation, il vaudrait mieux qu’il y ait une bonne raison. Les arguments comme « je n’ai pas trouvé de test existant pour cette fonctionnalité » ne font pas le poids ; même si c’est vrai, cela signifie que vous recevez la tâche super importante d’écrire les premiers tests pour cette fonctionnalité, et non pas que vous recevez une autorisation de ne pas écrire de test du tout.

• Soyez 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.

  Remember that Django has an eight-month release cycle, so there’s plenty of time for your patch to be reviewed.

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