English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Vogliamo renderti facile contribuire a OpenCode. Ecco i tipi di modifiche più comunemente mergiate:
- Correzioni di bug
- LSP / Formatter aggiuntivi
- Miglioramenti delle prestazioni LLM
- Supporto per nuovi provider
- Correzioni per particolarità di ambienti
- Comportamento standard mancante
- Miglioramenti alla documentazione
Tuttavia, qualsiasi funzionalità di UI o core del prodotto deve passare attraverso una revisione di design con il team principale prima dell'implementazione.
Tutte le PR devono referenziare una issue esistente. Prima di aprire una PR, apri una issue che descriva il bug o la funzionalità. Aiuta i manutentori a triare ed evita lavoro duplicato. Le PR senza issue collegata possono essere chiuse senza revisione.
Descrizioni di PR e issue lunghe generate da IA non sono accettabili e possono essere ignorate. Rispetta il tempo dei manutentori:
- Scrivi descrizioni brevi e mirate
- Spiega cosa è cambiato e perché con parole tue
- Se non puoi spiegarlo brevemente, la tua PR potrebbe essere troppo grande
I titoli PR devono seguire gli standard conventional commit: feat: nuova funzionalità, fix: correzione di bug, docs: documentazione, chore: manutenzione, refactor: refactoring, test: test.
Per dettagli completi sulla configurazione dell'ambiente di sviluppo, comandi di build e configurazione del debugger, consulta l'originale in inglese CONTRIBUTING.md.