English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Queremos facilitarte la contribución a OpenCode. Estos son los tipos de cambios más comúnmente mergeados:
- Corrección de bugs
- LSPs / Formatters adicionales
- Mejoras en el rendimiento del LLM
- Soporte para nuevos proveedores
- Correcciones para particularidades de entornos
- Comportamiento estándar faltante
- Mejoras en la documentación
Sin embargo, cualquier funcionalidad de UI o producto principal debe pasar por una revisión de diseño con el equipo central antes de implementarse.
Todos los PRs deben referenciar un issue existente. Antes de abrir un PR, abre un issue describiendo el bug o la funcionalidad. Esto ayuda a los maintainers a triar y evita trabajo duplicado. Los PRs sin issue vinculado pueden cerrarse sin revisión.
Las descripciones de PR e issues largas generadas por IA no son aceptables y pueden ser ignoradas. Respeta el tiempo de los maintainers:
- Escribe descripciones cortas y enfocadas
- Explica qué cambió y por qué con tus propias palabras
- Si no puedes explicarlo brevemente, tu PR puede ser demasiado grande
Los títulos de PR deben seguir los estándares de conventional commit: feat: nueva funcionalidad, fix: corrección de bug, docs: documentación, chore: mantenimiento, refactor: refactorización, test: pruebas.
Para detalles completos sobre configuración del entorno de desarrollo, comandos de build y configuración del debugger, consulta el original en inglés CONTRIBUTING.md.