Управление

Проектный менеджмент

Проект Davinci управляется с помощью инструмента Project.

План разработки

План разработки управляется в Roadmap. Участники (committers) могут добавлять карточки функций в раздел «To do». Когда функция находится на стадии карточки, это означает, что она всё ещё находится в стадии проектирования и обсуждения. Карточка должна содержать:

• Заголовок с описанием функции;
• Подробные сведения о дизайне и принципах работы функции;
• Список всех подфункций, если они есть.

После завершения проектирования и обсуждения функцию можно преобразовать в задачу (issue) и присвоить соответствующие метки (tags). Если участник планирует разработать эту функцию, он должен переместить задачу в раздел «In progress» и добавить себя в список исполнителей задачи. Необходимо убедиться, что функция была полностью спроектирована и обсуждена перед началом разработки. Задачи, которые не были обсуждены сообществом, не будут объединены.

Список задач по обслуживанию

Список задач по обслуживанию управляется в разделе Maintenance. Участники могут самостоятельно добавлять в раздел «To do» задачи по исправлению ошибок или срочных проблем. Если участник планирует исправить проблему, он должен перенести задачу в раздел «In progress» и добавить себя в список исполнителей.

Для обеспечения эффективности разработки и концентрации на целях рекомендуется, чтобы каждый участник имел не более 2 задач в списке «In progress».

Цикл выпуска версий и процесс

На текущем этапе, при отсутствии особых требований, ежемесячно выпускается версия с незначительными изменениями (minor). Официальные версии не следуют этому правилу.

Перед выпуском версии необходимо убедиться, что:

• Все функции работают нормально;
• Задачи и запросы на изменение (PR), связанные с этой версией, были правильно обработаны.

Процесс обновления журнала изменений и номера версии:

1. Создайте PR для объединения ветки dev-0.3 с master. Все операции по выпуску должны выполняться в ветке master. Обратите внимание! Не используйте squash merge, чтобы избежать потери информации о коммитах!
2. Создайте новую ветку release из master для выполнения операций по выпуску (например, git checkout -b release-beta.7).
3. Добавьте журнал изменений в файл CHANGELOG.md. Используйте функцию сравнения, чтобы найти различия между текущей и предыдущей версиями, и отразите значимые изменения в журнале изменений.
4. Не упоминайте изменения, которые незаметны для пользователей (исправления в документации, небольшие улучшения стиля, рефакторинг кода и т. д.), чтобы сохранить эффективность содержания журнала изменений.
5. Пишите журнал изменений с точки зрения разработчиков, избегая подробного описания исправлений, но описывая проблемы и их влияние на разработчиков.
6. По возможности предоставляйте исходные ссылки на PR. Для PR, отправленных сообществом, добавьте ссылку на автора или ссылку на задачу.
7. Если вы не уверены в цели изменения, проконсультируйтесь с автором.
8. Отправьте PR с изменениями в журнале изменений и попросите других членов комитета провести проверку.
9. После слияния изменений удалите ветку release-x и добавьте тег с номером версии к текущей ветке master.
10. Загрузите пакет выпуска и опубликуйте примечание к выпуску.