Управление проектом Kshana

В этом документе изложено, как управляется Kshana: кто принимает решения, как они принимаются и что проект будет и чего не будет принимать. Он намеренно лёгкий — соразмерный нынешнему масштабу проекта — и честно описывает сегодняшнее положение с единственным сопровождающим и путь к более широкому управлению по мере роста сообщества.

Миссия и область применения#

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

Роли#

Сопровождающий. Сейчас Kshana сопровождает его основатель, Ashforde OÜ (контакт: contact@ashforde.org). Сопровождающий принимает окончательные решения об области применения, архитектуре, выпусках и о том, что включается в код. Это модель благожелательного сопровождающего, названная прямо, а не выдаваемая за несуществующий комитет.
Участники. Все, кто открывает задачу (issue) или запрос на слияние. К вкладу предъявляются требования, изложенные в CONTRIBUTING.md: происхождение каждого числового параметра, проверка по опубликованному соотношению и честность в оценке зрелости.
Будущие коммиттеры. По мере того как устойчивый, качественный вклад будет это оправдывать, право фиксации изменений получат доверенные участники, а этот документ будет обновлён до модели с несколькими сопровождающими (решения по принципу ленивого консенсуса, а разногласия разрешает группа сопровождающих). До тех пор путь таков: вносить вклад, наработать репутацию и получить приглашение.

Как принимаются решения#

Открытое обсуждение. Существенные изменения начинаются с задачи на GitHub, чтобы обоснование, альтернативы и компромиссы были зафиксированы.
Ленивый консенсус. Предложение, по которому по истечении разумного срока нет устойчивых возражений и которое проходит приведённый ниже технический порог, принимается.
При разногласии решает сопровождающий. Если консенсус не достигнут, решение принимает сопровождающий и фиксирует причину. Разногласия разрешаются исходя из миссии и технического порога, а не по старшинству или громкости голоса.

Технический порог (не подлежит обсуждению)#

Это жёсткие инварианты, которые обеспечиваются CI и рецензированием и которые не отменяет ни одно решение:

Reproducibility. (scenario, seed, engine_version) должны побитово воспроизводить прогон. Изменение, из-за которого это перестаёт быть детерминированным, — ошибка, а не функция.
Происхождение. Никаких анонимных числовых констант: каждый параметр ссылается на источник.
Честность валидации. Каждая возможность помечена как validated (по внешнему оракулу) либо как modelled / not modeled. Ничто не утверждается сверх имеющихся доказательств. См. матрицу, проверяемую машиной, в src/verification.rs.
Гигиена. Никаких указаний на авторство автоматизированных инструментов ни в коммитах, ни в содержимом, ни в истории (обеспечивается scripts/check-no-attribution.sh).

Изменение, не проходящее порог, отклоняется, как бы полезно оно ни было.

Граница между открытым и закрытым#

Kshana построен по модели открытого ядра. Этот репозиторий — полный открытый движок под AGPL-3.0, нейтральный эталон, лицензируемый Ashforde OÜ также на коммерческих условиях (см. LICENSING.md), — и остаётся таким. Проект не будет принимать в открытый репозиторий:

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

И наоборот, проект не будет выхолащивать открытое ядро ради проприетарной ценности: проверенный движок, публичные опорные точки валидации, реестр честности, формат обмена и стандартный формат, а также каналы распространения остаются открытыми. Обеднение открытого ядра — единственная фатальная ошибка модели открытого ядра, и оно исключено.

Выпуски#

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

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

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

Товарный знак#

Название и логотип Kshana — товарные знаки Ashforde OÜ. Лицензия (AGPL-3.0 или коммерческая) распространяется на код, а не на знаки: форк может использовать код на условиях лицензии, но не название Kshana и не канонические идентификаторы распространения. Так Ashforde остаётся цитируемым источником истины, и это часть того, как открытое ядро остаётся нейтральным эталоном.

Внесение изменений в этот документ#

Изменения в управлении сами предлагаются запросом на слияние и решаются описанным выше порядком. По мере изменения масштаба проекта следует ожидать, что в этом документе появится модель принятия решений с несколькими сопровождающими; технический порог он не снизит.

Лёгкий по замыслу. Честный в отношении сегодняшнего дня, с обозначенным путём на завтра.