mirror of
https://github.com/django/django.git
synced 2025-11-03 21:25:09 +00:00
102 lines
5.4 KiB
Text
102 lines
5.4 KiB
Text
FAQ: Contributing code
|
|
======================
|
|
|
|
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?
|
|
--------------------------------------------------------------------------------------------
|
|
|
|
Don't worry: We're not ignoring you!
|
|
|
|
It's important to understand there is a difference between "a ticket is being
|
|
ignored" and "a ticket has not been attended to yet." Django's ticket system
|
|
contains hundreds of open tickets, of various degrees of impact on end-user
|
|
functionality, and Django's developers have to review and prioritize.
|
|
|
|
On top of that: the people who work on Django are all volunteers. As a result,
|
|
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
|
|
be able to spend as much time on Django as we might want.
|
|
|
|
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 Pillow/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.
|