mirror of
https://github.com/django/django.git
synced 2025-08-04 19:08:28 +00:00
Replaced usage of "patch" with more precise terms in faq, howto, and intro docs.
This commit is contained in:
parent
3556f63c4c
commit
85240139ca
4 changed files with 60 additions and 61 deletions
|
@ -10,8 +10,8 @@ How can I get started contributing code to Django?
|
|||
Thanks for asking! We've written an entire document devoted to this question.
|
||||
It's titled :doc:`Contributing to Django </internals/contributing/index>`.
|
||||
|
||||
I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
|
||||
============================================================================================
|
||||
I submitted a bug fix several weeks ago. Why are you ignoring my contribution?
|
||||
==============================================================================
|
||||
|
||||
Don't worry: We're not ignoring you!
|
||||
|
||||
|
@ -34,21 +34,21 @@ that area of the code, to understand the problem and verify the fix:
|
|||
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?
|
||||
* If there are several branches linked 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
|
||||
* Does the change 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.
|
||||
and shows that the branch 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
|
||||
If your contribution is not suitable for inclusion in Django, we won't ignore
|
||||
it -- we'll 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 team of a patch I care about?
|
||||
=============================================================
|
||||
When and how might I remind the team of a change I care about?
|
||||
==============================================================
|
||||
|
||||
A polite, well-timed message to the mailing list is one way to get attention.
|
||||
A polite, well-timed message in the forum/branch 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 right before a release deadline, you're not likely to get the
|
||||
sort of attention you require.
|
||||
|
@ -68,11 +68,11 @@ issue over and over again. This sort of behavior will not gain you any
|
|||
additional attention -- certainly not the attention that you need in order to
|
||||
get your issue addressed.
|
||||
|
||||
But I've reminded you several times and you keep ignoring my patch!
|
||||
===================================================================
|
||||
But I've reminded you several times and you keep ignoring my contribution!
|
||||
==========================================================================
|
||||
|
||||
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
|
||||
Seriously - we're not ignoring you. If your contribution is not suitable for
|
||||
inclusion in Django, we will close the ticket. For all the other tickets, we
|
||||
need to prioritize our efforts, which means that some tickets will be
|
||||
addressed before others.
|
||||
|
||||
|
@ -83,7 +83,7 @@ are edge cases.
|
|||
|
||||
Another reason that a bug might be ignored for a 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
|
||||
applying lots of little changes, 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 a matter of prioritizing scarce resources. By
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue