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>`.

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 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.