Процесс TensorFlow RFC

Каждая новая функция TensorFlow начинает свою жизнь как запрос на комментарий (RFC).

RFC — это документ, описывающий требование и предлагаемые изменения, которые позволят его решить. В частности, RFC будет:

Быть отформатированным в соответствии с шаблоном RFC .
Отправляться в виде запроса на включение в каталог сообщества/rfcs .
Подлежит обсуждению и обзорному совещанию перед принятием.

Цель запроса комментариев TensorFlow (RFC) — привлечь сообщество TensorFlow к разработке, получая отзывы от заинтересованных сторон и экспертов и широко сообщая об изменениях в дизайне.

Как отправить RFC

Прежде чем отправлять RFC, обсудите свои цели с участниками и сопровождающими проекта и получите раннюю обратную связь. Используйте список рассылки разработчиков соответствующего проекта (developers@tensorflow.org или список соответствующей SIG).
Составьте проект RFC.
- Ознакомьтесь с критериями проверки дизайна
- Следуйте шаблону RFC .
- Назовите свой файл RFC YYYYMMDD-descriptive-name.md , где YYYYMMDD — это дата отправки, а descriptive-name относится к заголовку вашего RFC. (Например, если ваш RFC называется Parallel Widgets API , вы можете использовать имя файла 20180531-parallel-widgets.md .
- Если у вас есть изображения или другие вспомогательные файлы, создайте каталог формы YYYYMMDD-descriptive-name , в котором будут храниться эти файлы.
После написания черновика RFC получите отзывы от сопровождающих и участников, прежде чем отправлять его.
Написание кода реализации не является обязательным требованием, но может помочь в организации дискуссий.
Привлечь спонсора.
- Спонсор должен быть сопровождающим проекта.
- Укажите спонсора в RFC, прежде чем публиковать PR.
Вы можете опубликовать RFC без спонсора, но если в течение месяца после публикации PR не будет спонсора, оно будет закрыто.
Отправьте свой RFC в виде запроса на включение в tensorflow/community/rfcs .
Включите таблицу заголовков и содержимое раздела «Цель» в комментарий вашего запроса на включение, используя Markdown. Пример см. в этом примере RFC . Включите идентификаторы соавторов, рецензентов и спонсоров на GitHub.
В верхней части PR укажите продолжительность периода комментариев. С момента публикации PR должно пройти не менее двух недель .
Отправьте электронное письмо в список рассылки разработчиков с кратким описанием, ссылкой на PR и запросом на проверку. Следуйте формату предыдущих рассылок, как вы можете видеть на этом примере .
Спонсор запросит проведение заседания комитета по рассмотрению не ранее, чем через две недели после публикации PR RFC. Если обсуждение оживленное, подождите, пока оно не утихнет, прежде чем переходить к рассмотрению. Целью обзорного совещания является решение мелких вопросов; По основным вопросам необходимо заранее достичь консенсуса.
Собрание может одобрить RFC, отклонить его или потребовать внесения изменений, прежде чем его можно будет рассмотреть снова. Утвержденные RFC будут объединены в сообщество/rfcs , а запросы на запросы отклоненных RFC будут закрыты.

Участники РФЦ

В процессе RFC участвует множество людей:

Автор RFC — один или несколько членов сообщества, которые пишут RFC и стремятся продвигать его на протяжении всего процесса.
Спонсор RFC — специалист по сопровождению, который спонсирует RFC и будет сопровождать его в процессе проверки RFC.
комитет по рассмотрению — группа сопровождающих, которая обязана рекомендовать принятие RFC.
Любой член сообщества может помочь, предоставив отзыв о том, удовлетворит ли RFC его потребности.

Спонсоры RFC

Спонсор — это специалист по сопровождению проекта, ответственный за обеспечение наилучшего результата процесса RFC. Это включает в себя:

Пропаганда предложенного проекта.
Руководство RFC по соблюдению существующих соглашений по дизайну и стилю.
Руководство комитетом по обзору для достижения продуктивного консенсуса.
Если комитет по рассмотрению запрашивает изменения, убедитесь, что они внесены, и получите последующее одобрение членов комитета.
Если RFC переходит к реализации:
- Обеспечение соответствия предлагаемой реализации проекту.
- Координируйте свои действия с соответствующими сторонами для успешной реализации.

Комитеты по рассмотрению RFC

Комитет по обзору на основе консенсуса решает, утвердить, отклонить или запросить изменения. Они несут ответственность за:

Обеспечение учета существенных вопросов общественного мнения.
Добавление заметок о встречах в качестве комментариев к PR.
Обоснование своих решений.

Состав наблюдательного комитета может меняться в зависимости от конкретного стиля управления и руководства каждого проекта. Что касается основного TensorFlow, комитет будет состоять из участников проекта TensorFlow, обладающих опытом в соответствующей предметной области.

Члены сообщества и процесс RFC

Цель RFC — обеспечить широкое представительство сообщества и его обслуживание новыми изменениями в TensorFlow. Члены сообщества обязаны участвовать в рассмотрении RFC, если они заинтересованы в результате.

Члены сообщества, заинтересованные в RFC, должны:

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

Внедрение новых функций

После одобрения RFC можно начинать реализацию.

Если вы работаете над новым кодом для реализации RFC:

Убедитесь, что вы понимаете функцию и дизайн, утвержденные в RFC. Задавайте вопросы и обсуждайте подход перед началом работы.
Новые функции должны включать новые модульные тесты, проверяющие, что функция работает должным образом. Рекомендуется написать эти тесты перед написанием кода.
Следуйте руководству по стилю кода TensorFlow.
Добавьте или обновите соответствующую документацию по API. Ссылка на RFC в новой документации.
Следуйте всем остальным рекомендациям, изложенным в файле CONTRIBUTING.md в репозитории проекта, в котором вы участвуете.
Запускайте модульные тесты перед отправкой кода.
Работайте со спонсором RFC, чтобы успешно разместить новый код.

Держать высокую планку

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

Первоначальные обсуждения дизайна в соответствующем списке рассылки.
Невозможность привлечь спонсора.
Критические возражения на этапе обратной связи.
Неспособность достичь консенсуса во время рассмотрения проекта.
Проблемы, возникшие во время реализации (например: невозможность достижения обратной совместимости, опасения по поводу обслуживания).

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

Если у вас есть какие-либо вопросы об этом процессе, не стесняйтесь задавать их в списке рассылки разработчиков или сообщать о проблеме в tensorflow/community .