Управління проєктом Kshana

Цей документ описує, як управляється Kshana: хто ухвалює рішення, як це відбувається і що проєкт прийматиме, а що ні. Він навмисно легкий — відповідно до нинішнього розміру проєкту — і чесно говорить про теперішню реальність єдиного супровідника та про шлях до ширшого управління в міру зростання спільноти.

Місія та обсяг#

Kshana — це нейтральний, відтворюваний, чесно перевірений еталон продуктивності та стійкості гібридного квантово-класичного PNT. Місія задає планку для кожного рішення: коректність, цитування та відтворюваність важливіші за широту охоплення. Чесний обсяг задокументовано в docs/CAPABILITY.md, а стан валідації — в docs/VALIDATION.md; пропозиції зважують щодо цього обсягу, а не щодо кількості функцій.

Ролі#

Супровідник. Нині Kshana супроводжує її засновник, Ashforde OÜ (контакт: contact@ashforde.org). Супровідник є остаточним ухвалювачем рішень щодо обсягу, дизайну, випусків і того, що зливається. Це модель доброзичливого супровідника, названа прямо, а не прикрашена комітетом, якого не існує.
Учасники. Будь-хто, хто відкриває запит чи запит на злиття змін. До внесків застосовують планку з CONTRIBUTING.md — походження кожного числового параметра, перевірка за опублікованим співвідношенням і чесність щодо зрілості.
Майбутні комітери. Коли сталий високоякісний внесок це виправдає, права на коміт буде надано довіреним учасникам, а цей документ буде оновлено до моделі з кількома супровідниками (рішення за ліниву згоду, а розбіжності вирішує група супровідників). До того часу шлях такий: вносити зміни, напрацювати репутацію й отримати запрошення.

Як ухвалюють рішення#

Відкрите обговорення. Суттєві зміни починаються із запиту (issue) на GitHub, щоб обґрунтування, альтернативи й компроміси були зафіксовані.
Лінива згода. Пропозиція, щодо якої після розумного часу немає тривалих заперечень і яка відповідає наведеній нижче технічній планці, рухається далі.
У разі розбіжностей вирішує супровідник. Якщо згоди не досягнуто, вирішує супровідник і фіксує причину. Розбіжність розв'язують місією та технічною планкою, а не стажем чи гучністю.

Технічна планка (не обговорюється)#

Це жорсткі інваріанти, що забезпечуються через CI та рецензування й які не скасовує жодне рішення:

Reproducibility. (scenario, seed, engine_version) мусить відтворювати прогін побітово. Зміна, через яку це стає недетермінованим, є помилкою, а не функцією.
Походження. Жодних анонімних числових констант — кожен параметр вказує джерело.
Чесність валідації. Кожну можливість позначено як validated (за зовнішнім оракулом) або modelled / not modeled. Нічого не стверджується понад наявні докази. Див. машинно перевірену матрицю в src/verification.rs.
Гігієна. Жодної вказівки на автоматизовані інструменти як авторів ніде в комітах, вмісті чи історії (забезпечується через scripts/check-no-attribution.sh).

Зміну, що не може відповідати планці, відхиляють, якою б корисною вона не була.

Межа між відкритим і закритим#

Kshana має модель відкритого ядра (open-core). Цей репозиторій є і залишається повним відкритим рушієм під AGPL-3.0 — нейтральним еталоном, що має подвійне комерційне ліцензування від Ashforde OÜ (див. LICENSING.md). Проєкт не прийматиме у відкритий репозиторій:

Глибину, що підпадає під експортний контроль або подвійного призначення — справжні бібліотеки загроз, форми хвиль противника чи параметри продуктивності проти глушіння/спуфінгу. Публічний репозиторій обмежується загальними опублікованими моделями та методами (див. CONTRIBUTING.md → Export control). Якщо вагаєтеся, запитайте до внеску.
Конфіденційні дані чи калібрування клієнтів або партнерів.
Копілефтні (GPL/AGPL/LGPL/MPL) залежності — не тому, що вони суперечать власній ліцензії AGPL рушія (вони не суперечать), а тому, що їх не можна перелицензувати в комерційне видання: комерційну ліцензію можна продавати лише на код, яким ми володіємо або який є дозвільним. Залежність із копілефтом заразила б комерційне видання і зруйнувала б подвійне ліцензування. Тому залежності залишаються дозвільними (Apache/MIT/BSD/ISC), що забезпечується через deny.toml.

І навпаки, проєкт не випотрошуватиме відкрите ядро заради закритої цінності: перевірений рушій, публічні опорні точки валідації, реєстр чесності, формат обміну/стандартний формат і канали розповсюдження залишаються відкритими. Знекровлення відкритого ядра — єдина фатальна помилка моделі open-core, і про неї не йдеться.

Випуски#

Семантичне версіонування. До версії 1.0 схема сценарію/результату може змінюватися; зміни, що порушують сумісність, оголошують, а версія схеми обміну (src/interchange.rs::SCHEMA_VERSION) є єдиним джерелом істини щодо сумісності артефактів.
Повноваження на випуск. Публікація (наприклад, cargo publish) — це ручний крок супровідника, що потребує токена реєстру. CI та Release-робочий процес, що запускається за тегом, ніколи не публікують автоматично у зовнішні реєстри — вони лише повторно виконують усі перевірки та додають артефакт збірки. Див. CONTRIBUTING.md → Commits and versioning.

Кодекс поведінки та безпека#

Поведінка регулюється CODE_OF_CONDUCT.md.
Питання безпеки розглядають за процесом приватного розкриття, описаним у SECURITY.md — не відкривайте публічний запит про вразливість.

Торговельна марка#

Назва та логотип Kshana є торговельними марками Ashforde OÜ. Ліцензія (AGPL-3.0 або комерційна ліцензія) охоплює код, а не марки: форк може використовувати код за ліцензією, але не назву Kshana чи канонічну ідентичність розповсюдження. Це зберігає за Ashforde статус цитованого джерела істини і є частиною того, як відкрите ядро залишається нейтральним еталоном.

Внесення змін до цього документа#

Зміни до управління самі пропонують як запит на злиття змін і вирішують за наведеним вище процесом. У міру зміни масштабу проєкту слід очікувати, що цей документ набуде моделі ухвалення рішень із кількома супровідниками; технічну планку він не знизить.

Легкий за задумом. Чесний щодо сьогодення, із заявленим шляхом на майбутнє.