{"title":"Tri des tickets","version":"2.1","locale":"fr","docname":"internals/contributing/triaging-tickets","url":"/fr/2.1/internals/contributing/triaging-tickets/","canonical":"https://djangodocs.dev/fr/2.1/internals/contributing/triaging-tickets/","summary":"Django uses Trac for managing the work on the code base. Trac is a community-tended garden of the bugs people have found and the features people would like to see…","html":"

Tri des ticketsLien vers cette rubrique#

\n

Django uses Trac for managing the work on the code base. Trac is a\ncommunity-tended garden of the bugs people have found and the features people\nwould like to see added. As in any garden, sometimes there are weeds to be\npulled and sometimes there are flowers and vegetables that need picking. We need\nyour help to sort out one from the other, and in the end we all benefit\ntogether.

\n

Like all gardens, we can aspire to perfection but in reality there’s no such\nthing. Even in the most pristine garden there are still snails and insects.\nIn a community garden there are also helpful people who – with the best of\nintentions – fertilize the weeds and poison the roses. It’s the job of the\ncommunity as a whole to self-manage, keep the problems to a minimum, and\neducate those coming into the community so that they can become valuable\ncontributing members.

\n

Similarly, while we aim for Trac to be a perfect representation of the state\nof Django’s progress, we acknowledge that this simply will not happen. By\ndistributing the load of Trac maintenance to the community, we accept that\nthere will be mistakes. Trac is « mostly accurate », and we give allowances for\nthe fact that sometimes it will be wrong. That’s okay. We’re perfectionists\nwith deadlines.

\n

We rely on the community to keep participating, keep tickets as accurate as\npossible, and raise issues for discussion on our mailing lists when there is\nconfusion or disagreement.

\n

Django is a community project, and every contribution helps. We can’t do this\nwithout you!

\n
\n

Triage workflowLien vers cette rubrique#

\n

Unfortunately, not all bug reports and feature requests in the ticket tracker\nprovide all the required details. A number of\ntickets have patches, but those patches don’t meet all the requirements of a\ngood patch.

\n

One way to help out is to triage tickets that have been created by other\nusers.

\n

Most of the workflow is based around the concept of a ticket’s\ntriage stages. Each stage describes where in its\nlifetime a given ticket is at any time. Along with a handful of flags, this\nattribute easily tells us what and who each ticket is waiting on.

\n

Since a picture is worth a thousand words, let’s start there:

\n\"Django's\n\n

We’ve got two roles in this diagram:

\n\n

En guise d’exemple, voici le cycle de vie d’un ticket moyen :

\n\n

Certains tickets n’ont pas besoin d’autant d’interventions, mais il y a aussi des tickets qui en nécessitent beaucoup plus.

\n
\n
\n

Étapes de triLien vers cette rubrique#

\n

Nous décrivons ci-dessous plus en détails les diverses étapes par lesquelles un ticket passe durant son parcours de vie.

\n
\n

Non traité (Unreviewed)Lien vers cette rubrique#

\n

Le ticket n’a pas été relu par quelqu’un qui se sentait qualifié pour juger si ce ticket contient un problème réel, une fonctionnalité raisonnable ou s’il devrait plutôt être fermé pour une ou différentes raisons.

\n
\n
\n

Accepté (Accepted)Lien vers cette rubrique#

\n

La grande zone grise ! La signification absolue de « accepté » est que le problème décrit dans le ticket est valide et se trouve dans un état où on peut travailler sur sa résolution. Au-delà de cela, d’autres aspects sont à prendre en considération :

\n\n
\n
\n

Prêt pour le commit (Ready For Checkin)Lien vers cette rubrique#

\n

The ticket was reviewed by any member of the community other than the person\nwho supplied the patch and found to meet all the requirements for a\ncommit-ready patch. A committer now needs to give the patch a final\nreview prior to being committed. See the\nNew contributors” FAQ for « My ticket has been in\nRFC forever! What should I do? »

\n
\n
\n

Un jour peut-être (Someday/Maybe)Lien vers cette rubrique#

\n

Cette étape n’apparaît pas dans le diagramme. Elle est utilisée avec modération pour garder la trace d’idées plus générales ou de demandes de fonctionnalités à plus long terme.

\n

These tickets are uncommon and overall less useful since they don’t describe\nconcrete actionable issues. They are enhancement requests that we might\nconsider adding someday to the framework if an excellent patch is submitted.\nThey are not a high priority.

\n
\n
\n
\n

Autres attributs de triLien vers cette rubrique#

\n

Un certain nombre de drapeaux, apparaissant sous forme de cases à cocher dans Trac, peuvent être définis pour un ticket :

\n
\n

Has patch (possède un correctif)Lien vers cette rubrique#

\n

Cela signifie que le ticket possède un correctif associé. Ceux-ci sont analysés pour estimer si le correctif est « bon ».

\n

Les trois champs suivants (Needs documentation, Needs tests, Patch needs improvement) ne s’appliquent que lorsqu’un correctif est disponible.

\n
\n
\n

Needs documentation (a besoin de documentation)Lien vers cette rubrique#

\n

Ce drapeau est utilisé pour les tickets ayant un correctif, mais pas encore de documentation. La documentation complète des fonctionnalités est un prérequis avant de pouvoir faire entrer du code dans Django.

\n
\n
\n

Needs tests (a besoin de tests)Lien vers cette rubrique#

\n

Ce drapeau indique que le correctif a besoin de tests unitaires associés. Encore une fois, il s’agit d’un élément obligatoire pour un correctif valable.

\n
\n
\n

Patch needs improvement (le correctif a besoin d’améliorations)Lien vers cette rubrique#

\n

Ce drapeau signifie que même si le ticket possède un correctif, il n’est pas encore prêt à être commité. Cela peut signifier que le correctif n’est plus applicable, que son implémentation est défaillante ou que le code ne correspond pas aux standards exigés.

\n
\n
\n

Easy pickings (simple à corriger)Lien vers cette rubrique#

\n

Désigne les tickets qui nécessitent de petits correctifs assez simples.

\n
\n
\n

TypeLien vers cette rubrique#

\n

Les billets doivent être classés par type parmi :

\n\n
\n
\n

Component (composant)Lien vers cette rubrique#

\n

Les tickets doivent être classés en composants indiquant quelle partie du code de Django ils concernent. Cela aide à organiser les tickets et à les rendre plus facilement retrouvables.

\n
\n
\n

Severity (sévérité)Lien vers cette rubrique#

\n

L’attribut severity est utilisé pour identifier les tickets bloquants, c’est-à-dire des problèmes devant être absolument résolus avant de publier la prochaine version de Django. Typiquement, il s’agit de bogues provoquant des régressions en comparaison d’anciennes versions ou qui sont potentiellement la cause de pertes de données importantes. Cet attribut est assez rarement utilisé et la grande majorité des tickets possèdent un niveau de sévérité « normal ».

\n
\n
\n

VersionLien vers cette rubrique#

\n

Il est possible d’utiliser l’attribut version pour indiquer la version dans laquelle le bogue signalé a été identifié.

\n
\n
\n

UI/UXLien vers cette rubrique#

\n

Ce drapeau est utilisé pour les tickets qui sont liés aux questions d’interface utilisateur et d’expérience d’utilisation. Par exemple, ce drapeau serait approprié pour des fonctionnalités de présentation à l’utilisateur dans les formulaires ou l’interface d’administration.

\n
\n
\n

CcLien vers cette rubrique#

\n

Il est possible d’ajouter son nom d’utilisateur ou son adresse électronique dans ce champ pour être averti lorsque de nouvelles contributions sont apportées au ticket concerné.

\n
\n
\n

Keywords (mots-clés)Lien vers cette rubrique#

\n

Avec ce champ, il est possible d’étiqueter un ticket par plusieurs mots-clés. Cela peut par exemple être utile pour grouper plusieurs tickets autour d’un même thème. Les mots-clés peuvent être séparés par des virgules ou des espaces. Les recherches par mot-clé cherchent un mot-clé dans toute l’expression. Par exemple, si on clique sur le mot-clé « form » d’un ticket, les résultats contiendront tous les tickets étiquetés avec des mots tels que « formset », « modelformset » ou « ManagementForm ».

\n
\n
\n
\n

Fermeture de ticketsLien vers cette rubrique#

\n

Lorsqu’un ticket a terminé son cycle de vie utile, il est temps de le fermer. Cependant, la fermeture d’un ticket est une grande responsabilité. Il faut être certain que le problème est réellement réglé, et il faut garder à l’esprit que celui qui a ouvert le ticket pourrait ne pas être heureux de voir son ticket fermé (sauf si une correction a été appliquée, bien sûr). Si vous n’êtes pas sûr qu’un ticket doit être fermé, laissez simplement un commentaire avec votre raisonnement.

\n

Si vous fermez réellement un ticket, vous devez toujours vous assurer des éléments suivants :

\n\n

Un ticket peut être résolu de plusieurs façons :

\n\n

Si vous pensez que le ticket a été fermé par erreur, soit que le problème demeure, soit qu’il est réapparu ailleurs ou encore que les trieurs se sont trompés, vous pouvez réouvrir le ticket en fournissant des informations complémentaires. Encore une fois, évitez de réouvrir des tickets qui ont été fermés comme « wontfix », mais dans ce cas, préférez la discussion du problème sur la liste django-developers.

\n
\n
\n

Commet puis-je aider à trier les tickets ?Lien vers cette rubrique#

\n

Le processus de tri est principalement mené par des membres de la communauté. Vraiment, TOUT LE MONDE peut aider.

\n

Pour vous impliquer, commencez par créer un compte sur Trac. Si vous disposez d’un compte mais que vous avez oublié le mot de passe, vous pouvez le réinitialiser en utilisant la page de réinitialisation de mot de passe.

\n

Puis, vous pouvez aider en :

\n\n\n

Cependant, nous demandons à tous les membres de la communauté de respecter les principes suivants en travaillant sur la base de données des tickets :

\n\n
\n
\n

Bisecting a regressionLien vers cette rubrique#

\n

A regression is a bug that’s present in some newer version of Django but not in\nan older one. An extremely helpful piece of information is the commit that\nintroduced the regression. Knowing the commit that caused the change in\nbehavior helps identify if the change was intentional or if it was an\ninadvertent side-effect. Here’s how you can determine this.

\n

Begin by writing a regression test for Django’s test suite for the issue. For\nexample, we’ll pretend we’re debugging a regression in migrations. After you’ve\nwritten the test and confirmed that it fails on the latest master, put it in a\nseparate file that you can run standalone. For our example, we’ll pretend we\ncreated tests/migrations/test_regression.py, which can be run with:

\n
Shell
$ ./runtests.py migrations.test_regression\n
\n

Next, we mark the current point in history as being « bad » since the test fails:

\n
Shell
$ git bisect bad\nYou need to start by "git bisect start"\nDo you want me to do it for you [Y/n]? y\n
\n

Now, we need to find a point in git history before the regression was\nintroduced (i.e. a point where the test passes). Use something like\ngit checkout HEAD~100 to checkout an earlier revision (100 commits earlier,\nin this case). Check if the test fails. If so, mark that point as « bad »\n(git bisect bad), then checkout an earlier revision and recheck. Once you\nfind a revision where your test passes, mark it as « good »:

\n
Shell
$ git bisect good\nBisecting: X revisions left to test after this (roughly Y steps)\n...\n
\n

Now we’re ready for the fun part: using git bisect run to automate the rest\nof the process:

\n
Shell
$ git bisect run tests/runtests.py migrations.test_regression\n
\n

You should see git bisect use a binary search to automatically checkout\nrevisions between the good and bad commits until it finds the first « bad »\ncommit where the test fails.

\n

Now, report your results on the Trac ticket, and please include the regression\ntest as an attachment. When someone writes a fix for the bug, they’ll already\nhave your test as a starting point.

\n
","rootId":"triaging-tickets","toc":[{"title":"Triage workflow","anchor":"triage-workflow","children":[]},{"title":"Étapes de tri","anchor":"triage-stages","children":[{"title":"Non traité (Unreviewed)","anchor":"unreviewed","children":[]},{"title":"Accepté (Accepted)","anchor":"accepted","children":[]},{"title":"Prêt pour le commit (Ready For Checkin)","anchor":"ready-for-checkin","children":[]},{"title":"Un jour peut-être (Someday/Maybe)","anchor":"someday-maybe","children":[]}]},{"title":"Autres attributs de tri","anchor":"other-triage-attributes","children":[{"title":"Has patch (possède un correctif)","anchor":"has-patch","children":[]},{"title":"Needs documentation (a besoin de documentation)","anchor":"needs-documentation","children":[]},{"title":"Needs tests (a besoin de tests)","anchor":"needs-tests","children":[]},{"title":"Patch needs improvement (le correctif a besoin d’améliorations)","anchor":"patch-needs-improvement","children":[]},{"title":"Easy pickings (simple à corriger)","anchor":"easy-pickings","children":[]},{"title":"Type","anchor":"type","children":[]},{"title":"Component (composant)","anchor":"component","children":[]},{"title":"Severity (sévérité)","anchor":"severity","children":[]},{"title":"Version","anchor":"version","children":[]},{"title":"UI/UX","anchor":"ui-ux","children":[]},{"title":"Cc","anchor":"cc","children":[]},{"title":"Keywords (mots-clés)","anchor":"keywords","children":[]}]},{"title":"Fermeture de tickets","anchor":"closing-tickets","children":[]},{"title":"Commet puis-je aider à trier les tickets ?","anchor":"how-can-i-help-with-triaging","children":[]},{"title":"Bisecting a regression","anchor":"bisecting-a-regression","children":[]}],"breadcrumbs":[{"docname":"internals/index","title":"Fonctionnement interne du projet Django","url":"/fr/2.1/internals/"},{"docname":"internals/contributing/index","title":"Contribuer à Django","url":"/fr/2.1/internals/contributing/"}],"prev":{"docname":"internals/contributing/bugs-and-features","title":"Signalement d’anomalies ou demandes de fonctionnalités","url":"/fr/2.1/internals/contributing/bugs-and-features/"},"next":{"docname":"internals/contributing/writing-code/index","title":"Écriture du code","url":"/fr/2.1/internals/contributing/writing-code/"},"formats":{"html":"/fr/2.1/internals/contributing/triaging-tickets/","markdown":"/fr/2.1/internals/contributing/triaging-tickets.md","json":"/fr/2.1/internals/contributing/triaging-tickets.json"},"source":"https://github.com/django/django/blob/stable/2.1.x/docs/internals/contributing/triaging-tickets.txt","official":"https://docs.djangoproject.com/fr/2.1/internals/contributing/triaging-tickets/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","zh-hans","fr","ja","id","pt-br","ko","es","el","pl"]}