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

Сообщение об ошибках ¶

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

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

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

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

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

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

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

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

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

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

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

См. Также: Документирование новых функций .

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

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

• +1: «Мне нравится эта идея, и я твердо ей привержен».
• +0: ​​«Мне кажется, все в порядке».
• -0: «Я не в восторге, но не стану мешать».
• -1: «Я категорически не согласен и был бы очень недоволен, если бы идея воплотилась в реальность».

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

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

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

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

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

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

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