Процесс внесения вклада в GitLab

Цели описания процесса внесения вклада

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

Общие действия

Команда по управлению проблемами

• Ищет задачи без тикетных меток рабочего процесса и сортирует задачи.

• Закрывает недействительные задачи с комментарием (дубликаты, запросы на новые возможности, вопрос решён в более новой версии, сообщение об ошибке для старой версии, это не является проблемой в GitLab и т.д.).

• Запрашивает обратную связь у автора задачи (некорректно-форматированное сообщение об ошибке, форматирование кода и т.д.).

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

• Закрывает задачи без обратной связи от автора за две недели.### Офицеры объединения запросов

• Отвечают на объединённые запросы, упомянутые командой по управлению проблемами, и отслеживают новые объединённые запросы.

• Предоставляют обратную связь отправителю объединённого запроса для улучшения объединённого запроса (стиль, тесты и т.д.).

• Указывают объединённые запросы как "готовые к объединению", когда они соответствуют руководствам по внесению вклада.

• Упоминают разработчика(ов) на основе списка членов команды и их специализаций.

• Закрывают объединённые запросы без обратной связи от отправителя за две недели.

Приоритеты команды по управлению проблемами

1. Упоминание людей (критически важно)
2. Метки рабочего процесса (обычный приоритет)
3. Функциональные метки (низкий приоритет)
4. Назначение задач (избегайте, если возможно)

Упоминание людейСамое важное — обеспечить, чтобы реальные задачи получали обратную связь от команды разработчиков. Поэтому приоритетом является упоминание разработчиков, которые могут помочь в решении этих задач. Пожалуйста, выберите человека с соответствующим опытом из основной команды GitLab. Если нет указанного человека с таким опытом, просмотрите историю коммитов для затронутых файлов, чтобы найти подходящего человека. Избегайте упоминания главного разработчика, это тот человек, который меньше всего склонен дать своевременный ответ. Если требуется участие главного разработчика, остальные члены основной команды укажут этого человека.

Метки рабочего процессаМетки рабочего процесса намеренно не очень детализированы, так как это затрудняет своевременное обновление после каждого комментария. Мы условно используем функциональные метки по мере необходимости, когда хотим группировать связанные проблемы для получения общего представления (например, все проблемы, связанные с RVM, чтобы решить их за один проход) и добавляем подробности к проблеме.

• Ожидание обратной связи: Ожидается ответ от автора проблемы
• Ожидание подтверждения исправления: Проблема должна быть уже решена в ветке master (обычно можно пропустить этот шаг рабочего процесса и сразу закрыть проблему)
• Прикрепленный MR: Прикреплен запрос на слияние (Merge Request), и обсуждение должно происходить там
  • Нам нужно обеспечивать согласованность между проблемами и MR. Это можно сделать с помощью комментария типа "Закрыто #XXXX" или "Исправлено #XXXX". Когда есть запрос на слияние, мы не можем закрывать проблему, так как иногда MR может быть некачественным, и его просто закрывают, тогда проблема должна остаться открытой.
• Ожидание действий/отзыва разработчика: Проблема требует исправления или уточнения со стороны разработчика

Функциональные метки

Эти метки описывают специализацию разработки, такие как: PostgreSQL, UX, LDAP.

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

Цвета меток

• Легкий оранжевый #fef2c0: метки рабочего процесса для членов команды по работе с проблемами (ожидание обратной связи, ожидание подтверждения исправления)
• Яркий оранжевый #eb6420: метки рабочего процесса для членов основной команды (прикрепленный MR, ожидание действий/отзыва разработчика)
• Легкий голубой #82C5FF: функциональные метки
• Зелёные метки #009800: задачи, которые обычно можно игнорировать. Например, задачи, имеющие следующие метки, могут быть немедленно закрыты:
  • Запрос на новую функцию (см. автоматический ответ: Feature Requests)
  • Поддержка (см. автоматический ответ: Support Requests and Configuration Questions)## Будьте доброжелательны

Будьте добры к тем, кто пытается внести свой вклад. Учитывайте, что люди могут быть как носителями английского языка, так и неносителями — они могут не понимать некоторых вещей или быть очень чувствительными к тому, как вы высказываетесь. Используйте эмодзи для выражения своих чувств (сердце, звезда, улыбка и т.д.). Некоторые полезные советы по предоставлению обратной связи для запросов слияния содержатся в руководстве Thoughtbot по проверке кода.

Копирование и вставка ответов### Неправильно отформатированное сообщение об ошибке

Спасибо за ваше сообщение об ошибке. Пожалуйста, переформатируйте ваш запрос, чтобы он соответствовал руководству по оформлению сообщений об ошибках, доступному по ссылке руководство по вкладам.

Запросы на новые функции

Благодарим вас за интерес к улучшению GitLab. Мы не используем систему отслеживания ошибок для запросов на новые функции. В случае, если что-то работает некорректно, но это не является регрессией по сравнению с более ранними версиями GitLab, такой запрос будет считаться запросом на новую функцию, а не сообщением об ошибке. Для этой цели пожалуйста воспользуйтесь форумом запросов на новые функции или создайте pull-request, реализующий эту функцию. Подробнее ознакомьтесь с руководством по вкладам \вкладам.

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

Спасибо за ваш интерес к GitLab. Мы не используем систему отслеживания ошибок для запросов поддержки и вопросов конфигурации. Пожалуйста, воспользуйтесь форумом поддержки, разделом Stack Overflow GitLab или IRC каналом #gitlab на сервере Freenode. Для получения платной поддержки перейдите по адресу http://www.gitlab.com. Подробнее ознакомьтесь с руководством по вкладам \вкладам.

Форматирование кода

Пожалуйста, используйте ``` для форматирования вывода консоли, логов и кода, поскольку очень сложно читать его без этого форматирования.### Ошибка была исправлена в более новой версии

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

Некорректно оформленный запрос на слияниеБлагодарим вас за интерес к улучшению кодовой базы GitLab! Обновите ваш запрос на слияние в соответствии с [правилами взаимодействия](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#pull-request-guidelines\).

Закрытие запроса по причине отсутствия активности

Прошло уже более двух недель (и вышел новый релиз) с момента последнего вашего сообщения. Я закрываю этот запрос, но если проблема все еще актуальна, пожалуйста, откройте новый запрос (не забудьте указать ссылку на старый запрос). Убедитесь, что вы также предоставили необходимую отладочную информацию согласно правилам работы с трекером ошибок, приведенным в наших [правилах взаимодействия](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#issue-tracker-guidelines\).

Закрытие запроса на слияние по причине отсутствия активности

Этот запрос на слияние был закрыт потому, что ответ на запрос информации не был дан более чем за две недели. Если вы ответите и будете следовать правилам оформления запросов на слияние в наших [правилах взаимодействия](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#pull-requests\), мы восстановим этот запрос на слияние.

Принятие запросов на слияниеЕсть ли аналогичный запрос на форуме запросов на новые возможности?

Если да, сделайте комментарий со ссылкой на него. Пожалуйста, имейте в виду, что новая функциональность, которая не помечена как приемлемая для слияния/выполнения запросов на форуме, может не войти в GitLab. Вы можете быть попрошены сделать изменения, а после реализации этих изменений ваша возможность все равно может быть отклонена. Чтобы снизить вероятность этого, рекомендуется обсудить вопрос на форуме заранее.