Open Source w .NET: jak znaleźć pierwszy issue i złożyć PR

Kąt widzenia: nie filozofia open source (to jest Wikipedia), ale konkretny workflow — od “chcę coś zrobić” do scalonego PR w repozytorium .NET
Przykład przewodni: znalezienie pierwszego issue w dotnet/runtime i złożenie PR z poprawką

Dlaczego warto — poza “budowaniem portfolio”

Portfolio to oczywiste. Mniej oczywiste: czytanie kodu dotnet/runtime uczy cię jak GC decyduje kiedy zebrać pamięć, jak Span<T> jest implementowany, jak działa pipeline HTTP w ASP.NET Core. To informacje niedostępne w żadnym tutorialu. Drugi benefit: feedback od maintainerów Microsoft/community na Twój konkretny kod — to lepsza code review niż większość komercyjnych projektów.

Repozytoria .NET — gdzie zacząć

Nie zaczynaj od dotnet/runtime — to milion linii kodu C++ i C#, złożoność CLR jest olbrzymia. Lepsza kolejność:

dotnet/docs to najłatwiejszy punkt wejścia — poprawka w dokumentacji to też wkład, a review jest szybki.

Jak znaleźć pierwszy issue

Szukaj po labelach

Na GitHub każde repozytorium ma labele. Te które szukasz:

label:"good first issue"
label:"up-for-grabs"
label:"help wanted"

URL do filtrowania w dotnet/aspnetcore:

https://github.com/dotnet/aspnetcore/issues?q=is%3Aopen+label%3A%22good+first+issue%22

Sprawdź czy issue jest wolne

Zanim zaczniesz pracę — sprawdź komentarze. Szukaj:

• Czy ktoś napisał “I’ll take this”?
• Czy jest przypisana osoba (Assignees)?
• Czy issue jest aktywne (komentarze z ostatnich tygodni)?

Możesz napisać: “I’d like to work on this. Could you assign it to me?” — maintainerzy doceniają to.

Typy pierwszych issue

Dobre na start:

• Brakujące testy jednostkowe
• Poprawki w komunikatach błędów (bardziej opisowe, linki do dokumentacji)
• Drobne optymalizacje wskazane przez maintainerów
• Dokumentacja i przykłady kodu

Unikaj na start:

• “Design changes” — wymagają długich dyskusji
• Problemy z wydajnością bez benchmarków
• Kwestie związane z bezpieczeństwem

Workflow: od fork do PR

1. Fork i konfiguracja

# Fork przez GitHub UI, potem:
git clone https://github.com/TWOJ_NICK/aspnetcore.git
cd aspnetcore

# Dodaj upstream remote:
git remote add upstream https://github.com/dotnet/aspnetcore.git

# Sprawdź:
git remote -v
# origin   https://github.com/TWOJ_NICK/aspnetcore.git
# upstream https://github.com/dotnet/aspnetcore.git

2. Przeczytaj CONTRIBUTING.md

Każde duże repozytorium .NET ma CONTRIBUTING.md. Przeczytaj go zanim dotkniesz kodu. Zawiera:

• Jak budować projekt lokalnie
• Wymagania (wersja .NET SDK, narzędzia)
• Jak uruchamiać testy
• Konwencje nazewnicze i styl kodu

Pominięcie tego to najczęstszy błąd — PR odrzucone bo formatowanie nie pasuje do konwencji projektu.

3. Branch dla swojego fix’a

# Zawsze pracuj na branchu, nigdy na main
git checkout -b fix/improve-error-message-for-missing-header

Konwencja nazw branchy w dotnet: fix/, feature/, test/ + krótki opis.

4. Budowanie i testowanie

# W dotnet/aspnetcore:
./restore.sh      # lub restore.cmd na Windows
./build.sh        # lub build.cmd
./test.sh         # lub uruchom konkretny test project

# W dotnet/efcore:
dotnet build
dotnet test

Zawsze uruchom testy przed commitem. PR bez zielonych testów nie zostanie przejrzany.

5. Commit i PR

git add -p  # interaktywnie zamiast "git add ." — sprawdzasz co committujesz
git commit -m "Improve error message when X is missing

Previously the error was 'NullReferenceException'. Now it includes the
parameter name and a link to documentation.

Fixes #12345"

Format commit message: Co zostało zrobione (pierwsza linia), pusty wiersz, Dlaczego (opcjonalnie), Fixes #numer-issue.

Jak napisać dobry PR

Template PR

Większość repozytoriów ma szablon PR (PULL_REQUEST_TEMPLATE.md). Wypełnij go sumiennie. Zwykle zawiera:

• Co zostało zmienione i dlaczego
• Jak przetestować (kroki)
• Czy są testy jednostkowe
• Czy jest breaking change

Przykład opisu PR

## Opis
Poprawia komunikat błędu gdy brakuje wymaganego nagłówka HTTP.

Poprzednio: `ArgumentNullException: Value cannot be null.`
Teraz: `Required header 'Authorization' is missing. See: https://...`

Fixes #12345

## Testowanie
1. Stwórz endpoint wymagający nagłówka Authorization
2. Wyślij request bez nagłówka
3. Sprawdź że komunikat błędu jest czytelny

## Checklist
- [x] Testy jednostkowe dodane/zaktualizowane
- [x] Dokumentacja zaktualizowana (jeśli dotyczy)
- [x] Brak breaking changes

Czego się spodziewać po review

Maintainerzy dużych projektów są zajęci. Czas oczekiwania na review: od kilku dni do kilku tygodni. To normalne.

Typowe odpowiedzi:

“Please rebase on main” — Twój branch rozjechał się z main. Rozwiązanie:

git fetch upstream
git rebase upstream/main
git push --force-with-lease origin twoj-branch

“Can you add tests for this?” — Dodaj testy i zaktualizuj PR (push na ten sam branch).

“This needs design discussion” — Maintainer chce najpierw podyskutować. Odpowiedz na komentarze, nie zniechęcaj się.

“LGTM” — “Looks Good To Me” — PR zostanie scalony.

Praktyczne narzędzia

# Sprawdź czy kod przechodzi formatowanie (wymagane w dotnet/runtime, aspnetcore):
dotnet format

# W VS Code: zainstaluj rozszerzenie C# DevKit
# Podpowie Ci styl kodu projektu automatycznie

dotnet format jest wymogiem w większości repozytoriów .NET. Jeśli nie uruchomisz go przed PR, CI zablokuje merge.

Gdzie pytać gdy utkniesz

• Komentarz do issue — “I’m working on this, could you clarify X?” — maintainerzy odpowiadają
• GitHub Discussions w repozytorium — dla większych pytań o kierunek
• .NET Discord — discord.gg/dotnet — kanał #contribute-to-dotnet
• Komentarz do PR — opisz problem, maintainer naprowadzi

Nie bój się pytać. Nikt nie oczekuje że znasz każdy zakamarek CLR zanim złożysz pierwszego PR.

Podsumowanie

Workflow od zera do PR:

1. Znajdź issue z labelką good first issue lub up-for-grabs w dotnet/aspnetcore lub dotnet/efcore
2. Skomentuj że chcesz to wziąć
3. Przeczytaj CONTRIBUTING.md
4. Fork → branch → zmiana → testy → dotnet format
5. PR z opisem co, dlaczego, jak testować i linkiem do issue
6. Odpowiadaj na review, rebasuj gdy trzeba

Pierwszy PR rzadko jest perfekcyjny — i to jest OK. Code review od maintainerów .NET to jedna z lepszych inwestycji w swój rozwój jako .NET developer.