Zarządzanie projektem Kshana

Ten dokument opisuje, jak zarządzany jest Kshana: kto podejmuje decyzje, w jaki sposób i co projekt będzie, a czego nie będzie przyjmował. Jest celowo lekki — proporcjonalny do obecnej wielkości projektu — i rzetelnie opisuje obecną rzeczywistość jednego opiekuna oraz drogę do szerszego zarządzania w miarę rozwoju społeczności.

Misja i zakres#

Kshana to neutralny, odtwarzalny i rzetelnie zwalidowany punkt odniesienia dla wydajności i odporności hybrydowego kwantowo-klasycznego PNT. Misja wyznacza próg dla każdej decyzji: poprawność, cytowania i odtwarzalność ważniejsze niż szerokość oferty. Rzetelny zakres jest opisany w docs/CAPABILITY.md, a status walidacji w docs/VALIDATION.md; propozycje są oceniane względem tego zakresu, a nie względem liczby funkcji.

Role#

Opiekun. Kshana jest obecnie utrzymywany przez swojego założyciela, Ashforde OÜ (kontakt: contact@ashforde.org). Opiekun jest ostatecznym decydentem w sprawie zakresu, projektu, wydań i tego, co zostaje włączone. To model życzliwego opiekuna, opisany wprost, a nie przebrany za komitet, który nie istnieje.
Współtwórcy. Każdy, kto otwiera zgłoszenie (issue) lub pull request. Wkład jest oceniany według progu z CONTRIBUTING.md — pochodzenie każdego parametru liczbowego, walidacja względem opublikowanej zależności i rzetelność co do dojrzałości.
Przyszli committerzy. Gdy trwały, wysokiej jakości wkład na to zasługuje, prawa do zatwierdzania zmian zostaną rozszerzone na zaufanych współtwórców, a ten dokument zostanie zaktualizowany do modelu wielu opiekunów (decyzje przez konsensus domniemany, z grupą opiekunów rozstrzygającą spory). Do tego czasu droga jest taka: wnosić wkład, zbudować dorobek i zostać zaproszonym.

Jak podejmowane są decyzje#

Dyskusja jawna. Istotne zmiany zaczynają się jako zgłoszenie na GitHubie, tak aby uzasadnienie, alternatywy i kompromisy były zapisane.
Konsensus domniemany. Propozycja bez trwałego sprzeciwu po rozsądnym czasie, która spełnia poniższy próg techniczny, jest realizowana.
Opiekun rozstrzyga w razie sporu. Gdy nie osiągnięto konsensusu, decyduje opiekun i zapisuje powód. Spór rozstrzyga misja i próg techniczny, a nie staż ani głośność.

Próg techniczny (niepodlegający negocjacjom)#

To twarde niezmienniki, egzekwowane przez CI i przegląd, których żadna decyzja nie uchyla:

Reproducibility. (scenario, seed, engine_version) musi odtworzyć przebieg bit po bicie. Zmiana, która to uniedeterministycznia, jest błędem, a nie funkcją.
Pochodzenie. Żadnych anonimowych stałych liczbowych — każdy parametr wskazuje źródło.
Rzetelność walidacji. Każda możliwość jest oznaczona jako validated (względem zewnętrznej wyroczni) albo modelled / not modeled. Niczego nie twierdzi się ponad to, co wynika z dowodów. Zob. sprawdzaną maszynowo macierz w src/verification.rs.
Higiena. Żadnego przypisywania autorstwa narzędziom automatycznym nigdzie w commitach, treści ani historii (egzekwowane przez scripts/check-no-attribution.sh).

Zmiana, która nie spełnia progu, jest odrzucana, choćby była bardzo użyteczna.

Granica między otwartym a zamkniętym#

Kshana działa w modelu open-core. To repozytorium jest i pozostanie kompletnym otwartym silnikiem AGPL-3.0 — neutralnym punktem odniesienia, z podwójnym licencjonowaniem komercyjnym przez Ashforde OÜ (zob. LICENSING.md). Projekt nie przyjmie do otwartego repozytorium:

Głębi objętej kontrolą eksportu lub podwójnego zastosowania — prawdziwych bibliotek zagrożeń, przebiegów przeciwnika ani parametrów skuteczności anti-jam/anti-spoof. Publiczne repozytorium ogranicza się do ogólnych, opublikowanych modeli i metod (zob. CONTRIBUTING.md → Export control). W razie wątpliwości zapytaj przed wniesieniem wkładu.
Poufnych danych lub kalibracji klientów albo partnerów.
Zależności copyleft (GPL/AGPL/LGPL/MPL) — nie dlatego, że kolidują z własną licencją AGPL silnika (nie kolidują), lecz dlatego, że nie można ich przelicencjonować do edycji komercyjnej: licencję komercyjną możemy sprzedawać tylko na kod, którego jesteśmy właścicielami lub który jest permisywny. Zależność copyleft skaziłaby edycję komercyjną i złamała podwójne licencjonowanie. Dlatego zależności pozostają permisywne (Apache/MIT/BSD/ISC), co egzekwuje deny.toml.

I odwrotnie: projekt nie wydrąży otwartego rdzenia, by przesunąć wartość do części zastrzeżonej: zwalidowany silnik, publiczne punkty zakotwiczenia walidacji, rejestr rzetelności, format wymiany i normy oraz kanały dystrybucji pozostają otwarte. Głodzenie otwartego rdzenia to jedyny fatalny błąd w modelu open-core i jest wykluczone.

Wydania#

Semantic Versioning. Przed wersją 1.0 schemat scenariusza i wyniku może się zmieniać; zmiany niezgodne wstecznie są wyraźnie wskazywane, a wersja schematu wymiany (src/interchange.rs::SCHEMA_VERSION) jest jedynym źródłem prawdy o zgodności artefaktów.
Uprawnienie do wydań. Publikowanie (np. cargo publish) jest ręcznym krokiem opiekuna, wymagającym tokenu rejestru. CI i wyzwalany tagiem przepływ Release nigdy nie publikują automatycznie w zewnętrznych rejestrach — jedynie ponownie uruchamiają wszystkie kontrole i dołączają artefakt kompilacji. Zob. CONTRIBUTING.md → Commits and versioning.

Kodeks postępowania i bezpieczeństwo#

Zasady postępowania określa CODE_OF_CONDUCT.md.
Kwestie bezpieczeństwa podlegają prywatnemu procesowi zgłaszania opisanemu w SECURITY.md — nie otwieraj publicznego zgłoszenia dotyczącego podatności.

Znak towarowy#

Nazwa i logo Kshana są znakami towarowymi Ashforde OÜ. Licencja (AGPL-3.0 lub licencja komercyjna) obejmuje kod, a nie znaki: fork może używać kodu na warunkach licencji, ale nie nazwy Kshana ani kanonicznej tożsamości dystrybucji. Dzięki temu Ashforde pozostaje cytowanym źródłem prawdy, co jest częścią tego, jak otwarty rdzeń pozostaje neutralnym punktem odniesienia.

Zmiana tego dokumentu#

Zmiany w zarządzaniu są same proponowane jako pull request i rozstrzygane opisanym wyżej procesem. W miarę zmiany skali projektu należy oczekiwać, że ten dokument zyska model decyzyjny wielu opiekunów; nie obniży to progu technicznego.

Lekki z założenia. Rzetelny co do dzisiaj, z jasno opisaną drogą na jutro.