Публичный процесс RFC AIO

1) Цель и область

Этот документ определяет публичную процедуру Request For Comment (RFC) AIO для предложения стандартов, спецификаций и изменений процессов. Он охватывает типы RFC, стадии продвижения, соглашения по подаче и нумерации, вопросы лицензирования, обязанности по рецензированию и соответствующие практики управления.

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

2) Типы документов

Standards Track: нормативные спецификации, определяющие форматы, поведение или API (примеры: RBP JSON, BYOR API).
Informational: руководства, фоновые материалы, случаи использования или пояснительные материалы.
Process: предложения по изменению организационных или процедурных правил.

3) Прогресс статусов

RFC проходят следующий жизненный цикл: Idea → Draft → Candidate (CR) → Final (STD) → Deprecated.

Draft: начинается период публичного рассмотрения (минимум 14 дней).
Candidate: проверка реализации и совместимости; обзор готовности (минимум 30 дней).
Final: утверждается после консенсуса и необходимых одобрений органов управления.
Deprecated: помечается при замене или выводе из рекомендованного использования.

4) Нумерация и метаданные

Идентификатор RFC: AIO-RFC-YYYY-NNN (например: AIO-RFC-2025-001).
Обязательные метаданные: заголовок, аннотация, мотивация, спецификация, обоснование, соображения по совместимости, вопросы безопасности/конфиденциальности, примечания по реализации, IPR/лицензирование, ссылочные документы, журнал изменений и список авторов.
Лицензирование: текст документа под CC BY 4.0; примеры кода под Apache-2.0 или MIT.

5) Подача и публикация

Способы подачи: issue/PR на GitHub или официальный механизм подачи, назначенный AIO (предпочтение — публичный).
Все артефакты (текст, эталонные реализации, векторы тестирования) должны по возможности публиковаться в публичном репозитории для облегчения проверки и воспроизводимости.

6) Роли проверки и принятия решений

Рецензенты: эксперты по предметной области и рабочие группы обеспечивают техническую проверку и верификацию утверждений.
Рабочая группа (WG): отвечает за сопровождение предложений до стадии Candidate и за подготовку руководств по реализации.
Сообщество: публичные каналы обсуждения и треды issues являются основными площадками для открытого обзора.

7) Сроки обзора и изменения

Draft: минимум 14 дней публичного обзора.
Candidate: минимум 30 дней для проверки реализации (за исключением утверждённых случаев).
Изменения отслеживаются суффиксами ревизий (например: -rev1, -rev2). Для мелких исправлений публикуются errata.

8) IPR и лицензирование

Авторы предоставляют AIO право публиковать текст документа под CC BY 4.0 и любой эталонный код под Apache-2.0 или MIT, если не указано иное.
От участников ожидается раскрытие патентных ограничений; обязательства по лицензированию должны быть явно указаны в RFC.

9) Редакционные и надзорные роли

Главный редактор (Editor-in-Chief): общая редакционная ответственность и полномочия публикации RFC.
Редактор RFC: отвечает за форматирование, метаданные и ведение индекса RFC.
Рабочие группы: предоставляют техническую экспертизу, наборы тестов и эталонные реализации при необходимости.

10) Графики и управление изменениями

Стандартные сроки (Draft 14 дней, Candidate 30 дней) являются значением по умолчанию; исключения требуют документированного обоснования.
Существенные изменения управляются с помощью версий и журналов изменений; экстренные исправления могут обрабатываться через errata.

11) IPR и раскрытие информации

Участники должны декларировать права и лицензии на предоставленные материалы. Если существуют права третьих лиц, участники должны объяснить статус и предоставленные разрешения.

12) Приложения и подачи WG

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

13) Ревизии

Ревизии фиксируются в журнале изменений документа. Крупные ревизии должны содержать сводку изменений и мотивацию.

14) Интеграция с управлением

RFC, затрагивающие организационные правила или устав, могут требовать проверки и утверждения соответствующим органом управления (например: Общее собрание, Совет).

15) Конфликт интересов и отвод

Участники и рецензенты должны раскрывать конфликты интересов. Когда конфликты влияют на решение, будут применяться отводы или другие меры смягчения.

16) Защита данных и конфиденциальность

Если RFC включает персональные данные, должны быть проведены и задокументированы оценки воздействия на конфиденциальность (DPIA).

17) Нормы публикации

RFC публикуются открыто; метаданные и история версий сохраняются для обеспечения отслеживаемости.

18) Лицензирование

Текст документа: CC BY 4.0.
Исходный код и тестовые артефакты: Apache-2.0 или MIT.

19) Принудительное исполнение и соответствие

Сотрудники AIO и соответствующие рабочие группы несут ответственность за обеспечение соблюдения практик публикации и архивирования.

20) Решения по управлению

Решения на уровне управления (например: принятие RFC в качестве официального стандарта) следуют правилам голосования, указанным в уставе, и могут требовать квалифицированного большинства.

21) Принятие и внедрение

Рабочая группа или спонсорская организация отвечает за координацию внедрения и мониторинга принятия; существенные решения должны быть задокументированы и опубликованы.

<sub>Final v1.0</sub>