Traducción automática, no revisada por un hablante nativo. El inglés es la referencia.

ProyectoEditar en GitHubFuente: GOVERNANCE.md

Gobernanza de Kshana

Este documento expone cómo se gobierna Kshana: quién toma las decisiones, cómo, y qué absorberá y qué no absorberá el proyecto. Es deliberadamente ligero, proporcional al tamaño actual del proyecto, y es honesto sobre la realidad actual de un único responsable y sobre el camino hacia una gobernanza más amplia a medida que crezca la comunidad.

Misión y alcance#

Kshana es una referencia neutral, reproducible y validada con honestidad sobre el rendimiento y la resiliencia de PNT híbrido cuántico/clásico. La misión fija el listón de cada decisión: corrección, citas y reproducibilidad por encima de la amplitud. El alcance honesto está documentado en docs/CAPABILITY.md y el estado de validación en docs/VALIDATION.md; las propuestas se sopesan frente a ese alcance, no frente al número de funciones.

Roles#

  • Responsable. Kshana la mantiene actualmente su fundadora, Ashforde OÜ (contacto: contact@ashforde.org). El responsable es quien toma la decisión final sobre el alcance, el diseño, las versiones y lo que se incorpora. Es un modelo de responsable benevolente, expuesto con claridad en lugar de disfrazado de un comité que no existe.
  • Colaboradores. Cualquiera que abra una incidencia o un pull request. Las contribuciones se someten al umbral de CONTRIBUTING.md: procedencia de cada parámetro numérico, validación frente a una relación publicada y honestidad sobre la madurez.
  • Futuros committers. Cuando una contribución sostenida y de calidad lo justifique, se concederán derechos de commit a colaboradores de confianza y este documento se actualizará a un modelo de varios responsables (decisiones por consenso tácito, con el grupo de responsables resolviendo los desacuerdos). Hasta entonces, el camino es: contribuir, construir un historial y recibir la invitación.

Cómo se toman las decisiones#

  1. Debate abierto. Los cambios sustantivos comienzan como una incidencia de GitHub, de modo que la justificación, las alternativas y las contrapartidas queden registradas.
  2. Consenso tácito. Una propuesta sin objeciones sostenidas tras un plazo razonable, y que supera el umbral técnico de más abajo, sigue adelante.
  3. El responsable decide si hay desacuerdo. Cuando no se alcanza consenso, decide el responsable y deja constancia del motivo. El desacuerdo se resuelve con la misión y el umbral técnico, no con la antigüedad ni el volumen.

El umbral técnico (no negociable)#

Son invariantes estrictas, aplicadas por CI y por revisión, que ninguna decisión anula:

  • Reproducibility. (scenario, seed, engine_version) debe reproducir una ejecución bit a bit. Un cambio que lo vuelva no determinista es un error, no una función.
  • Procedencia. Ninguna constante numérica anónima: cada parámetro cita una fuente.
  • Honestidad de la validación. Cada capacidad se etiqueta como validated (frente a una referencia independiente externa) o como modelled / not modeled. No se afirma nada más allá de su evidencia. Véase la matriz verificada por máquina en src/verification.rs.
  • Higiene. Ninguna atribución a herramientas automáticas en ningún lugar de los commits, el contenido o el historial (lo aplica scripts/check-no-attribution.sh).

Un cambio que no puede alcanzar el umbral se rechaza, por útil que fuera.

La frontera entre abierto y cerrado#

Kshana es open-core. Este repositorio es, y seguirá siendo, el motor AGPL-3.0 abierto completo, la referencia neutral, con licencia dual comercial de Ashforde OÜ (véase LICENSING.md). El proyecto no aceptará en el repositorio abierto:

  • Profundidad sujeta a control de exportaciones o de doble uso: bibliotecas de amenazas reales, formas de onda de adversarios o parámetros de rendimiento antiinterferencia/antispoofing. El repositorio público se limita a modelos y métodos genéricos y publicados (véase CONTRIBUTING.md → Control de exportaciones). Si hay dudas, pregunte antes de contribuir.
  • Datos o calibración confidenciales de clientes o socios.
  • Copyleft (GPL/AGPL/LGPL/MPL) en las dependencias: no porque choquen con la propia licencia AGPL del motor (no chocan), sino porque no pueden relicenciarse en la edición comercial: solo podemos vender una licencia comercial sobre código que poseemos o que es permisivo. Una dependencia con copyleft contaminaría la edición comercial y rompería la licencia dual. Por ello las dependencias siguen siendo permisivas (Apache/MIT/BSD/ISC), lo cual aplica deny.toml.

A la inversa, el proyecto no vaciará el núcleo abierto para empujar valor propietario: el motor validado, los anclajes públicos de validación, el registro de honestidad, el formato de intercambio/estándar y los canales de distribución siguen siendo abiertos. Asfixiar el núcleo abierto es el único error fatal del open-core, y queda descartado.

Versiones#

  • Versionado semántico. Antes de la 1.0 el esquema de escenarios y resultados puede cambiar; los cambios incompatibles se señalan, y la versión del esquema de intercambio (src/interchange.rs::SCHEMA_VERSION) es la única fuente de verdad sobre la compatibilidad de artefactos.
  • Autoridad de publicación. Publicar (p. ej. cargo publish) es un paso manual del responsable que requiere un token de registro. CI y el flujo de Release activado por etiqueta nunca publican automáticamente en registros externos: solo vuelven a ejecutar todas las comprobaciones y adjuntan un artefacto de compilación. Véase CONTRIBUTING.md → Commits y versionado.

Código de conducta y seguridad#

  • La conducta se rige por CODE_OF_CONDUCT.md.
  • Los problemas de seguridad siguen el proceso de divulgación privada de SECURITY.md; no abra una incidencia pública por una vulnerabilidad.

Marca registrada#

El nombre y el logotipo de Kshana son marcas registradas de Ashforde OÜ. La licencia (AGPL-3.0 o una licencia comercial) cubre el código, no las marcas: una bifurcación puede usar el código bajo la licencia, pero no el nombre Kshana ni la identidad canónica de distribución. Así Ashforde sigue siendo la fuente de verdad citada, y es parte de cómo el núcleo abierto sigue siendo una referencia neutral.

Modificación de este documento#

Los cambios de gobernanza se proponen a su vez como un pull request y se deciden mediante el proceso descrito arriba. A medida que cambie la escala del proyecto, cabe esperar que este documento incorpore un modelo de decisión de varios responsables; no rebajará el umbral técnico.

Ligera por diseño. Honesta sobre hoy, con un camino declarado para mañana.