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.

Les règles de portée et de ratification des RFC sont définies par FND-003. Le protocole actuel a été restreint par #9496, clarifié pour les votes différés par #10288 et simplifié par #10549.

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 déposés passent par une phase de préparation d’un instantané puis de discussion, mais il n’existe aucune durée minimale de discussion obligatoire. Chacun peut commenter. Les mainteneurs donnent leur avis. L’auteur itère sur le corps du texte en réponse.

Un vote Core peut être ouvert lorsque la proposition dispose d’un instantané stable et visible, que la personne qui ouvre le vote identifie le déclencheur de la RFC, et qu’un contributeur Core accepte de soumettre cet instantané à une décision. Les modifications du corps de la proposition effectuées avant un vote ne relancent pas de période d’attente automatique. Les modifications effectuées après l’ouverture d’un vote arrêtent soit le vote en cours, en tant que remplacement substantiel, soit restent en dehors de l’instantané soumis au vote jusqu’à la prochaine révision.

Ratification

Un cycle de vote reste normalement ouvert pendant 72 heures sur un instantané immuable de la proposition, identifié par un artefact ou un commit immuable, ou par un condensé enregistré du corps de l’issue accompagné d’un résumé concis de la décision. Le commentaire d’ouverture du vote consigne l’instantané, le corps électoral attribué, le seuil et la raison de son application, le fait que le quorum exige deux bulletins explicites, ainsi que la date limite exacte en UTC. Il ne peut pas ajouter de conditions de clôture ad hoc en dehors de ce protocole.

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 sont APPROVE, REVISE ou REJECT. APPROVE accepte l’instantané tel qu’il est rédigé, éventuellement avec des limites de mise en œuvre. REVISE met fin à l’instantané actuel lorsqu’il nomme le contrat ou le terme du corps concerné, la modification concrète du corps ou la décision nécessaire, et la raison pour laquelle l’ambiguïté empêche l’approbation. REJECT est une objection bloquante et nécessite une raison précise. Tant qu’un vote reste ouvert, votre dernier APPROVE ou REJECT avant la date limite enregistrée remplace votre bulletin précédent ; un REVISE valide est définitif pour cet instantané.

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 :

Retourné en révision : un REVISE éligible et valide avant la date limite arrête l’instantané actuel. L’enregistrement de retour indique la modification du corps ou la décision requise qui bloque.
Reportée : le vote ne peut pas être clos, soit parce qu’il comporte moins de deux bulletins explicites, soit parce que le quorum est atteint sans REVISE ni REJECT valides, mais que le seuil applicable ou les approbations explicites requises ne sont pas encore satisfaits. La proposition peut entrer dans un nouveau cycle de 72 heures portant sur le même instantané immuable. L’enregistrement de la poursuite ou de la réouverture mentionne l’instantané inchangé, les bulletins reportés, l’électorat à ce stade, le seuil, la condition manquante et la date limite exacte en UTC. Les bulletins explicites existants comptent pour le quorum et pour le résultat dans le cycle renouvelé, et sont reportés tant qu’ils ne sont pas retirés ou remplacés par un bulletin ultérieur. Toute modification substantielle de la proposition crée un nouvel instantané.
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.
Accepted : quorum atteint, aucun REVISE ou REJECT valide, et le seuil applicable est satisfait. Par défaut, cela signifie qu’au moins deux tiers approuvent explicitement ou par silence ; les votes exceptionnels à l’unanimité exigent un APPROVE explicite de chaque votant assigné. Le ticket porte status:accepted, et l’enregistrement de clôture ou la transmission à l’implémentation consigne les limites d’implémentation non bloquantes lorsqu’elles ont été soulevées. Les PR d’implémentation peuvent avancer une fois cette transmission visible.
Retourné à la discussion : le corps de la proposition change de manière substantielle, ou l’auteur demande une révision avant une décision. L’enregistrement de retour indique la prochaine cible stable de la proposition ou la révision nécessaire.
Retirée : l’auteur la retire. Close sans préjudice.

Un REVISE vague, qui ne nomme pas un blocage concret pour le corps, n’interrompt pas le vote et ne compte pas pour le quorum tant qu’il n’a pas été corrigé. L’ouvreur du vote peut demander des éclaircissements, mais ne peut pas écarter seul un REVISE en apparence valide ; si la validité est contestée, un autre contributeur Core doit convenir que le bulletin est invalide, sinon le bulletin est maintenu.

Le consentement tacite n’est évalué qu’à l’échéance d’un vote toujours ouvert et qui ne comporte aucun REVISE ni REJECT valide. Le silence ne prévaut jamais sur un instantané arrêté.

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 RFC ouverts après la fusion de la PR de documentation qui ratifie cette révision, sauf si Core consigne explicitement une utilisation antérieure sur un problème spécifique. Il n’invalide pas automatiquement les RFC précédemment acceptées ; le travail d’audit et de correction des processus historiques est suivi séparément.

Enregistrements de votes

Utilisez les exigences de rédaction de ce guide comme format canonique pour les commentaires d’ouverture, de poursuite et de clôture d’un vote. Il n’existe pas de modèles distincts obligatoires pour le registre des votes : le formulaire de ticket RFC collecte la proposition initiale, et non le registre du vote. FND-003 régit la validité des scrutins, les délais et la priorité des résultats.

Un enregistrement d’ouverture comprend le déclencheur de la RFC et les raisons pour lesquelles l’instantané est prêt, ainsi que les champs de ratification ci-dessus. Une poursuite sans modification de l’instantané répertorie les bulletins reportés qui n’ont pas été retirés ni remplacés et fixe une nouvelle échéance UTC exacte ; elle ne laisse pas le vote en attente indéfiniment. Un enregistrement de clôture ou de renvoi identifie l’instantané, les bulletins éligibles, le résultat et sa raison, ainsi que la révision requise, les limites de mise en œuvre ou la poursuite. Un REVISE valide et éligible arrête cet instantané, plutôt que de devenir une réserve à laquelle il faudrait passer outre lors du décompte à la clôture.

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