English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Wir möchten Ihnen die Mitarbeit an OpenCode erleichtern. Hier die am häufigsten gemergten Änderungstypen:
- Bugfixes
- Zusätzliche LSPs / Formatter
- Verbesserungen der LLM-Performance
- Unterstützung neuer Anbieter
- Umgebungsspezifische Korrekturen
- Fehlendes Standardverhalten
- Dokumentationsverbesserungen
Jede UI- oder Kernfunktion muss jedoch vor der Umsetzung einen Design-Review mit dem Kernteam durchlaufen.
Alle PRs müssen auf ein existierendes Issue verweisen. Öffnen Sie vor einem PR zunächst ein Issue, das den Bug oder das Feature beschreibt. Das erleichtert das Triage der Maintainer und verhindert doppelte Arbeit. PRs ohne verknüpftes Issue können ohne Review geschlossen werden.
Lange, KI-generierte PR-Beschreibungen und Issues sind nicht akzeptabel und können ignoriert werden. Respektieren Sie die Zeit der Maintainer:
- Schreiben Sie kurze, fokussierte Beschreibungen
- Erklären Sie in eigenen Worten, was sich warum geändert hat
- Wenn Sie es nicht kurz erklären können, ist Ihr PR vielleicht zu groß
PR-Titel sollten dem Conventional-Commit-Standard folgen: feat: neues Feature, fix: Bugfix, docs: Dokumentation, chore: Wartung, refactor: Refactoring, test: Tests.
Vollständige Details zur Einrichtung der Entwicklungsumgebung, zu Build-Befehlen und Debugger-Konfiguration finden Sie im englischen Original CONTRIBUTING.md.