# Documentation Django 5.2.8

# 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

If an unreviewed ticket reports a bug, try and reproduce it. If you can reproduce it and it seems valid, make a note that you confirmed the bug and accept the ticket. Make sure the ticket is filed under the correct component area. Consider writing a patch that adds a test for the bug’s behavior, even if you don’t fix the bug itself. See more at How can I help with development?.

### 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

Oftentimes the codebase will change between a patch being submitted and the time it gets reviewed. Make sure it still applies cleanly and functions as expected. Updating a patch is both useful and important! See more on Liste de contrôle de contribution.

### Écriture de documentation

Django’s documentation is great but it can always be improved. Did you find a typo? Do you think that something should be clarified? Go ahead and suggest a documentation patch! See also the guide on É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.