GNOME projednává proces RFC, ve kterém námitka platí, až ji uzná někdo další

Kdo v GNOME rozhodne, že se přestane používat jedna knihovna a začne jiná? Příručka projektu na to odpovídá vyhýbavě a návrh, který 27. července otevřela k diskusi Sophie Herold, z ní tu odpověď rovnou cituje: většina rozhodnutí v GNOME padá neformálně, mezi jednotlivci, kteří spolu spolupracují. Týká se to podle příručky i toho, kdo na čem dělá a jaká technická a uživatelská řešení se prosadí. Citace je z anglického originálu přeložená.

Proč to někomu vadí

Text návrhu chce z toho popisu odstranit slova „neformálně“ a „jednotlivci“. Shánění shody je podle něj pro přispěvatele vyčerpávající a ústí buď v malý pokrok, nebo ve vyhoření, nebo v rozhodnutí nízké kvality. Formální a sdílené struktury mají zvýšit odpovědnost a zároveň ji rozložit na víc lidí.

Není to první pokus. Emmanuele Bassi zveřejnil 15. srpna 2025 návrh RFC: Governance, který popisoval celou technickou správu projektu včetně řídicího výboru. Herold píše, že části Bassiho návrhu už dostávají podobu, ale samotný proces RFC se veřejně nepohnul. Její text je proto schválně užší: má zavést jen způsob projednávání a teprve jím pak stavět zbytek.

Jak by to fungovalo

RFC by byl obyčejný soubor v markdownu v repozitáři GNOME/rfcs na GitLabu. Podá ho kterýkoli člen nadace tím, že otevře žádost o začlenění (merge request); číslo RFC se přebírá z čísla té žádosti, takže se na dokument dá jednoduše odkazovat. V popisu žádosti stojí, koho se změna dotýká a kdo smí text upravovat – návrh těm dvěma rolím říká stakeholders a editors.

Nejzajímavější je práce s námitkami. Formální námitku smí vznést kdokoli tím, že komentář začne slovem Concern. Sama o sobě ale neznamená nic: musí ji přijmout někdo ze zúčastněných stran nebo editorů, a to někdo jiný než ten, kdo ji vznesl. Přijatá námitka se do popisu žádosti zapíše jako políčko k odškrtnutí. Návrh k tomu žádá, aby byla praktická, ne myšlenkový pokus, a aby měla zřejmou cestu k řešení.

Odškrtnout ji má ten, kdo ji přijal. Když se do čtrnácti dnů od zmínky neozve, může to udělat kdokoli další ze zúčastněných. Je to pojistka proti tomu, aby celý návrh uvázl na jednom mlčícím člověku.

Konec má podobu závěrečné lhůty na připomínky. Vyhlásí ji kterýkoli editor komentářem, ve kterém uvede, jak to má dopadnout: merge, nebo close. Čtrnáct dní se dají uplatnit poslední námitky, a když nějaká projde, lhůta se ruší a musí začít znovu. Pokud doběhne a všechny námitky jsou vyřešené, žádost se podle vyhlášeného záměru buď začlení, což znamená přijetí, nebo zavře, což znamená zamítnutí. Nad pravomoci, které jednotlivým lidem a skupinám dala nadace, se RFC dostat nesmí.

Spor první: smí se zamítat?

Podle Bassiho by se RFC zamítat neměl. Kdo návrh podává, měl by mít předem sehnané zastánce a rámcovou představu o proveditelnosti; místo zamítnutí navrhuje tři stavy – projednává se, platí, odloženo. Návrh, který nemá šanci projít teď ani později, se podle něj prostě zavře.

Herold s tím nesouhlasí. Zamítnutí má podle ní zůstat možností, protože z diskuse může vyjít, že je nápad slepá ulička; pak dává smysl, aby někdo napsal jiný RFC, ne aby se všechno cpalo do téhož textu. Stav „odloženo“ odmítá rovnou – podle ní zve k tomu nechávat rozhodnutí viset, čehož už projekt zažil dost.

Spor druhý: kde se má diskutovat

Druhá neshoda je o místě. Podle Bassiho nemá GitLab nástroje na moderování: odpověď v něm jde jen smazat nebo uživatele zablokovat, skrýt ji – na rozdíl od GitHubu – nelze. Navrhuje proto vést rozpravu na Discourse a v žádosti nechat jen úřední část, tedy zápis námitek a změny stavu a rolí. Na téže straně stojí i Allan Day.

Herold nejdřív hájila GitLab: účty jsou tam navázané na členství v nadaci, přispěvatelé se můžou přihlásit k odběru štítků jednotlivých týmů a návrh počítá s tím, že se žádost dá zamknout tak, aby psali dál jen členové. Po Bassiho výčtu – dělení vláken do samostatných témat, zpomalený režim, skrývání odpovědí, opatření mířená na uživatele místo plošného zákazu – ale napsala, že jí to i přes nechuť ke dvěma platformám v jednom procesu zní přesvědčivě.

Co návrh sám přiznává

Vlastní oddíl nevýhod jmenuje tři věci. Návrh nemá konečný způsob, jak rozhodnout spor mezi zúčastněnými stranami o přijaté námitce, takže i důležitý RFC může uváznout. Sepsat ho je pro část přispěvatelů technická překážka. A protože text sází na stručnost, nejspíš nepokryje okrajové případy.

Čtvrtou výhradu přidal do diskuse Benjamin Otte. Tři příklady, které Bassi uvedl jako věci, jež měly projít RFC – nový formát symbolických ikon, přechod od knihovny GdkPixbuf ke Glycinu a výměna nástroje na vývojářskou dokumentaci –, byly podle něj předem hotová rozhodnutí: jejich autoři si domluvili těch pár lidí, kterých se to týkalo, a udělali to. Skutečně sporné jsou podle Otteho jiné věci, třeba celoprojektový postoj k umělé inteligenci, jestli se smí základní aplikace psát v Rustu, nebo který terminál má být ten výchozí. Ptá se proto, jestli má pro obojí dávat smysl tentýž postup. Dílčí pravidla pro kód psaný modely přitom v projektu už vznikla – recenzent rozšíření je sepsal na blogu a jsou teď součástí oficiálního průvodce. Matthias Clasen se k tomu přidává z druhé strany: proces musí zůstat lehký, protože žádná z těch tří věcí by podle něj nevznikla, kdyby jí předcházela dlouhá rozprava o všech nepravděpodobných způsobech, jak to může selhat.

Co bude dál

Herold uvedla dva kroky: nejdřív ohlasy na fóru Discourse, a když návrh obstojí, projde vlastním procesem jako RFC-0001. Diskusi si přitom vyhradila pro aktivně přispívající členy nadace. Do 1. srpna se v ní sešlo osmnáct příspěvků od osmi lidí.

Podle nás je nejsilnější místo celého textu právě pravidlo, že námitku musí uznat druhý člověk. Bassi to v diskusi řekl bez obalu: dá se tím pominout komentář někoho, kdo do věci nic nevložil a jen šel kolem. Je to zároveň místo, kde návrh sám přiznává díru – když se neshodnou dva lidé, kteří do věci vložili oba dost, nerozhodne nikdo.

Zdroje: Proposal for an RFC Process na GNOME Discourse, znění návrhu na GitLabu, RFC: Governance z roku 2025, This Week in GNOME #260 a zpráva Phoronixu z 1. srpna 2026.