Governance i społeczność.
Wombat to rozwijana przez społeczność, neutralna wobec dostawców inicjatywa — z jasnym, przejrzystym governance wzorowanym na sprawdzonych modelach open source, takich jak CNCF. Każda decyzja jest identyfikowalna. Każda rola ma kadencję.
Zbudowany na lata, domyślnie otwarty.
Trzy zasady kształtują governance Wombat — wystarczająco lekkie, by działać szybko, i wystarczająco uporządkowane, by się skalować.
Decyzje przez RFC
Każda istotna zmiana przechodzi przez Request for Comments — przygotowany publicznie, zrecenzowany przez społeczność i rozstrzygnięty z uzasadnieniem. Bez cichych aktualizacji i nieprzejrzystych wyborów dostawców. Historia jest governance.
Przejrzyście i identyfikowalnie
Roadmapa, dyskusje, głosowania i decyzje są publicznie dokumentowane na GitHubie. Każdy może prześledzić uzasadnienie, zakwestionować decyzję lub zaproponować alternatywę — zawsze według tego samego procesu.
Zawsze neutralnie wobec dostawców
Żadna pojedyncza firma nie kontroluje Wombat. Role governance kierują się zasadą „najpierw aktywni kontrybutorzy” i neutralną równowagą między dostawcami. Skład TSC, statuty grup roboczych i Advisory Group zapewniają to z założenia.
Governance w skrócie.
Celowo odchudzone, ale skalowalne — zaprojektowane dla rosnącej społeczności. Decyzje zapadają przez RFC, przeglądy i udokumentowane głosowania.
Przejrzystość: GitHub · RFC · Notatki ze spotkań
Model governance (wzorowany na CNCF).
Sześć jasno zdefiniowanych ról i mechanizmów — każdy z własnym zakresem, odpowiedzialnością i procesem.
Technical Steering Committee
Odpowiada za kierunek techniczny, decyzje architektoniczne i zatwierdzanie RFC. Wybierany spośród aktywnych kontrybutorów. Odnawialne 12-miesięczne kadencje.
Zespół maintainerów
Utrzymuje główne repozytoria, prowadzi przeglądy i dba o spójność oraz jakość. Powoływany na 12 miesięcy, z możliwością przedłużenia w zależności od aktywności.
Grupy robocze
Tematyczne grupy zajmujące się filarami, scoringiem, kontrolami i architekturami referencyjnymi. Pracują otwarcie przez zgłoszenia na GitHubie i RFC. Każdy może zaproponować grupę.
User Advisory Group
Wnosi praktyczne perspektywy z projektów, operacji i audytów. Stawia na trafność — dba, by framework odzwierciedlał realia produkcji, a nie tylko teorię.
Domyślnie publicznie
Roadmapa, dyskusje, głosowania i decyzje są dokumentowane publicznie i identyfikowalnie na GitHubie. Brak prywatnych kanałów decyzyjnych dla zmian we frameworku.
Proces RFC
Szkic → przegląd społeczności → decyzja → implementacja. Każda istotna decyzja jest uzasadniona i powiązana z wątkiem dyskusji.
Role, kadencje i oczekiwania.
Jasne zasady sprawiają, że governance jest sprawiedliwe i przewidywalne. Oto jak zapadają decyzje i jak działają role.
Kadencje maintainerów
Powoływani na 12 miesięcy, z możliwością przedłużenia, jeśli wykazują zaangażowanie i aktywność w przeglądach, a nie ma uzasadnionych zastrzeżeń.
Brak aktywności: Po 90 dniach bez aktywności status może zostać zmieniony na „emeritus” po przypomnieniu i przejrzystej notatce. Ponowna aktywacja jest możliwa w każdej chwili.
Kadencje TSC
Członkowie TSC pełnią 12-miesięczne kadencje z możliwością odnowienia. Skład kieruje się zasadą „najpierw aktywni kontrybutorzy” i neutralną równowagą między dostawcami. Role i obowiązki są publicznie udokumentowane.
Zakładanie grupy roboczej
Każdy może zaproponować grupę. Wymagane są: statut (cel, zakres, rezultaty), osoba lub osoby prowadzące, kanał komunikacji oraz maintainer w roli opiekuna.
Rezultaty grup wracają do głównych repozytoriów jako PR i RFC.
Lazy consensus
Przy mniejszych zmianach: propozycja jest publikowana z 5 dniami roboczymi na przegląd. Brak uzasadnionych zastrzeżeń → przyjęta.
„Blokada” musi być uzasadniona i zawierać propozycję alternatywnego rozwiązania lub poprawki.
Kworum i głosowanie
Przy większych decyzjach (nowy filar, zmiany łamiące zgodność, zmiany statutu) głosuje TSC:
- Kworum: co najmniej 60% aktywnych członków TSC
- Większość: zwykła większość oddanych głosów
- Minimum: co najmniej 3 głosy, jeśli TSC jest nieliczny
- Konflikty: członkowie w konflikcie interesów wstrzymują się od głosu
Oczekiwania
Działaj neutralnie wobec dostawców, stawiaj interes społeczności na pierwszym miejscu, dokumentuj decyzje, komunikuj się z szacunkiem (kodeks postępowania) i zgłaszaj kwestie bezpieczeństwa odpowiedzialnie przez wyznaczone kanały.
Gdzie zapadają decyzje?
RFC dla większych zmian · ADR i notatki dla decyzji architektonicznych · Zgłoszenia i PR dla implementacji. Każda decyzja odsyła do dyskusji, która do niej doprowadziła.
Gdzie spotyka się społeczność.
Projekt powstał w kontekście Cloud Native Conference i istniejącej społeczności CCC. Cel: zebrać praktyczne doświadczenia i otwarcie je rozwijać.
Wymiana na konferencjach — prelekcje, panele i sesje Birds-of-a-Feather, podczas których inżynierowie dzielą się realnymi wyzwaniami i wzorcami.
Praktyczne warsztaty o modelach dojrzałości, scoringu i wdrażaniu — koncepcje frameworku przekładane na praktykę inżynierską.
Publiczne sesje o roadmapie i otwartych szkicach RFC — każdy może dołączyć, skomentować i współdecydować, co powstanie dalej.
Jak możesz pomóc.
Nie ma minimalnego rozmiaru wkładu. Każdy udostępniony przypadek użycia, każda recenzja i każdy komentarz do RFC posuwa framework naprzód.
Dziel się przypadkami użycia
Z jakimi wyzwaniami mierzysz się w projektach chmurowych? Które wzorce działają, a które nie? Praktyczne doświadczenie to najcenniejszy wkład dla frameworku.
Proponuj kryteria i kontrole
Wkład do modeli dojrzałości i kwestionariuszy: co trzeba sprawdzić bez względu na wszystko? Nowe kontrole, kryteria scoringu i wzorce oceny zaczynają się tutaj.
Recenzuj i przekazuj uwagi
Sprawdzaj wzorce architektoniczne i modele referencyjne pod kątem spójności, praktyczności i kompromisów. Otwarte RFC zawsze potrzebują przemyślanej perspektywy inżynierskiej.
Dokumentacja i tłumaczenia
Ulepszaj, rozszerzaj i tłumacz treści na kolejne języki. Dobra dokumentacja to połowa wartości — i zawsze jest potrzebna.
Dołącz do grupy roboczej
Pomagaj przy filarach, scoringu, kontrolach lub architekturach referencyjnych — przejrzyście na GitHubie. Grupy robocze rozwijają framework w skupionych sprintach z jasną odpowiedzialnością.
Prelegenci i sesje
Zgłaszaj tematy do CFP, wygłaszaj prelekcje lub prowadź sesje BoF na konferencjach. Publicznie prezentowane praktyczne przykłady kształtują framework bardziej niż samo RFC.
Identyfikowalnie, uczciwie, otwarcie.
Governance to żywa praktyka. Utrzymujemy procesy lekkie, ale jasne — by Wombat mógł rosnąć razem ze społecznością, nie tracąc rozliczalności.