{"id":183253,"date":"2026-09-05T16:53:29","date_gmt":"2026-09-05T14:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/reformirovanie-proczessa-utverzhdeniya-znachitelnyh-izmenenij-v-gnome"},"modified":"2026-09-05T16:53:33","modified_gmt":"2026-09-05T14:53:33","slug":"reforming-the-approval-process-for-major-changes-in-gnome","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/reforming-the-approval-process-for-major-changes-in-gnome","title":{"rendered":"Reformowanie procesu zatwierdzania istotnych zmian w GNOME","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Deweloperzy GNOME omawiaj\u0105 wprowadzenie nowego procesu podejmowania decyzji opartego na publikacji propozycji w formie RFC (Request for Comments) i ich p\u00f3\u017aniejszym wsp\u00f3lnym zatwierdzeniu. Uczestnicy GNOME Foundation s\u0105 zach\u0119cani do do\u0142\u0105czenia do dyskusji i przedstawienia swoich uwag do 4 pa\u017adziernika. Model oparty na RFC planuje si\u0119 stosowa\u0107 tylko w szczeg\u00f3lnych przypadkach, w celu rozwi\u0105zania impas\u00f3w, zatwierdzania globalnych zmian w projekcie, kt\u00f3re wp\u0142ywaj\u0105 na metody pracy uczestnik\u00f3w lub kod r\u00f3\u017cnych aplikacji i podsystem\u00f3w, a tak\u017ce zmian architektonicznych i du\u017cych przekszta\u0142ce\u0144 interfejsu. <\/p>\n
Zauwa\u017cono, \u017ce obecnie stosowany nieformalny model oparty na podejmowaniu indywidualnych decyzji prowadzi do wypalenia uczestnik\u00f3w, przed\u0142u\u017caj\u0105cych si\u0119 spor\u00f3w i wyczerpuj\u0105cego poszukiwania konsensusu w czatach. Nowy model proponuje sztywny regulamin, kt\u00f3ry zwi\u0119kszy przejrzysto\u015b\u0107, uporz\u0105dkuje proces i prze\u0142\u0105czy odpowiedzialno\u015b\u0107 za decyzj\u0119 z indywidualnej na kolektywn\u0105. W\u015br\u00f3d wad modelu zarz\u0105dzania opartego na RFC wymienia si\u0119 trudno\u015b\u0107 procesu dla niekt\u00f3rych deweloper\u00f3w oraz brak mechanizmu rozwi\u0105zywania konflikt\u00f3w, kt\u00f3re prowadz\u0105 do zastoju wa\u017cnych RFC. <\/p>\n
Etapy promowania RFC: <\/p>\n
\n
Wys\u0142anie do repozytorium GNOME\/rfcs pliku RFC-XXXX-nazwa.md z uporz\u0105dkowan\u0105 propozycj\u0105 i linkiem do dyskusji.\n
Dyskusja nad propozycj\u0105 na platformie Discourse z towarzysz\u0105cym dopracowaniem i wprowadzaniem poprawek do RFC.\n
Publikacja zg\u0142osze\u0144 uczestnik\u00f3w oznaczonych jako «**Concern**», opisuj\u0105cych potencjalne problemy lub proponuj\u0105cych alternatywne rozwi\u0105zania. W przypadku poparcia zg\u0142oszenia przez redaktora lub jednego z zainteresowanych uczestnik\u00f3w, staje si\u0119 ono obowi\u0105zkowe do rozpatrzenia.\n
Rozpatrzenie zg\u0142oszonych zastrze\u017ce\u0144, wypracowanie \u015brodk\u00f3w do ich uregulowania oraz wprowadzenie zmian do RFC.\n
Po zako\u0144czeniu dyskusji i rozpatrzeniu zastrze\u017ce\u0144 og\u0142aszany jest 14-dniowy ostateczny okres komentarzy (FCP, Final Comment Period), w czasie kt\u00f3rego mo\u017cna zg\u0142asza\u0107 tylko nowe zastrze\u017cenia. Je\u015bli nowe zastrze\u017cenie zostanie zaakceptowane, dyskusja zostaje wznowiona, a okres ostatecznego przyjmowania zastrze\u017ce\u0144 zostaje przesuni\u0119ty.\n
Po zako\u0144czeniu ostatecznego okresu komentarzy i rozpatrzeniu wszystkich zastrze\u017ce\u0144, RFC zostaje albo przyj\u0119te, albo odrzucone. <\/ul>\n