Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/flexberry/rfcs

RFCs for changes to Flexberry
https://github.com/flexberry/rfcs

rfc-process

Last synced: about 1 month ago
JSON representation

RFCs for changes to Flexberry

Awesome Lists containing this project

README 

        
# Flexberry RFC



Множество изменений, включая исправления ошибок и текста документации,

могут быть выполнены и проверены через обычный механизм пулл реквестов

на GitHub.



Однако некоторые изменения являются более "существенными" и соответственно

требуют предварительного проектирования и согласования с основной командой 

разработки платформы Flexberry.



Процесс запросов на комментарии (RFC - Request For Comments) обеспечивает

возможность согласованного и контролируемого принятия существенных 

изменений, касающихся платформы Flexberry.



[Список обсуждаемых RFC](https://github.com/Flexberry/rfcs/pulls)



## Когда необходимо использовать RFC

Необходимо использовать процесс RFC в случае желания или необходимости

внести более "существенные" изменения в любые фреймворки, подсистемы,

библиотеки или документацию, входящие в состав платформы Flexberry.



Понятие "существенных" изменений формируется нормами сообщества, но обычно

включает в себя следующее:



   - Изменения в архитектуре фреймворков или подсистем, вохдящих в состав

     платформы.

   - Публикация нового или изменение существующего API.

   - Добавление новых возможностей, механизмов или инструментов.

   - Удаление функционала, вошедшего в опубликованные ранее релизы.

   - Внедрение новых концепций или соглашений, даже если они не влекут за

     собой изменения в исходном коде.



Примеры изменений, которые не требуют RFC:



   - Рефакторинг, переименования и т.п.

   - Добавление или удаление сообщений об ошибках или предупрежденях.

   - Доработки, связанные исключительно с улучшением качественных 

     показателей (вопросы производительности, поддержка различными

     браузерами и т.п.).

   - Изменения, которые никаким образом не могут быть замечены конечными

     пользователями платформы, а только разработчиками.

   

Пулл реквесты в какие-либо репозитории платформы с реализацией новых 

возможностей без предварительного обсуждения через процесс RFC могут быть 

закрыты с просьбой предварительго создания RFC.



## Получение обратной связи перед созданием RFC



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

написанием RFC. **Вы можете создать [обсуждение (issue)] в данном репозитории,

чтобы организовать "высокоуровневое" обсуждение проблемы**. Это может 

помочь сформулировать конкретное проектное решение в рамках RFC, а также

понять необходимость создания 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 становится

активным.



Если Вы заинтересованы реализовать активный RFC, но не знаете, работает ли

кто-то над соответствующим RFC, не стесняйтесь спросить об этом (например,

оставив комментарий в обсуждении (issue), связанным с соответствующим RFC).



## Проверка 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](https://github.com/emberjs/rfcs)**.



[Пример]: https://github.com/emberjs/rfcs/pull/294#issue-288248080

[обсуждение (issue)]: https://github.com/Flexberry/rfcs/issues

[Твиттер]: https://twitter.com/Flexberry

[ВКонтакте]: https://vk.com/flexberry

[Facebook]: https://www.facebook.com/groups/Flexberry/