Nouveau contributeur et vous ne savez pas que faire ? Vous souhaitez aider mais ne savez pas par où commencer ? Cette section est pour vous.
\n\nCette page contient des conseils plus généraux sur les manières de contribuer à Django, et comment entamer ces démarches.
\nSi vous cherchez une référence sur la façon de contribuer au code de Django, consultez la documentation Contribution au code.
\nCommencez par ces étapes pour découvrir le processus de développement de Django.
\nSi 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 au développement ?.
\nCeci 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 !
\nIl 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 Liste de contrôle de contribution.
\nLa 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.
\n\nThe code that you write belongs to you or your employer. If your contribution\nis more than one or two lines of code, you have the option to sign the CLA.\nSee the Contributor License Agreement FAQ for a more thorough explanation.
\nEn 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.
\nChoisissez 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.
\nTrac 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.
\nIl 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).
\nCela 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.
\nIl 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 !
\nReady For Check-inLien vers cette rubrique#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.
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.
\nLorsque 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.
\nIl 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.
\nLe 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.
\nRappelez-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.
\nEnfin, un rappel à un temps opportun peut aider. Consultez la FAQ de contribution au code pour des idées à ce sujet.
\n