English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Ми хочемо зробити ваш внесок у OpenCode простим. Ось найчастіше мерджені типи змін:
- Виправлення багів
- Додаткові LSP / форматтери
- Покращення продуктивності LLM
- Підтримка нових постачальників
- Виправлення особливостей середовищ
- Відсутня стандартна поведінка
- Покращення документації
Однак будь-яка функція UI або основного продукту має пройти перевірку дизайну з основною командою до реалізації.
Усі PR мають посилатися на існуючий issue. Перш ніж відкривати PR, відкрийте issue, що описує баг або функцію. Це допомагає мейнтейнерам у triage та запобігає дублюванню роботи. PR без пов'язаного issue можуть бути закриті без перегляду.
Довгі описи PR та issues, згенеровані ШІ, неприйнятні й можуть бути проігноровані. Поважайте час мейнтейнерів:
- Пишіть короткі, сфокусовані описи
- Поясніть, що змінилося і чому, своїми словами
- Якщо не можете пояснити коротко, ваш PR, можливо, занадто великий
Заголовки PR повинні слідувати стандартам conventional commit: feat: нова функція, fix: виправлення бага, docs: документація, chore: обслуговування, refactor: рефакторинг, test: тести.
Повні подробиці щодо налаштування середовища розробки, команд збірки та конфігурації відладчика дивіться в оригіналі англійською CONTRIBUTING.md.