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