Removed references to the DDN triage state.

Rephrased "How can I help with triaging?" a bit to reflect the current
practice.

docs/internals/contributing/new-contributors.txt

@@ -140,12 +140,3 @@ FAQ
    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.

docs/internals/contributing/triaging-tickets.txt

@@ -51,8 +51,8 @@ attribute easily tells us what and who each ticket is waiting on.
 Since a picture is worth a thousand words, let's start there:
 
 .. image:: /internals/_images/triage_process.*
-   :height: 564
+   :height: 501
-   :width: 580
+   :width: 400
    :alt: Django's ticket triage workflow
 
 We've got two roles in this diagram:
@@ -128,30 +128,13 @@ Beyond that there are several considerations:
   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
 ~~~~~~~~~~~~~~~~~
 
@@ -165,11 +148,13 @@ RFC forever! What should I do?"
 Someday/Maybe
 ~~~~~~~~~~~~~
 
-Generally only used for vague/high-level features or design ideas. These
+This stage isn't shown on the diagram. It's only used by core developers to
-tickets are uncommon and overall less useful since they don't describe
+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
 -----------------------
@@ -301,20 +286,23 @@ developers and bring the issue to django-developers_ instead.
 How can I help with triaging?
 -----------------------------
 
-Although the core developers make the big decisions in the ticket triage
+The triage process is primarily driven by community members. Really,
-process, there's a lot that general community members can do to help the
+**ANYONE** can help.
-triage process. Really, **ANYONE** can help.
 
-Start by `creating an account on Trac`_. If you have an account but have
+Core developers may provide feedback on issues they're familiar with, or make
-forgotten your password, you can reset it using the `password reset page`_.
+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
+* Closing "Unreviewed" tickets as "needsinfo" when they're feature requests
-  decision needs to be made, or "Accepted" in case of obvious bugs or
+  requiring a discussion on `django-developers`_.
-  sensible, clearly defined, feature requests.
 
 * Correcting the "Needs tests", "Needs documentation", or "Has patch"
   flags for tickets where they are incorrectly set.
@@ -322,22 +310,18 @@ Then, you can help out by:
 * 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