Avant de signaler une anomalie dans le suivi des tickets, tenez compte des point suivants :
\nVérifiez que quelqu’un n’a pas déjà signalé le problème en cherchant ou en exécutant des requêtes personnalisées dans notre système de tickets.
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.
Don’t reopen issues that have been marked « needsnewfeatureprocess » without\nshepherding an issue through the new feature ideas GitHub project.
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 :
\nLisez 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 Procédures de tri des tickets.
\nSi le problème se rapporte à un élément visuel, voici quelques consignes supplémentaires à suivre :
\nIncluez 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.
Si le problème est lié à l’accessibilité, veuillez le lier au standard d’accessibilité approprié, le cas échéant.
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 :
\nÉvaluez si l’idée de fonctionnalité demande effectivement des modifications dans le cœur de Django. SI votre idée peut être développée en tant qu’application ou module indépendant, par exemple pour ajouter la prise en charge d’un nouveau moteur de base de données, on vous suggérera certainement de la développer de manière indépendante. Puis, si le projet obtient suffisamment de soutien de la communauté, il pourra être considéré comme candidat à l’inclusion dans Django.
Proposez la fonctionnalité dans le projet GitHub new feature ideas (pas dans le ticket tracker) en créant un nouvel élément dans la colonne Idea. C’est ici que la communauté et le :ref:`Conseil de Pilotage ` évaluent les nouvelles idées pour l’écosystème Django. Cette étape est particulièrement nécessaire pour des propositions importantes ou complexes. Nous préférons discuter de tout changement significatif au cœur de Django avant que le développement ne commence. Dans certains cas, une fonctionnalité peut être mieux adaptée en tant que paquetage tiers, où elle peut évoluer indépendamment du cycle de publication de Django.
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.
\nLes 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.
\nVoir Tests de performance django-asv pour plus de détails sur les benchmarks Django existants.
\nDans la mesure du possible, nous visons à obtenir un consensus. Les réactions des emoji sont utilisées sur les problèmes du projet GitHub Ideas new feature ideas pour suivre les commentaires de la communauté. Les significations suivantes sont attribuées à chaque réaction :
\n👍 : Je soutiens cette fonctionnalité et je l’utiliserais.
👎 : Je m’oppose à cette fonctionnalité ou je pense qu’elle causerait des problèmes pour moi ou pour Django.
😕 : Je n’ai pas d’avis tranché sur cette fonctionnalité.
🎉 : Cette fonctionnalité parait être un ajout simple et bénéfique.
Le Conseil de pilotage examinera régulièrement les idées contenues dans le projet, en faisant passer celles qui bénéficient du soutien de la communauté par les étapes suivantes :
\nIdée
Approuvé - Affinement de l’idée - Création d’une équipe
En cours
Solution de travail - Révision - Retour d’information
Besoin d’un mainteneur (Django uniquement)
Fait
Occasionnellement, des discussions sur des idées de fonctionnalités ou sur la direction de Django peuvent avoir lieu sur le forum Django. Ces discussions peuvent inclure des votes informels, qui suivent le style de vote inventé par Apache et utilisé sur Python lui-même, où les votes sont donnés comme +1, +0, -0, ou -1. En gros, ces votes signifient :
\n+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.
\nTesting pre-releases is a great way to contribute to Django. Early testers\nhelp catch bugs before the final release, ensuring a smoother upgrade\nexperience for everyone.
\nBefore testing a pre-release, it is important that your project is running\nsmoothly on the latest stable release of Django. That way, any regressions can\nbe attributed to the pre-release. See the Mise à jour de Django à une version plus récente guide\nfor instructions on getting up to date.
\nTo ensure your project is ready, you should also:
\nRead the release notes: Review the Notes de publication for the\nupcoming version to learn about upgrade paths for deprecated features or\nabout minor backward-incompatible changes.
Resolve deprecation warnings: Run your tests with deprecation warnings\nenabled to become aware of required follow-up actions:
\n$ python -Wa manage.py test\nYou can install the latest pre-release using pip:
$ python -m pip install --pre Django\nOnce installed, run your project’s test suite. Rather than just checking\nif tests pass, try the following:
\nCheck dependency support: Determine whether major dependencies support\nthe new version by checking Django version classifiers on PyPI.\nSince those projects also value early bug reports, don’t let a lack\nof support prevent you from testing.
Monitor performance: You can run your tests with the test\n--durations flag to identify potential performance regressions.
Automate tests in CI: Consider running your Continuous Integration (CI)\npipeline with the pre-release version.
Test manually: While automated tests are great, manually testing your\napplication’s main workflows is an important part of verifying compatibility\nwith a new release.
If you discover a bug, please report it via the Django issue tracker so it can be fixed before the final\nrelease. When creating the ticket, be sure to set the Django version field to\nthe exact pre-release version you are testing.
\nIf you suspect a regression, it’s helpful to report the specific commit that\ncaused it. See Recherche d’origine d’une régression avec bisect for instructions.
\nYou can also discuss any issues or share feedback in the Pre-releases category\non the Django Forum.
\n