FAQ: добавление кода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright ©2021 All rights reserved