Gdzie zacząć angaż w proste projekty grupowe?

Cześć społeczności,

Zwracam się do was z pytaniem - gdzie i jak najlepiej zacząć naukę (poprzez praktykę) realizowania projektów grupowych?
3 miesiące temu rozpocząłem naukę Javy, obecnie jestem na etapie realizacji pierwszych aplikacji webowych w Spring Boot. Uczę się sam, główną motywacją do nauki jest chęć stworzenia aplikacji, która ma pomóc mi w codziennej pracy (w innej branży).
Chciałbym zaczęrpnąć praktycznej wiedzy w jaki sposób pracuje się z Git oraz jak wygląda praca zespołowa przy wytwarzaniu oprogramowania.

Obecnie moja wiedza nt. Gita ogranicza się do umiejętności klonowaniu repo, commit praz push.

Obecnie moja wiedza nt. Gita ogranicza się do umiejętności klonowaniu repo, commit praz push. Czyli poziom 90% developerów :D

Możesz kontrybuować do opernsource. To chyba najprostsza droga.

Co do open source, to najłatwiej zacząć łatając literówki w dokumentacjach.

Nic nie zepsujesz przynajmniej, plus dostarczysz jakąś wartość (nawet jeśli małą) robiąc coś, czego ludziom rozwijającym projekty open source zwykle się nie chce poprawiać.

No i może nie zrobisz żadnego wielkiego impactu, ale przynajmniej zobaczysz, jak to jest robić pull request choćby.

to ode mnie bardziej konkretnie, bo open source możesz robić w każdym repo które jest na to otwarte w gitlabie, gihubie itp itd.
https://fedoramagazine.org/how-to-contribute-to-fedora/ - poczytaj
https://fedoramagazine.org/day-life-fedora-packager/ - tez poczytaj

Czemu fedora? :) nie wiem, lubie Redhata, możesz równie dobrze przejrzeć co jest do zrobienia w środowisku Debiana
wejdź do jakiejś społeczności na Discordzie, może coś ciekawego się znajdzie

wygląda praca zespołowa przy wytwarzaniu oprogramowania.

To szeroki temat, który wykracza poza sam kod. Ale mówiąc tylko o kodzie, to projekty zespołowe są zwykle większe niż projekty robione w pojedynkę, więc szykuj się na:

• dużo czytania kodu już napisanego (które może być trochę pułapką. Bo jak projekt jest duży, to i tak nie zrozumiesz go całego)
• modyfikację ww. kodu, żeby np. dodać nowy ficzer (bo rzadko się robi coś od zera)
• kod różnej jakości, w jednym projekcie mogą być jednocześnie miejsca, gdzie kod będzie ładny, jak i taki, gdzie będzie słabo
• brak dokumentacji, bo jedyną dokumentacją może być kolega, który już tutaj nie pracuje (klasyk) albo jakiś stare nieaktualne zapiski
• różny poziom otestowania
• dużo zajmujących czas dyskusji o tym, jak coś zrobić perfekcyjnie, zamiast to po prostu zrobić

Czyli dużo entropii. Popularne projekty open source mogą być pewnym przybliżeniem (jak chcesz zobaczyć, jak ludzie w nich pracują zespołowo, to zobacz sobie na dział issues na GH, tam ludzie prowadzą dyskusje na temat tego, jak coś zrobić w projekcie, czy może inaczej itp.).

Przy czym porównując open source z projektami "firmowymi", to w open source jest zwykle więcej troski o jakość i trzymanie standardów (również więcej testów i lepsza dokumentacja), ale też więcej bikesheddingu. Czasem drobna zmiana w projekcie o.s. to pół roku dyskusji, czy to nie będzie breaking change. A w projekcie firmowym też mogą być dyskusje, ale jednak nie takie trwające na pół czy półtora roku (co jest dość częste w świecie open source)

Ja bym powiedział tak, najlepiej wybrać projekt z którego chciałbyś korzystać i by cię interesował lub nawet jeszcze lepiej, z którego korzystasz.
Jak z czegoś korzystasz to znasz już interface i wiesz high level jak coś działa.

Teraz forkujesz, instalujesz ze źródeł, na początek próbujesz zrobić jakieś proste programy z użyciem tego projektu i powoli się oswajasz, próbujesz dodać swoją funkcjonalność do interface, zmodyfikować coś i potem budujesz nową wersję projektu lokalnie, ale robisz to na początku na nowym branchu swoim.
Tu chodzi o to żeby bardzo dobrze oswoić się z ekosystemem całego projektu architekturą wiedzieć gdzie co jest położone jak to działa.

Potem możesz jakieś problemy naprawiać, które sam dostrzegasz lub funkcjonalności jakie sam byś chciał mieć bo je widzisz to możesz robić.
W drugiej kolejności bierzesz problemy innych ludzi te są trudniejsze bo musisz jakby wejść w ich kontekst co czują jak ten błąd się u nich objawił z reprodukować zlokalizować przyczynę itp.
Jak projekt znasz bardzo dobrze to kontrybucję zrobisz od ręki, ale jak kompletnie nie wiesz jak coś działa, nigdy w tym nie pisałeś, nigdy nie zrobiłeś jakiś małych modyfikacji itp. im większą wiedzę na temat projektu zdobędziesz tym łatwiej ci będzie zrobić kontrybucję.

Tu nie chodzi o to jak dobrze umiesz programować, a to to że musisz wiedzieć jak jest prowadzony projekt, zrozumieć jak działa, jak go modyfikować żeby też wszystko działało.
Żyjesz w danym projekcie to każdego dnia odkrywasz jego nowe tajemnice.