|
| 1 | +# Contribuir a SIMUT |
| 2 | + |
| 3 | +¡Gracias por tu interés en contribuir! SIMUT es un firmware IoT de código abierto para la Raspberry Pi Pico W. Así es como puedes ayudar. |
| 4 | + |
| 5 | +[English](CONTRIBUTING.md) | [Português](CONTRIBUTING.pt-BR.md) | **Español** |
| 6 | + |
| 7 | +## Antes de empezar |
| 8 | + |
| 9 | +- **Abre un issue primero** para discutir tu idea antes de escribir código. Esto evita el esfuerzo en vano si el cambio no encaja en la hoja de ruta del proyecto. |
| 10 | +- Consulta la [Política de Seguridad](SECURITY.md) si tu contribución afecta la autenticación, la red o el manejo de datos. |
| 11 | + |
| 12 | +## Encontrar algo en qué trabajar |
| 13 | + |
| 14 | +Busca los issues etiquetados como [`good first issue`](https://github.com/angeloINTJ/simut/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) — estos están seleccionados para nuevos contribuyentes y abarcan desde documentación hasta pruebas en sistemas embebidos (embedded testing). Cada uno tiene un alcance claro, criterios de aceptación y archivos de referencia para ayudarte a empezar. |
| 15 | + |
| 16 | +| Habilidad | Ejemplos de issues | |
| 17 | +|-------|---------------| |
| 18 | +| C/C++ embedded | Pruebas de HistoryCodec, pruebas del analizador CLI, fuzz testing | |
| 19 | +| Python / DevOps | Entorno de desarrollo Docker, integración continua (CI) con cppcheck, pre-commit hooks | |
| 20 | +| Documentación / i18n | Traducción al español, insignias de validación social | |
| 21 | +| Diseño | Nuevo tema de color integrado | |
| 22 | + |
| 23 | +¿No estás seguro de por dónde empezar? Deja un comentario en cualquier `good first issue` y el mantenedor te ayudará a definir su alcance. |
| 24 | + |
| 25 | +## Configuración del Entorno de Desarrollo |
| 26 | +### Opción A — Docker (recomendado para nuevos contribuyentes) |
| 27 | + |
| 28 | +No hay necesidad de instalar PlatformIO, Python o el toolchain de ARM localmente. Docker se encarga de todo. |
| 29 | + |
| 30 | +**Requisitos previos:** [Docker Desktop](https://www.docker.com/products/docker-desktop/) (macOS / Windows) o [Docker Engine](https://docs.docker.com/engine/install/) (Linux) |
| 31 | + |
| 32 | +```bash |
| 33 | +# Clonar el repositorio |
| 34 | +git clone https://github.com/angeloINTJ/simut.git |
| 35 | +cd simut |
| 36 | + |
| 37 | +# Compilar el firmware para la Raspberry Pi Pico W |
| 38 | +docker compose run build |
| 39 | + |
| 40 | +# Ejecutar todas las pruebas unitarias nativas |
| 41 | +docker compose run test |
| 42 | +``` |
| 43 | + |
| 44 | +> **Nota sobre la primera ejecución:** Docker construirá la imagen y descargará el toolchain de ARM (~500 MB). Esto solo ocurre una vez — las ejecuciones posteriores usan la imagen en caché y son rápidas. |
| 45 | +> |
| 46 | +> **Usuarios de Linux:** Exporten `UID` y `GID` antes de ejecutar para que los artefactos de compilación no pertenezcan al usuario root: |
| 47 | +> ```bash |
| 48 | +> export UID GID |
| 49 | +> docker compose run build |
| 50 | +> ``` |
| 51 | +
|
| 52 | +| Comando | Comando equivalente en PlatformIO | |
| 53 | +|---|---| |
| 54 | +| `docker compose run build` | `pio run -e pico_w_release` | |
| 55 | +| `docker compose run test` | `pio test -e native && pio test -e native_history` | |
| 56 | +
|
| 57 | +--- |
| 58 | +
|
| 59 | +### Opción B — PlatformIO Local |
| 60 | +
|
| 61 | +### Requisitos Previos |
| 62 | +
|
| 63 | +- [PlatformIO Core](https://platformio.org/install/cli) 6.x o posterior |
| 64 | +- Raspberry Pi Pico W |
| 65 | +- Para pruebas de hardware: Pantalla ILI9341 TFT + Panel táctil XPT2046 + Sensor DS18B20 |
| 66 | +
|
| 67 | +### Compilación |
| 68 | +
|
| 69 | +```bash |
| 70 | +# Clonar el repositorio |
| 71 | +git clone https://github.com/angeloINTJ/simut.git |
| 72 | +cd simut |
| 73 | +
|
| 74 | +# Compilar el firmware |
| 75 | +pio run -e pico_w_release |
| 76 | +
|
| 77 | +# Ejecutar pruebas unitarias |
| 78 | +pio test -e native |
| 79 | +``` |
| 80 | +
|
| 81 | +### Flashear al Dispositivo |
| 82 | + |
| 83 | +```bash |
| 84 | +# Flashear el firmware |
| 85 | +pio run -e pico_w_release -t upload |
| 86 | + |
| 87 | +# Subir datos de LittleFS (paquetes de idiomas, favicon) |
| 88 | +pio run -e pico_w_release -t uploadfs |
| 89 | +``` |
| 90 | + |
| 91 | +## Convenciones de Código |
| 92 | + |
| 93 | +- **Idioma:** Todos los comentarios, nombres de variables y documentación deben estar en inglés. |
| 94 | +- **Nomenclatura:** `camelCase` para métodos y variables, `_underscorePrefix` para miembros privados, `UPPER_SNAKE_CASE` para constantes. |
| 95 | +- **Indentación:** Tabulaciones para indentar, espacios para alinear. |
| 96 | +- **Estilo de llaves:** K&R — la llave de apertura en la misma línea que la declaración. |
| 97 | +- **Doxygen:** Todos los métodos públicos en los archivos de cabecera (headers) deben tener documentación `@brief`. |
| 98 | +- **NULL:** Usa `nullptr` en código C++ (no `NULL`). |
| 99 | +- **Comentarios:** Explica el *por qué*, no el *qué* — el código en sí mismo es el "qué". |
| 100 | + |
| 101 | +## Presupuesto de Memoria Flash |
| 102 | + |
| 103 | +El espacio en la memoria flash es críticamente ajustado (~98.7% en uso). Antes de añadir nuevas características, considera: |
| 104 | + |
| 105 | +1. ¿Se puede optimizar para usar menos espacio? |
| 106 | +2. ¿Puede reemplazar algo de menor valor? |
| 107 | +3. ¿Puede residir en LittleFS en lugar del binario del firmware? |
| 108 | + |
| 109 | +## Proceso de Pull Request |
| 110 | + |
| 111 | +1. Abre un issue describiendo el cambio que quieres realizar. |
| 112 | +2. Haz un fork del repositorio y crea una rama (`feature/my-feature`). |
| 113 | +3. Escribe tu código y pruébalo en hardware si es posible. |
| 114 | +4. Asegúrate de que `pio run -e pico_w_release` se compile con **cero advertencias**. |
| 115 | +5. Asegúrate de que `pio test -e native` pase todas las pruebas. |
| 116 | +6. Actualiza la documentación en `docs/` si tu cambio afecta el comportamiento de cara al usuario. |
| 117 | +7. Envía el PR con una descripción clara, haciendo referencia al número de issue. |
| 118 | +8. La lista de verificación de la plantilla de PR te guiará en los pasos restantes. |
| 119 | + |
| 120 | +## Pruebas |
| 121 | + |
| 122 | +- Las pruebas unitarias usan el framework [Unity](http://www.throwtheswitch.org/unity). |
| 123 | +- Ejecútalas con `pio test -e native`. |
| 124 | +- Añade pruebas para nueva lógica de validación, codificación/decodificación y rutas críticas de seguridad. |
| 125 | +- Se requieren pruebas de hardware para cambios en la pantalla, sensores, WiFi y OTA. |
| 126 | + |
| 127 | +## Comunidad |
| 128 | + |
| 129 | +- Reporta errores a través de [GitHub Issues](https://github.com/angeloINTJ/simut/issues). |
| 130 | +- Haz preguntas en [GitHub Discussions](https://github.com/angeloINTJ/simut/discussions). |
| 131 | +- Sigue el [Código de Conducta](CODE_OF_CONDUCT.md). |
| 132 | +- Vulnerabilidades de seguridad: sigue la [Política de Seguridad](SECURITY.md) — no abras un issue público. |
| 133 | + |
| 134 | +## Herramientas de IA |
| 135 | + |
| 136 | +Usamos asistentes de IA (Claude, Copilot, etc.) como **herramientas de ingeniería**, no como sustitutos del criterio humano. La IA ayuda con código repetitivo (boilerplate), borradores de documentación y la estructura base de las pruebas, pero las decisiones de arquitectura, los tiempos (timing) de PIO, el presupuesto de la memoria flash y el endurecimiento de la seguridad son trabajo humano. Si usas IA en tu contribución, está bien, solo revisa el resultado. El código generado es tu responsabilidad. |
| 137 | + |
| 138 | +## Licencia |
| 139 | + |
| 140 | +Al contribuir, aceptas que tus contribuciones estarán licenciadas bajo la Licencia MIT. |
0 commit comments