Jak radzić sobie z trudnym programistą dołączającym do projektu open source?

Mam skrypt typu open source dla określonej witryny (staram się tutaj nie nazywać niczego po imieniu), którą wraz z kilkoma innymi programistami niedawno przeniosłem na GitHub. Od czasu przejścia na nowy system mamy kilku nowych programistów, w tym szczególnie jednego bardzo aktywnego. Jednak ten aktywny zaczął wiele zmieniać projekt.

Przede wszystkim usunął nasz system wersjonowania (nie taki jak Git, ale tak - nazwaliśmy go wersjami v4.1.16) i powiedział, że lepiej po prostu wepchnąć kod na stronę, gdy uznamy, że jest gotowy. Teraz nie ma scentralizowanego miejsca do umieszczania informacji o wydaniu, co stało się denerwujące.

Tym, co przygotowało mnie do spakowania walizek i wyjścia, był skrypt push. Inny programista projektu napisał prosty skrypt push oparty na języku Python. Ponieważ przechowujemy wiele wersji skryptu online w różnych miejscach, zacząłem kodować większy program Java z interfejsem graficznym, który zastąpi skrypt Pythona. Poszedłem na IRC, aby powiadomić o tym wszystkich, i dostałem bardzo irytującą odpowiedź od programisty, mówiąc, że stary skrypt oparty na języku Python może zrobić wszystko, co moje, i jest o wiele lżejszy (skomentował również fakt, że myślał Python był lepszy niż Java i tak dalej). Przejrzałem kod starego skryptu push i zobaczyłem, że nie ma tam żadnych funkcji, które według niego istnieją.

Więc teraz chcę wiedzieć, co robić. Spędziłem dużo czasu na tym projekcie, więc nie chcę po prostu wstać i odejść, ale ciężko mi pracować z tym nowym programistą. Z drugiej strony, jest on teraz numerem 1 w projekcie, z jeszcze większą liczbą zatwierdzeń niż główny programista. Nie jestem pewien, co z tym zrobić. Czy ktoś jeszcze doświadczył tego problemu? Jeśli tak, co zrobiłeś?

AKTUALIZACJA 1 : Wyłączyłem dostęp do zatwierdzania dla wszystkich i proszę ludzi o wykonanie poleceń ściągania. Zaproponowałem również kilka środków w celu rozwiązania innych problemów. Wszyscy inni nie wykazali żadnego wsparcia. Kłopotliwy twórca powiedział po prostu, że ludzie, którzy nie śledzą ściśle „akcji popełnienia”, mogą myśleć, że projekt jest zdezorganizowany, kiedy tak naprawdę nie jest. Oczywiście się z tym nie zgadzam, więc poważnie zastanawiam się nad rezygnacją z projektu.

AKTUALIZACJA 2 : Główny programista zaczął narzekać na to, że jeden z moich zatwierdzeń rzekomo usunął trzy nowe wiersze w kodzie (cofnięcie zatwierdzenia pojawiło się tuż po opublikowaniu dyskusji i nawet nie odnosi się do mojego „zatwierdzenia”), a następnie obaj zaczęli dyskutować, czy odwołać mój dostęp do zatwierdzania. Zrobiłem więc logiczną rzecz i opuściłem projekt. Dziękujemy za pomoc w tym wszystkim!

1. Możesz zrezygnować. Nie jest to najbardziej konstruktywna rzecz do zrobienia, ale czasami jest to jedyna opcja. Jeśli to zrobisz, nie siedź i nie narzekaj, jak musiałeś to porzucić, weź tę energię i włóż ją prosto w coś innego - innymi słowy „ruszaj”.

2. Możesz to rozwidlić. Nie ma powodu, dla którego musisz pracować z kimkolwiek. Rozwidlaj, popraw kod i pozwól pozostałym urządzić sobie własny ego-fest. Twój nowy projekt będzie po prostu konkurował ze starym i od Ciebie zależy, czy odniesiesz sukces, czy też stary przebije Cię pod względem użytkowników i funkcji.

3. Możesz zaangażować resztę zespołu programistów w projekt, aby wyrazić swoje obawy. Nie rób tego osobiście, ale pamiętaj, że jesteś niezadowolony z rezygnacji z kodu, braku ustalonych procesów jakościowych lub niezadowolony, że nowe decyzje są po prostu wypychane bez zgody wszystkich. Albo powiedzą ci, że nic nie jest wystarczająco złe, aby je zmienić, albo kilku innych zgodzi się z tobą, że zespół musi to naprawić. To może skończyć się tym, że destrukcyjny facet utraci dostęp do zatwierdzenia. Może wszyscy zgodzicie się, że niektóre zmiany nie są ulepszeniami i że projekt musi zostać przywrócony. (Ta ostatnia opcja jest najbardziej prawdopodobnym rezultatem, chyba że przekształci się w potężny argument zakorzenionych opinii).

Może być trudno, gdy ktoś przyjdzie i zmieni bezpieczne i wygodne procedury, do których przyzwyczaiłeś się, ale można powiedzieć, że obecność kogoś i wstrząsnięcie starymi, przytulnymi praktykami to same w sobie dobre rzeczy.

Sprawiłeś, że twoja rola jest trochę niejasna. Odpowiedź zależy od tego, jak się dopasujesz.

Jeśli prowadzisz projekt i kontrolujesz repozytorium git

Odzyskaj kontrolę. Jeśli ten facet popełnia zobowiązania, których nie lubisz bez konsultacji z tobą, usuń jego bezpośredni dostęp do zatwierdzania. Może rozwidlać projekt i wysyłać żądania ściągania, aby połączyć swoje zobowiązania. Tak powinno działać open source, dopóki użytkownik nie zbuduje zaufania. Nie musisz i nie powinieneś dawać pełnego dostępu od razu.

Jeśli ktoś inny kontroluje repozytorium

Wyraź swoje obawy osobie, która to robi, i zachęcaj do bardziej zdyscyplinowanego procesu planowania i zatwierdzania zmian. Jeśli przywództwo nie podlega procesowi, możesz zaakceptować status quo i nadal wnosić wkład, możesz rozwidlić projekt i pracować nad własną wersją (zabierając ze sobą każdego, kto się z tobą zgadza), lub możesz odejść i pracować nad innymi rzeczami. W każdym razie nie musisz dalej się tym zajmować.

Proszę wybaczyć moją szczerość, ale wasz post brzmi jak rant.

Mówisz, że to ten drugi facet chce bezmyślnych zmian, ale wtedy zaprzeczasz sobie, mówiąc o swoim nowym lśniącym programie Java.

Zrób sobie przerwę; nie jest to ulica jednokierunkowa, spróbuj znaleźć kompromisy (jeśli chcesz kontynuować pracę nad projektem - rozwidlenie jest najłatwiejszą decyzją, ale nie doprowadzi cię do niczego użytecznego, chociaż może pogłaskać twoje ego).

Zastanów się też dobrze nad podziałem pracy w projekcie - wojny darniowe są nieuniknione, jeśli nie masz czystych granic, które mówią ci, kto jest kompetentny . Tak, czasami musisz ufać osądowi innych ludzi.

W kilku odpowiedziach wspomniano już, że podział pracy jest jednym ze sposobów zmniejszenia konfliktu. Oto kilka konkretnych przykładów:

1. Zrównoważyć produktywność i stabilność. Aby pożyczyć analogię z gier strategicznych, drużyna musi składać się z mieszanki Boom, Turtle i Rush , a członkowie drużyny muszą być przygotowani na zmianę ról w reakcji na sytuację.
   • Kiedy jeden jest w szaleństwie produktywności, inni mogą pracować nad:
   • Inne funkcje
   • Naprawa błędów
   • Specyfikacje (zarządzanie żądaniami nowych funkcji i sprawdzanie, czy oprogramowanie spełnia uzgodnione kryteria)
   • Zapewnienie jakości
     • Testy ręczne (eksploracyjne)
     • Zautomatyzowane testowanie
   • Dokumentacja
   • Refaktoryzacja i czyszczenie kodu
   • Przeprowadź badania użytkowników, aby zebrać pomysły na ulepszenia
   • itp.
2. Projekt można zmodularyzować (jak w architekturze oprogramowania), a nawet podzielić na segmenty (jak w zarządzaniu projektami), dzięki czemu każdy moduł może pracować niezależnie.
   • Ogólnie rzecz biorąc, większość oprogramowania, które zawiera zarówno interfejs, jak i back-end, powinna być zmodularyzowana, ponieważ mają one inną prędkość rozwoju.
   • Oprogramowanie bogate w UX może być trudne do modularyzacji ze względu na intensywne wykorzystanie routingu zdarzeń między modułami.
   • Opiekun projektu może chcieć uprościć projekt, unikając modularyzacji.
3. Gałąź funkcji . Każdy programista może rozwidlić projekt, pracować nad swoją ulubioną funkcją zwierzaka i poprosić o scalenie po zakończeniu implementacji. Główny programista może decydować o tym, czy przyjąć scalenie.

Oprócz aspektu unikania konfliktów oczywiste jest, że zarządzanie projektem może być niewystarczające .

Dlaczego zarządzanie jest ważne? Wyobraź sobie, że pewnego dnia były kolega z zespołu wziął oprogramowanie i pozwał zespół o naruszenie. Lub zespół pozwany przez patentowego trolla. Lub nikt nie wie, kto zdecydował się wysłać zawiadomienia DMCA na stronę hostingową projektu i zażądać usunięcia kodu źródłowego projektu.

Co najmniej:

• Licencja do wykorzystania przez cały wniesiony kod źródłowy
• Licencje, na podstawie których można opublikować kod źródłowy projektu
  • W przypadku poszukiwania nowej licencji publicznej, w jaki sposób uzyskać zgodę każdego dostawcy
• Kto może mieć dostęp administracyjny do projektu
• Kto zostanie wyznaczony do odpowiedzi na wnioski prawne (takie jak zawiadomienia DMCA lub trolle patentowe)
• Kto będzie zarządzał finansami projektu (opłacanie kosztów serwera i księgowanie przychodów z reklam lub darowizn)
• Kto będzie miał prawo głosu w celu włączenia nowych członków i wydalenia członków.
• itp.

Większość witryn projektów typu open source może udostępniać gotowe karty zarządzania projektami.

Wcześniej widziałem problem. Ale po kilku latach naprawdę zmęczyłeś się projektem, więc moim rozwiązaniem było odejście z projektu . Może ci się to nie udać, ale problem polega na tym, że różni ludzie myślą inaczej. Funkcje, które uważasz za bardzo ważne, wcale nie są ważne dla innych ludzi.

Dobrym planem byłoby podzielenie zadań różnych ludzi. Jeśli możesz zgodzić się z osobami, która część projektu jest odpowiedzialna za każdą osobę, wtedy tylko jedna osoba podejmuje decyzje dotyczące określonej części projektu. Ale praca zespołowa jest zawsze trudna. Nadal nigdy nie polubisz decyzji podjętych przez innych programistów. Najlepszym rozwiązaniem jest nigdy nie patrzeć na to, co postanowili inni programiści. Wystarczy zaufać im, że zrobią właściwą rzecz, wystarczy.

Wspólny cel skoncentruje twoje wysiłki na ważnych rzeczach. Trudno jest dotrzeć do wszystkich pracujących w tym samym kierunku, a konflikty i tak się zdarzają. Decydowanie o wspólnym celu wymaga wiedzy o aktualnym stanie projektu, a następnie, po pewnym czasie, podjęcie decyzji, gdzie powinien on być.

Oto przykład rzeczy, których należy unikać: Na przykład duża liczba programistów c ++ uważa, że ​​kod, który nie korzysta z biblioteki STL, jest uszkodzony. Inni programiści uważają, że każda zależność od bibliotek zewnętrznych jest zerwana, w tym STL. Takich konfliktów po prostu nie da się poprawnie rozwiązać - obie sytuacje nie mogą być spełnione jednocześnie - a najbardziej problematyczni ludzie popchną swoją opinię bez względu na napotkany sprzeciw.

Sądzę, że cztery opcje.

1. Wykop go. Jesteś (podobno) nadal głównym gościem w tym projekcie; odwołać jego uprawnienia do wypychania i nazwać to dniem. Najbardziej prawdopodobne jest, że rozwiąże projekt, podzieli jego społeczność, a następnie wybuchnie wojna, a gdy opadnie kurz, jeden z widelców będzie popularny.
2. Rozwidl i kontynuuj gdzie indziej. Mniej agresywny niż 1., ale konsekwencje są takie same. Będziesz jednak musiał być aktywny w społeczności, aby przyciągać ludzi na swoją stronę.
3. Zostaw to: pozwól mu robić to, co robi, uspokój się i miej nadzieję na najlepsze.
4. Dyskutuj ze społecznością, w razie potrzeby kompromis i rozwiązuj sytuację.

Osobiście wolałbym opcję 4.

Kilka lat temu Google przeprowadził kilka rozmów technicznych na ten temat. Obejrzyj je:1 ,2 . W skrócie:

1. Pojąć : Zrozumienie motywacji swojej społeczności do pracy nad projektem vs wszystkich innych kosztów alternatywnych i zachować te powody.
2. Wzmocnić : Budowanie zdrowych społeczności z normami społecznymi uprzejmości, szacunku, zaufania i pokory.
3. Zidentyfikuj : Poszukaj znaków ostrzegawczych jadowitych ludzi (zbyt wielu, by je wymienić, ale jeśli zadajesz to pytanie, prawdopodobnie znasz już wielu z nich).
4. Dezynfekcja : zachowaj spokój i nie poddawaj się, nie reaguj na obelgi, lekceważenie, wyzwania, brak szacunku itp. I wytrwale wzmacniaj normy swojej społeczności.

Dostępny jest także kompleksowy zarys na piśmie, jeśli wolisz czytać zamiast oglądać.

Nie możesz po prostu rzucić palenie, nie starając się wyrazić swoich obaw i trudności. Wiem, że to może być trudne. Jeśli fakt, że ty i członkowie zespołu jesteście na tyle młodzi, aby nie doświadczyć wielu problemów społecznych z dowolnego zespołu programistów, może to być naprawdę trudne.

Powiedziawszy to, mocno wierzę, że powinieneś wyrazić swoje obawy. Możesz zapisać je w wiadomości e-mail i pokazać swoim zaufanym znajomym, którzy nie są częścią zespołu i nie interesują się tym, co robisz. W takim przypadku możesz otrzymać dobrą opinię, aby treść Twojego e-maila nie była zbyt surowa. Trzymaj się faktów. Nie oskarżaj ani nie obwiniaj. Tylko fakty, że ciężko coś dla ciebie zrobić, ponieważ brakuje „bla”. Dlaczego brakuje „bla”, powinno być jasne dla każdego członka zespołu, tzn. „Nowy programista” usunął lub czegoś nie zrobił.

Ponownie wysłanie tego e-maila jest trudne, ale samo w sobie jest świetnym doświadczeniem, które może być bardzo przydatne dla Ciebie w przyszłości. Świetna lekcja do nauki.

PS: Nie chciałem zabrzmieć zbyt rodzicielsko. Jest to jednak coś, co powiedziałbym każdemu, w tym moim dzieciom.