Contribución y seguridad
Dónde notificar problemas, cómo se revisan las pull requests, las comprobaciones locales que hay que ejecutar y la política de seguridad.
Las contribuciones son bienvenidas en toda la organización. Cada repositorio posee un único cometido, así que el primer paso es siempre elegir el correcto. No hay CI: cada repositorio incluye un script de comprobación local y el mantenedor lo ejecuta antes de hacer push, así que ejecute las mismas comprobaciones antes de abrir una pull request.
Dónde informar
Abra el issue en el repositorio que posee el comportamiento:
| Tema | Repositorio |
|---|---|
| Instalación, actualizaciones, paquetes, tema de inicio de sesión | dots |
| Configuración del compositor, atajos de teclado, scripts | hyprland |
| Barra, paneles, widgets, editor | shell |
| Fondos de pantalla, escenas, selector | davincix, background |
| Colores y temas | palettes, theme-sync |
| Hora, clima, calendario | timex |
| Interfaz de ajustes de terminal | xturing |
| Motor de escenas y demonio de fondos de pantalla | x-ports/xwww |
Si no está seguro, use la plantilla de issue de toda la organización y elija el componente allí.
Pull requests
- Mantenga el cambio enfocado: un tema por pull request.
- Use el estilo de commit existente (
feat:,fix:,docs:,chore:,ci:) con un asunto imperativo breve. - Ejecute las comprobaciones de cada repositorio que toque.
- Actualice el
CHANGELOG.mddel repositorio cuando exista; las versiones salen de esas entradas. - Los archivos nuevos usan por defecto la licencia que ya emplea el repositorio: el código es estilo MIT salvo que se indique lo contrario; los fondos de pantalla y la documentación siguen los términos de background.
Comprobaciones locales
| Repositorio | Comando |
|---|---|
| shell | scripts/check.sh |
| hyprland | scripts/check.sh |
| palettes | scripts/check.sh |
| theme-sync | scripts/check.sh |
| xturing | scripts/check.sh |
- Shell:
qmllintsobre cada archivo.qmlynode --checksobre los módulos JS. - Hyprland:
luac -psobre cada módulo de configuración Lua ybash -nsobre los scripts (shellcheckse usa como asesor cuando está instalado). - Paletas: validación del esquema más consistencia de
index.json. - theme-sync:
compileally una prueba de humo de la CLI (--list,--dry-run). - xturing:
cargo fmt --check, clippy con-D warningsy las pruebas.
Guías de estilo
- La documentación se escribe en inglés.
- Las configuraciones y los scripts siguen siendo controlados por la paleta: lea la paleta activa en lugar de codificar colores.
- Prefiera los pequeños ayudantes existentes de cada repositorio a nuevas dependencias.
- Para las escenas de xwww, permanezca dentro del sandbox documentado: solo activos locales, sin temporizadores, sin red y redibujado dirigido por cambios.
Política de seguridad
No abra un issue público para un problema de seguridad. Use en su lugar el sistema de notificación privada de GitHub:
- Abra el repositorio afectado y vaya a Security -> Report a vulnerability (Seguridad -> Notificar una vulnerabilidad; GitHub Security Advisories), o póngase en contacto con el mantenedor indicado en el repositorio.
- Incluya el componente y la versión afectados, una descripción del impacto y una reproducción si la tiene.
- Recibirá un acuse de recibo lo antes posible y crédito en el aviso una vez publicado el arreglo.
Alcance
La pila se ejecuta en la sesión del usuario e instala piezas del sistema:
paquetes, el tema SDDM y /etc/pam.d/quickshell. Los informes sobre el shell,
los scripts de Hyprland, los instaladores, el motor de fondos de pantalla o el
entorno de ejecución de escenas son bienvenidos. Las escenas ejecutan código
escrito por el usuario en el cliente xwww por diseño; el sandbox en tiempo de
ejecución (límites de memoria y pila, tiempo de espera por fotograma, sin E/S,
solo activos locales) está documentado en
equisdots/x-ports.
Versiones compatibles
Solo la última versión de cada repositorio recibe correcciones. dots update
mantiene la instalación en las versiones actuales, y dots doctor informa de
lo que está desincronizado. Consulte
Actualización y diagnóstico.
Consejos prácticos
- Pruebe los instaladores antes de ejecutarlos en una máquina que le importe; usan sudo y cambian la configuración del sistema.
- Revise los scripts antes de bifurcarlos o compartirlos; las configuraciones personales pueden contener rutas o tokens.
- Use el modo dry-run de xturing o una copia de
settings.jsonal experimentar con opciones. - Valide las paletas antes de enviarlas:
python3 tools/validate_palettes.pyen el repositorio de paletas.
Páginas relacionadas
- Arquitectura y repositorios para el diseño y los contratos.
- Actualización y diagnóstico para el flujo de actualización.