English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Nous voulons vous faciliter la contribution à OpenCode. Voici les types de changements les plus souvent mergés :
- Corrections de bugs
- LSPs / Formateurs supplémentaires
- Améliorations des performances LLM
- Support de nouveaux fournisseurs
- Corrections pour particularités d'environnements
- Comportement standard manquant
- Améliorations de la documentation
Cependant, toute fonctionnalité UI ou cœur de produit doit passer par une revue de design avec l'équipe principale avant implémentation.
Tous les PRs doivent référencer une issue existante. Avant d'ouvrir un PR, ouvrez une issue décrivant le bug ou la fonctionnalité. Cela aide les mainteneurs à trier et évite le travail en double. Les PRs sans issue liée peuvent être fermés sans revue.
Les descriptions de PR et les issues longues générées par IA ne sont pas acceptables et peuvent être ignorées. Respectez le temps des mainteneurs :
- Écrivez des descriptions courtes et ciblées
- Expliquez ce qui a changé et pourquoi avec vos propres mots
- Si vous ne pouvez pas l'expliquer brièvement, votre PR est peut-être trop gros
Les titres de PR doivent suivre les standards conventional commit : feat: nouvelle fonctionnalité, fix: correction de bug, docs: documentation, chore: maintenance, refactor: refactorisation, test: tests.
Pour les détails complets sur la configuration de l'environnement de développement, les commandes de build et la configuration du débogueur, consultez l'original en anglais CONTRIBUTING.md.