Browse files

Added a description of our new ticket workflow to the contributing doc.

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
1 parent f2a3deb commit 2926fb238dbb2123239f415022ca50c85c7de8ba @jacobian jacobian committed Jan 17, 2007
Showing with 61 additions and 15 deletions.
  1. +61 −15 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.
-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.
-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'
+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.
+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.
+Since a picture is worth a thousand words, let's start there:
+.. image::
+ :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

0 comments on commit 2926fb2

Please sign in to comment.