Participar en las metodologías¶
Puedes mejorar ASILO, MILPA y SCAFFOLD sin pertenecer a Kasai Labs. Aceptamos aportaciones de redacción, ejemplos ficticios o casos reales depurados, traducción, accesibilidad, fuentes y evaluación de requisitos. También puedes señalar una contradicción o proponer un cambio metodológico sin escribir código.
Estas páginas son la fuente común de las políticas de contribución, gobernanza y convivencia. Se mantienen en Git y se muestran en MkDocs. Los archivos de entrada del repositorio enlazan estas políticas; una propuesta de cambio utiliza el mismo proceso de revisión que el resto de la documentación.
Participar en cualquier idioma¶
Puedes abrir Issues, comentar y proponer cambios en el idioma que prefieras. No necesitas escribir en español ni en inglés para participar. Quienes mantienen el repositorio pueden usar traducción automática para entender tu aportación y te lo dirán cuando lo hagan; si una frase puede leerse de dos maneras, preguntarán antes de decidir. El texto normativo se mantiene en español, por lo que una propuesta aceptada se redacta después en español y se revisa contigo cuando sea posible.
Elegir una aportación¶
| Quieres… | Primer paso |
|---|---|
| Corregir una errata o un enlace | Envía un PR (solicitud de cambios) con la corrección y su comprobación. |
| Aclarar una explicación o traducción | Identifica el texto español de referencia y explica la diferencia. |
| Añadir una fuente o ejemplo | Explica qué afirmación respalda; usa datos ficticios y referencias verificables. |
| Aportar un caso real depurado | Obtén el consentimiento escrito de las personas o de la organización implicadas y anonimiza el caso; una persona mantenedora revisa la anonimización antes de integrarlo. No adjuntes el consentimiento en la Issue ni en el PR. |
| Cambiar un requisito o su alcance | Abre una Issue con el ID, la edición, el problema y el impacto esperado. |
| Revisar una propuesta | Comenta en su Issue o PR con argumentos y fuentes. |
| Comunicar un problema sensible | Sigue el procedimiento de reporte. |
Un fork es una copia del repositorio donde puedes trabajar sin permisos de escritura en el original. Una rama reúne los cambios de una aportación. Un pull request (PR) propone integrar esa rama y conserva su discusión y revisión. Codeberg documenta ese recorrido en su guía de forks y PR.
De la idea al PR¶
- Consulta el repositorio y localiza la página o el requisito afectado. Para un cambio sustantivo, abre una Issue con problema, alcance y evidencia. Una corrección menor puede empezar directamente como PR.
- Crea un fork en tu cuenta de Codeberg y una rama descriptiva, por ejemplo
docs/milpa-provenance-example. Mantén una aportación concreta por rama. - Edita los archivos necesarios. Puedes revisar Markdown sin instalar herramientas; para compilar el sitio utiliza las instrucciones y dependencias del propio repositorio. Esta participación no requiere acceso a otros repositorios o servicios del ecosistema.
- Redacta y revisa primero el español. Una traducción identifica la página y revisión fuente, conserva IDs, condiciones, cifras y fuerza normativa, y registra las diferencias por resolver. El inglés es informativo; usa los axiomas editoriales.
- Ejecuta las comprobaciones documentadas que correspondan al cambio. Si no puedes ejecutarlas, indícalo en el PR con la razón; no presentes una comprobación pendiente como aprobada.
- Envía el PR desde tu rama. Describe problema, archivos e IDs afectados, resultado, evidencia, impacto sobre versiones y comprobaciones. Enlaza la Issue cuando exista y declara la asistencia de inteligencia artificial (IA) pertinente.
- Responde a la revisión. El mantenedor integra cuando quedan resueltas las observaciones y registrada la decisión exigida por el tipo de cambio. La gobernanza explica quién revisa, quién decide y cómo reconsiderar una decisión.
Comprobar la aportación¶
Con Python 3.11 o posterior, crea un entorno virtual e instala requirements-docs.txt desde
la raíz del clon. Con ese entorno activado, ejecuta la revisión común:
python scripts/check-all-docs.py
El comando comprueba enlaces, términos, integridad normativa, fuentes de diagramas y
traducciones; después compila MkDocs con --strict en una carpeta temporal propia y revisa
patrones sensibles en fuentes y sitio. La coincidencia de un hash detecta cambios; no demuestra
equivalencia lingüística. Un escáner sin hallazgos tampoco demuestra ausencia de datos sensibles.
Para un cambio visual, revisa también el sitio en escritorio y móvil, la explicación textual, las etiquetas y los SVG (gráficos vectoriales escalables). Registra entorno, resultado y pendientes. No es una auditoría del software de implementación ni una certificación de accesibilidad o seguridad.
Fuentes, autoría y asistencia de IA¶
La persona contribuyente responde por el texto que presenta, aunque use IA para redactar, traducir o investigar. Indica qué tarea asistió la herramienta y qué verificaste: por ejemplo, «IA para primer borrador; fuentes y equivalencia revisadas por la persona contribuyente». La declaración no sustituye la revisión de las fuentes ni concede autoridad a un agente. Usa ejemplos sintéticos o casos reales depurados con consentimiento escrito, y evita enviar datos sensibles a herramientas externas. Comprueba que los términos del proveedor de IA te permiten aportar el resultado y no subas material de terceros que no puedas compartir. Si un interés comercial, laboral o personal se relaciona con tu propuesta, decláralo en el PR; declararlo no impide contribuir.
Conserva atribución, licencia y procedencia de cada recurso. Aporta sólo material que puedas
distribuir bajo la licencia aplicable. El texto propio está bajo CC BY-SA 4.0, salvo
indicación específica; el resumen oficial
explica atribución, cambios y compartir adaptaciones bajo sus términos. Consulta también
LICENSE y ASSETS.md en el repositorio para texto completo y excepciones de recursos.
La revisión de un PR regula su integración en este repositorio; no restringe los derechos
que la licencia concede para copiar, adaptar o mantener un fork.
Los recursos de marca y las fuentes tipográficas conservan sus condiciones particulares.
Scripts, pruebas, plantillas, CSS y JavaScript están bajo Apache-2.0, porque Creative Commons
recomienda licencias específicas para software.
REUSE.toml fija la licencia de cada ruta y NOTICE la resume. Una aportación entra bajo la
licencia del archivo que cambia; no se pide cesión de derechos.
Empezar sin un cambio preparado¶
Abre una Issue breve con la ruta relativa, el párrafo o ID y la pregunta que no puedes resolver. No incluyas credenciales, rutas personales ni expedientes reales o capturas sin depurar. Una observación concreta ya ayuda a mejorar la documentación. La discusión pública registra participación; por sí sola no acredita aprobación comunitaria ni adopción del método.