Процессы проекта OpenColorIO

Документ описывает важные процессы и процедуры разработки и администрирования, которые соблюдаются в проекте OpenColorIO. Этот документ следует изучить вместе с CONTRIBUTING.md перед предложением или подачей изменений.

• Изменения в основной библиотеке
• Необходимые утверждения

Изменения в основной библиотеке

Этот процесс описывает процедуру проекта OpenColorIO для проектирования, разработки и проверки изменений в основной библиотеке, крупных новых функциях или любых других изменений, которые могут быть восприняты как изменение общего направления проекта. Цель состоит в том, чтобы обсуждения и решения вокруг таких изменений проводились публично и имели прозрачные результаты, ища руководства как от TSC (Технического Комитета по управлению), так и от более широкого сообщества OpenColorIO и заинтересованных сторон.ВАЖНО: Изменения в процессы или управление проектом OpenColorIO имеют последующие эффекты по всему проекту, поэтому они рассматриваются как основные изменения. 1. Все основные изменения начинаются с обсуждения в сообществе, которое может включать неформальные беседы в Slack или на ocio-dev, но в конечном итоге обсуждение проводится на собрании TSC, где достигается консенсус относительно релевантности и подхода к предложению. Собрания TSC являются открытыми, а протоколы собраний публикуются в репозитории OCIO в течение нескольких дней после собрания для постоянного отслеживания решений. 2. После принятия предложения TSC создается задача в GitHub для представления проекта дизайна. Стимулируется период дальнейшего обсуждения сообщества вокруг предложенных изменений, зафиксированный в комментариях к задаче. Продолжающиеся озабоченности могут продолжать высказываться в этой задаче и представляться TSC до и во время разработки. 3. Задачи с предложениями функций добавляются к проекту Разработка функций в GitHub коммиттером для отслеживания статуса всех принятых предложений в одном месте. 4. В процессе разработки работа в разработке может быть опционально представлена для обратной связи. и раннего обзора через черновик запроса на вытягивание. 5. По завершении разработки функции создается запрос на вытягивание для обзора и связывается с соответствующей задачей для обзора. Связывание задачи и запроса на вытягивание приведет к автоматическому закрытию задачи при слиянии запроса на вытягивание, и облегчит отслеживание предложенной функции в Разработка функций. См. CONTRIBUTING.md для обзора требований к подписанию коммитов и руководства по отправке запроса на вытягивание. 6. Запрос на вытягивание слияется после одобрения, как указано в разделе Требуемые одобрения ниже. ЗАМЕЧАНИЕ: Проектирование программного обеспечения часто является итеративным процессом, связанным с разработкой. Хотя требуется предложение по дизайну, понимается, что разработка предложенного функционала может начаться до открытия задачи по дизайну в GitHub. Однако настоятельно рекомендуется предложить дизайн как можно раньше, чтобы уважать время и усилия участников. Это избегает разработки без участия сообщества, что может привести к переработке и значительным изменениям перед одобрением.## Требуемые одобрения

Изменения содержимого репозитория OpenColorIO осуществляются на основе сотрудничества. Любой человек с аккаунтом в GitHub может предложить изменения через pull request, и они будут рассмотрены членами проекта Committers.

Pull requests должны удовлетворять минимальному числу одобрений от Committers до слияния. Вместо жесткого правила для всех PRs, требование основано на сложности и риске предложенных изменений, учитывая время, проведенное на обсуждение PR. Следующие руководства описывают установленные правила проекта для одобрения слияния:

• Все изменения должны получить минимальное количество двух одобрений от Committers, указанных в COMMITTERS.md до слияния. Защита веток GitHub включена для обеспечения минимального количества Committers и статуса Committer. Одобрение Committer отмечается зелёной галочкой в PR. Серая галочка рядом с одобрением означает, что одобритель не учитывается в минимальном количестве одобрений, но такие одобрения приветствуются и поощряются сообществом.

• Мелкие изменения (установка багов, документация, тесты, улучшения) могут быть одобрены любыми двумя Committers (кроме автора).

• Значительные изменения должны получить одобрения от двух Committers, не связанных с автором или его компанией.* Все pull requests, кроме критических аварийных исправлений, должны быть опубликованы минимум на 48 часов до слияния, даже при наличии необходимых одобрений. Это дает всем возможность увидеть изменения в различных часовых поясах и графиках. Если одобрение не происходит в течение двух недель с момента открытия pull request и нет возражений или нерешённых обсуждений относительно функции, Committer, связанный с автором, может её одобрить. В какой-то момент нам нужно предположить, что люди, которые знают и заботятся, следят за pull request и что продолжительный период без возражений действительно является согласием. Уведомление должно быть дано в pull request за 2-4 дня до намеченной даты слияния. Это даёт возможность для рецензентов оставить комментарии или запросить дополнительное время для проверки. Если один или несколько Committer'ов противодействуют предложенному изменению, то изменение не может быть принято, если:* Обсуждения и/или дополнительные изменения приводят к тому, что ни один Committer не возражает против изменений. Предыдущие Committer'ы, которые возражали, не обязательно должны одобрить изменения, но они не должны быть против них.

• Изменение поднимается до TSC, и TSC голосует за одобрение изменений. Это должно происходить только в том случае, если разногласия между Committer'ами не могут быть разрешены через обсуждение.

Committer'ы могут выбрать поднять значительные или спорные модификации до TSC, присвоив метку tsc-review к запросу на слияние или задаче. TSC должна служить окончательным арбитром там, где это необходимо.