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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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