Czyja odpowiedzialność polega na usuwaniu błędów?

Sytuacja, która pojawiła się kilka razy w projektach typu open source, wygląda następująco:

1. Zauważam błąd w naszym wdrożeniu i wymyślam łatkę do szybkiego hakowania. (Na przykład po prostu komentując kod, którego tak naprawdę nie potrzebujemy).
2. Poświęcam trochę dodatkowego wysiłku, aby znaleźć prawdziwy błąd, wymyślić łatkę i przesłać ją za pośrednictwem żądania ściągnięcia Git lub podobnego.
3. Moje żądanie ściągnięcia zostało odrzucone. Być może łatka była niedoskonała (np. Zawierała linie, których nie powinna mieć), być może naruszyła styl kodowania, może miała inne konsekwencje. A może zrobiłem coś złego w Git - prośba o ściągnięcie powinna była zostać cofnięta lub coś takiego. Opiekun przekazuje informacje zwrotne o tym, jak ulepszyć poprawkę, i prosi o jej ponowne przesłanie.

W tym momencie jestem zdezorientowany, jak daleko mam iść. Jeśli chodzi o mnie, nie mam problemu: naprawiłem go w kroku 1. Zgłosziłem problem, podjąłem nawet kroki, aby go naprawić dla innych. Ale nie uważam, że to „moja” prośba o ściągnięcie, więc nie uważam, że odpowiedzialność za ulepszenie łatki powinna spoczywać na mnie.

Jedna szczególna sytuacja, która mnie denerwuje, to po dyskusji o wadach mojej łatki, osiągamy porozumienie na liście mailingowej co do tego, jaka byłaby poprawna łatka (tj. Jak powinna się zachowywać, czasami włączając w to wszystkie wypisane wiersze kodu). W dalszym ciągu przypuszczam, że moim obowiązkiem jest wygenerowanie i przesłanie łatki.

Czy w takich sytuacjach istnieje standardowa etykieta? Jak są rozwiązane? Czy moja reakcja jest niezwykła? Jak daleko masz się posunąć, aby zaakceptować naprawę błędu?

(Uwaga: kiedy mówię „projekt open source”, niektóre z nich są bardzo małe, ale mogą nie być hobby - po prostu małe projekty oprogramowania, które są przydatne dla kilku organizacji, które przeznaczają zasoby programistów na pracę nad nimi. W przypadku oczywistej odpowiedzi to „napraw łatkę i prześlij ponownie”, rozumiem, że mam obowiązek wobec mojego pracodawcy, aby pracować nad rzeczami, które są dla nich korzystne. Poświęcenie czasu na naprawienie błędu, który nas nie dotyczy, byłoby błędem ...)

Moim zdaniem, jeśli znajdziesz błąd lub masz prośbę o ulepszenie, nie jesteś uczestnikiem projektu i przesłałeś raport o usterce za pośrednictwem odpowiednich kanałów, gotowe. Jeśli chodzi o zwrot społeczności, każdy, kto korzysta z projektu open source i znajdzie wadę, powinien to zgłosić.

Próba znalezienia rozwiązania, zaprojektowania go i wdrożenia jest bonusem projektu. Jeśli to zrobiłeś, dobrym pomysłem może być przesłanie go, albo poprzez żądanie ściągnięcia, albo może wysyłając delty plików do zespołu programistów wraz z raportem o usterce lub prośbą o ulepszenie, aby dać im coś do pracy. Nie są one jednak zobowiązane do przyjęcia Twojego wkładu w projekt.

Oczekiwanie, że użytkownik doda poprawki, wydaje mi się błędne. Dość łatwo jest uczestniczyć w dyskusji na temat problemu, ale znalezienie rozwiązania jest znacznie dłuższe. Żaden projekt nie powinien oczekiwać, że osoby, które się nie przyczyniły, staną się współpracownikami, aby rozwiązać tylko jeden problem.

Idź tak daleko, jak tylko chcesz. Byłoby miło naprawić łatkę i udostępnić ją światu w głównym bagażniku, ale jeśli opiekun tego nie chce, wzrusz ramionami. Możesz opublikować gdzieś swój problem i łatkę, aby sobie z nim poradzić, aby inni w tej samej łodzi mogli znaleźć rozwiązanie.

I nie jesteś bez problemu. Twoja łatka nie będzie w następnym uaktualnieniu. Będziesz więc musiał ponownie ładować i mieć nadzieję, że zadziała lub wmasuje na miejsce, gdy tylko zdobędziesz nową wersję. Włączenie go do głównego projektu pozwoli zaoszczędzić Tobie i Twojej firmie czas na dłuższą metę.

To dla ciebie boli, ale przyczyniasz się do społeczności. Z pewnością doceniam wkład wszystkich twórców. To nie jest tak, jak wysokiej jakości oprogramowanie, po prostu magicznie geneza mas. Ktoś musi wykonać pracę. (Więc kto jest niesamowity? Jesteś wspaniały). Jeśli nie masz ochoty na to, ogłoś społeczności, że choć doceniasz dyskusję o tym, jak powinno być, po prostu jesteś zbyt zajęty, aby to zrobić. Mam na myśli, co oni zamierzają zrobić? Obniż swoje zarobki?

Istnieje jedna zasada, która ułatwia zrozumienie kultury open source: osoba, która wykonuje pracę, decyduje, nad czym pracować. Jest to jeden z jej odwołań w porównaniu z codziennymi zadaniami programistów. Twoim priorytetem może być numer 50 w zaległościach. Jeśli nie naprawisz swojego żądania ściągnięcia, ostatecznie prawdopodobnie spłynie ono na szczyt i oni się tym zajmą. Jeśli jednak ułatwisz im to, zajmą się tym teraz.

Inny powód, dla którego proszą cię o naprawienie twojego żądania ściągania, jest bardziej wspaniałomyślny. Chcą, abyś otrzymał kredyt na swój wkład, choćby nie był to mały. Jeśli wykonasz naprawę, twoje imię i nazwisko będzie w polu autora zatwierdzenia. Większość ludzi jest na tyle dumna ze swojego wkładu, że chce je przejrzeć, więc domyślnym sposobem działania opiekunów jest pozwolić im.

Jeśli chodzi o twoją odpowiedzialność wobec pracodawcy, jeśli Twoja firma polega na tym kodzie, nie robisz im krzywdy. Pracodawcy znają korzyści z tego, że robotnik poświęca czas na ostrzenie swoich narzędzi.

AFAIK, metoda open source polega na tym, że odpowiedzialność za naprawianie błędów spoczywa na tym, kto dba o błąd wystarczająco, aby poradzić sobie z obciążeniem, aby upewnić się, że zostanie naprawiony. W zależności od okoliczności zrobiłem wszystko, od ignorowania problemu po walkę (dostarczanie łatek i argumentowanie, aby zostały zaakceptowane), aby upewnić się, że zostało to naprawione.

Wszystko jest w porządku, po prostu nie pozwól osobom zarządzającym projektem oczekiwać od ciebie złej rzeczy (tj. Dać im nadzieję, że rozwiążesz problem właściwie za pomocą opcji dyskusji, a następnie nic nie zrobisz), prawdopodobnie są świadomi większej liczby problemów niż oni poradzą sobie i postarają się, aby ci się to regularnie powiodło.

Pierwotny błąd może dotyczyć tylko Ciebie, więc w Twoim interesie jest, aby zgłoszenie zostało zrobione, robiąc wszystko, co konieczne, aby dostosować twoją łatę do zgodności. W przeciwnym razie kolejna wersja, którą ściągniesz (ponieważ potrzebujesz innych poprawek), nie będzie dostępna.

Nie chcesz utrzymywać listy łat, które musisz zastosować za każdym razem, gdy wyciągasz nową kopię projektu - to po prostu zbyt duży problem. Poświęć trochę dodatkowego czasu i napraw go na stałe, abyś nie musiał się z nim ponownie zajmować.

Dla programisty open source istnieją dwa rodzaje problemów:

• (a) problemy bez łatki
• (b) problemy spowodowane przez łatkę

Myślę, że większość opiekunów / deweloperów pakietów open source UWIELBIA pomysł pomógł w przyspieszeniu ich poprawek.

Ich głównym celem jest jednak zminimalizowanie liczby problemów typu b. Właśnie dlatego poprzeczka jest ustawiona dość wysoko.

Niektórzy ludzie to przezwyciężają. Stają się współpracownikami, a może nawet głównymi współpracownikami. Inni się poddają. Open Source ma pewną darwinowską naturę - przetrwanie najsilniejszych.

Zachęcam cię, byś naciskał i pluł na swój wkład do momentu, w którym zespół go zaakceptuje. Po dokonaniu kilku wpłat będą ci jeszcze bardziej ufać, ale powinieneś upewnić się, że Twoje wpłaty są nienaganne.

Wynik końcowy jest tego wart. Rzeczy takie, jak możliwość powiedzenia „Czy koduję? Tak… Codziennie prowadzisz coś, co napisałem”.