Сообщения об ошибках и запросы о новых фичах¶
Важно
Пожалуйста, сообщайте о проблемах безопасности только по адресу security@djangoproject.com. Это закрытый список, открытый только для давних, пользующихся большим доверием разработчиков Django, и его архивы не являются общедоступными. Для получения более подробной информации см. наши политики безопасности.
В противном случае, прежде чем сообщать об ошибке или запрашивать новый функционал в тикет-трекере, учтите следующие моменты:
Проверьте, не отправил ли кто-нибудь запрос на ошибку или функционал, выполнив поиск`_ или запустив пользовательские запросы в системе отслеживания тикетов.
Не используйте систему тикетов, чтобы задавать вопросы о поддержке. Используйте для этого Форум Django или сервер Django Discord.
Не открывайте повторно проблемы, отмеченные как «wontfix», не найдя консенсуса на этот счет на Форуме Django.
Не используйте трекер тикетов для длительных обсуждений, так как они, скорее всего, затеряются. Если конкретный тикет вызывает споры, пожалуйста, перенесите обсуждение на Форум Django.
Отправка сообщений об ошибках¶
Хорошо написанные отчеты об ошибках невероятно полезны. Однако работа с любой системой отслеживания ошибок сопряжена с определенными накладными расходами, поэтому мы ценим вашу помощь в поддержании максимальной полезности нашего трекера тикетов. В частности:
Обязательно прочтите FAQ, чтобы узнать, не является ли ваша проблема давно решенной.
Сначала спросите на Форуме Django или Сервере Django Discord, если вы не уверены, что то, что вы видите, является ошибкой.
**Пишите полные, воспроизводимые, конкретные отчеты об ошибках. Вы должны включить четкое, краткое описание проблемы и набор инструкций по ее воспроизведению. Добавьте как можно больше отладочной информации: фрагменты кода, тестовые случаи, обратные трассировки исключений, снимки экрана и т. д. Хороший небольшой тест кейс является лучшим способом сообщить об ошибке, поскольку он дает нам способ быстро подтвердить ошибку.
Не пишите на Форуме Django только для того, чтобы объявить, что вы отправили отчет об ошибке. Все тикеты отправляются в другой список, django-updates, который отслеживается разработчиками и заинтересованными членами сообщества; мы видим их как отправленные.
Чтобы статус вашего тикета после его создания, обратитесь к Сортировка тикетов.
Сообщение об ошибках и запрос функционала пользовательского интерфейса¶
Если ваш запрос на исправление ошибки или функцию касается чего-либо визуального, есть несколько дополнительных рекомендаций, которым следует следовать:
Включайте в свой тикет скриншоты, которые демонстрируют тест кейс. Покажите проблему, а не безумные настройки, которые вы внесли в свой браузер.
Если проблему сложно продемонстрировать с помощью неподвижного изображения, рассмотрите возможность снять короткий скринкаст. Если ваше программное обеспечение это позволяет, снимите только соответствующую область экрана.
Если вы предлагаете патч, который изменяет внешний вид или поведение пользовательского интерфейса Django, вы должны прикрепить его до и после снимков экрана/скринкастов. Без них тикеты трудно быстро оценить.
Снимки экрана не освобождают вас от других правил составления отчетов. Обязательно включайте URL-адреса, фрагменты кода и пошаговые инструкции о том, как воспроизвести поведение, видимое на снимках экрана.
Обязательно установите флаг UI/UX на тикете, чтобы заинтересованные стороны могли найти ваш тикет.
Запрос новых функций¶
Мы всегда стараемся сделать Django лучше, и ваши запросы на новые функции являются ключевой частью этого. Вот несколько советов о том, как сделать запрос наиболее эффективно:
Убедитесь, что функция действительно требует изменений в ядре Django. Если ваша идея может быть разработана как независимое приложение или модуль — например, вы хотите поддерживать другой движок базы данных — мы, вероятно, предложим вам разработать ее независимо. Затем, если ваш проект получит достаточную поддержку сообщества, мы можем рассмотреть возможность включения его в Django.
Сначала запросите функцию на Форуме Django, а не в системе отслеживания тикетов. Оно будет прочитано более внимательно и охватит более широкую аудиторию. Это еще более важно для крупномасштабных запросов функций. Мы предпочитаем обсуждать любые крупные изменения в ядре Django, прежде чем приступать к работе над ними.
Опишите четко и кратко, какой функции не хватает и как бы вы хотели ее реализовать. Приложите пример кода (код необязательно должен быть на 100% рабочим), если это возможно.
Объясните, почему вам нужна эта функция. Это поможет другим понять, где она вписывается, и существуют ли уже другие способы достичь того же.
Если по этой функции достигнут консенсус, то необходимо создать тикет. Включите ссылку на обсуждение в описание тикета.
Как и в большинстве проектов с открытым исходным кодом, код говорит сам за себя. Если вы готовы написать код для функции самостоятельно или, что еще лучше, если вы уже написали его, то вероятность того, что его примут, гораздо выше. Сделайте форк Django на GitHub, создайте ветку функции и покажите нам свою работу!
См. также: Документирование новых функций.
Запрос на оптимизацию производительности¶
Отчеты о регрессии производительности или предлагаемые оптимизации производительности должны содержать контрольные показатели и команды для воспроизведения.
Дополнительные сведения о существующих тестах производительности Django см. в Тесты django-asv.
Как мы принимаем решения¶
По возможности мы стремимся к консенсусу. С этой целью мы часто проводим неформальные голосования на форуме Django по поводу функции. В этих голосованиях мы следуем стилю голосования, изобретенному Apache и используемому в самом Python, где голоса даются как +1, +0, -0 или -1. Эти голоса означают:
+1: «Мне нравится эта идея.
+0: «Сойдет.»
-0: «Я не в восторге, но и мешать не буду».
-1: «Я категорически не согласен и был бы очень недоволен, если бы эта идея воплотилась в реальность.»
Хотя эти голосования неформальны, они будут восприняты очень серьезно. После голосования, если возникнет очевидный консенсус, мы перейдем к действиям.
Однако консенсус не всегда возможен. Если консенсус не может быть достигнут, или если обсуждение в направлении консенсуса заходит в тупик без конкретного решения, решение может быть передано руководящему совету.
Руководящий совет будет использовать тот же механизм голосования. Предложение будет считаться принятым, если:
Не менее трех голосов «+1» от членов руководящего совета.
Ни один из членов руководящего совета не подал ни одного голоса «-1».
Голоса необходимо подать в течение недели.
Поскольку этот процесс позволяет любому члену руководящего совета наложить вето на предложение, голосование «-1» должно сопровождаться объяснением того, что необходимо для превращения этого «-1» как минимум в «+0».
Голосование по техническим вопросам должно быть объявлено и проведено публично на Форуме Django.