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

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

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

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

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

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

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

• Include screenshots in your ticket which are the visual equivalent of a minimal test case. Show off the issue, not the crazy customizations you’ve made to your browser.
• Если проблему сложно продемонстрировать с помощью неподвижного изображения, подумайте о том, чтобы сделать краткий снимок экрана. Если ваше программное обеспечение позволяет это сделать, захватите только соответствующую область экрана.
• If you’re offering a patch that changes the look or behavior of Django’s UI, you must attach before and after screenshots/screencasts. Tickets lacking these are difficult for triagers to assess quickly.
• Скриншоты не освобождают вас от других хороших методов отчетности. Обязательно укажите URL-адреса, фрагменты кода и пошаговые инструкции по воспроизведению поведения, видимого на скриншотах.
• Обязательно установите флаг UI/UX на билете, чтобы заинтересованные лица могли найти ваш билет.

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

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

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

If there’s a consensus agreement on the feature, then it’s appropriate to create a ticket. Include a link to the discussion on django-developers in the ticket description.

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

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

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

Whenever possible, we strive for a rough consensus. To that end, we’ll often have informal votes on django-developers or the Django Forum about a feature. In these votes we follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

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

Although these votes are informal, they’ll be taken very seriously. After a suitable voting period, if an obvious consensus arises we’ll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion toward a consensus fizzles out without a concrete decision, the decision may be deferred to the steering council.

Internally, the steering council will use the same voting mechanism. A proposition will be considered carried if:

• There are at least three «+1» votes from members of the steering council.
• There is no «-1» vote from any member of the steering council.

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

Since this process allows any steering council member to veto a proposal, a «-1» vote should be accompanied by an explanation of what it would take to convert that «-1» into at least a «+0».

Votes on technical matters should be announced and held in public on the django-developers mailing list or on the Django Forum.