Triage workflow¶

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

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

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

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

We’ve got two roles in this diagram:

• Mergers: people with commit access who are responsible for making the final decision to merge a patch.
• Ticket triagers: anyone in the Django community who chooses to become involved in Django’s development process. Our Trac installation is intentionally left open to the public, and anyone can triage tickets. Django is a community project, and we encourage triage by the community.

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

• Alice creates a ticket and sends an incomplete pull request (no tests, incorrect implementation).
• Bob reviews the pull request, marks the ticket as «Accepted», «needs tests», and «patch needs improvement», and leaves a comment telling Alice how the patch could be improved.
• Alice updates the pull request, adding tests (but not changing the implementation). She removes the two flags.
• Charlie reviews the pull request and resets the «patch needs improvement» flag with another comment about improving the implementation.
• Alice updates the pull request, fixing the implementation. She removes the «patch needs improvement» flag.
• Daisy reviews the pull request and marks the ticket as «Ready for checkin».
• Jacob, a merger, reviews the pull request and merges it.

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

Triage stages¶

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

Other triage attributes¶

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

Closing Tickets¶

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

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

• Be certain that the issue is resolved.
• Leave a comment explaining the decision to close the ticket.
• If there is a way they can improve the ticket to reopen it, let them know.
• If the ticket is a duplicate, reference the original ticket. Also cross-reference the closed ticket by leaving a comment in the original one – this allows to access more related information about the reported bug or requested feature.
• Be polite. No one likes having their ticket closed. It can be frustrating or even discouraging. The best way to avoid turning people off from contributing to Django is to be polite and friendly and to offer suggestions for how they could improve this ticket and other tickets in the future.

A ticket can be resolved in a number of ways:

• fixed

  Used once a patch has been rolled into Django and the issue is fixed.

• invalid

  Used if the ticket is found to be incorrect. This means that the issue in the ticket is actually the result of a user error, or describes a problem with something other than Django, or isn’t a bug report or feature request at all (for example, some new users submit support queries as tickets).

• wontfix

  Used when someone decides that the request isn’t appropriate for consideration in Django. Sometimes a ticket is closed as «wontfix» with a request for the reporter to start a discussion on the Django Forum or django-developers mailing list if they feel differently from the rationale provided by the person who closed the ticket. Other times, a discussion precedes the decision to close a ticket. Always use the forum or mailing list to get a consensus before reopening tickets closed as «wontfix».

• duplicate

  Used when another ticket covers the same issue. By closing duplicate tickets, we keep all the discussion in one place, which helps everyone.

• worksforme

  Used when the ticket doesn’t contain enough detail to replicate the original bug.

• needsinfo

  Used when the ticket does not contain enough information to replicate the reported issue but is potentially still valid. The ticket should be reopened when more information is supplied.

If you believe that the ticket was closed in error – because you’re still having the issue, or it’s popped up somewhere else, or the triagers have made a mistake – please reopen the ticket and provide further information. Again, please do not reopen tickets that have been marked as «wontfix» and bring the issue to the Django Forum or django-developers instead.

How can I help with triaging?¶

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

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

Then, you can help out by:

• Closing «Unreviewed» tickets as «invalid», «worksforme», or «duplicate», or «wontfix».
• Closing «Unreviewed» tickets as «needsinfo» when the description is too sparse to be actionable, or when they’re feature requests requiring a discussion on the Django Forum or django-developers.
• Correcting the «Needs tests», «Needs documentation», or «Has patch» flags for tickets where they are incorrectly set.
• Setting the «Easy pickings» flag for tickets that are small and relatively straightforward.
• Set the type of tickets that are still uncategorized.
• Checking that old tickets are still valid. If a ticket hasn’t seen any activity in a long time, it’s possible that the problem has been fixed but the ticket hasn’t yet been closed.
• Identifying trends and themes in the tickets. If there are a lot of bug reports about a particular part of Django, it may indicate we should consider refactoring that part of the code. If a trend is emerging, you should raise it for discussion (referencing the relevant tickets) on the Django Forum or django-developers.
• Verify if patches submitted by other users are correct. If they are correct and also contain appropriate documentation and tests then move them to the «Ready for Checkin» stage. If they are not correct then leave a comment to explain why and set the corresponding flags («Patch needs improvement», «Needs tests» etc.).

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

• Please don’t promote your own tickets to «Ready for checkin». You may mark other people’s tickets that you’ve reviewed as «Ready for checkin», but you should get at minimum one other community member to review a patch that you submit.
• Please don’t reverse a decision without posting a message to the Django Forum or django-developers to find consensus.
• If you’re unsure if you should be making a change, don’t make the change but instead leave a comment with your concerns on the ticket, or post a message to the Django Forum or django-developers. It’s okay to be unsure, but your input is still valuable.

Bisecting a regression¶

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

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

$ ./runtests.py migrations.test_regression

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

$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y

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

$ git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)
...

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

$ git bisect run tests/runtests.py migrations.test_regression

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

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