Cómo contribuir a Music Life¶

Gracias por sumarte. Este repositorio lo usan varias personas a la vez, así que estas reglas existen para que nadie pise el trabajo de nadie y para que siempre sepamos qué está decidido y qué no.

1. Flujo de trabajo¶

Abre o elige un issue con la plantilla que corresponda (propuesta de diseño, tarea, decisión o bug). Si es algo pequeño (una errata), puedes ir directo al paso 2.
Crea una rama desde main con un nombre corto y descriptivo, en inglés:
docs/<topic> para documentación (docs/rent-economy)
design/<topic> para propuestas de diseño (design/band-system)
feat/<topic>, fix/<topic> para código (cuando lo haya)
art/<topic>, audio/<topic> para material visual o sonoro
Haz commits pequeños con mensajes claros en español, en imperativo: Añade curva de fans a la guía aplicada.
Abre un Pull Request contra main rellenando la plantilla. Enlaza el issue (Cierra #12).
Revisión: al menos una aprobación de un propietario del área (ver .github/CODEOWNERS). Responde a los comentarios con cambios o con razones.
Merge: lo hace quien abrió el PR una vez aprobado, preferiblemente con squash.

Nunca se escribe directamente en main.

2. Documentación¶

Markdown (.md) por defecto. Se revisa línea a línea en los PR y se lee bien en GitHub.
HTML solo para páginas visuales (pitch, guías maquetadas). Si cambias el .md fuente de una página HTML, actualiza también la página o indícalo en el PR.
Nombres en inglés, contenido en español. El juego será multiidioma, así que los nombres de archivos, carpetas, rutas, ramas y etiquetas van siempre en inglés, en minúsculas y con guiones (docs/concept/v2/vision-v2.md, img/ui-career.jpg). El contenido de los documentos se escribe en español, con los términos de industria en inglés cuando son el estándar (core loop, vertical slice, playtest).
Un documento, un tema. Mejor varios documentos enlazados que uno enorme.
Versiones del concepto: no se reescribe la historia. Una versión nueva del concepto va en una carpeta nueva (docs/concept/v3/) y la anterior queda como histórico.
Juego original: nada de marcas, artistas, canciones ni juegos reales recreados. Todo el mundo del juego (Albor, sellos, Waveline, festivales) es ficticio.

3. Decisiones¶

Cuando algo se decide (motor, modelo de negocio, alcance del MVP, un cambio de diseño relevante), se registra en docs/decisions/ con la plantilla de ese directorio. Así cualquiera que llegue después entiende el porqué sin tener que preguntar.

Si una propuesta contradice una decisión registrada, abre un issue de tipo Decisión para reabrirla en lugar de cambiarla en silencio.

4. Tablero: cómo mover una tarjeta¶

Con el proyecto de GitHub cargado (propuesta 0032), las tarjetas se mueven en el Kanban, con etiquetas set-status/* o con Closes #N en el PR; ver herramientas de producción. Lo que sigue aplica al registro en Markdown.

El plan se sigue en el tablero: una tarjeta en Markdown por paso del apéndice C de la guía aplicada (decisión 0003).

Coge una tarjeta en Listo (todas sus dependencias en Hecho). Para empezar antes, pide permiso a PROD, que lo anota en el registro de la tarjeta.
Cambia el estado por PR: actualiza en el mismo commit la tarjeta (docs/production/board/cards/NNN-<slug>.md), su fila del índice y el resumen por estado del tablero, y el "Estado actual" del README.md raíz si cambia la fase o el paso en curso. En #021, OPS añadirá una comprobación de CI que valide o genere el índice desde las tarjetas. Pasa a En curso al empezar y a En revisión al abrir el PR con el entregable.
El revisor es el de la tarjeta y nunca el autor. Como máximo dos rondas; a la tercera decide el director del área.
Hecho va en el mismo PR que el entregable y vale al fusionarlo. Antes, completa el Registro (herramientas, decisiones, procedencia, tiempo y coste).
Bloqueado siempre lleva en el campo Bloqueo el motivo y a quién se espera.
Pasos con 👤: el agente lo prepara todo y deja la solicitud a Enrique en la tarjeta; ningún agente firma, paga, publica ni abre cuentas.

Si prefieres trabajar con issues, abre uno con la plantilla Ficha de paso; es un espejo de la tarjeta, que es la que manda.

5. Imágenes y archivos pesados¶

Formatos: .jpg para imágenes conceptuales, .png para UI con transparencia, .svg para diagramas.
Máximo recomendado: 1 MB por imagen y 1600 px de ancho para documentos.
Archivos de producción grandes (modelos 3D, audio, texturas fuente, vídeos) no se suben sin hablarlo antes: cuando empiece la producción se activará Git LFS.
Las imágenes compartidas entre documentos van en docs/assets/; las de un documento concreto, junto a él en una carpeta img/.

6. Código (cuando llegue)¶

El código vivirá en code/ (estructura completa en el apéndice F de la guía aplicada). Antes de escribir la primera línea se añadirán aquí las convenciones (motor, estilo, tests, CI). Hasta entonces, cualquier prototipo va en una rama proto/<topic> y no se fusiona en main sin acordarlo.

7. Confidencialidad y trato¶

El repositorio es privado y su contenido, confidencial.
No subas contraseñas, claves ni datos personales.
Crítica directa a las ideas, respeto a las personas.