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 y las reglas de ratificación de los RFC se definen en FND-003. El protocolo actual fue restringido por #9496, aclarado para las votaciones diferidas por #10288 y simplificado por #10549.

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?

Las RFC presentadas pasan por la preparación de una instantánea y por una discusión, pero no existe un temporizador mínimo obligatorio para la discusión. Cualquiera puede comentar. Los mantenedores dan su opinión. El autor itera sobre el cuerpo en respuesta a los comentarios.

Una votación de Core puede abrirse una vez que la propuesta tenga una versión estable y visible, la persona que abre la votación identifique el desencadenante del RFC y un contribuidor de Core esté dispuesto a someter esa versión a una decisión. Las ediciones del cuerpo antes de una votación no reinician ningún periodo de espera automático; las ediciones del cuerpo después de abrirse una votación detienen la votación actual como un reemplazo sustancial o quedan fuera de la versión votada hasta la siguiente revisión.

Ratificación

A vote cycle normally stays open for 72 horas against an immutable proposal snapshot, identified by an immutable artifact or commit, or by a recorded issue-body digest plus a concise decision summary. The vote-opening comment records the snapshot, the assigned electorate, the threshold and why it applies, that quorum requires two explicit ballots, and the exact UTC deadline. It may not add ad hoc closing conditions outside this protocol.

Wait, I need to correct that: the translation should read “72 horas” only if I preserve the bold correctly. Here is the final translation:

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.

Las papeletas son APPROVE, REVISE o REJECT. APPROVE acepta el snapshot tal como está escrito, opcionalmente con límites de implementación. REVISE detiene el snapshot actual cuando indica el término del contrato o del cuerpo afectado, el cambio concreto en el cuerpo o la decisión necesaria, y por qué la ambigüedad impide la aprobación. REJECT es una objeción bloqueante y requiere un motivo específico. Mientras una votación permanezca abierta, tu último APPROVE o REJECT antes del plazo registrado reemplaza tu voto anterior; un REVISE válido es terminal para ese snapshot.

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:

Devuelto para revisión: un REVISE válido y elegible antes de la fecha límite detiene la instantánea actual. El registro de devolución indica el cambio bloqueante en el cuerpo o la decisión necesaria.
Diferida: la votación no puede cerrarse porque tiene menos de dos votos explícitos, o porque se alcanza el quórum sin ningún voto REVISE o REJECT válido, pero el umbral aplicable o las aprobaciones explícitas requeridas aún no se cumplen. La propuesta puede entrar en otro ciclo de 72 horas sobre la misma instantánea inmutable. El registro de continuación o reapertura indica la instantánea sin cambios, los votos arrastrados, el electorado hasta el momento, el umbral, la condición pendiente y la fecha límite exacta en UTC. Los votos explícitos existentes cuentan para el quórum y el resultado en el nuevo ciclo, y se mantienen vigentes hasta que sean retirados o reemplazados por un voto posterior. Un cambio material en la propuesta crea una nueva instantánea.
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.
Accepted: se alcanza el quórum, no hay ningún REVISE ni REJECT válido y se cumple el umbral aplicable. Por defecto, eso significa que al menos dos tercios aprueban de forma explícita o por silencio; las votaciones excepcionales por unanimidad requieren un APPROVE explícito de cada votante asignado. La incidencia lleva status:accepted, y el registro de cierre o el traspaso de implementación registra los límites de implementación no bloqueantes cuando se hayan planteado. Los PR de implementación pueden avanzar una vez que el traspaso sea visible.
Devuelto a discusión: el cuerpo de la propuesta cambia de forma sustancial, o el autor pide revisarla antes de tomar una decisión. El registro de devolución indica el siguiente objetivo estable de la propuesta o la revisión necesaria.
Retirada: el autor la retira. Cerrada sin perjuicio.

Un REVISE vago que no nombra un bloqueo concreto del cuerpo no detiene la votación ni cuenta para el quórum hasta que se subsane. El iniciador de la votación puede pedir aclaraciones, pero no puede descartar por sí solo un REVISE válido en apariencia; si se cuestiona su validez, otro contribuidor de Core debe acordar que la papeleta es inválida, o la papeleta se mantiene.

La aprobación por silencio solo se evalúa al vencer el plazo de una votación que sigue abierta y no tiene ningún REVISE ni REJECT válido. El silencio nunca anula una instantánea detenida.

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 que se incorpore el PR de documentación que ratifica esa revisión, a menos que Core registre explícitamente un uso anterior en un issue específico. No invalida automáticamente los RFC aceptados anteriormente; el trabajo de auditoría y corrección del proceso histórico se gestiona por separado.

Registros de votos

Use los requisitos de redacción de esta guía como formato canónico para los comentarios de apertura, continuación y cierre de votaciones. No existen plantillas obligatorias independientes para el registro de votos; el formulario de incidencias RFC recoge la propuesta inicial, no el registro de votos. FND-003 rige la validez de las papeletas, los plazos y la precedencia de los resultados.

Un registro de apertura incluye el disparador de la RFC y el motivo por el que la instantánea está lista, junto con los campos de ratificación indicados arriba. Una continuación de instantánea sin cambios enumera las votaciones acumuladas que no han sido retiradas ni reemplazadas y establece un nuevo plazo exacto en UTC; no deja la votación pendiente indefinidamente. Un registro de cierre o de devolución identifica la instantánea, las votaciones elegibles, el resultado y el motivo, y la revisión requerida, los límites de implementación o la continuación. Un REVISE elegible y válido detiene esa instantánea en lugar de convertirse en una preocupación que pueda pasarse por alto en el cierre.

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