English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Queremos facilitar sua contribuição ao OpenCode. Aqui estão os tipos de mudanças mais comumente mergeados:
- Correções de bugs
- LSPs / formatters adicionais
- Melhorias de desempenho do LLM
- Suporte a novos provedores
- Correções para peculiaridades de ambiente
- Comportamento padrão ausente
- Melhorias na documentação
No entanto, qualquer funcionalidade de UI ou produto central deve passar por uma revisão de design com o time principal antes da implementação.
Todos os PRs devem referenciar uma issue existente. Antes de abrir um PR, abra uma issue descrevendo o bug ou recurso. Isso ajuda os mantenedores na triagem e evita trabalho duplicado. PRs sem issue vinculada podem ser fechados sem revisão.
Descrições longas de PRs e issues geradas por IA não são aceitáveis e podem ser ignoradas. Respeite o tempo dos mantenedores:
- Escreva descrições curtas e focadas
- Explique o que mudou e por quê com suas próprias palavras
- Se você não consegue explicá-lo brevemente, seu PR pode estar grande demais
Os títulos de PR devem seguir os padrões de conventional commit: feat: novo recurso, fix: correção de bug, docs: documentação, chore: manutenção, refactor: refatoração, test: testes.
Para detalhes completos sobre configuração do ambiente de desenvolvimento, comandos de build e configuração do depurador, consulte o original em inglês CONTRIBUTING.md.