Множество изменений, включая исправления ошибок и текста документации, могут быть выполнены и проверены через обычный механизм пулл реквестов на GitHub.
Однако некоторые изменения являются более "существенными" и соответственно требуют предварительного проектирования и согласования с основной командой разработки платформы Flexberry.
Процесс запросов на комментарии (RFC - Request For Comments) обеспечивает возможность согласованного и контролируемого принятия существенных изменений, касающихся платформы Flexberry.
Необходимо использовать процесс RFC в случае желания или необходимости внести более "существенные" изменения в любые фреймворки, подсистемы, библиотеки или документацию, входящие в состав платформы Flexberry.
Понятие "существенных" изменений формируется нормами сообщества, но обычно включает в себя следующее:
- Изменения в архитектуре фреймворков или подсистем, вохдящих в состав платформы.
- Публикация нового или изменение существующего API.
- Добавление новых возможностей, механизмов или инструментов.
- Удаление функционала, вошедшего в опубликованные ранее релизы.
- Внедрение новых концепций или соглашений, даже если они не влекут за собой изменения в исходном коде.
Примеры изменений, которые не требуют RFC:
- Рефакторинг, переименования и т.п.
- Добавление или удаление сообщений об ошибках или предупрежденях.
- Доработки, связанные исключительно с улучшением качественных показателей (вопросы производительности, поддержка различными браузерами и т.п.).
- Изменения, которые никаким образом не могут быть замечены конечными пользователями платформы, а только разработчиками.
Пулл реквесты в какие-либо репозитории платформы с реализацией новых возможностей без предварительного обсуждения через процесс RFC могут быть закрыты с просьбой предварительго создания RFC.
Часто полезно получить обратную связь перед детальным проектированием и написанием RFC. Вы можете создать обсуждение (issue) в данном репозитории, чтобы организовать "высокоуровневое" обсуждение проблемы. Это может помочь сформулировать конкретное проектное решение в рамках RFC, а также понять необходимость создания RFC.
Кроме того, по некоторым вопросам у основной команды разработки платформы могут иметься принципиальные соображения, которые изначально могут быть неочевидны для тех, кто хочет добавить в платформу новые возмжности или изменить существующие.
Перед добавлением новых возможностей или "существенных" изменений, касающихся платформы Flexberry, необходимо, чтобы в данном репозитории был добавлен соответствующий RFC в виде файла с использванием markdown-разметки. После добавления RFC в данный репозиторий он становится "активным" и может быть реализован, что означает включение соответствующего функционала в те или иные части платформы.
- Сделайте форк репозитория https://github.com/Flexberry/rfcs.
- Скопируйте файл
0000-template.mdвtext/0000-my-feature.md(где 'my-feature' требуется заменить на описание соответствующего функционала (на английском языке); номер RFC присваивать на данном шаге не нужно). - Заполните RFC. В тексте должно быть достаточно деталей: RFC, в которых отсутствует достаточное обоснование, демонстрация понимания влияния на архитектуру соответствующих частей платформы или достаточное описание недостатков и альтернатив для предложенного решения, с большой вероятностью не будут приняты.
- Создайте пулл реквест. В первом комментарии к пулл реквесту необходимо написать слово "Выполнено" (или "Rendered") со ссылкой на RFC в Вашем репозитории (в форке данного репозитория) (Пример). После создания пулл реквеста RFC получит обратную связь от основной команды разработки платформы и от всего сообщества в комментариях к пулл реквесту. Автор должен быть готов аргументированно отвечать на различные вопросы из комментариев.
- С учетом высказанных замечаний при необходимости исправьте текст RFC в дополнительных коммитах. RFC, которые получили широкую поддержку в виде множества лайков и комментариев, с большей вероятностью будут приняты.
- В конце концов основная команда разработки платформы примет решение о том, что проектное решение из RFC может быть включено в платформу, либо аргументированно отклонит предложенное решение.
- Для RFC, которые являются кандидатами для включения в платформу, инициируется в финальный период, который длится 7 дней. Начало этого периода отмечается в виде соответствующего комментария и метки в пулл реквесте RFC. Кроме того, в официальном аккаунте платформы Flexberry на Твиттер, а также в официальных группах платформы ВКонтакте и Facebook, появится пост о соответствующием RFC для привлечения внимания сообщества.
- RFC может быть изменен на основе обратной связи от основной команды разработки платформы или от сообщества. Исправление существенных замечаний может инициировать новый финальный период RFC.
- RFC может быть отклонен основной командой разработки платформы на основании результатов публичного обсуждения, если по результатам обсуждения будет выявлено соответствующее обоснование для отклонения. В этом случае один из членов основной команды разработки платформы закрывает соответствующий пулл реквест.
- RFC принимается по завершении финального периода. Основная команда разработки платформы в этом случае выполняет мердж пулл реквеста вместе с указанием фактического номера пулл-реквеста в тексте RFC и в названии соответствующего markdown-файла. После этого RFC становится "активным".
Когда RFC становится активным, авторы могут выполнить соответствующую реализацию заявленного в RFC функционала или исправлений, создав необходимый пулл реквест в соответствующий репозиторий с исходным кодом нужной части платформы. Активный статус RFC еще не означает, что соответствующие правки в конечном итоге будут обязательно включены в исходный код платформы. Это лишь означает, что основная команда разработки платформы согласилась с RFC в принципе и согласна включить соответствующие правки в исходный код.
Кроме того, активный статус RFC ничего не говорит о приоритете его реализации. Также этот статус не говорит о том, что кто-то вообще работает над реализацией соответствующего функционала RFC.
Модификация активных RFC может быть выполнена при помощи последующих пулл реквестов. Мы стремимся к тому, чтобы каждый RFC отражал конечное проектное решение; но природа процесса разработки платформы такова, что мы не можем во всех случаях ожидать полного соответствия описанного в RFC проектного решения и конечного результата на уровне исходного кода. Более того, мы стараемся поддерживать соответствие каждого документа RFC и функицонала, который должен быть реализован согласно имеющемуся плану развития платформы. Соответствующие изменения текста документа RFC выполняются в последующих пулл реквестах в данный репозиторий.
Автор RFC не обязан выполнять реализацию заявленных в RFC функционала и изменений. Безусловно, автор RFC (как и любой другой разработчик) может предложить реализацию заявленного в RFC функционала в виде соответствующего пулл реквеста в нужные репозитории платформы, после того как RFC становится активным.
Если Вы заинтересованы реализовать активный RFC, но не знаете, работает ли кто-то над соответствующим RFC, не стесняйтесь спросить об этом (например, оставив комментарий в обсуждении (issue), связанным с соответствующим RFC).
Каждую неделю основная команда разработки старается проверить некоторые из открытых пулл реквестов с RFC.
О каждом принятом (перешедшим в статус активного) RFC основная команда разработки сообщает в официальных аккаунтах и группах в социальных сетях. По каждому активному RFC назначается ответственный из основной команды разработки платформы, который будет отслеживать и курировать выполнение соответствующего RFC. Назначение ответственного отражается в комментариях к соответствующему пулл реквесту с RFC.
- Примеры пулл реквестов с RFC: https://github.com/emberjs/rfcs/pulls
- Примеры предварительных обсуждений (issues) перед созданием RFC: https://github.com/emberjs/rfcs/issues
- Примеры текстов RFC: https://github.com/emberjs/rfcs/tree/master/text
Создание процесса RFC платформы Flexberry вдохновлено процессом RFC фреймворка Ember.js.