FAQ: участие в развитии Django¶
Как начать оказывать содействие развитию проекта?¶
Спасибо вам за вашу заинтересованность! Данному вопросу посвящен отдельный документ содействие развитию Django.
I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?¶
Не беспокойтесь! Мы вас не игнорируем.
Важно понимать разницу между двумя состояниями, в котором может находится ваше предложение: «игнорируется» и «еще не принято к рассмотрению». В системе обработки заявок, поступающих от пользователей, на рассмотрении находятся сотни предложений. Они различаются по степени влияния на функционал Django, предоставляемый конечным пользователям. Разработчики Django должны просмотреть и ранжировать по важности весь объем этих предложений.
Кроме этого, нельзя упускать из виду тот факт, что люди, работающие над развитием Django, делают это по своей инициативе. В результате этого количество времени, отводимого нами на работу с фреймворком, ограничено и может различаться от недели к неделе, в зависимости от нашей загруженности. Если мы заняты, то на разработку Django приходится уделять не так много времени, сколько бы нам хотелось.
Лучший способ добиться того, чтобы ваше предложение не застряло на пути к рассмотрению - это сделать его предельно простым и понятным. Тогда любой участник, даже не слишком хорошо знакомый с конкретной частью кода, сможет понять суть проблемы и проверить корректность вашего предложения. Вот некоторые рекомендации на этот счет:
Есть ли указания на то, при каких условиях возникает ошибка? Если появление ошибки связано с использованием библиотек Python (таких как Pillow), модулей Django, входящих в состав
contrib, или конкретной СУБД, то достаточно ли понятным является ваше описание?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 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 right before a release deadline, you’re not likely to get the sort of attention you require.
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 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. 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.
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.
Одним из критериев, используемых для ранжирования предложений, является количество пользователей, которые могут пострадать от конкретной ошибки. Ошибки, которые потенциально могут отрицательно сказаться для большого числа людей получают приоритет над теми, которые затрагивают незначительное количество пользователей.
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 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.
Пожалуйста, имейте в виду, что вы регулярно можете встречать определенную ошибку, но из этого не обязательно следует, что каждый пользователь Django сталкивается с той же самой ошибкой. Разные пользователи используют Django по-разному, используя различные компоненты в различных условиях. При расстановке относительных приоритетов мы, как правило, пытаемся учесть потребности всего сообщества в целом, а не отдельных пользователей. Это не означает, что мы думаем будто ваша проблема несущественна. В условиях ограниченности имеющегося у нас времени, мы придерживаемся мнения, что лучше удовлетворить потребности 10 человек, а не одного конкретного.