Сообщение об аномалиях или запросах функций ¶

Сообщение об аномалиях ¶

Хорошо написанные отчеты об ошибках чрезвычайно полезны. Тем не менее, в системе управления аномалиями всегда нужно проделать некоторую работу, поэтому ваша помощь в поддержании нашей системы в рабочем состоянии приветствуется. В частности :

• Читайте в FAQ , чтобы увидеть , если ваша проблема не регулярно задаваемый вопрос.
• Задайте первый на Джанго пользователей или #django , если вы не уверены в том, что вы видите , это действительно аномалия.
• Пишите подробные, повторяемые и точные отчеты об ошибках . Вы должны включить ясное и краткое описание проблемы и серию инструкций по ее воспроизведению. Добавьте как можно больше отладочной информации: фрагменты, тестовые примеры, трассировки исключений, снимки экрана и т. Д. Небольшой хорошо выполненный тестовый пример - лучший способ сообщить об аномалии, поскольку он быстро подтверждает достоверность обнаруженной проблемы.
• Не пишите в Django-разработчики просто сообщить , что вы сделали об ошибке отчет. Все тикеты появляются в другом списке django-updates , за которым следят разработчики и заинтересованные члены сообщества; мы видим их такими, какими они были созданы.

Чтобы понять жизненный цикл заявки после ее создания, см. Сортировка заявок .

Сообщение об ошибках или функциях пользовательского интерфейса ¶

Если проблема или запрос функции относится к визуальному элементу, вот несколько дополнительных рекомендаций, которым необходимо следовать:

• Включите в заявку скриншоты, которые являются визуальным эквивалентом минимального тестового примера. Выделите проблему, а не удивительные настройки, которые вы внесли в свой браузер.
• Если проблему сложно продемонстрировать с помощью неподвижного изображения, рассмотрите возможность записи короткого видеоклипа. Если ваше программное обеспечение позволяет, снимайте только значительную часть экрана.
• Если вы предложили исправление, которое изменяет внешний вид или поведение интерфейса Django, вы должны прикрепить записи до и после. Билеты, в которых нет этих элементов, трудно быстро обработать тем, кто их подает.
• Снимки экрана не заменяют другие передовые методы создания отчетов. Не забудьте включить URL-адреса, фрагменты кода и пошаговые инструкции о том, как воспроизвести поведение, показанное на снимках экрана.
• Обязательно отметьте опцию UI / UX в билете, чтобы наиболее заинтересованные люди могли найти ваш билет.

Запросы функций ¶

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

• Убедитесь, что функция действительно запрашивает изменения в ядре Django. Если ваша идея может быть разработана как приложение или отдельный модуль, например, для добавления поддержки нового механизма базы данных, вам, безусловно, будет предложено разработать его самостоятельно. Затем, если проект получит достаточную поддержку сообщества, его можно будет считать кандидатом на включение в Django.
• Сначала поговорите об этой функции в списке рассылки django-developers , а не в системе тикетов. Аудитория в списке будет больше. Это тем более важно, если спрос на функциональность имеет определенную величину. Разработчики Django любят сначала обсуждать важные изменения в списке рассылки, прежде чем фактически приступить к работе над кодом.
• Ясно и кратко опишите недостающий функционал и то, как вы хотели бы его реализовать. Если возможно, добавьте образец кода (даже нефункционального).
• Объясните, почему вам нужна эта функция. Объяснение минимального варианта использования поможет другим понять, где он подходит, и есть ли уже другие способы достижения того же.

Если есть консенсус относительно функциональности, необходимо создать заявку. Добавьте в описание заявки ссылку на обсуждение django-developers .

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

См. Также Документацию по новым функциям .

Как мы принимаем решения ¶

Насколько это возможно, мы стремимся достичь общего консенсуса. С этой целью часто бывает, что в списке разработчиков django проводятся неофициальные голосования по поводу функции. В этом голосовании мы следуем стилю голосования, инициированному Apache, а также используемому для Python, где голоса даются как +1, +0, -0 или -1. В грубом переводе эти голоса означают:

• +1: «Идея нравится, полностью ее поддерживаю».
• +0: ​​«Звучит нормально».
• -0: «Не убежден, но возражать не собираюсь».
• -1: «Я категорически не согласен и буду огорчен, если идея материализуется».

Хотя голосование за django-developers неофициально, к нему будут относиться очень серьезно. После разумного периода голосования и при достижении четкого консенсуса мы будем следить за голосованием.

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

Внутри технический комитет использует тот же механизм голосования. Предложение считается подтвержденным, если:

• Члены технического комитета набрали не менее трех голосов «+1».
• Члены технического комитета не голосуют «-1».

Голоса должны быть отправлены в течение недели.

Поскольку этот процесс позволяет любому члену технического комитета наложить вето на предложение, голос «-1» должен сопровождаться объяснением того, что необходимо, чтобы превратить этот «-1» в «+». 0 ”по крайней мере.

Голосование по техническим вопросам должно объявляться и проводиться публично в списке рассылки django-developers .