El apunte admite aportes de terceros, pero no como edición directa sin curaduría.
Toda contribución debería entrar por un canal explícito, quedar trazable y revisarse antes de incorporarse al material publicado.
Canales admitidos¶
| Canal | Cuándo conviene usarlo | Qué debería incluir |
|---|---|---|
| Issue tracker del repositorio | Errores, referencias rotas, sugerencias editoriales, capítulos confusos, pedidos de mejora | archivo afectado, problema observado, propuesta concreta y contexto |
| Pull request del repositorio | Cambios ya implementados sobre archivos del sitio | alcance del cambio, archivos tocados, motivo y referencia al issue si existe |
Correo institucional mrvilugron@unrn.edu.ar | Comentarios sensibles, observaciones no públicas, consultas institucionales o aportes que todavía no están listos para abrirse | tema, motivación, material involucrado y forma de contacto |
Canal recomendado según el tipo de aporte¶
si el aporte describe un problema o una mejora, conviene abrir primero un issue,
si el aporte ya trae una solución concreta, conviene abrir un pull request,
si el aporte no debería discutirse en público, conviene usar email.
Qué tipos de aporte son útiles¶
Se consideran aportes valiosos, entre otros:
corrección de errores conceptuales o tipográficos,
mejora de navegación, TOC o referencias cruzadas,
clarificación pedagógica de una explicación,
propuesta de ejercicios o ejemplos,
mejora de una infografía SVG,
detección de material desactualizado o inconsistente.
Qué debería traer una buena contribución¶
Para reducir idas y vueltas, conviene que el aporte indique:
archivo o sección afectada,
problema concreto detectado,
por qué ese problema importa,
propuesta de corrección o mejora,
si corresponde, referencia a reglas de
reglas/o deeditorial/.
Criterios de revisión¶
Un aporte externo no debería incorporarse solo porque está bien intencionado.
Antes de integrarlo, conviene revisar:
| Criterio | Pregunta de control |
|---|---|
| Coherencia editorial | ¿respeta la estructura y el tono del sitio? |
| Coherencia pedagógica | ¿encaja con el recorrido de la materia y el enfoque late objects? |
| Consistencia técnica | ¿no contradice capítulos o reglas ya publicadas? |
| Trazabilidad | ¿queda claro por qué se hizo el cambio? |
| Publicabilidad | ¿está listo para figurar en el contenido vigente? |
Flujo recomendado para issues¶
describir el problema con enlace o ruta de archivo,
clasificar si es error, mejora, duda o propuesta,
acordar el alcance de la corrección,
resolverlo con commit o PR asociado,
cerrar el issue cuando el cambio ya quedó integrado.
Flujo recomendado para pull requests¶
mantener el cambio acotado a un problema claro,
explicar qué se modificó y por qué,
enlazar el issue relacionado si existe,
evitar mezclar correcciones editoriales independientes en un mismo PR,
dejar el contenido alineado con
editorial/y conmyst.ymlsi corresponde.
Uso del email¶
El email no debería reemplazar al issue tracker para correcciones rutinarias.
Conviene usarlo cuando:
hay datos o contexto que no corresponde publicar,
el aporte es preliminar y todavía no tiene forma de issue o PR,
la consulta requiere coordinación institucional,
o el remitente necesita un canal más directo antes de abrir un cambio público.
Si un aporte recibido por email termina generando trabajo editorial real, conviene trasladarlo después a un issue o a un PR para que quede trazabilidad.
Regla editorial de integración¶
La existencia de un issue, un PR o un email no convierte automáticamente el contenido en parte del apunte.
El material recién pasa a ser contenido vigente cuando:
fue revisado,
quedó alineado con las reglas editoriales,
se integró al repositorio,
y forma parte de la versión publicada del sitio.
Próximo paso¶
Si el aporte implica modificar páginas existentes o sumar material nuevo, conviene revisar también estado