RFC-процесс TensorFlow

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

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

Цель запроса комментариев (RFC) TensorFlow - вовлечь сообщество 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 в виде запроса на перенос в tenorflow / community / rfcs .

    Включите таблицу заголовков и содержимое раздела Objective в комментарий вашего запроса на вытягивание с помощью Markdown. Для примера см. Этот пример RFC . Включите GitHub дескрипторы соавторов, рецензентов и спонсоров.

    Вверху PR укажите, как долго будет период комментариев. Это должно быть минимум две недели с момента публикации PR.

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

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

  7. Собрание может утвердить RFC, отклонить его или потребовать внесения изменений перед повторным рассмотрением. Утвержденные RFC будут объединены в community / rfcs , а PR для отклоненных RFC будут закрыты.

Участники 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 в CONTRIBUTING.md проекта, в который вы вносите свой вклад.
  • Перед отправкой кода запустите модульные тесты.
  • Работайте со спонсором RFC, чтобы успешно внедрить новый код.

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

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

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

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

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