Processus RFC public AIO

1) Objet et périmètre

Ce document définit la procédure publique Request For Comment (RFC) d'AIO pour proposer des normes, des spécifications et des changements de processus. Il couvre les types de RFC, les étapes d'avancement, les conventions de soumission et de numérotation, les questions de licence, les responsabilités de revue et les pratiques de gouvernance associées.

Le processus RFC a pour objectif de créer un enregistrement ouvert et auditable des propositions techniques et de procédure que les parties prenantes de l'écosystème peuvent examiner et mettre en œuvre.

2) Types de documents

• Standards Track : spécifications normatives définissant des formats, comportements ou API (exemples : RBP JSON, BYOR API).
• Informational : guides, contexte, cas d'usage ou matériel explicatif.
• Process : propositions modifiant des règles organisationnelles ou procédurales.

3) Progression des statuts

Les RFC progressent selon le cycle de vie suivant : Idea → Draft → Candidate (CR) → Final (STD) → Deprecated.

• Draft : période de revue publique débutant (minimum 14 jours).
• Candidate : vérification d'implémentation et d'interopérabilité ; revue de préparation (minimum 30 jours).
• Final : ratifié après consensus et les approbations de gouvernance applicables.
• Deprecated : marqué lorsqu'il est supplanté ou retiré de l'usage recommandé.

4) Numérotation et métadonnées

• Identifiant RFC : AIO-RFC-YYYY-NNN (ex. : AIO-RFC-2025-001).
• Métadonnées requises : titre, résumé, motivation, spécification, justification, considérations de compatibilité, sécurité/ confidentialité, notes d'implémentation, IPR/licences, documents référencés, journal des modifications, et liste des auteurs.
• Licence : texte du document sous CC BY 4.0 ; exemples de code sous Apache-2.0 ou MIT.

5) Soumission et publication

• Méthodes de soumission : issue/PR GitHub ou mécanisme officiel désigné par AIO (préférence pour le public).
• Tous les artefacts (texte, implémentations de référence, vecteurs de test) doivent, lorsque possible, être publiés dans un dépôt public pour faciliter la revue et la reproductibilité.

6) Rôles de revue et décision

• Relecteurs : experts et groupes de travail fournissent la revue technique et la vérification des affirmations.
• Working Group (WG) : responsable d'accompagner les propositions jusqu'au stade Candidate et de produire des guides d'implémentation.
• Communauté : les canaux de discussion publics et les threads d'issues sont les espaces principaux pour la revue ouverte.

7) Durées de revue et révisions

• Draft : minimum 14 jours de revue publique.
• Candidate : minimum 30 jours pour vérification d'implémentation (des exceptions peuvent être approuvées).
• Les révisions sont suivies par des suffixes de révision (ex. : -rev1, -rev2). Des errata sont publiés pour les corrections mineures.

8) IPR et licences

• Les auteurs accordent à AIO le droit de publier le texte du document sous CC BY 4.0 et tout code de référence sous Apache-2.0 ou MIT, sauf indication contraire.
• Les contributeurs doivent divulguer tout engagement en matière de brevets ; les engagements de licence doivent être explicites dans le RFC.

9) Rôles éditoriaux et stewardship

• Editor-in-Chief : responsabilité éditoriale globale et autorité de publication pour les RFC.
• RFC Editor : gère le formatage, les métadonnées et la maintenance de l'index des RFC.
• Working Groups : fournissent la revue technique, les suites de tests et les implémentations de référence lorsque nécessaire.

10) Calendriers et gestion du changement

• Les calendriers standards (Draft 14 jours, Candidate 30 jours) sont la valeur par défaut ; les exceptions requièrent une justification documentée.
• Les changements significatifs sont gérés par des versions et des journaux de modifications ; les corrections d'urgence peuvent être traitées via des errata.

11) IPR et divulgation

• Les contributeurs doivent déclarer les droits et licences relatifs au matériel apporté. Lorsqu'il existe des droits tiers, les contributeurs doivent expliquer l'état et les autorisations.

12) Annexes et soumissions des WG

• Les RFC peuvent être rédigés ou sponsorisés par des working groups, des comités ou des contributeurs individuels. Les WG doivent produire des artefacts de revue et des implémentations de référence lorsque cela s'applique.

13) Révisions

• Les révisions sont consignées dans le journal des modifications du document. Les révisions majeures doivent inclure un résumé des changements et la motivation.

14) Intégration à la gouvernance

• Les RFC qui affectent les règles organisationnelles ou les statuts peuvent nécessiter l'examen et l'approbation de l'organe de gouvernance compétent (ex. : Assemblée générale, Conseil).

15) Conflit d'intérêt et récusation

• Les contributeurs et relecteurs doivent déclarer les conflits d'intérêts. Lorsque ceux-ci affectent une décision, des récusations ou d'autres mesures d'atténuation seront appliquées.

16) Protection des données et confidentialité

• Lorsque les RFC impliquent des données personnelles, des évaluations d'impact sur la vie privée (DPIA) ou équivalentes doivent être réalisées et documentées.

17) Normes de publication

• Les RFC sont publiés ouvertement ; les métadonnées et l'historique des versions sont conservés pour assurer la traçabilité.

18) Licence

• Texte du document : CC BY 4.0.
• Code source et artefacts de test : Apache-2.0 ou MIT.

19) Application et conformité

• Le personnel AIO et les working groups concernés sont responsables d'assurer le respect des pratiques de publication et d'archivage.

20) Décisions de gouvernance

• Les décisions de niveau gouvernance (par ex. adoption d'un RFC comme standard formel) suivent les règles de vote précisées dans les statuts et peuvent nécessiter des majorités qualifiées.

21) Adoption et mise en œuvre

• Le working group ou l'entité sponsorisante coordonne la mise en œuvre et le suivi de l'adoption ; les décisions majeures doivent être documentées et publiées.

---

_{Final v1.0}