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