Removed references to the DDN triage state.

   Short answer: No. It's always better to get another set of eyes on a

   ticket. If you're having trouble getting that second set of eyes, see

   question 1, above.

3. **My ticket has been in DDN forever! What should I do?**

   Design Decision Needed requires consensus about the right solution.  At the

   very least it needs consensus among the core developers, and ideally it has

   consensus from the community as well. The best way to accomplish this is to

   start a thread on the django-developers mailing list, and for very complex

   issues to start a wiki page summarizing the problem and the possible

   solutions.

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

.. image:: /internals/_images/triage_process.*

   :height: 564

   :width: 580

   :height: 501

   :width: 400

   :alt: Django's ticket triage workflow

We've got two roles in this diagram:

  and docs, running the test suite with the included patch, and leaving

  feedback on the ticket.

* **Accepted + Has Patch + (any other flag)**

* **Accepted + Has Patch + Needs ...**

  This means the ticket has been reviewed, and has been found to need further

  work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch

  needs improvement" will generally be accompanied by a comment on the ticket

  explaining what is needed to improve the code.

Design Decision Needed

~~~~~~~~~~~~~~~~~~~~~~

This stage is for issues which may be contentious, may be backwards

incompatible, or otherwise involve high-level design decisions. These issues

should be discussed either in the ticket comments or on `django-developers`_.

If a ticket has been marked as "DDN", decisions are generally eventually

made by the core committers, however that is not a requirement. See the

:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in

DDN forever! What should I do?"

This stage will often be used for feature requests. It can also be used for

issues that *might* be bugs, depending on opinion or interpretation. Obvious

bugs (such as crashes, incorrect query results, or non-compliance with a

standard) skip this stage and move straight to "Accepted".

Ready For Checkin

~~~~~~~~~~~~~~~~~

Someday/Maybe

~~~~~~~~~~~~~

Generally only used for vague/high-level features or design ideas. These

tickets are uncommon and overall less useful since they don't describe

This stage isn't shown on the diagram. It's only used by core developers to

keep track of high-level ideas or long term feature requests.

These tickets are uncommon and overall less useful since they don't describe

concrete actionable issues. They are enhancement requests that we might

consider adding someday to the framework if an excellent patch is submitted.

These tickets are not a high priority.

They are not a high priority.

Other triage attributes

-----------------------

How can I help with triaging?

-----------------------------

Although the core developers make the big decisions in the ticket triage

process, there's a lot that general community members can do to help the

triage process. Really, **ANYONE** can help.

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

**ANYONE** can help.

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`_.

Core developers may provide feedback on issues they're familiar with, or make

decisions on controversial ones, but they aren't responsible for triaging

tickets in general.

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."

* Promoting "Unreviewed" tickets to "Design decision needed" if a design

  decision needs to be made, or "Accepted" in case of obvious bugs or

  sensible, clearly defined, feature requests.

* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests

  requiring a discussion on `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.

* Contacting the owners of tickets that have been claimed but have not

  seen any recent activity. If the owner doesn't respond after a week

  or so, remove the owner's claim on the ticket.

* Identifying trends and themes in the tickets. If there 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 `django-developers`_.

* Set the *type* of tickets that are still uncategorized.

* Verify if patches submitted by other users are correct. If they do and

  also contain appropriate documentation and tests then move them to the

  "Ready for Checkin" stage. If they don't then leave a comment to explain