123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109 |
- ======================
- FAQ: Contributing code
- ======================
- .. _new-contributors-faq:
- 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 several weeks ago. Why are you ignoring my contribution?
- ==============================================================================
- 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), a contrib module, or a specific
- database, are those instructions clear enough even for someone not
- familiar with it?
- * 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 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 branch actually fixes it.
- 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 change I care about?
- ==============================================================
- 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.
- Gentle reminders in the ``#contributing-getting-started`` channel in the
- `Django Discord server`_ can work.
- Another way to get traction is to pull several related tickets together. When
- someone sits down to review 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 anyone personally or repeatedly raising the same
- 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.
- .. _`Django Discord server`: https://discord.gg/xcRH6mN4fa
- But I've reminded you several times and you keep ignoring my contribution!
- ==========================================================================
- 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.
- 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 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 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
- 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, instead of prioritizing the impact on 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 a single person happy.
- I'm sure my ticket is absolutely 100% perfect, can I mark it as "Ready For Checkin" myself?
- ===========================================================================================
- Sorry, no. It's always better to get another set of eyes on a ticket. If
- you're having trouble getting that second set of eyes, see questions above.
|