Код и управление проектами¶

Поднятие вопроса¶

За исключением вопросов безопасности, конечно, вы можете поднимать вопросы любым удобным для вас способом - using Discourse, or the Slack group или лично, если вы случайно встретите другого разработчика django CMS.

Однако очень полезно, если вы не просто поднимаете проблему, упоминая о ней людям, но и действительно подаете ее, а это означает создание new issue on GitHub.

Создание хорошего отчета о выпуске - это целое искусство.

Заголовок Title должен быть кратким и информативным. «show_sub_menu отображает неправильные узлы при использовании с soft_root» полезно, в то время как «Меню сломано» - нет.

В Описании вашего отчета мы хотели бы видеть:

• как воспроизвести проблему

• что вы ожидали, что произойдет

• что произошло (часто полезен трассировочный откат, если вы его получили)

Получение одобрения вашего выпуска¶

Другие разработчики django CMS увидят ваш вопрос и смогут прокомментировать его. Разработчик ядра может добавить дополнительные комментарии, или label.

На этом этапе важно, чтобы ваша проблема была принята. Это означает, что мы согласились с тем, что это действительно проблема, и она представляет собой что-то, что мы можем или готовы сделать в CMS.

Вас могут попросить предоставить дополнительную информацию, прежде чем вопрос будет принят, и, возможно, состоится обсуждение. Она также может быть отклонена как non-issue (на самом деле это не проблема) или won’t fix (решение вашего вопроса выходит за рамки проекта или несовместимо с другими нашими целями).

Не стесняйтесь объяснить, почему вы считаете решение об отклонении вашего вопроса неверным - очень немногие решения являются окончательными, и мы всегда рады исправить наши ошибки.

Правила системы обработки билетов django CMS¶

• один и только один статус должен быть применен к каждому билету

• здоровый билет (синий) **не может иметь ни одного critical needs (красный)

• при закрытии билеты должны иметь либо здоровый (синий), либо мертвый (черный) статус

• билет с меткой critical needs не должен иметь меток non-critical needs или miscellaneous other

• Метки has patch и on hold подразумевают связанный запрос на притяжение, который **должен быть связан, когда эти метки применяются

• компонент, метки non-critical need и miscellaneous other должны применяться по мере необходимости

Статус¶

Первое, что мы делаем, это решаем, принимаем ли мы билет, будь то запрос на исправление или проблема. Принятый статус означает, что билет здоров и будет иметь синюю метку.

В принципе, хорошо, когда открытые билеты здоровые (синие), потому что это означает, что они куда-то идут.

Желательно, чтобы билет был либо принят (синий цвет), либо отклонен (черный цвет), либо отмечен как критически важный (красный цвет) как можно скорее. Важно, чтобы у открытых тикетов был четкий статус, не в последнюю очередь для того, чтобы человек, подавший тикет, знал, что его оценивают.

Не следует позволять тикетам с критическими (красными) потребностями затягиваться на неопределенное время. Если мнения или информация, необходимые для принятия билета, не поступают, билет должен быть объявлен нездоровым (серым) с marked for rejection и отклонен (черным) в следующем релизе.

Требуется¶

Критические потребности (красный цвет) влияют на статус.

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

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

Виды и компоненты¶

Разумеется, это несколько непостоянные категории. Например, не всегда абсолютно ясно, представляет ли запрос на исправление или улучшение, а тикеты могут относиться к нескольким частям CMS - так что делайте с ними все, что можете.

Другие метки¶

Метки backport, blocker, has patch или easy pickings должны быть нанесены, в зависимости от ситуации, только на здоровые (синие) билеты.

Комментарии¶

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

Статусы¶

Статус билета - это его положение в конвейере - его точка в нашем рабочем процессе.

У каждого вопроса должен быть статус, и он должен быть присвоен как можно скорее. Каждый вопрос должен иметь только один статус.

Многие из этих статусов одинаково хорошо применимы как к проблемам, так и к запросам, но некоторые имеют смысл только для одного или другого:

принято¶

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

не вопрос¶

Проблема или запрос на исправление в какой-то мере ошибочны - «проблема» на самом деле является правильным и ожидаемым поведением, или проблемы были вызваны (например, неправильной конфигурацией).

При применении этой метки необходимо дать пояснение в комментарии.

не исправит¶

Проблема или запрос на вытягивание подразумевают изменения в дизайне или поведении django CMS, которые основная команда считает несовместимыми с выбранным нами подходом.

При применении этой метки необходимо дать пояснение в комментарии.

помеченный для отказа¶

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

При применении этой метки необходимо дать пояснение в комментарии.

незавершённая работа¶

(только запросы на исправление) Работа продолжается.

Автор заявки должен включить «(work in progress)» в ее заголовок и удалить его, когда посчитает, что она готова к окончательному рассмотрению.

готово к рассмотрению¶

(только для запросов на объединение) Запрос на объединение должен быть рассмотрен. (Любой может просмотреть его и сделать комментарии, рекомендующие объединить его (или вообще предпринять какие-либо дальнейшие действия), но только сопровождающий ядра может изменить метку).

готовы к объединению¶

(только для запросов на слияние) Запрос на слияние успешно прошёл проверку. Сопровождающие ядра не должны помечать свой собственный код, за исключением самых простых случаев, как готовый к слиянию, также они не должны помечать какой-либо код как готовый к слиянию и затем сами сливать его - в процессе должен участвовать другой человек.

Когда запрос на исправление будет объединен, метка должна быть удалена.

Требуется¶

Если в проблеме или запросе не хватает чего-то, что должно быть предоставлено для дальнейшего продвижения, это должно быть отмечено меткой «needs». Пометка «needs» указывает на действие, которое необходимо предпринять, чтобы повысить статус элемента.

Другое¶

имеет заплату¶

(только для проблем) Существует исправление, предназначенное для решения проблемы. Это не означает, что патч будет принят, и даже не означает, что он содержит жизнеспособное решение.

Когда применяется эта метка, комментарий должен содержать перекрестную ссылку на запрос(ы), содержащий(ие) исправление.

лёгкая добыча¶

Проблема, которую легко исправить, или запрос на исправление - новичкам в разработке django CMS рекомендуется заниматься легкодоступными тикетами.

блокиратор¶

Мы не можем выпустить следующий релиз, не решив эту проблему.

backport¶

Любое исправление должно быть перенесено в предыдущий выпуск, потому что оно имеет последствия для безопасности или улучшает документацию.

в режиме ожидания¶

(только для заявок на вытягивание) Заявка на вытягивание должна подождать, пока не появится более приоритетная заявка на вытягивание, чтобы избежать сложного слияния или дополнительной работы в дальнейшем. Любой отложенный запрос на вытягивание по определению work in progress.

Когда применяется эта метка, комментарий должен содержать перекрестную ссылку на другой запрос (запросы).