GNOME redacta un proceso RFC para sus grandes decisiones técnicas
14 días de comentarios, partes interesadas nombradas y una merge request: GNOME ha redactado una vía formal para las decisiones que hoy se toman en el chat.
3 min de lectura

GNOME está decidiendo cómo decidir. Sophie Herold, editora de RFC del proyecto, ha redactado un proceso formal para los cambios técnicos importantes, y Phoronix informa de que las partes interesadas ya lo están discutiendo. Hoy una decisión importante puede tomarse en una sala de Matrix y perderse después. El borrador dejaría esas decisiones por escrito, en público y con un plazo.
La propuesta se publicó el 27 de julio de 2026 en el foro Discourse de GNOME. Sigue siendo una propuesta. No se ha adoptado nada.
Cómo funcionaría el proceso
Un RFC aquí es un Request for Comments: una propuesta escrita que se debate en abierto antes de que nadie se comprometa. Rust, Python y Kubernetes usan algo parecido.
El borrador de GNOME tiene cuatro piezas.
| Paso | Qué ocurre |
|---|---|
| Enviar | Un desarrollador abre la propuesta como merge request |
| Identificar | Los editores determinan quiénes son las partes interesadas de esa área |
| Discutir | La propuesta se debate en Discourse |
| Decidir | Se abre un periodo final de comentarios de 14 días y luego editores y partes interesadas valoran |
Cada RFC lleva uno de tres estados: en discusión, activo o aplazado. La palabra «parte interesada» hace un trabajo real en este diseño. Solo la objeción de una parte interesada cuenta como objeción bloqueante. Todo el mundo puede comentar, pero no todo comentario puede detener un cambio.
El borrador se adoptaría aplicándose a sí mismo. Si la respuesta es buena, el proceso sale como RFC-0001. La merge request que lo contiene tiene ahora seis commits.
Por qué GNOME lo quiere ahora
El problema que se plantea es de memoria, no de conflicto. Las decisiones importantes se toman de manera informal, repartidas entre registros de IRC y salas de Matrix. Esos sitios se buscan mal. Un año después, nadie puede decir quién aceptó qué, ni por qué.
La propuesta de Herold cita tres decisiones pasadas como ejemplos de cambios que merecían constancia escrita:
- el nuevo formato de iconos simbólicos en GTK
- el cambio de GdkPixbuf a la biblioteca de imágenes Glycin
- la migración de gtk-doc a gi-docgen para la documentación
Cada una cambió el trabajo de personas que no estaban en la sala donde se decidió. Los desarrolladores de aplicaciones tuvieron que seguir el paso, a menudo sin un documento que explicara el razonamiento.
Emmanuele Bassi, del equipo de plataforma de GNOME, aportó comentarios detallados sobre el diseño. La discusión ha sido de fondo, no hostil.
La objeción que conviene leer
Benjamin Otte cuestionó el alcance. Preguntó si las decisiones técnicas que ya están decididas de antemano necesitan la misma ceremonia que las verdaderas cuestiones de política.
Esa objeción es el núcleo de todo proceso RFC. Los procedimientos escritos capturan las decisiones que necesitan debate. También gravan las que no lo necesitan. Un responsable obligado a escribir un RFC para cambiar un formato de iconos quizá no lo cambie. GNOME aún no lo ha resuelto, y la respuesta actual del borrador es dejar que los editores juzguen qué cambios entran.
La gobernanza del software libre ha estado especialmente visible este año. Debian fijó su postura sobre las contribuciones asistidas por IA mediante una votación formal, mientras que el equipo central de Nixpkgs se disolvió a los diez meses, alegando agotamiento y fricciones con su comité directivo. GNOME intenta construir estructura antes de necesitarla.
Qué significa esto para los desarrolladores
Si publicas una aplicación GNOME, vigila RFC-0001. Su resultado decide si los futuros cambios de plataforma llegan con una justificación escrita que puedas leer, o como un commit que descubres cuando se te rompe la compilación.
Si mantienes una biblioteca de la que GNOME depende, averigua ya si cuentas como parte interesada en tu área. Según este borrador, ese estatus es lo que convierte tu objeción en un bloqueo y no en un comentario.
Si diriges cualquier proyecto con más de un puñado de responsables, la parte trasladable es el argumento de la búsqueda. No necesitas el proceso exacto de GNOME. Necesitas que las decisiones vivan en un lugar donde alguien nuevo pueda encontrarlas dentro de un año, y los registros de chat no lo son.
Y si quieres influir en su forma, la discusión está abierta ahora en Discourse. Una vez adoptado RFC-0001, cambiar el proceso exigirá presentar un RFC sobre el proceso RFC.
Fuentes
- GNOME Stakeholders Discussing RFC Process For Solving Major Technical Changes - Phoronix
- Proposal for an RFC process - GNOME Discourse
- rfcs: add the RFC process - GNOME GitLab
Artículos relacionados

Debian Code Search elimina su última dependencia de cgo
Michael Stapelberg sustituyó una biblioteca en C de 7 años por Go puro usando el paquete SIMD experimental, y alcanzó la velocidad de la versión en C.

Un binario strip manipulado puede colar una puerta trasera en todo NixOS
Unos investigadores han construido el ataque trusting-trust de Ken Thompson con GNU strip, no con un compilador, y han colado puertas traseras en casi todo un instalador de NixOS.

Debian vota permitir contribuciones asistidas por IA, con condiciones
Los desarrolladores de Debian eligieron la opción de uso responsable de la IA generativa en una votación cerrada el 28 de agosto de 2026. La ayuda de la IA se permite y revelarla sigue siendo opcional.