diff --git a/docs/contributing.txt b/docs/contributing.txt
index de9236f6c1..3317bff4c1 100644
--- a/docs/contributing.txt
+++ b/docs/contributing.txt
@@ -151,24 +151,70 @@ Unfortunately, not all bug reports 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* bugs that have been reported by other users.
-Pick an open ticket that is missing some details, and try to replicate the
-problem. Fill in the missing pieces of the report. If the ticket doesn't have
-a patch, create one.
+One way to help out is to *triage* bugs that have been reported by other
+users. We have a couple of dedicated volunteers who work on this regularly,
+but more help is always appriciated.
 
-Once you've completed all the missing details on the ticket and you have a
-patch with all the required features, e-mail `django-developers`_. Indicate
-that you have triaged a ticket, and recommend a course of action for dealing
-with that ticket.
+Most of the workflow is based around the concept of a ticket's "triage stage".
+This stage describes where in its lifetime a given ticket is at any time.
+Along with a handful of flags, this field easily tells us what and who each
+ticket is waiting on.
 
-At first, this may require you to be persistent. If you find that your triaged
-ticket still isn't getting attention, occasional polite requests for eyeballs
-to look at your ticket may be necessary. However, as you earn a reputation for
-quality triage work, you should find that it is easier to get the developers'
-attention.
+Since a picture is worth a thousand words, let's start there:
+
+.. image:: http://media.djangoproject.com/img/doc/djangotickets.png
+   :height: 451
+   :width: 590
+   :alt: Django's ticket workflow
+
+We've got two roles here:
+
+    * Core developers: people with commit access who make the decisions and
+      write the bulk of the code
+
+    * Ticket triagers: community members who keep track of tickets, making
+      sure that they're always categorized correctly.
+
+Second, note the four triage stages:
+
+    1. "Unreviewed", meaning that a triager has yet to examine the ticket and
+       move it along.
+
+    2. "Design decision needed", meaning "this concept requires a design
+       decision," which should be discussed either in the ticket comments or on
+       django-developers.
+
+    3. Once a ticket is ruled to be approved for fixing, it's moved along into
+       the "Accepted" stage. This stage is where all the real work gets done.
+
+    4. If a ticket has an associated patch (see below), a triager will review the
+       patch. If the patch is complete, it'll be marked as "ready for checkin" so
+       that a core developer knows to review and check in the patches.
+       
+The second part of this workflow involves a set of flags the describe what the
+ticket has or needs in order to be "ready for checkin":
+
+    "Has patch"
+        The means that the ticket has an associated patch_. These will be
+        reviewed to see if the patch is "good".
+        
+    "Needs documentation"
+        This flag is used for tickets with patches that need associated
+        documentation. Complete documentation of features is a prerequisite
+        before we can check a fix into the codebase.
+
+    "Needs tests"
+        This flags the patch as needing associated unit tests.  Again,
+        this is required part of a valid patch.
+        
+    "Patch needs improvement"
+        This flag means that although the ticket *has* a patch, it's not quite
+        ready for checkin. This could mean the patch no longer applies
+        cleanly, or that the code doesn't live up to our standards.
 
 .. _required details: `Reporting bugs`_
 .. _good patch: `Patch style`_
+.. _patch: `Submitting patches`_
 
 Submitting and maintaining translations
 =======================================