Процесс TensorFlow RFC

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

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

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

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

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

  1. Прежде чем отправлять RFC, обсудите свои цели с участниками и сопровождающими проекта и получите раннюю обратную связь. Используйте список рассылки разработчиков соответствующего проекта (developers@tensorflow.org или список соответствующей SIG).

  2. Составьте проект RFC.

    • Ознакомьтесь с критериями проверки дизайна
    • Следуйте шаблону RFC .
    • Назовите свой файл RFC YYYYMMDD-descriptive-name.md , где YYYYMMDD — это дата отправки, а descriptive-name относится к заголовку вашего RFC. (Например, если ваш RFC называется Parallel Widgets API , вы можете использовать имя файла 20180531-parallel-widgets.md .
    • Если у вас есть изображения или другие вспомогательные файлы, создайте каталог формы YYYYMMDD-descriptive-name , в котором будут храниться эти файлы.

    После написания черновика RFC получите отзывы от сопровождающих и участников, прежде чем отправлять его.

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

  3. Привлечь спонсора.

    • Спонсор должен быть сопровождающим проекта.
    • Укажите спонсора в RFC, прежде чем публиковать PR.

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

  4. Отправьте свой RFC в виде запроса на включение в tensorflow/community/rfcs .

    Включите таблицу заголовков и содержимое раздела «Цель» в комментарий вашего запроса на включение, используя Markdown. Пример см. в этом примере RFC . Включите идентификаторы соавторов, рецензентов и спонсоров на GitHub.

    В верхней части PR укажите продолжительность периода комментариев. С момента публикации PR должно пройти не менее двух недель .

  5. Отправьте электронное письмо в список рассылки разработчиков с кратким описанием, ссылкой на PR и запросом на проверку. Следуйте формату предыдущих рассылок, как вы можете видеть на этом примере .

  6. Спонсор запросит проведение заседания комитета по рассмотрению не ранее, чем через две недели после публикации PR RFC. Если обсуждение оживленное, подождите, пока оно не утихнет, прежде чем переходить к рассмотрению. Целью обзорного совещания является решение мелких вопросов; По основным вопросам необходимо заранее достичь консенсуса.

  7. Собрание может одобрить 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 .