ВОПРОСЫ И ОТВЕТЫ: Внесение кода

Как я могу начать вносить код в Django?

Спасибо за вопрос! Мы написали целый документ, посвященный этому вопросу. Он называется Contributing to Django.

Я отправил исправление ошибки в систему тикетов несколько недель назад. Почему вы игнорируете мой патч?

Не волнуйтесь: мы вас не игнорируем!

Важно понимать, что есть разница между «тикет игнорируется» и «тикет еще не рассмотрен». Система тикетов Django содержит сотни открытых тикетов, различной степени влияния на функциональность конечного пользователя, и разработчикам Django приходится рассматривать их и расставлять приоритеты.

Кроме того, все люди, работающие над Django, являются добровольцами. В результате, количество времени, которое у нас есть для работы над фреймворком, ограничено и будет меняться от недели к неделе в зависимости от нашего свободного времени. Если мы заняты, мы не сможем уделять Django столько времени, сколько нам хотелось бы.

Лучший способ убедиться, что билеты не зависнут на пути к регистрации, - это сделать так, чтобы даже человеку, который, возможно, не очень хорошо знаком с этой областью кода, было очень легко понять проблему и проверить ее устранение:

  • Есть ли четкие инструкции о том, как воспроизвести ошибку? Если это касается зависимости (например, Pillow), модуля contrib или конкретной базы данных, достаточно ли ясны эти инструкции даже для человека, не знакомого с ними?
  • Если к билету прилагается несколько патчей, ясно ли, что делает каждый из них, какие из них можно игнорировать, а какие имеют значение?
  • Включает ли патч модульный тест? Если нет, есть ли четкое объяснение, почему нет? Тест лаконично выражает суть проблемы и показывает, что патч действительно ее устраняет.

Если у вашего патча нет шансов на включение в Django, мы не будем его игнорировать - мы просто закроем тикет. Так что если ваш тикет все еще открыт, это не значит, что мы игнорируем вас; это просто означает, что у нас еще не было времени рассмотреть его.

Когда и как я могу напомнить команде о патче, который меня волнует?

Вежливое, вовремя отправленное сообщение в список рассылки - один из способов привлечь внимание. Чтобы определить подходящее время, необходимо следить за расписанием. Если вы опубликуете свое сообщение непосредственно перед крайним сроком выпуска, вы вряд ли получите то внимание, которое вам нужно.

Мягкие напоминания в IRC также могут сработать - опять же, по возможности, в стратегически подходящее время. Например, во время баг-спринта это очень подходящее время.

Еще один способ добиться успеха - объединить несколько связанных между собой тикетов. Когда кто-то садится за рассмотрение ошибки в области, к которой он давно не обращался, ему может понадобиться несколько минут, чтобы вспомнить все тонкости работы этой области кода. Если вы соберете несколько мелких исправлений в одну тематическую группу, вы станете привлекательной мишенью, поскольку затраты на введение в курс дела по данной области кода можно распределить на несколько заявок.

Пожалуйста, не пишите никому лично и не поднимайте один и тот же вопрос снова и снова. Такое поведение не привлечет к вам никакого дополнительного внимания - и уж точно не того внимания, которое вам необходимо для того, чтобы добиться решения вашего вопроса.

Но я напоминал вам несколько раз, а вы продолжаете игнорировать мой патч!

Серьезно - мы не игнорируем вас. Если у вашего патча нет шансов на включение в Django, мы закроем тикет. Что касается всех остальных тикетов, нам нужно расставить приоритеты, что означает, что некоторые тикеты будут рассмотрены раньше других.

Одним из критериев, который используется для определения приоритетности исправления ошибок, является количество людей, которые могут пострадать от данной ошибки. Ошибки, которые потенциально могут повлиять на многих людей, обычно получают приоритет над теми, которые являются крайними случаями.

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 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 человек, а не одного.

Я уверен, что мой билет абсолютно на 100% безупречен, могу ли я сам отметить его как «Готов к регистрации»?

К сожалению, нет. Всегда лучше получить еще один взгляд на билет. Если у вас возникли проблемы с получением второго взгляда, см. вопросы выше.

Вернуться на верх