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.

Tri de 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 ?.

Relecture de correctifs de tickets acceptés

Ceci vous aidera à 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 !

Remise à jour d’anciens correctifs

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.

Écriture de 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.

Faites un choix de thème

Choisissez un domaine qui vous tient à cœur, avec lequel vous êtes familier ou au sujet duquel vous souhaitez en apprendre plus. Vous n’avez pas besoin d’être déjà un expert de ce domaine ; 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).

Attendez la confirmation que votre idée a du soutien avant de vous engager dans une grande tâche

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 !

Soyez prudent 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 le canal #contributing-getting-started du serveur Discord de Django 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.

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.