mirror of https://github.com/django/django.git
Fixed #10110 -- Added FAQ on how and when to poke the core developers about tickets. Thanks to Graham King for turning a couple of django-dev posts into a good first draft.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@9789 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
15b1675af9
commit
ff78aef93b
|
@ -24,7 +24,81 @@ the amount of time that we have to work on the framework is limited and will
|
||||||
vary from week to week depending on our spare time. If we're busy, we may not
|
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.
|
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
|
||||||
won't ignore it -- we'll just close the ticket. So if your ticket is still
|
to make it dead easy, even for someone who may not be intimately familiar with
|
||||||
open, it doesn't mean we're ignoring you; it just means we haven't had time to
|
that area of the code, to understand the problem and verify the fix:
|
||||||
look at it yet.
|
|
||||||
|
* 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 patch 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 core team of a patch I care about?
|
||||||
|
------------------------------------------------------------------
|
||||||
|
|
||||||
|
A polite, well-timed message to the mailing list is one way to get attention.
|
||||||
|
To determine the right time, you need to keep an eye on the schedule. If you
|
||||||
|
post your message when the core developers are trying to hit a feature
|
||||||
|
deadline or manage a planning phase, you're not going to get the sort of
|
||||||
|
attention you require. However, if you draw attention to a ticket when the
|
||||||
|
core developers are paying particular attention to bugs -- just before a bug
|
||||||
|
fixing sprint, or in the lead up to a beta release for example -- you're much
|
||||||
|
more likely to get a productive response.
|
||||||
|
|
||||||
|
Gentle IRC reminders can also work -- again, strategically timed if possible.
|
||||||
|
During a bug sprint would be a very good time, for example.
|
||||||
|
|
||||||
|
Another way to get traction is to pull several related tickets together. When
|
||||||
|
the core developers sit down to fix a bug in an area they haven't touched for
|
||||||
|
a while, it can take a few minutes to remember all the fine details of how
|
||||||
|
that area of code works. If you collect several minor bug fixes together into
|
||||||
|
a similarly themed group, you make an attractive target, as the cost of coming
|
||||||
|
up to speed on an area of code can be spread over multiple tickets.
|
||||||
|
|
||||||
|
Please refrain from emailing core developers personally, or repeatedly raising
|
||||||
|
the same issue over and over. This sort of behavior will not gain you any
|
||||||
|
additional attention -- certainly not the attention that you need in order to
|
||||||
|
get your pet bug addressed.
|
||||||
|
|
||||||
|
But I've reminded you several times and you keep ignoring my patch!
|
||||||
|
-------------------------------------------------------------------
|
||||||
|
|
||||||
|
Seriously - we're not ignoring you. If your patch stands no chance of
|
||||||
|
inclusion in Django, we'll close the ticket. For all the other tickets, we
|
||||||
|
need to prioritize our efforts, which means that some tickets will be
|
||||||
|
addressed before others.
|
||||||
|
|
||||||
|
One of the criteria that is used to prioritize bug fixes is the number of
|
||||||
|
people that will likely be affected by a given bug. Bugs that have the
|
||||||
|
potential to affect many people will generally get priority over those that
|
||||||
|
are edge cases.
|
||||||
|
|
||||||
|
Another reason that bugs might be ignored for while is if the bug is a symptom
|
||||||
|
of a larger problem. While we can spend time writing, testing and applying
|
||||||
|
lots of little patches, sometimes the right solution is to rebuild. If a
|
||||||
|
rebuild or refactor of a particular component has been proposed or is
|
||||||
|
underway, you may find that bugs affecting that component will not get as much
|
||||||
|
attention. Again, this is just a matter of prioritizing scarce resources. By
|
||||||
|
concentrating on the rebuild, we can close all the little bugs at once, and
|
||||||
|
hopefully prevent other little bugs from appearing in the future.
|
||||||
|
|
||||||
|
Whatever the reason, please keep in mind that while you may hit a particular
|
||||||
|
bug regularly, it doesn't necessarily follow that every single Django user
|
||||||
|
will hit the same bug. Different users use Django in different ways, stressing
|
||||||
|
different parts of the code under different conditions. When we evaluate the
|
||||||
|
relative priorities, we are generally trying to consider the needs of the
|
||||||
|
entire community, not just the severity for one particular user. This doesn't
|
||||||
|
mean that we think your problem is unimportant -- just that in the limited
|
||||||
|
time we have available, we will always err on the side of making 10 people
|
||||||
|
happy rather than making 1 person happy.
|
||||||
|
|
Loading…
Reference in New Issue