Roo-Code/locales/pl/CONTRIBUTING.md

English • Català • Deutsch • Español • Français • हिंदी • Italiano • Nederlands • Русский

日本語 • 한국어 • Polski • Português (BR) • Türkçe • Tiếng Việt • 简体中文 • 繁體中文

Współtworzenie Roo Code

Roo Code to projekt napędzany przez społeczność i bardzo cenimy każdy wkład. Aby zapewnić płynny i skuteczny proces dla wszystkich, działamy według zasady "Issue-First". Oznacza to, że każda praca powinna być powiązana z GitHub Issue przed zgłoszeniem Pull Requesta (szczegóły w naszej Polityce PR). Przeczytaj ten przewodnik uważnie, aby dowiedzieć się, jak możesz współtworzyć. Ten przewodnik opisuje, jak współtworzyć Roo Code – czy to naprawiając błędy, dodając funkcje, czy ulepszając dokumentację.

Spis treści

• I. Zanim zaczniesz współtworzyć
  • 1. Kodeks postępowania
  • 2. Zrozumienie roadmapy projektu
    • Wsparcie providerów
    • Wsparcie modeli
    • Wsparcie systemów
    • Dokumentacja
    • Stabilność
    • Internacjonalizacja
  • 3. Dołącz do społeczności Roo Code
• II. Znajdowanie i planowanie swojego wkładu
  • 1. Typy wkładów
  • 2. Kluczowa zasada: podejście Issue-First
  • 3. Decydowanie, nad czym pracować
  • 4. Zgłaszanie błędów lub problemów
• III. Proces rozwoju i zgłaszania
  • 1. Konfiguracja środowiska
  • 2. Wytyczne dotyczące pisania kodu
  • 3. Zgłaszanie kodu: proces Pull Request (PR)
    • Pull Requesty w wersji roboczej
    • Opis Pull Requesta
    • Polityka Pull Request (PR)
      • Cel
      • Podejście Issue-First
      • Warunki dla otwartych PR
      • Procedura
      • Odpowiedzialności
• IV. Prawne
  • Umowa współtwórcy

I. Zanim zaczniesz współtworzyć

Najpierw zapoznaj się ze standardami społeczności i kierunkiem projektu.

1. Kodeks postępowania

Wszyscy współtwórcy muszą przestrzegać naszego Kodeksu postępowania. Przeczytaj go przed rozpoczęciem współtworzenia.

2. Zrozumienie roadmapy projektu

Roo Code ma jasną roadmapę rozwoju, która wyznacza nasze priorytety i przyszły kierunek. Zrozumienie roadmapy pomoże ci:

• Dopasować swój wkład do celów projektu
• Znaleźć obszary, w których twoja wiedza będzie najbardziej wartościowa
• Zrozumieć kontekst niektórych decyzji projektowych
• Zainspirować się do nowych funkcji wspierających naszą wizję

Obecna roadmapa skupia się na sześciu kluczowych filarach:

Wsparcie providerów

Chcemy dobrze wspierać jak najwięcej providerów:

• Więcej wsparcia "OpenAI Compatible"
• xAI, Microsoft Azure AI, Alibaba Cloud Qwen, IBM Watsonx, Together AI, DeepInfra, Fireworks AI, Cohere, Perplexity AI, FriendliAI, Replicate
• Ulepszone wsparcie dla Ollama i LM Studio

Wsparcie modeli

Chcemy, aby Roo działał na jak największej liczbie modeli, w tym lokalnych:

• Wsparcie modeli lokalnych przez niestandardowe prompty systemowe i workflowy
• Benchmarki, ewaluacje i przypadki testowe

Wsparcie systemów

Chcemy, aby Roo działał dobrze na każdym komputerze:

• Integracja terminala międzyplatformowego
• Silne i spójne wsparcie dla Mac, Windows i Linux

Dokumentacja

Chcemy kompleksowej, dostępnej dokumentacji dla wszystkich użytkowników i współtwórców:

• Rozszerzone przewodniki użytkownika i samouczki
• Jasna dokumentacja API
• Lepsze wskazówki dla współtwórców
• Wielojęzyczne zasoby dokumentacyjne
• Interaktywne przykłady i fragmenty kodu

Stabilność

Chcemy znacznie zmniejszyć liczbę błędów i zwiększyć automatyczne testowanie:

• Przełącznik debugowania logów
• Przycisk "Kopiuj informacje o maszynie/zadaniu" do zgłoszeń błędów/wsparcia

Internacjonalizacja

Chcemy, aby Roo mówił językiem każdego:

• 我们希望 Roo Code 说每个人的语言
• Queremos que Roo Code hable el idioma de todos
• हम चाहते हैं कि Roo Code हर किसी की भाषा बोले
• نريد أن يتحدث Roo Code لغة الجميع

Szczególnie mile widziane są wkłady, które realizują cele roadmapy. Jeśli pracujesz nad czymś zgodnym z tymi filarami, wspomnij o tym w opisie PR.

3. Dołącz do społeczności Roo Code

Nawiązanie kontaktu ze społecznością Roo Code to świetny sposób na rozpoczęcie:

• Główna metoda:
  1. Dołącz do społeczności Roo Code na Discordzie.
  2. Po dołączeniu wyślij wiadomość prywatną (DM) do Hannes Rudolph (Discord: hrudolph), aby omówić swoje zainteresowanie i uzyskać wskazówki.
• Alternatywa dla doświadczonych współtwórców: Jeśli dobrze znasz podejście Issue-First, możesz działać bezpośrednio przez GitHub, śledząc tablicę Kanban i komunikując się przez issues i pull requesty.

II. Znajdowanie i planowanie swojego wkładu

Zdecyduj, nad czym chcesz pracować i jak się za to zabierzesz.

1. Typy wkładów

Witamy różne typy wkładów:

• Poprawki błędów: Naprawianie problemów w istniejącym kodzie
• Nowe funkcje: Dodawanie nowych funkcjonalności
• Dokumentacja: Ulepszanie przewodników, dodawanie przykładów lub poprawianie literówek

2. Kluczowa zasada: podejście Issue-First

Każdy wkład musi zaczynać się od GitHub Issue. To kluczowe, by zapewnić zgodność i uniknąć niepotrzebnej pracy.

• Znajdź lub utwórz Issue:
  • Przed rozpoczęciem sprawdź w GitHub Issues, czy już istnieje issue dla twojego wkładu.
  • Jeśli istnieje i nie jest przypisane, skomentuj, że chcesz się tym zająć. Maintainer ci je przypisze.
  • Jeśli nie istnieje, utwórz nowe, korzystając z odpowiedniego szablonu na naszej stronie issues:
    • Dla błędów: szablon "Bug Report"
    • Dla nowych funkcji: szablon "Detailed Feature Proposal". Poczekaj na zatwierdzenie przez maintainerów (szczególnie @hannesrudolph) przed rozpoczęciem implementacji.
    • Uwaga: Ogólne pomysły lub wstępne dyskusje o funkcjach mogą zacząć się w GitHub Discussions. Gdy pomysł się sprecyzuje, należy utworzyć issue "Detailed Feature Proposal".
• Zgłaszanie i przypisywanie:
  • Wyraźnie zaznacz chęć pracy nad issue, komentując je.
  • Poczekaj, aż maintainer oficjalnie ci je przypisze na GitHubie. Dzięki temu unikniemy dublowania pracy.
• Konsekwencje nieprzestrzegania:
  • Pull Requesty (PR) bez powiązanego, zatwierdzonego i przypisanego issue mogą zostać zamknięte bez pełnej recenzji. Ta polityka zapewnia zgodność wkładów z celami projektu i szanuje czas wszystkich.

To podejście pomaga nam śledzić pracę, upewnić się, że zmiany są pożądane, i skutecznie koordynować wysiłki.

3. Decydowanie, nad czym pracować

• Good First Issues: Sprawdź sekcję "Issue [Unassigned]" w naszym projekcie Roo Code Issues na GitHubie.
• Dokumentacja: Choć ten CONTRIBUTING.md to główny przewodnik dla wkładów kodowych, jeśli chcesz współtworzyć inną dokumentację (np. przewodniki użytkownika lub API), sprawdź repozytorium Roo Code Docs lub zapytaj na Discordzie.
• Proponowanie nowych funkcji:
  1. Wstępny pomysł/dyskusja: Ogólne lub początkowe pomysły omawiaj w GitHub Discussions.
  2. Formalna propozycja: Dla konkretnych, gotowych do rozważenia propozycji utwórz issue "Detailed Feature Proposal" z szablonu na naszej stronie issues. To kluczowy element naszego podejścia Issue-First.

4. Zgłaszanie błędów lub problemów

Jeśli znajdziesz błąd:

1. Szukaj istniejących issues: Sprawdź GitHub Issues, czy nie ma już zgłoszenia.
2. Utwórz nowe issue: Jeśli to unikalny problem, użyj szablonu "Bug Report" na naszej stronie issues.

🔐 Luki bezpieczeństwa: Jeśli odkryjesz lukę bezpieczeństwa, zgłoś ją prywatnie przez GitHub Security Advisory Tool. Nie twórz publicznego issue dla luk bezpieczeństwa.

III. Proces rozwoju i zgłaszania

Postępuj według tych kroków, aby kodować i zgłaszać swój wkład.

1. Konfiguracja środowiska

1. Fork & Clone:
   • Zrób fork repozytorium na GitHubie.
   • Sklonuj swojego forka lokalnie: git clone https://github.com/TWÓJ_UŻYTKOWNIK/Roo-Code.git
2. Zainstaluj zależności: npm run install:all
3. Uruchom Webview (Dev Mode): npm run dev (dla aplikacji Vite/React z HMR)
4. Debuguj rozszerzenie: Wciśnij F5 w VS Code (lub Run → Start Debugging), aby otworzyć nowe okno Extension Development Host z Roo Code.

Zmiany w webview (webview-ui) pojawią się natychmiast dzięki Hot Module Replacement. Zmiany w głównym rozszerzeniu (src) wymagają ponownego uruchomienia Extension Development Host.

Możesz też zbudować i zainstalować paczkę .vsix:

npm run build
code --install-extension bin/roo-cline-<wersja>.vsix

(Zamień <wersja> na faktyczny numer wersji wygenerowanego pliku).

2. Wytyczne dotyczące pisania kodu

• Skoncentrowane PRy: Jedna funkcja/poprawka na PR.
• Jakość kodu:
  • Przejdź przez CI (lint, formatowanie)
  • Napraw ostrzeżenia lub błędy ESLint (npm run lint)
  • Odpowiadaj na feedback z narzędzi automatycznej recenzji kodu
  • Stosuj dobre praktyki TypeScript i dbaj o bezpieczeństwo typów
• Testowanie:
  • Dodaj testy dla nowych funkcji
  • Uruchom npm test, by upewnić się, że wszystko przechodzi
  • Zaktualizuj istniejące testy, jeśli twoje zmiany je dotyczą
• Wiadomości commitów:
  • Pisz jasne, opisowe wiadomości commitów
  • Odnoś się do odpowiednich issues przez #numer-issue (np. Fixes #123)
• Checklist przed zgłoszeniem PR:
  • Zrebase'uj swoją gałąź na najnowszym main z upstream
  • Upewnij się, że kod się buduje (npm run build)
  • Wszystkie testy muszą przechodzić (npm test)
  • Usuń kod debugowania lub console.log

3. Zgłaszanie kodu: proces Pull Request (PR)

Pull Requesty w wersji roboczej

Używaj PRów w wersji roboczej dla pracy, która nie jest jeszcze gotowa do pełnej recenzji, ale dla której chcesz:

• Uruchomić automatyczne sprawdzenia (CI)
• Otrzymać wczesny feedback od maintainerów lub innych współtwórców
• Zasygnalizować, że praca jest w toku

Oznacz PR jako "Ready for Review" dopiero, gdy wszystkie sprawdzenia przejdą i uważasz, że spełnia kryteria "Wytycznych dotyczących pisania kodu" i "Opisu Pull Requesta".

Opis Pull Requesta

Opis PRa musi być kompletny i zgodny ze strukturą naszej Pull Request Template. Kluczowe elementy:

• Link do zatwierdzonego GitHub Issue, którego dotyczy
• Jasny opis wprowadzonych zmian i ich celu
• Szczegółowe kroki testowania zmian
• Lista wszelkich breaking changes
• Dla zmian w UI: zrzuty ekranu lub wideo przed/po
• Wskaż, czy PR wymaga aktualizacji dokumentacji użytkownika i które dokumenty/sekcje są dotknięte

Polityka Pull Request (PR)

Cel

Utrzymanie czystego, skoncentrowanego i zarządzalnego backlogu PRów.

Podejście Issue-First

• Wymagane: Przed rozpoczęciem pracy musi istnieć zatwierdzone i przypisane GitHub Issue ("Bug Report" lub "Detailed Feature Proposal").
• Zatwierdzenie: Issues, zwłaszcza dotyczące większych zmian, muszą być zatwierdzone przez maintainerów (szczególnie @hannesrudolph) przed rozpoczęciem kodowania.
• Odniesienie: PRy muszą wyraźnie odnosić się do tych zatwierdzonych issues w opisie.
• Konsekwencje: Nieprzestrzeganie tego procesu może skutkować zamknięciem PRa bez pełnej recenzji.

Warunki dla otwartych PR

• Gotowe do merge: Przechodzi wszystkie testy CI, jest zgodny z roadmapą (jeśli dotyczy), powiązany z zatwierdzonym i przypisanym Issue, ma jasną dokumentację/komentarze, zawiera zrzuty ekranu/wideo dla zmian w UI
• Do zamknięcia: Błędy CI, poważne konflikty merge, brak zgodności z celami projektu lub długotrwała bezczynność (>30 dni bez aktualizacji po feedbacku)

Procedura

1. Kwalifikacja i przypisanie Issue: @hannesrudolph (lub inni maintainerzy) przeglądają i przypisują nowe i istniejące issues.
2. Wstępna triage PRów (codziennie): Maintainerzy szybko przeglądają nowe PRy pod kątem pilności lub krytycznych problemów.
3. Szczegółowa recenzja PRów (tygodniowo): Maintainerzy dokładnie oceniają PRy pod kątem gotowości, zgodności z zatwierdzonym Issue i ogólnej jakości.
4. Szczegółowy feedback i iteracja: Na podstawie recenzji maintainerzy udzielają feedbacku (Approve, Request Changes, Reject). Oczekuje się, że współtwórcy odpowiedzą i poprawią PR.
5. Etap decyzji: Zatwierdzone PRy są mergowane. PRy z nierozwiązywalnymi problemami lub niezgodne mogą być zamknięte z wyjaśnieniem.
6. Follow-up: Autorzy zamkniętych PRów mogą poprawić je według feedbacku i otworzyć nowe, jeśli problemy zostaną rozwiązane lub zmieni się kierunek projektu.

Odpowiedzialności

• Kwalifikacja Issue i przestrzeganie procesu (@hannesrudolph & maintainerzy): Zapewnienie, że wszystkie wkłady stosują podejście Issue-First. Wskazówki dla współtwórców.
• Maintainerzy (zespół deweloperski): Przegląd PRów, udzielanie feedbacku technicznego, podejmowanie decyzji o zatwierdzeniu/odrzuceniu, mergowanie PRów.
• Współtwórcy: Powiązanie PRów z zatwierdzonym i przypisanym Issue, przestrzeganie wytycznych jakości, szybka reakcja na feedback.

Ta polityka zapewnia przejrzystość i efektywną integrację.

IV. Prawne

Umowa współtwórcy

Zgłaszając pull request, zgadzasz się, że twój wkład będzie licencjonowany na licencji Apache 2.0 (lub aktualnej licencji projektu), tak jak cały projekt.