{"title":"Triaging tickets","version":"5.2","locale":"pl","docname":"internals/contributing/triaging-tickets","url":"/pl/5.2/internals/contributing/triaging-tickets/","canonical":"https://djangodocs.dev/pl/5.2/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 Django has decided to add.…","html":"

Triaging ticketsLink to this heading#

\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 Django\nhas decided to add. As in any garden, sometimes there are weeds to be pulled\nand sometimes there are flowers and vegetables that need picking. We need your\nhelp to sort out one from the other, and in the end, we all benefit together.

\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 of\nDjango’s progress, we acknowledge that this will not happen. By distributing\nthe load of Trac maintenance to the community, we accept that there will be\nmistakes. Trac is „mostly accurate”, and we give allowances for the fact that\nsometimes it will be wrong. That’s okay. We’re perfectionists with deadlines.

\n

We rely on the community to keep participating, keep tickets as accurate as\npossible, and raise issues for discussion on the Django Forum 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 workflowLink to this heading#

\n

Unfortunately, not all reports in the ticket tracker provide all the\nrequired details. A number of tickets have proposed\nsolutions, but those don’t necessarily meet all the requirements adhering\nto the guidelines for contributing.

\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

By way of example, here we see the lifecycle of an average ticket:

\n\n

Some tickets require much less feedback than this, but then again some tickets\nrequire much much more.

\n
\n
\n

Triage stagesLink to this heading#

\n

Below we describe in more detail the various stages that a ticket may flow\nthrough during its lifetime.

\n
\n

UnreviewedLink to this heading#

\n

The ticket has not been reviewed by anyone who felt qualified to make a\njudgment about whether the ticket contained a valid issue or ought to be closed\nfor any of the various reasons.

\n
\n
\n

AcceptedLink to this heading#

\n

The big gray area! The absolute meaning of „accepted” is that the issue\ndescribed in the ticket is valid and is in some stage of being worked on.\nBeyond that there are several considerations:

\n\n
\n
\n

Ready For CheckinLink to this heading#

\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 contribution. A merger now needs to give\na final review prior to being committed.

\n

There are a lot of pull requests. It can take a while for your patch to get\nreviewed. See the contributing code FAQ for some\nideas here.

\n
\n
\n

Someday/MaybeLink to this heading#

\n

This stage isn’t shown on the diagram. It’s used sparingly to keep track of\nlong-term changes.

\n

These tickets are uncommon and overall less useful since they don’t describe\nconcrete actionable issues.

\n
\n
\n
\n

Other triage attributesLink to this heading#

\n

A number of flags, appearing as checkboxes in Trac, can be set on a ticket:

\n
\n

Has patchLink to this heading#

\n

This means the ticket has an associated solution. These will be reviewed to\nensure they adhere to the documented guidelines.

\n

The following three fields (Needs documentation, Needs tests,\nPatch needs improvement) apply only if a patch has been supplied.

\n
\n
\n

Needs documentationLink to this heading#

\n

This flag is used for tickets with patches that need associated\ndocumentation. Complete documentation of features is a prerequisite\nbefore we can check them into the codebase.

\n
\n
\n

Needs testsLink to this heading#

\n

This flags the patch as needing associated unit tests. Again, this\nis a required part of a valid contribution.

\n
\n
\n

Patch needs improvementLink to this heading#

\n

This flag means that although the ticket has a solution, it’s not quite\nready for checkin. This could mean the patch no longer applies\ncleanly, there is a flaw in the implementation, or that the code\ndoesn’t meet our standards.

\n
\n
\n

Easy pickingsLink to this heading#

\n

Tickets that would require small, easy, changes.

\n
\n
\n

TypLink to this heading#

\n

Tickets should be categorized by type between:

\n\n
\n
\n

ComponentLink to this heading#

\n

Tickets should be classified into components indicating which area of\nthe Django codebase they belong to. This makes tickets better organized and\neasier to find.

\n
\n
\n

SeverityLink to this heading#

\n

The severity attribute is used to identify blockers, that is, issues that\nshould get fixed before releasing the next version of Django. Typically those\nissues are bugs causing regressions from earlier versions or potentially\ncausing severe data losses. This attribute is quite rarely used and the vast\nmajority of tickets have a severity of „Normal”.

\n
\n
\n

VersionLink to this heading#

\n

It is possible to use the version attribute to indicate in which\nversion the reported bug was identified.

\n
\n
\n

UI/UXLink to this heading#

\n

This flag is used for tickets that relate to User Interface and User\nExperiences questions. For example, this flag would be appropriate for\nuser-facing features in forms or the admin interface.

\n
\n
\n

CcLink to this heading#

\n

You may add your username or email address to this field to be notified when\nnew contributions are made to the ticket.

\n
\n
\n

KeywordsLink to this heading#

\n

With this field you may label a ticket with multiple keywords. This can be\nuseful, for example, to group several tickets on the same theme. Keywords can\neither be comma or space separated. Keyword search finds the keyword string\nanywhere in the keywords. For example, clicking on a ticket with the keyword\n„form” will yield similar tickets tagged with keywords containing strings such\nas „formset”, „modelformset”, and „ManagementForm”.

\n
\n
\n
\n

Closing TicketsLink to this heading#

\n

When a ticket has completed its useful lifecycle, it’s time for it to be\nclosed. Closing a ticket is a big responsibility, though. You have to be sure\nthat the issue is really resolved, and you need to keep in mind that the\nreporter of the ticket may not be happy to have their ticket closed (unless\nit’s fixed!). If you’re not certain about closing a ticket, leave a comment\nwith your thoughts instead.

\n

If you do close a ticket, you should always make sure of the following:

\n\n

A ticket can be resolved in a number of ways:

\n\n

If you believe that the ticket was closed in error – because you’re\nstill having the issue, or it’s popped up somewhere else, or the triagers have\nmade a mistake – please reopen the ticket and provide further information.\nAgain, please do not reopen tickets that have been marked as „wontfix” and\nbring the issue to the Django Forum instead.

\n
\n
\n

How can I help with triaging?Link to this heading#

\n

The triage process is primarily driven by community members. Really,\nANYONE can help.

\n

To get involved, start by creating an account on Trac. If you have an\naccount but have forgotten your password, you can reset it using the password\nreset page.

\n

Then, you can help out by:

\n\n\n

However, we do ask the following of all general community members working in\nthe ticket database:

\n\n
\n
\n

Bisecting a regressionLink to this heading#

\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 main branch, put it\nin a separate file that you can run standalone. For our example, we’ll pretend\nwe created 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 check out 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 check out 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":"Triage stages","anchor":"triage-stages","children":[{"title":"Unreviewed","anchor":"unreviewed","children":[]},{"title":"Accepted","anchor":"accepted","children":[]},{"title":"Ready For Checkin","anchor":"ready-for-checkin","children":[]},{"title":"Someday/Maybe","anchor":"someday-maybe","children":[]}]},{"title":"Other triage attributes","anchor":"other-triage-attributes","children":[{"title":"Has patch","anchor":"has-patch","children":[]},{"title":"Needs documentation","anchor":"needs-documentation","children":[]},{"title":"Needs tests","anchor":"needs-tests","children":[]},{"title":"Patch needs improvement","anchor":"patch-needs-improvement","children":[]},{"title":"Easy pickings","anchor":"easy-pickings","children":[]},{"title":"Typ","anchor":"type","children":[]},{"title":"Component","anchor":"component","children":[]},{"title":"Severity","anchor":"severity","children":[]},{"title":"Version","anchor":"version","children":[]},{"title":"UI/UX","anchor":"ui-ux","children":[]},{"title":"Cc","anchor":"cc","children":[]},{"title":"Keywords","anchor":"keywords","children":[]}]},{"title":"Closing Tickets","anchor":"closing-tickets","children":[]},{"title":"How can I help with triaging?","anchor":"how-can-i-help-with-triaging","children":[]},{"title":"Bisecting a regression","anchor":"bisecting-a-regression","children":[]}],"breadcrumbs":[{"docname":"internals/index","title":"Dokumentacja wewnętrzna Django","url":"/pl/5.2/internals/"},{"docname":"internals/contributing/index","title":"Wkład w rozwój Django","url":"/pl/5.2/internals/contributing/"}],"prev":{"docname":"internals/contributing/bugs-and-features","title":"Zgłaszanie błędów i próśb o funkcjonalności","url":"/pl/5.2/internals/contributing/bugs-and-features/"},"next":{"docname":"internals/mailing-lists","title":"Mailing lists and Forum","url":"/pl/5.2/internals/mailing-lists/"},"formats":{"html":"/pl/5.2/internals/contributing/triaging-tickets/","markdown":"/pl/5.2/internals/contributing/triaging-tickets.md","json":"/pl/5.2/internals/contributing/triaging-tickets.json"},"source":"https://github.com/django/django/blob/stable/5.2.x/docs/internals/contributing/triaging-tickets.txt","official":"https://docs.djangoproject.com/pl/5.2/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"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}