Processus RFC

Un RFC consigne une décision durable au niveau du projet avant sa mise en œuvre. Le processus vise à mettre en évidence les compromis de conception, à donner aux mainteneurs et aux contributeurs la possibilité de faire part de leurs objections en amont, et à conserver une trace consultable du pourquoi de la décision.

La plupart des travaux n’en nécessitent pas. Le critère de déclenchement d’une RFC est volontairement restrictif, afin que les propositions qui nécessitent véritablement une décision à l’échelle du projet ne soient pas retardées par des fonctionnalités courantes.

Le périmètre des RFC, le calendrier des discussions et les règles de ratification ont été définis pour la dernière fois par #9496, acceptée le 2026-08-10 et adoptée en tant que FND-003 Rév. 15. Consultez FND-003 pour le protocole durable.

Quand soumettre une RFC plutôt qu’une simple PR

Soumettez une RFC lorsque la proposition nécessite une décision durable au niveau du projet avant sa mise en œuvre, c’est-à-dire qu’elle relève d’au moins l’un des cas suivants :

une nouvelle couche de sécurité, ou une modification substantielle du modèle de sécurité du projet ;
une modification de la gouvernance, du processus de contribution ou de l’autorité du projet ;
une refactorisation architecturale transversale qui modifie la responsabilité ou les contrats entre des frontières établies ; ou
un nouveau sous-système ou une autre frontière de capacité à l’échelle du projet.

Ne soumettez pas une RFC simplement parce que le travail comprend :

un ajout de fonctionnalité ordinaire ;
une migration de schéma ou de données ;
une modification d’un champ de configuration ou de sa valeur par défaut ; ou
une refactorisation circonscrite de l’implémentation.

Ils passent par une issue et une PR. Un nouveau canal, un nouveau fournisseur, un nouvel outil et une correction de bug relèvent tous du travail ordinaire, quelle que soit l’ampleur du diff. Ils ne nécessitent un RFC que lorsque leur effet substantiel franchit également l’un des quatre déclencheurs ci-dessus.

Le critère repose sur l’impact substantiel sur le projet, et non sur le titre de l’issue, son auteur, le fait que le brouillon ait été assisté par IA, ou la simple présence d’une migration, d’une fonctionnalité ou d’une modification des valeurs par défaut. En cas de doute, ouvrez une issue ordinaire et indiquez pourquoi vous pensez qu’elle pourrait franchir un seuil de déclenchement. Un mainteneur peut la promouvoir ; cela coûte bien moins cher qu’une RFC bloquée.

Les vulnérabilités de sécurité sont signalées en privé conformément à SECURITY.md, jamais sous la forme d’une RFC publique.

Les mainteneurs peuvent renommer ou fermer un RFC soumis pour le traiter comme un ticket ordinaire, une demande de fonctionnalité ou un suivi d’implémentation lorsqu’il ne remplit pas le critère de déclenchement. Cette décision indique si le travail sous-jacent reste pertinent et où il se poursuit ; il s’agit d’une décision d’orientation, et non d’un rejet sur le fond.

Soumettre une RFC

Les RFC sont des Issues GitHub taguées type:rfc. Format du titre :

RFC: <short description of the proposal>

Structure du corps : à adapter à la taille de la proposition :

Problème : quelle douleur utilisateur ou déficience système motive cela ?
Proposal : que proposez-vous de faire ?
Design : les détails ; ébauches de code, structures de schémas, plans de migration
Alternatives envisagées : qu’avez-vous évalué d’autre, et pourquoi pas ?
Non-objectifs : ce que cette proposition ne cherche explicitement pas à résoudre
Risques et mesures d’atténuation : ce qui pourrait mal tourner, et quelle est la stratégie de rollback
Rollout : feature-flagged ? schema-versioned ? fenêtre de breaking change ?

Les RFC soumises suivent une période minimale de discussion sur une proposition publique : 48 heures pour une RFC ordinaire, 72 heures pour une RFC demandant la procédure exceptionnelle à l’unanimité. Tout le monde peut commenter. Les mainteneurs donnent leur avis. L’auteur fait évoluer le corps du document en conséquence.

Les révisions et clarifications ordinaires au cours de la discussion ne remettent pas le délai à zéro. Une révision qui modifie substantiellement la décision proposée établit un nouvel instantané stable, identifié publiquement, et relance la période minimale applicable. Le vote ne s’ouvre qu’une fois la période écoulée et la proposition stabilisée.

Ratification

Le vote se déroule pendant 72 heures sur la base d’un instantané immuable de la proposition, identifié par un artefact ou un commit immuable, ou par une empreinte enregistrée du corps de l’issue accompagnée d’un résumé concis de la décision. Le commentaire d’ouverture du vote consigne l’instantané, l’électorat désigné, le seuil et la raison de son application, ainsi que l’échéance UTC exacte.

Corps électoral. Un contributeur actif de Core est un membre actuel de Core Team qui a exprimé explicitement son vote lors d’un vote RFC officiellement ouvert au cours des 30 jours précédents. Tout membre actuel de Core Team qui ne fait pas partie de cet ensemble peut néanmoins voter ; ce faisant, il rejoint le corps électoral de ce vote et est réactivé pour les votes ultérieurs.

Les bulletins de vote sont APPROVE, REVISE ou REJECT. REVISE refuse l’approbation, mais ne constitue pas un veto. REJECT constitue une objection bloquante et doit être justifié par une raison précise. Votre dernier bulletin de vote avant la date limite remplace le précédent.

Seuil. Par défaut, les deux tiers de l’électorat actif final, arrondis à l’électeur supérieur. Le quorum exige au moins deux bulletins explicites ; le silence ne compte jamais pour le quorum. Une fois le quorum atteint, le silence de l’électorat compte comme APPROVE pour les votes ordinaires. L’unanimité est réservée aux décisions dont le coût ou l’irréversibilité rend une supermajorité insuffisante, comme les changements de licence ou de propriété juridique ; elle exige que chaque électeur désigné vote explicitement APPROVE, et le silence ne peut pas l’établir.

Résultats, appliqués dans cet ordre :

Reportée : moins de deux votes explicites. Le compte rendu de clôture indique quand elle peut être rouverte. Une proposition reportée inchangée peut être soumise à un nouveau vote de 72 heures sans reprendre la discussion.
Rejeté : quorum atteint et tout vote final est REJECT. Problème clôturé avec l’objection bloquante consignée, en établissant un lien vers tout problème où le problème sous-jacent persiste. Cela rejette la proposition, pas nécessairement le problème.
Accepté : quorum atteint, aucun REJECT, et au moins deux tiers approuvent explicitement ou par leur silence. L’issue porte status:accepted, et le compte rendu de clôture répond à chaque point soulevé par REVISE au lieu de l’écarter. Les PR d’implémentation peuvent avancer dès que cette passation est visible.
Renvoyé à la discussion : aucune des options ci-dessus. Les demandes de révision non résolues sont enregistrées.
Retirée : l’auteur la retire. Close sans préjudice.

Un vote ne peut être clos par anticipation que lorsque tous les membres de l’électorat actif final l’ont explicitement approuvé et qu’aucun contributeur Core inactif n’a demandé que la période complète soit respectée. L’enregistrement de clôture doit indiquer la raison de sa clôture anticipée.

Le protocole actuel s’applique aux votes de RFC ouverts après la ratification. Il n’invalide pas automatiquement les RFC acceptées antérieurement ; les travaux d’audit et de correction du processus historique sont suivis séparément.

Implémentation d’un RFC accepté

Les PRs d’implémentation doivent :

Confirmez que le ticket RFC documente sa forme finale approuvée et sa résolution pérenne avant le début de l’implémentation
Référencez le numéro de l’issue RFC (Implements #5574 phase 1)
Respecter le design accepté ; si un détail change pendant l’implémentation, mettre à jour le corps de la RFC ou créer un ticket de clarification de suivi
Déployer derrière un indicateur de fonctionnalité si la RFC prévoit un déploiement progressif
Incluez des chemins de migration pour les utilisateurs affectés par les modifications incompatibles.

Les grandes RFC sont souvent déployées sur plusieurs PR au fil de plusieurs versions. Le commentaire de suivi de la RFC est mis à jour au fur et à mesure que les phases sont intégrées.

Les RFC actuellement ouvertes

Les RFC ouvertes sont la meilleure source primaire pour savoir « ce qui arrive ensuite » dans ZeroClaw. Parcourir :

sh

gh issue list --repo zeroclaw-labs/zeroclaw --label type:rfc --state open

Cette requête est la source de référence. Cette page ne la reproduit délibérément pas sous forme d’instantané, car une liste gérée manuellement devient obsolète plus vite que quiconque ne s’en aperçoit.

RFC fondamentaux ratifiés

Ces éléments influencent tout le reste. Lisez-les avant de proposer des modifications transversales :

#5574 : Transition vers un micronoyau : découpage en crates, taxonomie des feature flags, feuille de route vers la v1.0
#5576 : Normes de documentation et architecture des connaissances
#5577 : Gouvernance du projet : équipe principale, autorité de ce document. Son périmètre RFC et ses seuils de vote sont remplacés par #9496 (FND-003 Rev. 15)
#5579 : Infrastructure d’ingénierie : pipelines CI, automatisation des versions
#5615 : Culture de contribution : normes de co-écriture humain/IA
#5653: Zéro compromis : gestion des erreurs, politique de code mort, seuil de préparation à la publication

RFC rédigés par l’IA

La rédaction de RFC par des assistants IA (avec un parrain humain) est explicitement autorisée selon la RFC #5615. Si une RFC a été rédigée avec l’aide d’une IA :

Indiquez-le clairement dans le corps (“rédigé avec Claude, relu par @maintainer”)
L’humain parrain est responsable de l’exactitude et de la réponse aux commentaires.
Seuls les membres actuels de la Core Team émettent des votes contraignants. Le parrainage d’un RFC rédigé par une IA ne confère pas de droit de vote, et le fait qu’une proposition ait été élaborée avec l’aide d’une IA ne change pas à lui seul si elle remplit les conditions de déclenchement d’un RFC.

Cela a bien fonctionné jusqu’à présent. Traitez les brouillons générés par IA comme des éléments à part entière, mais rappelez-vous que le sponsor reste responsable.

ZeroClaw Docs