FERRAMENTAS LINUX: O GNOME Adota o Processo RFC: O Que Muda para os Desenvolvedores e Usuários?

O GNOME adota um processo formal de RFC para as decisões técnicas. Entenda como funciona, quem participa, exemplos práticos e o impacto para os desenvolvedores e usuários do Linux.

O GNOME, um dos ambientes desktop mais populares do mundo Linux, está passando por uma transformação significativa em sua governança técnica. Em 5 de setembro de 2026, a comunidade anunciou a discussão de um novo processo formal de Request for Comments (RFC) para lidar com mudanças técnicas de grande impacto.

Mas o que exatamente isso significa? E por que isso importa para você, seja você um desenvolvedor, um entusiasta ou apenas um usuário do GNOME ? Vamos explorar tudo o que você precisa saber sobre essa novidade.

O que é o novo processo de RFC do GNOME ?

RFC significa Request for Comments — uma prática consagrada no desenvolvimento de software e na internet. Em essência, é um processo formal para propor, discutir e decidir sobre mudanças significativas em um projeto.

No contexto do GNOME, o novo processo de RFC foi proposto por Sophie Herold e está sendo discutido ativamente pela comunidade. Ele substituirá o método informal e ad-hoc que os desenvolvedores usavam até agora para tomar decisões sobre mudanças técnicas importantes.

O processo está documentado em um merge request no GitLab e está sendo debatido no GNOME Discourse.

Por que o GNOME está adotando um processo formal de RFC ?

A resposta é simples: escalabilidade e clareza. O GNOME cresceu imensamente ao longo dos anos.

O que funcionava para um projeto menor — decisões tomadas em conversas de corredor ou em listas de e-mail dispersas — já não é suficiente para um ecossistema com dezenas de equipes, centenas de colaboradores e milhões de usuários.

O processo informal existente gerava problemas como:

Falta de transparência: Decisões importantes eram tomadas sem que todos os envolvidos fossem devidamente consultados.

Dificuldade de rastreamento: Sem um registro formal, era difícil saber por que uma decisão foi tomada e quem participou.

Sobrecarga de mantenedores: Sem um processo claro, os mantenedores acabavam sobrecarregados com decisões que poderiam ser delegadas.

Perda de conhecimento tribal: As informações importantes ficavam na cabeça de poucas pessoas, dificultando a continuidade do projeto.

O novo processo RFC visa resolver esses problemas, empoderando as partes interessadas a tomar decisões em suas áreas de atuação, com um fluxo claro e documentado.

Quer se aprofundar em governança de projetos de código aberto ? O Código Aberto e a Governança Colaborativa é um ótimo ponto de partida para entender como projetos como o GNOME evoluem suas estruturas de decisão.

Como funciona o novo processo de RFC ?

O processo é estruturado em etapas bem definidas. Vamos detalhar cada uma delas.

1. Proposta inicial

Qualquer pessoa pode propor um RFC. A proposta deve ser um documento escrito que descreve a mudança proposta, seu impacto e suas justificativas. Esse documento é adicionado ao projeto RFC como um merge request.

2. Identificação das partes interessadas

Uma vez submetido, as partes interessadas são identificadas e notificadas. Equipes também podem se identificar voluntariamente como interessadas. Isso garante que todos os que serão impactados pela mudança tenham voz no processo.

3. Discussão no Discourse

Toda a discussão do RFC acontece no GNOME Discourse — a plataforma oficial de fórum da comunidade. Isso centraliza o debate e mantém um registro público e acessível.

4. Levantamento de preocupações

Qualquer pessoa pode levantar preocupações sobre um RFC. As preocupações devem ser de natureza prática — não meros exercícios teóricos — e devem ter um caminho claro para resolução. Exemplos de preocupações válidas incluem:

Propor alternativas ou ideias adicionais.

Elaborar um plano para alcançar consenso posteriormente.

Estar aberto a discussões adicionais.

5. Resolução das preocupações

Uma preocupação é considerada resolvida quando a parte interessada que a aceitou originalmente fica satisfeita com as mudanças ou esclarecimentos fornecidos. Para evitar atrasos, se a parte interessada não responder a uma menção @ em até 14 dias, qualquer outra parte interessada pode resolver a preocupação.

6. Período de comentários finais

Quando a discussão se acalma, é anunciado um período de comentários finais, com uma proposta para aceitar ou rejeitar o RFC. A partir desse ponto, há 14 dias para levantar novas preocupações antes da decisão final.

7. Decisão e implementação

Após o período de comentários finais, o RFC é aceito ou rejeitado. Se aceito, as mudanças são implementadas conforme o plano aprovado.

Produto Recomendado

Anker Adaptador otg USB-C para USB 3.0 pacote com 2, adaptador usb tipo c -> https://link.amazon/B0b7wy4gp

Eu ganho uma comissão quando você faz uma compra.

Quem são as partes interessadas ?

As partes interessadas (stakeholders) são os times e indivíduos que serão impactados pela mudança proposta. O processo RFC do GNOME prevê que diferentes equipes possam se identificar como partes interessadas em diferentes RFCs.

Alguns exemplos de equipes mencionadas na discussão incluem:

Platform team — responsável pela plataforma central.

Design team — equipe de design de interface.

Core apps team — equipe de aplicativos centrais.

Documentation team — equipe de documentação.

Bindings team — equipe responsável pelas bindings de linguagens.

Security team — equipe de segurança.

Infrastructure team — equipe de infraestrutura e CI.

Essa abordagem garante que as decisões sejam tomadas por quem tem expertise e responsabilidade sobre cada área.

Exemplos de mudanças que exigiriam um RFC

Para entender melhor o escopo, vejamos alguns exemplos concretos de mudanças que, no novo modelo, seriam tratadas via RFC:

Novo formato de ícones simbólicos

O GTK adicionou um novo conjunto de funcionalidades ao SVG para formalizar ícones simbólicos, incluindo animações. Isso impactou:

Como o GTK interpreta SVG

Assets de ícones incorporados por bibliotecas e aplicativos

A funcionalidade de rasterizar assets SVG em PNG com dados extras para recolorir

Um RFC teria envolvido as equipes de plataforma, design, aplicativos centrais e documentação.

Migração de GdkPixbuf para o Glycin

A biblioteca de carregamento de imagens recomendada mudaria de GdkPixbuf (de 1999) para Glycin, considerando requisitos modernos de segurança e performance. Um RFC teria envolvido as equipes de plataforma, bindings, documentação e segurança.

Novo formato de documentação

Com o gtk-doc em modo de manutenção profunda, a adoção do gi-docgen como gerador de documentação exigiria um RFC para discutir os requisitos, processo de migração, compatibilidade e integração com a CI.

O que isso significa para desenvolvedores e usuários ?

Para os Desenvolvedores

Mais transparência: você saberá exatamente como e por que decisões importantes são tomadas.

Mais oportunidades de participação: qualquer pessoa pode levantar preocupações ou propor mudanças.

Processo mais previsível: prazos e etapas claras reduzem a incerteza.

Menos sobrecarga: decisões são delegadas às equipes apropriadas.

Para os usuários

Maior estabilidade: mudanças significativas serão mais bem planejadas e discutidas.

Melhor qualidade: decisões técnicas mais robustas, com contribuição de múltiplas expertises.

Comunidade mais saudável: um processo claro reduz conflitos e desgastes entre desenvolvedores.

Desafios e críticas

Como todo processo novo, o RFC do GNOME não está isento de desafios. Alguns pontos levantados pela comunidade incluem:

Burocracia excessiva: será que o processo pode tornar mudanças simples mais lentas?

Capacitação: nem todos os colaboradores estão familiarizados com o formato RFC.

Aderência: será que o processo será seguido na prática, ou continuará havendo decisões informais?

A própria proposta reconhece que o processo pode ser ajustado ao longo do tempo, e que mudanças no processo podem ser feitas sem um novo RFC.

Perguntas Frequentes (FAQ)

1. Qualquer pessoa pode propor um RFC ?

Sim! Qualquer pessoa pode submeter uma proposta de RFC. O documento é adicionado como um merge request e a discussão é aberta a todos.

2. O que acontece se ninguém levantar preocupações durante o período de comentários finais ?

Se não houver preocupações novas dentro dos 14 dias do período de comentários finais, o RFC é aceito ou rejeitado com base na proposta apresentada.

3. Este processo substitui completamente as decisões informais?

O objetivo é que mudanças com "amplas repercussões" sejam tratadas via RFC. Mudanças menores ou rotineiras ainda podem seguir fluxos mais simples, conforme definido pelas equipes.