Team/Workflow

Team/Workflow

Эта страница предназначена для новых разработчиков.

Все правила указанные здесь обязательны для выполнения.

Выбор задач (тикетов)

Каждый разработчик может брать любые активные задачи. При выборе задачи строго придерживаться правил:

  • Задача (тикет) не должна иметь отметки о исполнителе в поле owner (т.е. ей сейчас никто не занимается)
  • В первую очередь выполнять задачи типа "баг" и назначенные на ближайшую версию
  • Если открытых багов в ближайшей версии нет - брать задачи типа "улучшение" для ближайшей версии
  • Если в ближайшей версии нет интересных вам задач (или вы не можете выбрать) - брать задачи из дальних версий.

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

  • Заходим в тикет, в нижней форме отмечаем флаг assign и сохраняем. После этого в поле owner тикета должно показываться ваше имя.

С любыми вопросами по выбору и приоритету задач можно обращаться к координаторам:

  • r2 (icq 252015-десять-5)

Внесение изменений в SVN

  • Все изменения можно коммитить только в свой бранч;
  • В файле version_log.txt (в корне сайта) необходимо добавить сообщения о завершенных задачах и их номера (по аналогии)
  • Если для решения задачи потребовалось изменить структуру базы данных, в файле /migrate/index.php должен быть код, выполняющий эти изменения (создание таблиц, добавление полей и т.п.), по аналогии с текущим содержимым этого файла. Каждый запрос в /migrate/index.php должен выполняться только при необходимости. Например, перед созданием таблицы нужно проверять что она уже не существует и т.д. Без этого пользователи получат ошибки из-за несовпадения базы после обновления.
  • Когда version_log.txt и скрипт миграции поправлены - делаем коммит. В комментарии к коммиту обязательно указываем (хотя бы кратко) что изменилось.

Если коммит закрывает тикет (важно):

  • Комментарий к коммиту должен выглядеть так: 
  close #123 - краткое_описание_тикета
  • В коммите должны участвовать только те файлы, которые имеют непосредственное отношение к закрываемому багу. Это важно, т.к. пользователи будут пытаться повторить ваши изменения по диффу между ревизиями. Если в коммите были лишние файлы, то пользователи исправят и их.