Signalement d’anomalies ou demandes de fonctionnalités

Important

Veuillez signaler les problèmes de sécurité uniquement à l’adresse [e-mail]. C’est une liste privée uniquement ouverte à des développeurs Django de longue date et extrêmement fiables, et ses archives ne sont pas publiques. Pour plus de détails, veuillez consulter nos politiques de sécurité.

Signalement d’anomalies

Before reporting a bug on the ticket tracker consider these points:

• Check that someone hasn’t already filed the bug report by searching or running custom queries in the ticket tracker.

• N’utilisez pas le système des tickets pour poser des questions d’aide. Utilisez le forum Django ou le serveur Discord de Django à cet effet.

• Ne réouvrez pas des rapports qui ont été marqués comme wontfix sans d’abord chercher un consensus sur le forum Django.

• N’utilisez pas le système des tickets pour de longues discussions, car elles risquent de se perdre. Si un ticket particulier est sujet à controverse, veuillez faire passer la discussion sur le forum Django.

Des rapports d’anomalies bien écrits sont extrêmement utiles. Cependant, il y a toujours un certain travail à effectuer dans un système de gestion des anomalies, votre aide pour conserver notre système utilisable est donc appréciée. En particulier :

• Lisez la FAQ pour voir si votre problème n’est pas une question régulièrement posée.

• Demandez d’abord sur le forum Django ou le serveur Discord de Django si vous n’êtes pas sûr·e que ce que vous voyez est réellement une anomalie.

• Écrivez des rapports d’anomalies complets, reproductibles et précis. Vous devez inclure une description claire et concise du problème ainsi qu’une série d’instructions pour le reproduire. Ajoutez autant d’informations de débogage que possible : extraits de code, cas de test, traces d’exceptions, captures d’écran, etc. Un petit cas de test bien fait est la meilleure manière de signaler une anomalie, car cela permet de confirmer rapidement la validité du problème rencontré.

• N’écrivez pas sur le forum Django seulement pour annoncer que vous avez rédigé un rapport d’anomalie. Tous les tickets apparaissent dans une autre liste, django-updates, qui est suivie par les développeurs et les membres intéressés de la communauté ; nous les voyons au fur et à mesure de leur création.

Pour comprendre le cycle de vie d’un ticket après sa création, consultez Tri des tickets.

Reporting user interface bugs

If your bug impacts anything visual in nature, there are a few additional guidelines to follow:

• Incluez des captures d’écran dans le ticket, ce qui correspond à l’équivalent visuel d’un cas de test minimal. Mettez en évidence le problème, pas les personnalisations incroyables que vous avez appliquées à votre navigateur.

• Si le problème est difficile à démontrer par une image figée, envisagez de capturer une brève séquence vidéo. Si votre logiciel le permet, ne capturez que la partie significative de l’écran.

• Si vous proposez un correctif qui modifie l’apparence ou le comportement de l’interface de Django, vous devez joindre les captures avant et après. Les tickets qui ne possèdent pas ces éléments sont difficiles à traiter rapidement par ceux qui classent les tickets.

• Les captures d’écran ne dispensent pas des autres bonnes pratiques de signalement. Prenez soin d’inclure des URL, des extraits de code et des instructions pas à pas sur la façon de reproduire les comportements visibles dans les captures d’écran.

• Prenez soin de cocher l’option UI/UX du ticket afin que les personnes les plus concernées puissent trouver votre ticket.

Demandes de fonctionnalités

Nous essayons de constamment améliorer Django, et vos demandes de fonctionnalités constituent un élément clé de ce processus. Voici quelques astuces pour rédiger une demande de la manière la plus efficace possible :

• Evaluate whether the feature idea requires changes in Django’s core. If your idea can be developed as an independent application or module — for instance, you want to support another database engine — we’ll probably suggest that you develop it independently. Then, if your project gathers sufficient community support, we may consider it for inclusion in Django.

• Propose the feature in the new feature ideas GitHub project (not in the ticket tracker) by creating a new item in the Idea column. This is where the community and the Steering Council evaluate new ideas for the Django ecosystem. This step is especially important for large or complex proposals. We prefer to discuss any significant changes to Django’s core before any development begins. In some cases, a feature may be better suited as a third-party package, where it can evolve independently of Django’s release cycle.

• Décrivez clairement et courtement la fonctionnalité manquante et la manière dont vous souhaiteriez qu’elle soit implémentée. Ajoutez si possible du code d’exemple (même non fonctionnel).

• Expliquez pourquoi vous souhaitez cette fonctionnalité. En présentant un cas d’utilisation minimal, cela aidera d’autres à comprendre le contexte de la demande et s’il existe déjà d’autres manières d’arriver au même résultat.

Voir aussi Documentation de nouvelles fonctionnalités.

Demande d’optimisations de performance

Les rapports de régression de performance ou les suggestions d’optimisations de performance doivent fournir des analyses (« benchmarks ») et des commande permettant au trieur de tickets de les reproduire.

Voir Tests de performance django-asv pour plus de détails sur les benchmarks Django existants.

Comment nous prenons des décisions

Whenever possible, we aim for rough consensus. Emoji reactions are used on issues within the new feature ideas GitHub project to track community feedback. The following meanings are assigned to each reaction:

• 👍: I support this feature and would use it

• 👎: I oppose this feature or believe it would cause issues for me or Django

• 😕: I have no strong opinion on this feature

• 🎉: This feature seems like a straightforward and beneficial addition

The Steering Council will regularly review the ideas in the project, moving those with community support through the following stages:

• Idea

• Approved - Idea refinement - Team creation

• In progress

• Working solution - Review - Feedback

• Needs maintainer (Django only)

• Done

Occasionally, discussions on feature ideas or the direction of Django may take place on the Django Forum. These discussions may include informal votes, which follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

• +1 : « J’aime bien l’idée et je l’appuie sans réserve ».

• +0 : « Ça me semble OK ».

• -0 : « Je ne suis pas convaincu, mais je n’ai pas l’intention de m’y opposer ».

• -1 : « Je désapprouve fortement et je serai contrarié de voir l’idée se concrétiser ».

Bien que ces votes soient informels, ils sont pris très au sérieux. Après une période de vote raisonnable et si un consensus clair se dessine, nous suivons les votes.