Index: docs/faq/contributing.txt
===================================================================
--- docs/faq/contributing.txt (revision 9787)
+++ docs/faq/contributing.txt (working copy)
@@ -24,7 +24,43 @@
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 :-)