Сообщать об ошибках и запрашивать функции¶

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

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

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

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

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

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

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

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

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

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

Если есть консенсусное согласие по поводу функции, то целесообразно создать тикет. Включите ссылку на обсуждение в описание тикета.

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

См. также: Документирование новых возможностей.

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

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

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

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

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

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

• Не менее трех голосов «+1» от членов управляющего совета.
• Ни один из членов управляющего совета не имеет права голоса «-1».

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

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

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