Публичный процесс 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) Принятие и внедрение

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

---

_{Final v1.0}