English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Chcemy, aby wkład w OpenCode był łatwy. Oto najczęściej mergowane typy zmian:
- Poprawki błędów
- Dodatkowe LSP / Formattery
- Usprawnienia wydajności LLM
- Wsparcie nowych dostawców
- Poprawki specyficzne dla środowisk
- Brakujące standardowe zachowanie
- Usprawnienia dokumentacji
Jednak każda funkcja UI lub główna funkcjonalność produktu musi przejść przegląd projektu z głównym zespołem przed implementacją.
Wszystkie PR muszą odwoływać się do istniejącego issue. Przed otwarciem PR otwórz issue opisujące błąd lub funkcję. Pomaga to opiekunom w triage i zapobiega powieloną pracą. PR bez powiązanego issue mogą zostać zamknięte bez przeglądu.
Długie, generowane przez SI opisy PR i issues nie są akceptowalne i mogą być ignorowane. Szanuj czas opiekunów:
- Pisz krótkie, skupione opisy
- Wyjaśnij co się zmieniło i dlaczego własnymi słowami
- Jeśli nie potrafisz wyjaśnić krótko, twój PR może być zbyt duży
Tytuły PR powinny przestrzegać standardów conventional commit: feat: nowa funkcja, fix: poprawka błędu, docs: dokumentacja, chore: konserwacja, refactor: refaktoryzacja, test: testy.
Pełne szczegóły dotyczące konfiguracji środowiska deweloperskiego, poleceń budowania i konfiguracji debuggera znajdują się w angielskim oryginale CONTRIBUTING.md.