Proceso público RFC de AIO

1) Propósito y alcance

Este documento define el procedimiento público Request For Comment (RFC) de AIO para proponer estándares, especificaciones y cambios de proceso. Cubre los tipos de RFC, las etapas de progreso, convenciones de envío y numeración, licencias, responsabilidades de revisión y prácticas de gobernanza relacionadas.

El proceso RFC pretende crear un registro abierto y auditable de propuestas técnicas y de procedimiento que las partes interesadas del ecosistema puedan revisar e implementar.

2) Tipos de documentos

• Standards Track: especificaciones normativas que definen formatos, comportamientos o APIs (ej.: RBP JSON, BYOR API).
• Informational: guías, contexto, casos de uso o material explicativo.
• Process: propuestas que cambian reglas organizacionales o procedimentales.

3) Progresión de estado

Los RFCs progresan por el siguiente ciclo de vida: Idea → Draft → Candidate (CR) → Final (STD) → Deprecated.

• Draft: comienza el periodo de revisión pública (mínimo 14 días).
• Candidate: verificación de implementación e interoperabilidad; revisión de preparación (mínimo 30 días).
• Final: ratificado tras consenso y las aprobaciones de gobernanza aplicables.
• Deprecated: marcado cuando es sustituido o eliminado del uso recomendado.

4) Numeración y metadatos

• Identificador RFC: AIO-RFC-YYYY-NNN (p. ej., AIO-RFC-2025-001).
• Metadatos requeridos: título, resumen, motivación, especificación, justificación, consideraciones de compatibilidad, consideraciones de seguridad/privacidad, notas de implementación, IPR/licencias, documentos referenciados, registro de cambios y lista de autores.
• Licenciamiento: texto del documento bajo CC BY 4.0; ejemplos de código bajo Apache-2.0 o MIT.

5) Envío y publicación

• Métodos de envío: issue/PR en GitHub o un mecanismo oficial designado por AIO (preferencia por lo público).
• Todos los artefactos (texto, implementaciones de referencia, vectores de prueba) deben publicarse en un repositorio público cuando sea factible para apoyar la revisión y reproducibilidad.

6) Roles de revisión y decisión

• Revisores: expertos temáticos y grupos de trabajo que proveen revisión técnica y verificación de afirmaciones.
• Grupo de Trabajo (WG): responsable de guiar propuestas hasta la etapa de Candidate y de producir guías de implementación.
• Comunidad: canales públicos de discusión e hilos de issues son los espacios principales para la revisión abierta.

7) Duraciones de revisión y revisiones

• Draft: mínimo 14 días de revisión pública.
• Candidate: mínimo 30 días para verificación de implementación (excepciones aprobadas).
• Las revisiones se rastrean con sufijos de revisión (ej.: -rev1, -rev2). Se publican erratas para correcciones menores.

8) IPR y licencias

• Los autores otorgan a AIO el derecho a publicar el texto del documento bajo CC BY 4.0 y cualquier código de referencia bajo Apache-2.0 o MIT, salvo que se especifique lo contrario.
• Se espera que los contribuyentes divulguen cargas de patentes; los compromisos de licencia deben ser explícitos en el RFC.

9) Roles editoriales y stewardship

• Editor en jefe: responsabilidad editorial general y autoridad de publicación para los RFCs.
• Editor RFC: gestiona formato, metadatos y mantiene el índice de RFCs.
• Grupos de trabajo: aportan revisión técnica, suites de prueba e implementaciones de referencia cuando sean necesarias.

10) Cronogramas y gestión de cambios

• Los cronogramas estándar (Draft 14 días, Candidate 30 días) son predeterminados; las excepciones requieren justificación documentada.
• Los cambios significativos se gestionan con versiones y registros de cambios; las correcciones de emergencia pueden manejarse mediante erratas.

11) IPR & divulgación

• Los contribuyentes deben declarar derechos y licencias para el material aportado. Cuando existan derechos de terceros, los contribuyentes deben explicar el estado y permisos.

12) Anexos y envíos de WG

• Los RFCs pueden ser redactados o patrocinados por grupos de trabajo, comités o por contribuyentes individuales. Los WG deben producir artefactos de revisión e implementaciones de referencia cuando corresponda.

13) Revisiones

• Las revisiones se registran en el changelog del documento. Las revisiones mayores deben incluir un resumen de cambios y la motivación.

14) Integración con gobernanza

• Los RFCs que afectan reglas organizativas o estatutos pueden requerir revisión y aprobación por el órgano de gobernanza correspondiente (p. ej., Asamblea General, Junta Directiva).

15) Conflictos de interés y recusación

• Los contribuyentes y revisores deben declarar conflictos de interés. Cuando afecten una decisión, se aplicarán recusaciones u otras mitigaciones.

16) Protección de datos y privacidad

• Cuando los RFCs involucren datos personales, se deben realizar y documentar evaluaciones de impacto de privacidad o DPIAs.

17) Normas de publicación

• Los RFCs se publican de forma abierta; los metadatos y el historial de versiones se conservan para garantizar trazabilidad.

18) Licenciamiento

• Texto del documento: CC BY 4.0.
• Código fuente y artefactos de prueba: Apache-2.0 o MIT.

19) Cumplimiento y ejecución

• El personal de AIO y los grupos de trabajo relevantes son responsables de asegurar prácticas de publicación y archivo.

20) Decisiones de gobernanza

• Las decisiones a nivel de gobernanza (p. ej., adopción como estándar formal) siguen las reglas de votación especificadas en los estatutos y pueden requerir mayorías calificadas.

21) Adopción e implementación

• El grupo de trabajo responsable o la entidad patrocinadora coordina la implementación y el seguimiento; las decisiones importantes deben registrarse y publicarse.

---

_{Final v1.0}