PageRenderTime 5ms CodeModel.GetById 2ms app.highlight 0ms RepoModel.GetById 1ms app.codeStats 0ms

Plain Text | 102 lines | 81 code | 21 blank | 0 comment | 0 complexity | 78181c9d24e87da0567cc717806274c2 MD5 | raw file
  1FAQ: Contributing code
  4How can I get started contributing code to Django?
  7Thanks for asking! We've written an entire document devoted to this question.
  8It's titled :doc:`Contributing to Django </internals/contributing>`.
 10I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
 13Don't worry: We're not ignoring you!
 15It's important to understand there is a difference between "a ticket is being
 16ignored" and "a ticket has not been attended to yet." Django's ticket system
 17contains hundreds of open tickets, of various degrees of impact on end-user
 18functionality, and Django's developers have to review and prioritize.
 20On top of that: the people who work on Django are all volunteers. As a result,
 21the amount of time that we have to work on the framework is limited and will
 22vary from week to week depending on our spare time. If we're busy, we may not
 23be able to spend as much time on Django as we might want.
 25The best way to make sure tickets do not get hung up on the way to checkin is
 26to make it dead easy, even for someone who may not be intimately familiar with
 27that area of the code, to understand the problem and verify the fix:
 29    * Are there clear instructions on how to reproduce the bug? If this
 30      touches a dependency (such as PIL), a contrib module, or a specific
 31      database, are those instructions clear enough even for someone not
 32      familiar with it?
 34    * If there are several patches attached to the ticket, is it clear what
 35      each one does, which ones can be ignored and which matter?
 37    * Does the patch include a unit test? If not, is there a very clear
 38      explanation why not? A test expresses succinctly what the problem is,
 39      and shows that the patch actually fixes it.
 41If your patch stands no chance of inclusion in Django, we won't ignore it --
 42we'll just close the ticket. So if your ticket is still open, it doesn't mean
 43we're ignoring you; it just means we haven't had time to look at it yet.
 45When and how might I remind the core team of a patch I care about?
 48A polite, well-timed message to the mailing list is one way to get attention.
 49To determine the right time, you need to keep an eye on the schedule. If you
 50post your message when the core developers are trying to hit a feature
 51deadline or manage a planning phase, you're not going to get the sort of
 52attention you require. However, if you draw attention to a ticket when the
 53core developers are paying particular attention to bugs -- just before a bug
 54fixing sprint, or in the lead up to a beta release for example -- you're much
 55more likely to get a productive response.
 57Gentle IRC reminders can also work -- again, strategically timed if possible.
 58During a bug sprint would be a very good time, for example.
 60Another way to get traction is to pull several related tickets together. When
 61the core developers sit down to fix a bug in an area they haven't touched for
 62a while, it can take a few minutes to remember all the fine details of how
 63that area of code works. If you collect several minor bug fixes together into
 64a similarly themed group, you make an attractive target, as the cost of coming
 65up to speed on an area of code can be spread over multiple tickets.
 67Please refrain from emailing core developers personally, or repeatedly raising
 68the same issue over and over. This sort of behavior will not gain you any
 69additional attention -- certainly not the attention that you need in order to
 70get your pet bug addressed.
 72But I've reminded you several times and you keep ignoring my patch!
 75Seriously - we're not ignoring you. If your patch stands no chance of
 76inclusion in Django, we'll close the ticket. For all the other tickets, we
 77need to prioritize our efforts, which means that some tickets will be
 78addressed before others.
 80One of the criteria that is used to prioritize bug fixes is the number of
 81people that will likely be affected by a given bug. Bugs that have the
 82potential to affect many people will generally get priority over those that
 83are edge cases.
 85Another reason that bugs might be ignored for while is if the bug is a symptom
 86of a larger problem. While we can spend time writing, testing and applying
 87lots of little patches, sometimes the right solution is to rebuild. If a
 88rebuild or refactor of a particular component has been proposed or is
 89underway, you may find that bugs affecting that component will not get as much
 90attention. Again, this is just a matter of prioritizing scarce resources. By
 91concentrating on the rebuild, we can close all the little bugs at once, and
 92hopefully prevent other little bugs from appearing in the future.
 94Whatever the reason, please keep in mind that while you may hit a particular
 95bug regularly, it doesn't necessarily follow that every single Django user
 96will hit the same bug. Different users use Django in different ways, stressing
 97different parts of the code under different conditions. When we evaluate the
 98relative priorities, we are generally trying to consider the needs of the
 99entire community, not just the severity for one particular user. This doesn't
100mean that we think your problem is unimportant -- just that in the limited
101time we have available, we will always err on the side of making 10 people
102happy rather than making 1 person happy.