1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/mirrors-dpvs

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
CONTRIBUTING.md 13 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
gitlife-traslator Отправлено 30.11.2024 06:21 aae3abb

Вклад в проект

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

В целом, вы можете внести свой вклад в проект тремя способами, как указано ниже.

  • Вносите код в проект, исправление ошибок или новая функция приветствуются.
  • Рассматривайте запросы на включение (pull requests) проекта.
  • Решайте проблемы проекта.

1. Внести код

Как внести код в проект? В целом мы следуем рабочему процессу Git «форк-и-пул» Git workflow. Существуют две основные ветки с бесконечным сроком жизни: master и devel. Рекомендуется следовать приведённому ниже рабочему процессу, если вы хотите отправить патч в проект.

  • S1. Форкните репозиторий на Github.
  • S2. Клонируйте проект в свою локальную среду разработки.
  • S3. Проверьте ветку devel проекта в вашей локальной среде разработки.
  • S4. Зафиксируйте изменения в своей локальной ветке.
  • S5. Отправьте свою работу обратно в форкнутый репозиторий на Github.
  • S6. Отправьте запрос на включение, чтобы мы могли рассмотреть ваши изменения.

ПРИМЕЧАНИЕ: Обязательно объедините последние изменения из «апстрима», прежде чем делать запрос на включение!

2. Рассмотрение запросов на включение Pull Requests

Учитывая сложность некоторых запросов на включение (PR), PR DPVS рассматриваются поэтапно. Чтобы явно продемонстрировать прогресс рассмотрения PR, DPVS Maintainers определили серию меток PR. Все метки PR начинаются с префикса 'pr/'. Существует два типа меток PR: метки этапа и метки статуса. Первые показывают, что нужно сделать на текущем этапе, а вторые показывают статус предыдущих этапов. В зависимости от того, были ли обнаружены проблемы на предыдущих этапах, метки статуса бывают двух типов: метки статуса ok и метки статуса false. В следующей таблице перечислены все метки PR, определённые DPVS.

этап статус /ok статус/false
to-confirm-needs needs-confirmed do-not-need
to-confirm-bug bug-confirmed not-a-bug
to-review-codes codes-reviewed-ok codes-need-change
to-test-codes codes-tested-ok codes-test-failed
to-evaluate-performance performance-ok performance-bad
to-test-compatibility compatibility-ok compatibility-bad
to-accept-or-reject accepted rejected

Разные типы меток окрашены разными цветами. Метка PR описана здесь вкратце.

  • метки этапа: окрашенные оранжевым цветом, что делать для PR.
  • статусные метки:
    • статус-ok метки: окрашенные. Зелёный — статус PR в порядке, и процесс проверки может быть продолжен.
    • Статус «false» помечается метками: окрашено в фиолетовый, обнаружены проблемы, PR требует доработки или должен быть отклонён.

На рисунке ниже показан общий ход проверки PR. ![Техническое обслуживание PR](./pic/техническое обслуживание PR.png)

  • S1. DPVS разработчики присваивают метку этапа (метка оранжевого цвета) PR.
  • S2. Проверяющие просматривают список PR, выбирают те метки с оранжевым цветом и выполняют работу текущего этапа проверки. Отправляют результаты проверки в рамках PR.
  • S3. Разработчики DPVS присваивают статусную метку в соответствии с результатами проверки, то есть метку «ok», если на этом этапе проблем не обнаружено, в противном случае — метку «false».
  • S4. Если требуются последующие этапы проверки, переход к шагу S1, в противном случае PR закрывается.

Следует отметить, что не все шесть этапов обязательны для простых PR. Например, этапы «to-test-codes», «to-evaluate-performance» и «to-test-compatibility» могут быть пропущены, если в них нет очевидной необходимости.

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

Ожидается, что PR будут проверены в течение недели и закрыты (объединены или отклонены) в течение месяца. Сложные PR могут потребовать больше времени для проверки, разработчики должны своевременно обновлять ход проверки и поддерживать связь с участниками кода, если код в PR нуждается в доработке перед принятием.

3. Решение проблем

Мы ценим помощь разработчикам DPVS в решении проблем сообщества DPVS, особенно тех, кто сообщает об ошибках или проблемах. Нет ничего приятнее, чем помогать другим, не так ли? Как и в случае с PR, серия меток проблем определяется разработчиками DPVS и имеет фиксированный префикс «issue/». Аналогично, метки проблем также имеют разные типы.

  • Метка этапа: окрашена в оранжевый, что нужно сделать для решения проблемы.
  • Статусные метки:
    • Метки статуса «ok»: окрашены в зелёный, статус проблемы в порядке.
    • Метка статуса «false»: окрашена в пурпурный, проблема не является проблемой.
Метка этапа Метка статуса/ok Метка статуса/false
воспроизвести воспроизведено не воспроизведено
решить решено

Рисунок ниже показывает ход обработки проблемы DPVS. ![Обслуживание проблемы](./pic/обслуживание проблемы.png)

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

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

Соглашения о кодировании

В основном стиль кодирования должен быть последовательным во всём проекте. Мы рекомендуем использовать стиль кодирования Linux kernel.

ПРИМЕЧАНИЕ: Что касается отступов, мы используем 4-символьные отступы, а не 8-символьные. Это отличается от стиля кодирования Linux kernel.

Награды участникам

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

  • Активных участников следует приглашать в сопровождающие DPVS, им предоставляются широкие права доступа к проекту.
  • IQIYI будет ежегодно готовить для активных участников некоторые золотые членские карты.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/mirrors-dpvs.git
git@api.gitlife.ru:oschina-mirror/mirrors-dpvs.git
oschina-mirror
mirrors-dpvs
mirrors-dpvs
master