ВОПРОСЫ И ОТВЕТЫ: Внесение кода¶
Как я могу начать вносить код в Django?¶
Спасибо за вопрос! Мы написали целый документ, посвященный этому вопросу. Он называется Contributing to Django.
Я отправил исправление ошибки в систему тикетов несколько недель назад. Почему вы игнорируете мой патч?¶
Не волнуйтесь: мы вас не игнорируем!
Важно понимать, что есть разница между «тикет игнорируется» и «тикет еще не рассмотрен». Система тикетов Django содержит сотни открытых тикетов, различной степени влияния на функциональность конечного пользователя, и разработчикам Django приходится рассматривать их и расставлять приоритеты.
Кроме того, все люди, работающие над Django, являются добровольцами. В результате, количество времени, которое у нас есть для работы над фреймворком, ограничено и будет меняться от недели к неделе в зависимости от нашего свободного времени. Если мы заняты, мы не сможем уделять Django столько времени, сколько нам хотелось бы.
Лучший способ убедиться, что билеты не зависнут на пути к регистрации, - это сделать так, чтобы даже человеку, который, возможно, не очень хорошо знаком с этой областью кода, было очень легко понять проблему и проверить ее устранение:
- Есть ли четкие инструкции о том, как воспроизвести ошибку? Если это касается зависимости (например, Pillow), модуля contrib или конкретной базы данных, достаточно ли ясны эти инструкции даже для человека, не знакомого с ними?
- Если к билету прилагается несколько патчей, ясно ли, что делает каждый из них, какие из них можно игнорировать, а какие имеют значение?
- Включает ли патч модульный тест? Если нет, есть ли четкое объяснение, почему нет? Тест лаконично выражает суть проблемы и показывает, что патч действительно ее устраняет.
Если у вашего патча нет шансов на включение в Django, мы не будем его игнорировать - мы просто закроем тикет. Так что если ваш тикет все еще открыт, это не значит, что мы игнорируем вас; это просто означает, что у нас еще не было времени рассмотреть его.
Когда и как я могу напомнить команде о патче, который меня волнует?¶
Вежливое, вовремя отправленное сообщение в список рассылки - один из способов привлечь внимание. Чтобы определить подходящее время, необходимо следить за расписанием. Если вы опубликуете свое сообщение непосредственно перед крайним сроком выпуска, вы вряд ли получите то внимание, которое вам нужно.
Мягкие напоминания в IRC также могут сработать - опять же, по возможности, в стратегически подходящее время. Например, во время баг-спринта это очень подходящее время.
Еще один способ добиться успеха - объединить несколько связанных между собой тикетов. Когда кто-то садится за рассмотрение ошибки в области, к которой он давно не обращался, ему может понадобиться несколько минут, чтобы вспомнить все тонкости работы этой области кода. Если вы соберете несколько мелких исправлений в одну тематическую группу, вы станете привлекательной мишенью, поскольку затраты на введение в курс дела по данной области кода можно распределить на несколько заявок.
Пожалуйста, не пишите никому лично и не поднимайте один и тот же вопрос снова и снова. Такое поведение не привлечет к вам никакого дополнительного внимания - и уж точно не того внимания, которое вам необходимо для того, чтобы добиться решения вашего вопроса.
Но я напоминал вам несколько раз, а вы продолжаете игнорировать мой патч!¶
Серьезно - мы не игнорируем вас. Если у вашего патча нет шансов на включение в Django, мы закроем тикет. Что касается всех остальных тикетов, нам нужно расставить приоритеты, что означает, что некоторые тикеты будут рассмотрены раньше других.
Одним из критериев, который используется для определения приоритетности исправления ошибок, является количество людей, которые могут пострадать от данной ошибки. Ошибки, которые потенциально могут повлиять на многих людей, обычно получают приоритет над теми, которые являются крайними случаями.
Еще одна причина, по которой ошибку можно игнорировать некоторое время, - если она является симптомом более серьезной проблемы. Хотя мы можем тратить время на написание, тестирование и применение множества мелких исправлений, иногда правильным решением является перестройка. Если было предложено переделать или рефакторить определенный компонент, вы можете обнаружить, что ошибки, затрагивающие этот компонент, не будут привлекать столько внимания. Опять же, это вопрос приоритетности ограниченных ресурсов. Сосредоточившись на перестройке, мы сможем устранить все мелкие ошибки сразу и, надеюсь, предотвратить появление других мелких ошибок в будущем.
Какова бы ни была причина, пожалуйста, имейте в виду, что, хотя вы можете регулярно сталкиваться с определенной ошибкой, не обязательно, что каждый пользователь Django будет сталкиваться с той же ошибкой. Разные пользователи используют Django по-разному, нагружая разные части кода в разных условиях. Когда мы оцениваем относительные приоритеты, мы обычно стараемся учитывать потребности всего сообщества, вместо того, чтобы отдавать предпочтение влиянию на одного конкретного пользователя. Это не значит, что мы считаем вашу проблему неважной - просто в условиях ограниченного времени, которое у нас есть, мы всегда будем склоняться к тому, чтобы сделать счастливыми 10 человек, а не одного.
Я уверен, что мой билет абсолютно на 100% безупречен, могу ли я сам отметить его как «Готов к регистрации»?¶
К сожалению, нет. Всегда лучше получить еще один взгляд на билет. Если у вас возникли проблемы с получением второго взгляда, см. вопросы выше.