Proceso RFC

Un RFC registra una decisión duradera a nivel de proyecto antes de la implementación. El proceso existe para hacer visibles las ventajas y desventajas del diseño, dar a los mantenedores y colaboradores la oportunidad de plantear objeciones desde el principio y dejar un registro consultable de por qué se tomó una decisión.

La mayoría del trabajo no necesita una. El criterio para activar una RFC es deliberadamente restringido, de modo que las propuestas que realmente necesitan una decisión a nivel del proyecto no queden relegadas detrás de funcionalidades ordinarias.

El alcance de los RFC, el calendario de las discusiones y las reglas de ratificación fueron establecidos por última vez mediante #9496, aceptado el 2026-08-10 y adoptado como FND-003 Rev. 15. Consulta FND-003 para conocer el protocolo vigente.

Cuándo presentar una RFC en lugar de simplemente un PR

Presenta un RFC cuando la propuesta requiera una decisión duradera a nivel de proyecto antes de la implementación, es decir, cuando corresponda al menos a uno de los siguientes casos:

una nueva capa de seguridad o un cambio sustancial en el modelo de seguridad del proyecto;
un cambio de gobernanza, del proceso de contribución o de la autoridad del proyecto;
una refactorización arquitectónica transversal que cambia la propiedad o los contratos entre límites establecidos; o
un nuevo subsistema u otro límite de capacidades de todo el proyecto.

No presentes un RFC simplemente porque el trabajo incluya:

una adición de funcionalidad ordinaria;
una migración de esquema o de datos;
un cambio en un campo de configuración o en el valor predeterminado; o
una refactorización acotada de la implementación.

Estos cambios se tramitan mediante una incidencia y una PR. Un canal nuevo, un proveedor nuevo, una herramienta nueva y una corrección de errores se consideran trabajo ordinario, por grande que sea el diff. Solo necesitan un RFC cuando su impacto sustancial también activa uno de los cuatro criterios anteriores.

La prueba se basa en el efecto sustancial en el proyecto, no en el título de la incidencia, el autor, si el borrador contó con asistencia de IA ni en la mera presencia de una migración, una funcionalidad o un cambio de valor predeterminado. Si no estás seguro, abre una incidencia normal y explica por qué crees que podría superar uno de los umbrales. Un mantenedor puede elevarla; eso cuesta mucho menos que una RFC estancada.

Las vulnerabilidades de seguridad se notifican de forma privada según SECURITY.md, nunca como un RFC público.

Los mantenedores pueden cambiar la etiqueta de un RFC presentado o cerrarlo como una incidencia ordinaria, una solicitud de funcionalidad o un seguimiento de implementación cuando no cumpla el criterio de activación. Esa decisión indica si el trabajo subyacente sigue siendo válido y dónde continúa; es una decisión de enrutamiento, no un rechazo por el fondo.

Presentar una RFC

Los RFC son Issues de GitHub etiquetados con type:rfc. Formato del título:

RFC: <short description of the proposal>

Estructura del cuerpo: adáptela al tamaño de la propuesta:

Problema: ¿qué dolor del usuario o deficiencia del sistema lo motiva?
Propuesta: ¿qué propones hacer?
Diseño: los detalles; bocetos de código, formas de esquemas, planes de migración
Alternativas consideradas: ¿qué más evaluaste y por qué no?
No-objetivos: lo que esta propuesta explícitamente no intenta resolver
Riesgos y mitigaciones: qué podría salir mal y cuál es el plan de reversión
Rollout: ¿controlado por feature flags? ¿con versionado de esquema? ¿ventana de cambios incompatibles?

Los RFC presentados pasan por un periodo mínimo de debate sobre una propuesta visible: 48 horas para un RFC ordinario, 72 horas para uno que solicite la vía excepcional de unanimidad. Cualquiera puede comentar. Los mantenedores aportan su opinión. El autor actualiza el contenido en respuesta.

Las revisiones y aclaraciones ordinarias durante el debate no reinician el plazo. Una revisión que cambie sustancialmente la decisión propuesta establece una nueva instantánea estable, identificada públicamente, y reinicia el período mínimo aplicable. La votación se abre únicamente después de que haya transcurrido el período y la propuesta sea estable.

Ratificación

La votación dura 72 horas sobre una instantánea inmutable de la propuesta, identificada mediante un artefacto o commit inmutable, o mediante un resumen registrado del cuerpo de la incidencia junto con un resumen conciso de la decisión. El comentario que abre la votación registra la instantánea, el electorado asignado, el umbral y por qué se aplica, y la fecha límite exacta en UTC.

Electorado. Un colaborador activo de Core es un miembro actual del Core Team que emitió un voto explícito en una votación RFC abierta formalmente durante los 30 días anteriores. Cualquier miembro actual del Core Team que no pertenezca a ese conjunto aún puede votar; al hacerlo, se incorpora al electorado de esa votación y se reactiva para votaciones posteriores.

Los votos son APPROVE, REVISE o REJECT. REVISE retira la aprobación, pero no ejerce veto. REJECT es una objeción bloqueante y necesita un motivo específico. Tu voto más reciente antes de la fecha límite sustituye al anterior.

Umbral. Dos tercios del electorado activo final de forma predeterminada, redondeados al alza hasta un número entero de votantes. El quórum requiere al menos dos votos explícitos; el silencio nunca cuenta para el quórum. Una vez alcanzado el quórum, el silencio del electorado cuenta como APPROVE en las votaciones ordinarias. La unanimidad se reserva para decisiones cuyo coste o irreversibilidad haga insuficiente una mayoría cualificada, como los cambios de licencia o de titularidad legal; requiere un APPROVE explícito de cada votante asignado, y el silencio no puede establecerla.

Resultados, aplicados en este orden:

Aplazada: menos de dos votos explícitos. El registro de cierre indica cuándo puede reabrirse. Una propuesta aplazada que no haya cambiado puede volver a someterse a una nueva votación de 72 horas sin repetir el debate.
Rechazado: se alcanzó el quórum y cualquier votación final es REJECT. Incidencia cerrada con la objeción bloqueante registrada, enlazando cualquier incidencia en la que continúe el problema subyacente. Esto rechaza la propuesta, no necesariamente el problema.
Aceptado: se alcanzó el quórum, no hay REJECT y al menos dos tercios aprueban explícitamente o por silencio. El issue lleva status:accepted, y el registro de cierre aborda todas las observaciones de REVISE en lugar de descartarlas. Los PR de implementación pueden continuar una vez que esa transferencia sea visible.
Devuelto a la discusión: ninguna de las anteriores. Se registran las solicitudes de revisión sin resolver.
Retirada: el autor la retira. Cerrada sin perjuicio.

Una votación solo puede cerrarse antes de tiempo cuando todos los miembros del electorado activo final la hayan aprobado explícitamente y ningún colaborador inactivo de Core haya solicitado la ventana completa. El registro de cierre debe indicar por qué se cerró antes de tiempo.

El protocolo actual se aplica a las votaciones de RFC abiertas después de la ratificación. No invalida automáticamente los RFC aceptados anteriormente; el trabajo de auditoría y corrección del proceso histórico se realiza por separado.

Implementando un RFC aceptado

Los PRs de implementación deben:

Confirma que el registro del problema RFC refleja su forma final aceptada y su disposición duradera antes de que comience la implementación
Referencia el número de la incidencia del RFC (Implements #5574 fase 1)
Ajústate al diseño aceptado; si un detalle cambia durante la implementación, actualiza el cuerpo del RFC o crea un issue de aclaración como seguimiento
Implementa la funcionalidad detrás de una bandera de características si la RFC requiere un despliegue gradual.
Incluye rutas de migración para los usuarios afectados por cambios incompatibles

Los RFC grandes a menudo se entregan a través de múltiples PRs en varias versiones. El comentario de seguimiento del RFC se actualiza a medida que se implementan las fases.

RFCs abiertos actuales

Las RFC abiertas son la mejor fuente primaria para “qué viene después” en ZeroClaw. Explorar:

sh

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

Esa consulta es la fuente canónica. Esta página no refleja deliberadamente una instantánea de ella, porque una lista mantenida manualmente queda obsoleta más rápido de lo que nadie llega a notar.

RFCs fundamentales ratificados

Estos influyen en todo lo demás. Léelos antes de proponer cambios transversales:

#5574: Transición a microkernel: división de crates, taxonomía de feature flags, ruta hacia la v1.0
#5576: Estándares de documentación y arquitectura del conocimiento
#5577: Gobernanza del proyecto: equipo central, autoridad de este documento. Su alcance de RFC y sus umbrales de votación han sido reemplazados por #9496 (FND-003 Rev. 15)
#5579: Infraestructura de ingeniería: pipelines de CI, automatización de versiones
#5615: Cultura de contribución: normas de coautoría humano/IA
#5653: Cero Compromisos: manejo de errores, política de código muerto, listón de preparación para el lanzamiento

RFCs generados por IA

La autoría de RFC por asistentes de IA (con un patrocinador humano) está explícitamente permitida según RFC #5615. Si un RFC fue redactado con ayuda de IA:

Márcalo claramente en el cuerpo (“redactado con Claude, revisado por @maintainer”)
El humano patrocinador es responsable de la precisión y de responder a la revisión.
Solo los miembros actuales del Core Team emiten votos vinculantes. Patrocinar un RFC redactado por IA no otorga autoridad para votar, y un origen asistido por IA no cambia por sí solo si una propuesta cumple el umbral para activar un RFC.

Esto ha funcionado bien hasta ahora. Trata los borradores de IA como elementos de primera clase, pero recuerda que el patrocinador es el responsable.

ZeroClaw Docs