Отправка сообщений об ошибках¶

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

• Обязательно прочтите FAQ, чтобы узнать, не является ли ваша проблема давно решенной.

• Do ask on django-users or #django first if you’re not sure if what you’re seeing is a bug.

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

• Don’t post to django-developers only to announce that you have filed a bug report. All the tickets are mailed to another list, django-updates, which is tracked by developers and interested community members; we see them as they are filed.

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

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

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

• Include screenshots in your ticket which are the visual equivalent of a minimal testcase. Show off the issue, not the crazy customizations you’ve made to your browser.

• Если проблему сложно продемонстрировать с помощью неподвижного изображения, рассмотрите возможность снять короткий скринкаст. Если ваше программное обеспечение это позволяет, снимите только соответствующую область экрана.

• If you’re offering a patch which 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.

• First request the feature on the django-developers list, not in the ticket tracker. It’ll get read more closely if it’s on the mailing list. This is even more important for large-scale feature requests. We like to discuss any big changes to Django’s core on the mailing list before actually working on them.

• Опишите четко и кратко, какой функции не хватает и как бы вы хотели ее реализовать. Приложите пример кода (код необязательно должен быть на 100% рабочим), если это возможно.

• Объясните, почему вам нужна эта функция. Это поможет другим понять, где она вписывается, и существуют ли уже другие способы достичь того же.

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

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

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

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

Whenever possible, we strive for a rough consensus. To that end, we’ll often have informal votes on django-developers 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 on django-developers 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 towards a consensus fizzles out without a concrete decision, the decision may be deferred to the technical board.

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

• There are at least three «+1» votes from members of the technical board.

• There is no «-1» vote from any member of the technical board.

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

Since this process allows any technical board 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.