Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

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

git-svn-id: http://code.djangoproject.com/svn/django/trunk@4346 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 2926fb238dbb2123239f415022ca50c85c7de8ba 1 parent f2a3deb
Jacob Kaplan-Moss authored January 17, 2007

Showing 1 changed file with 61 additions and 15 deletions. Show diff stats Hide diff stats

  1. 76  docs/contributing.txt
76  docs/contributing.txt
@@ -151,24 +151,70 @@ Unfortunately, not all bug reports in the `ticket tracker`_ provide all
151 151
 the `required details`_. A number of tickets have patches, but those patches
152 152
 don't meet all the requirements of a `good patch`_.
153 153
 
154  
-One way to help out is to *triage* bugs that have been reported by other users.
155  
-Pick an open ticket that is missing some details, and try to replicate the
156  
-problem. Fill in the missing pieces of the report. If the ticket doesn't have
157  
-a patch, create one.
158  
-
159  
-Once you've completed all the missing details on the ticket and you have a
160  
-patch with all the required features, e-mail `django-developers`_. Indicate
161  
-that you have triaged a ticket, and recommend a course of action for dealing
162  
-with that ticket.
163  
-
164  
-At first, this may require you to be persistent. If you find that your triaged
165  
-ticket still isn't getting attention, occasional polite requests for eyeballs
166  
-to look at your ticket may be necessary. However, as you earn a reputation for
167  
-quality triage work, you should find that it is easier to get the developers'
168  
-attention.
  154
+One way to help out is to *triage* bugs that have been reported by other
  155
+users. We have a couple of dedicated volunteers who work on this regularly,
  156
+but more help is always appriciated.
  157
+
  158
+Most of the workflow is based around the concept of a ticket's "triage stage".
  159
+This stage describes where in its lifetime a given ticket is at any time.
  160
+Along with a handful of flags, this field easily tells us what and who each
  161
+ticket is waiting on.
  162
+
  163
+Since a picture is worth a thousand words, let's start there:
  164
+
  165
+.. image:: http://media.djangoproject.com/img/doc/djangotickets.png
  166
+   :height: 451
  167
+   :width: 590
  168
+   :alt: Django's ticket workflow
  169
+
  170
+We've got two roles here:
  171
+
  172
+    * Core developers: people with commit access who make the decisions and
  173
+      write the bulk of the code
  174
+
  175
+    * Ticket triagers: community members who keep track of tickets, making
  176
+      sure that they're always categorized correctly.
  177
+
  178
+Second, note the four triage stages:
  179
+
  180
+    1. "Unreviewed", meaning that a triager has yet to examine the ticket and
  181
+       move it along.
  182
+
  183
+    2. "Design decision needed", meaning "this concept requires a design
  184
+       decision," which should be discussed either in the ticket comments or on
  185
+       django-developers.
  186
+
  187
+    3. Once a ticket is ruled to be approved for fixing, it's moved along into
  188
+       the "Accepted" stage. This stage is where all the real work gets done.
  189
+
  190
+    4. If a ticket has an associated patch (see below), a triager will review the
  191
+       patch. If the patch is complete, it'll be marked as "ready for checkin" so
  192
+       that a core developer knows to review and check in the patches.
  193
+       
  194
+The second part of this workflow involves a set of flags the describe what the
  195
+ticket has or needs in order to be "ready for checkin":
  196
+
  197
+    "Has patch"
  198
+        The means that the ticket has an associated patch_. These will be
  199
+        reviewed to see if the patch is "good".
  200
+        
  201
+    "Needs documentation"
  202
+        This flag is used for tickets with patches that need associated
  203
+        documentation. Complete documentation of features is a prerequisite
  204
+        before we can check a fix into the codebase.
  205
+
  206
+    "Needs tests"
  207
+        This flags the patch as needing associated unit tests.  Again,
  208
+        this is required part of a valid patch.
  209
+        
  210
+    "Patch needs improvement"
  211
+        This flag means that although the ticket *has* a patch, it's not quite
  212
+        ready for checkin. This could mean the patch no longer applies
  213
+        cleanly, or that the code doesn't live up to our standards.
169 214
 
170 215
 .. _required details: `Reporting bugs`_
171 216
 .. _good patch: `Patch style`_
  217
+.. _patch: `Submitting patches`_
172 218
 
173 219
 Submitting and maintaining translations
174 220
 =======================================

0 notes on commit 2926fb2

Please sign in to comment.
Something went wrong with that request. Please try again.