Skip to content
Tech AI Wire

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.

Por Tech AI Wire Team

3 min de lectura

XLinkedIn
The GNOME Discourse thread titled Proposal for an RFC process, opened by sophie-h.

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.

PasoQué ocurre
EnviarUn desarrollador abre la propuesta como merge request
IdentificarLos editores determinan quiénes son las partes interesadas de esa área
DiscutirLa propuesta se debate en Discourse
DecidirSe 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

  1. GNOME Stakeholders Discussing RFC Process For Solving Major Technical Changes - Phoronix
  2. Proposal for an RFC process - GNOME Discourse
  3. rfcs: add the RFC process - GNOME GitLab

Artículos relacionados