GNOME redige um processo de RFC para grandes decisões técnicas

O GNOME está a decidir como decide. Sophie Herold, editora de RFC do projeto, redigiu um processo formal para mudanças técnicas importantes, e a Phoronix relata que as partes interessadas já o estão a discutir. Hoje uma decisão grande pode ser tomada numa sala do Matrix e depois perder-se. O rascunho colocaria essas decisões por escrito, em público e com prazo.

A proposta foi publicada a 27 de julho de 2026 no fórum Discourse do GNOME. Continua a ser uma proposta. Nada foi adotado.

Como o processo funcionaria

Um RFC aqui é um Request for Comments: uma proposta escrita que se discute em público antes de alguém se comprometer. Rust, Python e Kubernetes usam algo semelhante.

O rascunho do GNOME tem quatro partes.

Passo	O que acontece
Submeter	Um programador abre a proposta como merge request
Identificar	Os editores determinam as partes interessadas daquela área
Discutir	A proposta é debatida no Discourse
Decidir	Corre um período final de comentários de 14 dias e depois editores e partes interessadas avaliam

Cada RFC tem um de três estados: em discussão, ativo ou adiado. A palavra "parte interessada" tem peso real neste desenho. Só a objeção de uma parte interessada conta como objeção bloqueadora. Todos podem comentar, mas nem todo o comentário consegue travar uma mudança.

O rascunho seria adotado aplicando-se a si próprio. Se a reação for boa, o processo sai como RFC-0001. O merge request que o contém tem atualmente seis commits.

Porque é que o GNOME quer isto agora

O problema apontado é de memória, não de conflito. As decisões importantes são tomadas de forma informal, espalhadas por registos de IRC e salas do Matrix. Esses sítios são difíceis de pesquisar. Um ano depois, ninguém consegue dizer quem concordou com o quê, nem porquê.

A proposta de Herold cita três decisões passadas como exemplos de mudanças que mereciam registo escrito:

• o novo formato de ícones simbólicos no GTK
• a passagem de GdkPixbuf para a biblioteca de imagens Glycin
• a migração de gtk-doc para gi-docgen na documentação

Cada uma mudou o trabalho de pessoas fora da sala onde foi decidida. Os programadores de aplicações tiveram de acompanhar, muitas vezes sem um documento a explicar o raciocínio.

Emmanuele Bassi, da equipa de plataforma do GNOME, deu contributos detalhados sobre o desenho. A discussão tem sido de substância e não hostil.

A objeção que vale a pena ler

Benjamin Otte contestou o âmbito. Perguntou se decisões técnicas que já estão de antemão tomadas precisam da mesma cerimónia que verdadeiras questões de política.

Essa objeção é o cerne de qualquer processo de RFC. Procedimentos escritos apanham as decisões que precisam de debate. Também sobrecarregam as que não precisam. Um maintainer obrigado a escrever um RFC para mudar um formato de ícones talvez simplesmente não o mude. O GNOME ainda não resolveu isto, e a resposta atual do rascunho é deixar os editores julgar que mudanças se qualificam.

A governação do software livre esteve invulgarmente visível este ano. O Debian fixou a sua posição sobre contribuições assistidas por IA através de uma votação formal, enquanto a equipa central do Nixpkgs se dissolveu ao fim de dez meses, invocando esgotamento e atritos com o seu comité diretivo. O GNOME está a tentar construir estrutura antes de precisar dela.

O que isto significa para programadores

Se distribui uma aplicação GNOME, siga o RFC-0001. O seu desfecho decide se as futuras mudanças da plataforma chegam com uma justificação escrita que pode ler, ou como um commit que descobre quando a sua build parte.

Se mantém uma biblioteca da qual o GNOME depende, apure já se conta como parte interessada na sua área. Segundo este rascunho, é esse estatuto que transforma a sua objeção num bloqueio em vez de um comentário.

Se gere um projeto com mais do que um punhado de maintainers, a parte transferível é o argumento da pesquisa. Não precisa do processo exato do GNOME. Precisa que as decisões fiquem num sítio onde alguém novo as encontre daqui a um ano, e os registos de chat não são esse sítio.

E se quiser influenciar o formato, a discussão está aberta no Discourse agora. Assim que o RFC-0001 for adotado, mudar o processo implicará submeter um RFC sobre o processo de RFC.