W poprzednich wpisach opisaliśmy drabinę rozwoju i ścieżkę od obserwatora do core teamu. Teraz pokażemy, jak działa podejmowanie decyzji w projekcie. Kto ma głos, jak rozstrzygamy spory i dlaczego jedna osoba ma ostatnie słowo.
Autor projektu i BDFL
Slayer jest projektem autorstwa Kacpra Wikieła. To on jest inicjatorem, autorem kierunku i osobą odpowiedzialną za początkową strukturę projektu: zakres badań, standard publikacji, ton marki, priorytety techniczne i decyzje o tym, co trafia do oficjalnego Slayera.
Początkowy model organizacyjny to BDFL — Benevolent Dictator For Life. Model znany z wczesnej historii Pythona. W praktyce oznacza to, że Kacper Wikieł ma ostatnie słowo w sprawach kierunku, jakości, publikacji, nazwy, marki i konfliktów decyzyjnych.
To nie jest zamknięcie projektu. To mechanizm utrzymania spójności, dopóki Slayer nie ma dojrzałego governance, stałych maintainerów i jasnych procesów rozstrzygania sporów.
Struktura własności
Obecnie Kacper Wikieł posiada 100% projektu. To stan startowy, nie docelowy. W miarę jak Slayer dojrzewa, własność będzie się otwierać dla osób, które realnie go budują.
Przewidujemy, że ścieżka core membera będzie wiązać się z vested equity (udziałami nabywanymi w czasie, za dowożoną pracę i odpowiedzialność). Pojawią się też prawdopodobnie inwestorzy — finansowanie compute i zespołu wymaga kapitału.
Szczegóły opiszemy, gdy będą realne — bez obietnic bez pokrycia.
Reguły pracy
Jedna oficjalna linia
Każdy może eksperymentować, forkować i proponować zmiany. Oficjalny Slayer zachowuje jednak jedną linię decyzyjną i jedną odpowiedzialność redakcyjną.
Merit, nie hałas
Decyzje techniczne zapadają na podstawie artefaktów: kodu, danych, pomiarów, kosztu, replikowalności i jakości odpowiedzi. Sama opinia nie wystarczy.
To jest kluczowa zasada: nie liczy się, jak głośno mówisz, ale co przynosisz. Dowód jest królem.
Wkład daje głos
Realni kontrybutorzy mają wpływ na plan działania i priorytety. Wpływ rośnie z odpowiedzialnością za dowożone rzeczy, a nie z deklaracjami.
Jeśli chcesz zmienić kierunek projektu — przynieś dowód.
Spory domykamy
Jeśli dyskusja nie prowadzi do decyzji, BDFL domyka temat. Celem jest ruch projektu, nie nieskończona debata.
To nie jest demokracja. To jest meritokracja z awaryjnym hamulcem.
Governance może dorosnąć
Gdy projekt będzie miał stabilnych maintainerów, regularnych kontrybutorów i większą powierzchnię odpowiedzialności, struktura może przejść w bardziej formalny model. Do tego czasu obowiązuje BDFL.
Pracujemy publicznie
Wszystkie decyzje, eksperymenty, wyniki i porażki są publiczne. Nie ma ukrytych roadmap ani tajnych projektów. Jeśli coś robimy, możesz to zobaczyć.
Publiczność jest najlepszym filtrem jakości. Kiedy pracujesz na widoku, nie możesz oszukiwać.
Jak to działa w praktyce
Propozycja — ktoś proponuje zmianę, eksperyment, nowy kierunek.
Dyskusja — społeczność analizuje, zadaje pytania, proponuje modyfikacje.
Dowód — autor pokazuje artefakty: kod, dane, wyniki, koszt.
Decyzja — jeśli dowód jest solidny, zmiana wchodzi. Jeśli nie, jest odrzucona.
Awaryjny hamulec — jeśli dyskusja utknie, BDFL decyduje.
Dlaczego to działa
Bo jasne zasady są lepsze niż udawana demokracja. Większość projektów open-source upada nie z braku pomysłów, ale z braku decyzji. My wolimy mieć jedną osobę, która podejmuje decyzje, niż pięć osób, które nie podejmuje żadnych.
Wejście jest otwarte
Jeśli chcesz dołożyć kod, dane, ewaluację albo compute — wejście jest otwarte. Jeśli chcesz zmienić kierunek projektu — przynieś dowód.
Nawigacja
Poprzedni: Drabina: od obserwatora do core teamu
Więcej: Pełne zasady projektu · Dołącz do zespołu · GitHub