Ticket #10110: 10110.diff

docs/faq/contributing.txt

@@ -24 +24 @@
 vary from week to week depending on our spare time. If we're busy, we may not
 be able to spend as much time on Django as we might want.
 
-Besides, if your feature request stands no chance of inclusion in Django, we
+The best way to make sure tickets do not get hung up on the way to checkin 
+is to make it dead easy, even for someone who may not be intimately familiar 
+with that area of the code, to understand the problem and verify the fix:
+
+    * Are there clear instructions on how to reproduce the bug? If this touches
+    a dependency (such as PIL), a contrib module, or a specific database, are 
+    those instructions clear enough even for someone not familiar with it?
+    
+    * If there are several patches attached to the ticket, is it clear what 
+    each one does, which ones can be ignored and which matter?
+    
+    * Does the patch include a unit test? If not, is there a very clear 
+    explanation why not? A test expresses succinctly what the problem is,
+    and shows that the patch actually fixes it.
+
+If your feature request stands no chance of inclusion in Django, we
 won't ignore it -- we'll just close the ticket. So if your ticket is still
 open, it doesn't mean we're ignoring you; it just means we haven't had time to
 look at it yet.
+
+When and how might I remind the dev team of a bug I care about?
+---------------------------------------------------------------
+
+A polite, well-timed message to the mailing list is certainly one way
+to get attention. Keep an eye on the grand schedule. If you make noise
+when the core devs are under the hammer trying to hit a feature
+deadline or manage a planning phase, you're probably going to get
+ignored. However, raising the ticket when the core devs are paying
+attention to bugs - just before a bug fixing sprint, or in the leadup
+to a beta release for example - is likely to get some traction.
+
+Gentle IRC reminders can also work - again, strategically timed
+(during a bug sprint would be a very good time, for example).
+
+Another way to get traction is to pull related items together. When I
+jump into the code to fix a bug in an area I haven't touched for a
+while, it can take a few minutes to refresh my memory on exactly how
+things work. If you collect minor bugs together into similarly themed
+groups, you make an attractive target for us core devs (who are, after
+all, exceedingly lazy and like easy jobs much more than hard jobs :-)