Jaka jest kanoniczna retorta do „to open source, prześlij łatkę”? [Zamknięte]

215

Niebezpieczeństwo zasugerowania jakiejkolwiek funkcji produktu, zwłaszcza open source, polega na tym, że otrzymasz odpowiedź „dlaczego tego nie zrobisz?”.

To ważne i fajnie, że możesz sam dokonać zmiany. Ale wiemy praktycznie, że produkty często się poprawiają, ponieważ programiści słuchają głosu użytkowników - nawet jeśli ci użytkownicy są innymi programistami. I skutecznym sposobem wprowadzenia tych zmian może być ktoś, kto już pracuje nad projektem, podejmując pomysł i wdrażając go.

Istnieje kilka typowych terminów odnoszących się do problemów związanych z programowaniem. np . jazda rowerem . Czy jest używany często używany termin, który zasadniczo odpowiada: „Tak, wiem, że mogę zmienić prawie wszystko na świecie - nawet zamknięte źródło. Mogę zostać zatrudniony i napisać ten kod. Ale w tym przypadku robię tylko spostrzeżenie, które w rzeczywistości może być przydatne dla innego kodera, który jest już dobrze przystosowany do łatwej zmiany - lub po prostu ogólnie omawia możliwości ”.

[ps (kilka dni później) - Powinienem zauważyć, że „prześlij łatkę” często mówi się z ironicznym humorem i szukam odpowiedniej dowcipnej odpowiedzi.]

open-source

— Vincent Scheib
źródło

16

Chciałbym móc to głosować więcej niż raz! (I to pochodzących od kogoś, kto ma . Przedłożonej poprawki do kilku różnych projektów, a dostał je przyjęły opisać Taka postawa jest po prostu irytujące!)

— Mason Wheeler

62

Przypuszczam: „Jak wyglądam bezrobotna małpka kodowa? Mam życie!” nie jest do przyjęcia ;-)

— Steven A. Lowe

12

Z mojego doświadczenia wynika, że odpowiedź „prześlij łatkę” zwykle pojawia się po tym, jak deweloper wyjaśnił już, dlaczego dodanie tej funkcji nie byłoby praktyczne.

— user16764

7

@Steven, zależy od tego, czy chcesz po prostu znieść zniewagę lub faktycznie zmusić ich do zrobienia tego, czego potrzebujesz. Uważam, że nie jest to optymalna strategia, jeśli chcesz tego drugiego.

12

@orokusaki: Lub D) Uważają tę funkcję za mniej wartościową niż inne funkcje, nad którymi mogliby pracować, i mają ograniczone zasoby.

— David Thornley,

115

To trudna kwestia: ponieważ użytkownik nie płaci bezpośrednio ani pośrednio za produkt, nie może poprosić o wdrożenie funkcji. To nie tak, jakbyś był interesariuszem lub bezpośrednim klientem, który zamówił produkt, a nawet nie końcowym użytkownikiem produktu komercyjnego.

To powiedzenie: „prześlij łatkę” nie jest prawidłową odpowiedzią. To nie jest grzeczne. To jest niepoprawne. Nawet dla produktu open source. „Prześlij łatkę” to krótka wersja:

„Nie obchodzi nas, czy podoba ci się nasz produkt, czy nie. Przejdź i zmodyfikuj go, jeśli chcesz, ale nie zawracaj nam głowy życzeniami klientów”.

Co powiesz na przesłanie łatki?

Cóż, to nie jest takie proste. Aby to zrobić:

Musisz znać języki używane w projekcie open source.
Musisz mieć możliwość załadowania kodu źródłowego z kontroli wersji, aby móc go zmodyfikować.
Musisz mieć zainstalowane wszystkie prawidłowe wersje dowolnych zależności kompilacji (w tym zarówno biblioteki wykonawcze, jak i narzędzia kompilacji).
Musisz być w stanie skompilować ten kod źródłowy , co w niektórych przypadkach nie jest tak oczywiste. Zwłaszcza, gdy skompilowanie dużego projektu zajmuje kilka godzin i wyświetla 482 błędy i tysiące ostrzeżeń, możesz odważnie szukać źródła tych błędów.
Powinieneś bardzo dobrze zrozumieć, w jaki sposób realizowany jest projekt , jakiego stylu kodowania użyć, jeśli w ogóle, jak przeprowadzać testy jednostkowe itp. Jeśli projekt nie ma porządnej dokumentacji (co często ma miejsce w przypadku projektów open source ), może to być naprawdę trudne.
Musisz dostosować się do projektu i nawyków programistów, którzy aktywnie uczestniczą w projekcie. Na przykład, jeśli korzystasz z .NET Framework 4 codziennie, ale projekt korzysta z .NET Framework 2.0, nie możesz używać LINQ, ani kontraktów kodowych, ani innych tysięcy nowych funkcji najnowszych wersji frameworka.
Twoja łatka musi zostać zaakceptowana (chyba że zrobisz zmianę tylko dla siebie, bez zamiaru dzielenia się nią ze społecznością).

Jeśli masz zamiar aktywnie uczestniczyć w projekcie, możesz zrobić wszystkie te rzeczy i poświęcić na to swój czas. Z drugiej strony, jeśli brakuje tylko denerwującego drobnego błędu lub prostej funkcji, spędzania dni, tygodni lub miesięcy na studiowaniu projektu, wykonanie samej pracy w ciągu kilku minut jest po prostu nieuzasadnione, chyba że ci się podoba.

Czy istnieje kanoniczna retorta do „to open source, prześlij łatkę”? Nie wydaje mi się Albo wytłumaczysz osobie, że jest niegrzeczna, albo przestaniesz z nią rozmawiać.

— MainMa
źródło

9

Brzmi to tak, jakby zostało napisane przez kogoś bez doświadczenia w utrzymaniu projektu open source.

— Rein Henrichs

46

@ Rein: Utrzymanie projektu open source nie różni się niczym od utrzymywania jakiegokolwiek innego projektu. Masz klientów Jeśli zignorujesz tych klientów, przestaną oni przekazywać ci cenne informacje zwrotne i pójdą gdzie indziej po swoje rozwiązania. Może to w porządku dla ludzi z otwartym oprogramowaniem, ale z pewnością chciałbym wiedzieć, czy będę całkowicie odpowiedzialny za poprawki błędów w oprogramowaniu typu open source, ponieważ to sprawiłoby, że zastanowiłem się dwa razy nad jego użyciem.

— Robert Harvey

17

@ Rein: Jak dotąd słyszałem, jak mówiłeś dwa razy, że nie wiemy o czym mówimy. Może możesz nas oświecić, co?

— Robert Harvey

8

@ Rein Henrichs: Pierwsze dwa komentarze to ataki typu „ad hominem”. Jeśli są między nimi różnice, powiedz, kim są, zamiast mówić, że inni nic nie wiedzą.

— Andrew Grimm,

13

Podejrzewam, że celem było „Utrzymanie projektu open source nie różni się niczym od utrzymywania jakiegokolwiek innego projektu w zakresie słuchania opinii klientów i zachowania ich dobrej woli”. Jeśli tak, jestem w pełni skłonny to porzucić, ale jako ktoś, kto utrzymywał kilka projektów FOSS z udziałem od garstki do setek współpracowników, uważam, że oryginalne stwierdzenie ogólne jest „nieprawidłowe”.

— Rein Henrichs

79

Kanoniczna retorta polega na przesłaniu łatki.

— wnoise
źródło

47

Albo jeszcze lepiej, mówiąc: „Zrobiłem to już sześć miesięcy temu. Kiedy macie zamiar zająć się recenzowaniem i popełnianiem tego?”

— Bob Murphy,

14

Zwykle nie lubię krótkich odpowiedzi, ale jest to naprawdę jedyny sposób na odpowiedź, który z pewnością zakończy się wynikiem, którego szukasz. Wyraźnie wskazali najlepszy możliwy sposób osiągnięcia celu. Po co grzebać z jakimś mniejszym rozwiązaniem?

19

-1 odpowiedź dupka typu open source. Nieużyteczne. (Przepraszam.) Nie ma kanonicznej „retorty”. Najlepsza odpowiedź (zakładając, że OP nie może po prostu przesłać łatki, co w tym przypadku uważam za rozsądne założenie) to jedna z (1) „Nie mam możliwości ani zasobów, aby wygenerować łatkę [i ewentualnie zawierać link do tego samego pytania] ", (2) eyeroll, brak odpowiedzi, użycie narzędzia w obecnym stanie lub (3) poszukiwanie lepszego narzędzia.

— JohnL4

1

Nie musi to być łatka. Warto również podać szczegółowe i dopracowane informacje zwrotne. Wszystko to mówi, nie oczekuj, że zainwestuję mój czas w zaspokojenie twojej konkretnej potrzeby, jeśli nie masz nic do zaoferowania w zamian.

— Evan Plaice,

67

Jest to standardowa odpowiedź, gdy programiści nie sądzą, że zaczną coś robić w rozsądnych ramach czasowych, ale była wielokrotnie podnoszona.

Jest to niesprawiedliwe, gdy jest wielokrotnie wychowywane, ale osoba, która ostatnio o tym wspominała, nie wie o tym i po prostu dostaje „bierzemy za to łatki” od razu. W tym przypadku opiekun ma dość dyskusji, ale użytkownik uważa, że jest to nowy temat. W każdym razie, najprawdopodobniej, jeśli od razu dostaniesz „branie łatek”, nie powinieneś brać go osobiście, ale możesz przeczytać w archiwum i narzędziu do śledzenia błędów, aby uzyskać więcej szczegółów na temat problemu.

Jeśli wielokrotnie sam wysuwasz prośbę, „usuwanie łatek” może potencjalnie być względnie uprzejmym oderwaniem od innych mniej uprzejmych alternatyw ...

No i oczywiście są niegrzeczni opiekunowie, którzy powiedzą „branie łat” bez żadnego wytłumaczenia, ale powiedziałbym, że to mniejszość.

Jeśli kiedykolwiek utrzymywałeś projekt open source z dużą liczbą użytkowników, będziesz wiedział, że jest 100 razy więcej żądań, niż opiekunowie mogliby kiedykolwiek uzyskać, a wiele z nich jest ważnych dla zlecającego, ale byłoby to niezwykle trudne, lub zakłóciłoby wielu innych użytkowników, lub miałoby jakąś inną wadę, która jest widoczna tylko przy globalnym zrozumieniu projektu i bazy kodu. Lub czasem są tylko wezwania do osądu, a kłócenie się z każdym z nich trwa zbyt długo.

Większość firm, które nie są źródłami otwartymi, w ogóle nie daje ci dostępu do programistów, a po prostu uzyskasz ciche traktowanie lub uprzejmą, ale fałszywą historię z obsługi klienta. Tak więc, w otwartym kodzie źródłowym masz przynajmniej kilka opcji (zapłać komuś za zakodowanie funkcji itp.) I chociaż programiści mogą być niegrzeczni, przynajmniej dają proste odpowiedzi. Wolę mieć „nie” niż zwykle ”jest to na naszej mapie drogowej… [2 lata później]… wciąż jest na naszej mapie drogowej” coś, co otrzymałem od wielu dostawców…

Więc nie sądzę, żeby była retorta. Być może opiekun oprogramowania open source jest po prostu bardzo zajęty, może są palantem, ale w każdym razie prawdopodobnie mają ciężką pracę i debata „kto ostatni raz” nigdzie się nie zmierza. Najlepsze, co możesz zrobić, to w jakiś sposób przyczynić się i starać się być konstruktywne.

Może to nie jest kod, ale być może istnieje wiele analiz i dokumentacji scenariuszy użytkownika, które możesz zrobić. Kiedy utrzymywałem menedżera okien GNOME, wiele razy byłoby pomocne, aby ludzie analizowali problem globalnie, biorąc pod uwagę wszystkich użytkowników, i naprawdę zapisywali problemy, plusy i minusy oraz to, co powinno się stać z globalnej perspektywy.

(Zamiast tego zwykłą rzeczą było zacząć płonąć, jakby byli jedynym użytkownikiem, który się liczył i nie było żadnych kompromisów. I chociaż to świetnie, i był to punkt danych, a często udało mi się zachować uprzejmość, a nawet rozwiązać problem w końcu .. płomienie nie przyspieszają niczego. To po prostu wprawia emocje w problem i marnuje czas wszystkich).

— Havoc P
źródło

4

@Aaronaught Byłem w setkach projektów open source i nie zauważyłem DIY jako domyślnej odpowiedzi. Jest to odpowiedź na niektóre smaki zapytania.

— Havoc P

2

Mówię tylko: myślę, że częściej niż nie, istnieje jakiś powód, dla którego opiekun ma co najmniej trochę za mało tematu (lub osoby), zanim powie „zabrać łaty”, i warto zastanowić się, dlaczego dostałem tę odpowiedź. To moje doświadczenie, fwiw. Jeśli pytanie dotyczy przypadków, w których nie ma powodu, by mieć dość tego tematu lub osoby, to na pewno „zabranie łatek” prawdopodobnie nie jest dobrą rzeczą dla opiekuna. Ludzie popełniają błędy. Nadal twierdzę, że wątpię w retortę (lub taką meta-dyskusję), która może pomóc, ale czasem konstruktywne zaangażowanie.

— Havoc P

5

Ponadto, chociaż można go sformułować mniej lub bardziej grzecznie, jeśli opiekun ma w głowie zaległości w pracy, prawdopodobnie ma jedną rzecz, którą może dostać do siebie, na każde 100 rzeczy, dla których wziąłby łatkę, ponieważ chcieliby funkcja; i jest jeszcze jedna kategoria zmian, które odrzuciliby, nawet gdyby ktoś inny wykonał pracę. Musi więc istnieć jakiś sposób komunikowania się „Przyjąłbym tę zmianę, ale nie mam planów, aby zrobić to sam”. Wydaje się, że niektórzy ludzie uważają, że „Pewnie, że zaraz nadejdzie” to jedyna akceptowalna odpowiedź. Ale „robienie łatek” to prawdziwa kategoria.

— Havoc P

2

@Aaronaught te brzmią jak dobre frazesy. Myślę, że często nie ma na celu obrażenia / chamstwa przez „wzięlibyśmy łatkę”, ale programiści z reguły nie są najbardziej wrażliwymi emocjonalnie typami, mogą pędzić przez e-mail, a ton nie przekazuje tekstu zbyt dobrze, więc łatwo jest go rozpoznać jako krótko.

— Havoc P

2

W rzeczywistości „weźmiemy za to łatkę” różni się na dwa subtelne, ale ważne sposoby: (1) nie nakłada odpowiedzialności bezpośrednio na użytkownika i (2) przyznaje, że wniosek został poważnie rozpatrzony, mimo że nie był zaimplementowano. Chociaż wynik netto jest zasadniczo taki sam, jest to o wiele bardziej humanitarna odpowiedź. (Nadal nie zaszkodzi jawnie dodać domniemanych ... ale nie mamy zasobów, aby sami je teraz ukończyć. )

— Aaronaught 18.04.18

43

Powodem, dla którego otrzymujesz tę odpowiedź, nie jest to, że opiekunowie są szarpnięciami, ale to, że nie przekonałeś ich odpowiednio o propozycji wartości, jaką oni pracują nad twoją funkcją dla ciebie .

Najlepszą odpowiedzią jest rozpoczęcie dialogu na temat wartości Twojej funkcji dla całej społeczności , aby przekonać się, czy możesz przekonać ich do zmiany zdania. Może mają rację i wiedzą więcej o potrzebach swojej społeczności niż ty - ale z drugiej strony, może nie.

Jeśli ta funkcja jest tylko dla ciebie cenna i ma niewielką lub żadną wartość dla społeczności, uważam, że pieniądze są doskonałym czynnikiem motywującym, podczas gdy narzekanie na ich podejście nie jest.

— Rein Henrichs
źródło

15

Oczywiście, może to szarpnięcia. Ta odpowiedź sama w sobie nie jest bardzo dokładnym wskaźnikiem, ponieważ jest również używana przez nie-szarpnięć, gdy pytający jest palantem.

— Rein Henrichs

4

Chciałbym również dodać, że przy braku pieniędzy często możesz zamienić coś w naturze na pracę: pomóż uporządkować zajętą kolejkę problemów, spędzaj czas na kanale IRC i udzielaj wsparcia, łat testowych lub pisz dokumentację. Projekty open source mają ograniczone zasoby i muszą je jak najlepiej wykorzystać. Dodanie funkcji jest wykonalne, jeśli jest ważne dla wystarczającej liczby osób lub ważne dla osób, które robią / dają wystarczająco dużo. Jeśli twoja sprawa nie jest pierwsza, zrób to drugie.

— HedgeMage 16.04.2011

2

Szczerze mówiąc, najlepszym sposobem na przekonanie programisty jest pokazanie mu, jak bardzo jego baza użytkowników chce tej funkcji. Bugtrackerzy z głosowaniem, wątkami na forum itp. Są do tego bardzo dobrzy i są wykorzystywani w wielu projektach typu open source.

— ProdigySim

4

Podobnie, gdy ludzie dostać RTFM lub cyfrowym eliminatorem sprzężeń akustycznych jako odpowiedź lub -1 w przypadku SE, to dlatego, że pytający nie przekonały odpowiadającego odpowiednio z propozycją wartości odpowiadając na ich pytania dla nich . Jestem pewien, że wielu z was może odnosić się do tego uczucia.

— Rein Henrichs

1

@ Walter Tak, dlatego zasugerowałem przekonanie osoby o „wartości Twojej funkcji dla całej społeczności”.

— Rein Henrichs

31

Jaka jest kanoniczna retorta do „to open source, prześlij łatkę”?

Nie ma rozsądnej retorty, która mogłaby coś zmienić. Próba przekonania wolontariuszy do zrobienia czegoś, czego nie zamierzają zrobić, jest stratą czasu ... lub gorzej.

Twoje opcje to:

Rób, co sugeruje odpowiedź; tj. zaimplementuj funkcję i prześlij ją jako poprawkę. Nazywa się to „oddawaniem czegoś”.
Znajdź kogoś, kto byłby skłonny zaimplementować tę funkcję za prawdziwe pieniądze. Może to być sam projekt (np. W zamian za sponsoring), ktoś powiązany z projektem lub jakiś losowy „programista do wynajęcia”.
Znajdź alternatywny produkt.

Jeśli otrzymałeś tę odpowiedź, gdy zaproponowałeś „pomocną” sugestię, zastanów się, jak mógłbyś zareagować, gdybyś był w jego sytuacji. Na przykład, jak zareagowałbyś, gdybyś pomyślał, że ta sugestia nie była opłacalna / dobrze przemyślana / zrozumiała / itp., Ale nie miała czasu ani cierpliwości, aby zaangażować się w przedłużającą się debatę?

Byłem zaangażowany w długo działający projekt systemu operacyjnego typu open source, a jedną z najbardziej denerwujących rzeczy są ludzie, którzy siedzą w „galerii orzeszków ziemnych” i wysypują cię strumieniem sugestii dotyczących robienia rzeczy „lepiej”, które:

są niekompletne, niezrozumiałe lub wręcz nonsensowne,
są niesprawdzonymi pomysłami z obiektywnie niską szansą na sukces,
wymagałoby ogromnego wysiłku w celu wdrożenia i / lub
są sprzeczne z podanymi celami projektu.

Często najlepszą odpowiedzią jest wyraźne wezwanie osoby do zaangażowania się w projekt ... i nadzieja, że skorzystają z podpowiedzi ... aby „założyć lub zamknąć się”. Niestety, najbardziej irytujące nawet nie biorą podpowiedzi.

Oczywiście inną odpowiedzią na takie osoby jest brak odpowiedzi lub całkowite zignorowanie ich.

— Stephen C.
źródło

7

„Jak zareagowałbyś, gdybyś pomyślał, że ta sugestia nie jest opłacalna / przemyślana / zrozumiała / itp.” - dokładnie tak, jak zareaguje każdy inny profesjonalista. „Czy możesz wyjaśnić / podać przykłady tego, o co prosisz?” lub „Czy mógłbyś podać mi podstawy, dlaczego uważasz, że potrzebujesz tej funkcji?” lub „A gdybyśmy zamiast tego zrobili coś innego, czy to by zadziałało dla ciebie?” a może po prostu „Dzięki za sugestię, rozważymy ją w przyszłej wersji”. To podstawowe umiejętności interpersonalne, a nie nauka rakietowa.

— Aaronaught 16.04.11

12

@Aaronaught - Przepraszam, ale tego nie rozumiesz. Typowy programista open source nie ma czasu na grzeczne, ale ostatecznie bezcelowe dyskusje mające na celu pogłębienie ego jego „klientów”; to znaczy udając, że się troszczy, kiedy półinteligentna osoba może dowiedzieć się, że to wszystko fasada. I szczerze mówiąc, uważam, że takie ego głaszczące uprzejmość jest protekcjonalne ... i WIĘCEJ ofensywne niż mówienie bez ogródek, że nie ma szans na wdrożenie XYZ.

— Stephen C

6

@kurige - w rzeczywistości, jeśli osoby, o których mowa, ZŁOŻYŁY łaty, ZDECYDOWANIE byłyby brane pod uwagę. Problem polega na tym, że ludzie, o których mowa, są „ustami”; tzn. brak zainteresowania jakimkolwiek wysiłkiem.

— Stephen C

10

Ponieważ typowy programista open source już ma pracę, a dla zabawy opracowuje oprogramowanie open source. Robienie tego, co inni ludzie chcą od ciebie, to praca. Robienie tego, co chcesz robić, jest zabawne.

— ProdigySim

8

@Aaronaught: Czy trzeba leczyć wiele szarpnięć z szacunkiem? Biorąc udział w służbie publicznej, znajdą się ludzie, którzy będą wysuwać nieuzasadnione żądania, często w obraźliwej formie. Radzenie sobie z nieuprzejmi głupcami może być prawdziwym bólem. Wymóg szanowania ich wyeliminowałby wiele osób z branży F / OS i byłby to strata dla wszystkich.

— David Thornley,

20

Odpowiedź byłaby rozsądna, gdybyś ty i programista byli równi, i wiedzielibyście prawie to samo o podstawie kodu i języku oraz wszystkich innych rzeczach związanych z tą konkretną rzeczą, którą wskazaliście.

Nie jesteś równy (lub prawdopodobnie po prostu byś to zrobił), więc sugerowałbym odpowiednią retortę:

„Nie ma możliwości, żebym mógł to zrobić tak szybko i dobrze, jak potrafisz, dlatego właśnie poprosiłem cię o pomoc. Proszę!”

Uważam, że powiedzenie wtedy „och, tak, to, nad czym spędziłem długo i jest naprawdę dobry, jest tak proste, że każdy może przyjść z ulicy i wykonać tak dobrą robotę jak Mogę ”.

— 1249
źródło

Tyle że wcale tak nie mówią. Mówią: „to, czego chcesz, nie jest czymś, czego chce społeczność, więc nie jesteśmy naprawdę zainteresowani pracą nad tym. Możemy zaakceptować łatkę, jeśli chcesz nad tym popracować”. Domniemane jest to, że „możemy również zmienić zdanie, jeśli społeczność tego chce”. Pamiętajcie, że „Chcę, abyście mi pomogli ” jest sprzeczne z podstawową naturą projektów open source , w których (aby w pełni wykorzystać moje umiejętności w Star Trek) dobro wielu zawsze przewyższa dobro niewielu.

— Rein Henrichs

Cóż, chyba że ci nieliczni mają dużo pieniędzy, historycznie rzecz biorąc.

— Rein Henrichs

2

@ Rein, nie, oni mówią, że ONI nie chcą tego robić. Całe to „społeczeństwo chce” to tylko słaby człowiek. Chodzi o to, że jeden ze WSPÓLNOTY tego żąda.

1

„nieuprzejmie jest sugerować napisanie łatki, jeśli nie wiesz z góry, że - jeśli się pojawi - rozważysz ją dla swojego produktu”. Zgoda. Tak jak powiedziałem, dlatego nie używam tej odpowiedzi. Ale mogę z tym współczuć. „Jeśli szczerze masz na myśli, że„ prześlij łatkę ”ma na celu zamknięcie ludzi zamiast delegowania pracy, to zgadzasz się, że poprosił o to członek społeczności, a nie programista”. Przepraszam, nie jestem do końca pewien, co tu mówisz.

— Rein Henrichs,

1

@ Thorbjørn Ah tak. Cóż, w rzeczywistości opiekunowie open source, których znam, na pewno nie myślą w ten sposób. W rzeczywistości dokładamy wszelkich starań, aby zapewnić wytyczne dla programistów i dokumentację, aby pomóc ludziom poznać projekt i konwencje dotyczące przyczyniania się do niego właśnie dlatego, że jesteśmy świadomi różnic w umiejętnościach. Na przykład rubini.us/doc/en/contributing

— Rein Henrichs

16

Kanoniczna retorta polega na rozwidleniu projektu.

— użytkownik16764
źródło

8

lub prześlij łatę

— Kamil Szot

2

Co dobre będą rozwidlone doprowadzić cię?

1

@Thorbjorn: Każdy może od czasu do czasu użyć dobrego widelca. Nawet litość.

— user18014

15

Kanoniczna odpowiedź na „prześlij łatkę” brzmi:

„Nie mam wymaganych umiejętności, doświadczenia ani czasu, więc czy możesz mi powiedzieć, gdzie mam wysłać skrzynki piwa facetowi, który może to dla mnie zrobić?”

— gbjbaanb
źródło

13

Prześlij kompleksową walizkę testową .

— alecco
źródło

1

Podoba mi się ten, ale często zajmuje to więcej czasu niż samo przesłanie łatki! Stała tutaj jest czas na zapoznanie się z bazą kodu i najprawdopodobniej największa część albo stworzenia testu, albo napisania łaty bezpośrednio!

— Newtopian

1

Podoba mi się ta odpowiedź na błędy. Nawet jeśli nie rozumiesz struktury wystarczającej do przesłania poprawki, oszczędza to ogromną ilość czasu dla kogoś, kto to robi. Nie ma nic mniej skłonnego do rozwiązania problemu niż niejasny i nieodwracalny „błąd”, który może być po prostu źle skonfigurowanym systemem. Nie ma nic, co sprawiłoby, że podskoczyłem do problemu szybciej niż prosta walizka testowa, dzięki czemu mogę szybko wypróbować różne poprawki.

— BobMcGee

11

„Jeśli to zrobisz, uwzględnię to” jest znacznie lepsze niż „nie”.

Jeśli nie możesz wykonać pracy z tego czy innego powodu, wyjaśnij to osobiście opiekunowi projektu.

Jeśli nie chcesz w żaden sposób wnosić wkładu w projekt typu open source, z którego chciałbyś skorzystać, powinieneś poszukać wsparcia handlowego lub innego produktu komercyjnego.

— yfeldblum
źródło

5

Więc tylko ci, którzy bezpośrednio przyczyniają się, mają prawo narzekać na błąd lub brakującą funkcję? Zgadza się, ale oznacza to również, że ani autorzy, ani użytkownicy nie mają prawa narzekać na brak adopcji.

— Aaronaught 16.04.2011

@Aaronaught Nie, mają prawo złożyć skargę, ale istnieje limit czasu, który deweloper może zainwestować w projekt, i jest to ważne, aby użytkownicy mogli to rozpoznać. W mojej własnej pracy zastrzegam „Z zadowoleniem przyjmuję prośbę o łatkę / ściągnięcie” dla funkcji, które mają kiepskie propozycje wysiłku / wartości dla społeczności. Lub w przypadku, gdy użytkownik nalega, aby otrzymał funkcję PRAWIDŁOWO TERAZ i nie szanuje cudzego czasu ani innych zobowiązań projektowych.

— BobMcGee,

10

"Dzięki za odpowiedzi."

Dlatego:

Przy zerowej cenie popyt (zapytania o funkcje) przewyższa podaż (dostępni koderzy do implementacji wspomnianych funkcji).
Szarpanie się na wszystkim, co zapewniono za darmo, nie ma klasy IMHO.
Taki jest cel FOSS: ludzie przynoszą własne warzywa i mięso, aby wzbogacić kamienną zupę. Jeśli nie mogę coś wnieść, to powinienem być wdzięczny, że mogę w ogóle jeść i nie narzekać, że nie jem lepiej.

— Jan
źródło

9

Nie musisz nic mówić. Sam fakt, że programiści odpowiedzieli, jest wystarczającą wskazówką, że już wiedzą, że problem istnieje i że powoduje ból (przynajmniej niektórych) użytkowników.

Pod koniec dnia nic, co powiesz, nie przekona programisty do pracy dla ciebie, jeśli nie będzie chciał.

— Dean Harding
źródło

9

Dobry projekt open source będzie miał system zgłaszania błędów / funkcji, w którym użytkownicy mogą zgłaszać błędy / funkcje, a inni mogą głosować na nie, aby opiekunowie mogli zidentyfikować to, co jest ważne dla całej społeczności. Najszybszym sposobem na wprowadzenie funkcji jest jednak przesłanie łatki. Okres ... nie można tego obejść.

— Michael Brown
źródło

8

Osobiście wolałbym uzyskać odpowiedź: „To znany problem, ale niestety nie jest to problem, który należy rozwiązać w najbliższym czasie. Deweloperzy pracują nad innymi problemami. W tej chwili nie ma ETA”.

Odpowiedź „prześlij łatkę” jest bardzo niegrzeczna, ponieważ zakłada wiele rzeczy:

Wszyscy użytkownicy programu są programistami lub wszyscy zgłaszający błędy są programistami.
Wszyscy programiści znają język, w którym znajduje się program.
Wszyscy programiści wiedzą o każdym rodzaju problemu, jaki może mieć każdy program.
Wszyscy programiści mają czas wolny na pracę nad projektem typu open source.

Nawet jeśli założymy, że twórca odpowiedzi „prześlij łatkę” wie wszystko powyższe, to po prostu sprawia, że stwierdzenie brzmi: „X godzin mojego czasu jest wart więcej niż rząd wielkości więcej godzin twojego czasu, w którym wstaniesz przyspieszyć i naprawić problem ".

Zasadniczo, kiedy otrzymuję nieuprzejmi odpowiedź od dewelopera, kiedy pytam o problem, który mam lub zgłaszam błąd, ja przestaję używać tego programu. Nie używam już na przykład uTorrenta (nie open source, ale o to chodzi), ponieważ odpowiedzi, które otrzymałem na ich forum „wsparcia” były bardzo niegrzeczne. Zgłosiłem problem na forum z raportami błędów. Wątek został natychmiast zablokowany za pomocą łącza do innego wątku na podobny, ale inny problem w wątku (który również został oczywiście zablokowany). W międzyczasie otworzyłem wątek na forum dyskusji ogólnej, pytając, czy ktoś znalazł rozwiązanie tego problemu. W czasie, gdy trzeba było zapisać ten wątek i wrócić i zobaczyć, że mój pierwszy wątek został zablokowany, mój wątek w ogóle został zablokowany, a moje konto na forum zostało zablokowane za zachowanie zakłócające. Odinstalowałem uTorrent i od tamtej pory nie wróciłem.

— Boczek
źródło

Czy masz na myśli „wolałbym otrzymać odpowiedź” w przeciwieństwie do „wolałbym nie otrzymywać”?

— Andrew Grimm

Dziękuję w szczególności za pierwszy akapit. To niesamowite, jak tak podstawowa forma profesjonalnej uprzejmości może być obca tak wielu osobom. Bez względu na to, czy otrzymujesz zapłatę, czy nie, właściwą odpowiedzią jest potwierdzenie problemu i wyjaśnienie jego statusu (nawet jeśli status jest „odroczony”).

— Aaronaught 16.04.11

8

Samo odpowiedzenie „prześlij łatkę” jest niegrzeczne IMO, ale nadal ... jeśli używasz oprogramowania open source do czegoś poważnego, musisz być przygotowany, aby zająć się nim, jeśli zajdzie taka potrzeba.

Poniższy artykuł oparty jest na postu Jeremiasa Maerki (znanego z Apache FOP):

Jeśli coś nie działa, masz kilka opcji:

To jest oprogramowanie typu open source: możesz to naprawić samodzielnie.

Jeśli nie możesz tego naprawić samodzielnie, możesz poczekać, aż ktoś będzie miał czas wolny i uzna, że wdrożenie go jest przyjemne.

Jeśli tak się nie stanie, możesz znaleźć lub zatrudnić kogoś, kto zrobi to za Ciebie.

Myślę, że jest to bardzo ważna pełna wersja odpowiedzi „prześlij łatkę”.

— Bertrand Delacretaz
źródło

6

Za każdym razem, gdy to widzę, od razu zaczynam szukać alternatywnego produktu. Dla mnie jest to niebezpieczny znak, że opiekunowie albo nie dbają o swoich użytkowników (źle, jeśli twój projekt jest wszędzie używany), albo stracili zainteresowanie projektem. Oba z nich zwykle oznaczają, że projekt wkrótce umrze lub będzie nękany stagnacją, ponieważ programiści odmawiają kontynuowania projektu

(Pamiętaj, że nie mówię, że pierwszy raport o błędach, który widzisz z tego rodzaju odpowiedzią, którą uruchamiasz. Musisz spojrzeć na ogólny trend. Jeśli większość raportów o błędach kończy się z tego rodzaju odpowiedzią, zastosuj się do tej porady. Jeśli to tylko kilka, są to najprawdopodobniej żądania funkcji, które nie pasują do celów projektu lub są bardzo specyficzne dla konkretnego zastosowania)

Jak powiedział @MainMa, rozpoczęcie tworzenia nowego projektu jest bardzo trudne. Większość programistów nie rozumie tego, ponieważ pracują nad projektem od miesięcy / lat i ma to dla nich sens. Może to czasem być uczciwy błąd.

— TheLQ
źródło

3

Od czasu do czasu żartuję, że darmowe oprogramowanie może być darmowe jak w piwie, wolne jak w mowie lub wolne, gdy dostajesz to, za co płacisz.

Mówię to żartem (pracuję dla firmy, która używa dużo OSS), ale myślę, że jest w tym prawda - jeśli chcesz wsparcia na poziomie komercyjnym, musisz albo użyć komercyjnego oprogramowania z odpowiednią ofertą wsparcia, albo znaleźć oprogramowanie typu open source, które pozwala na taki poziom wsparcia (zazwyczaj przez kogoś, kto za to zapewnia, ale potencjalnie przez twoją organizację zatrudniającą lub przydzielającą zasoby programistyczne do pracy nad nim).

„Prześlij łatkę” jest denerwujące, ale podkreśla coś na temat OSS i być może powinno przypominać, że OSS nie jest odpowiedni dla wszystkich w każdej sytuacji, przynajmniej nie upewniając się, że masz solidne ramy wsparcia (albo wewnętrznie, opłacane za społeczność lub za jej pośrednictwem).

Często myślimy o oprogramowaniu, które jest bezpłatne jak w piwie, ale nie w mowie (to znaczy nie otwarte darmowe oprogramowanie). Być może jest to przypadek, w którym powinniśmy myśleć o oprogramowaniu tak wolnym jak w mowie, ale nie tak jak w piwie.

— Jon Hopkins
źródło

2

Przełącz się na dobrze utrzymaną alternatywę.

Z mojego doświadczenia z dobrze utrzymanymi projektami typu open source wynika, że jeśli utworzysz dobrze zdefiniowany raport o błędzie lub prośbę o funkcję, ma ona bardzo dużą szansę na wdrożenie.

— vartec
źródło

2

Raporty o błędach i prośby o funkcje często nie są dobrze zdefiniowane. Z mojego doświadczenia wynika, że kompetencje i szacunek działają dobrze. Ponadto najlepiej rozważyć dobrze zdefiniowane żądanie funkcji. Może to być uważane za niski priorytet lub może być czymś, czego grupa projektowa wyraźnie nie chce robić (w PuTTY FAQ są dobre przykłady i ładna lista żądań funkcji pogrupowanych według kategorii).

— David Thornley,

1

„Mogę pracować tylko nad jedną rzeczą na raz, ale mogę narzekać na wiele rzeczy naraz. Myślę, że obie funkcje są przydatne”. - akkartik na ycombinator .

— Vincent Scheib
źródło

1

Uważam, że kiedy pracujemy nad projektem, dostarczając wydania i wsparcie, powstaje niewypowiedziana, dorozumiana, umowa wsparcia między deweloperem a użytkownikiem. Twórca przyjął domyślną odpowiedzialność za obsługę bazy kodów dla swoich użytkowników, w tym dodawanie funkcji na żądanie.

Moim zdaniem „Prześlij łatę” zasadniczo daje palec użytkownikom. Jest to kontekstowe - czasami jest to po prostu zbyt duży wysiłek, aby go wdrożyć, czasem zniszczyłby istniejący projekt lub wywoływałoby rozgorączkowane zapalenie skóry lub z wielu innych powodów. Ale ostatecznie mówi: „pieprzyć cię, nie robiąc tego”. Co, moim zdaniem, jest do pewnego stopnia naruszeniem tej niewypowiedzianej umowy.

— Paul Nathan
źródło

To nie jest umowa, chyba że obie strony coś otrzymają. To, czego projekt zazwyczaj chce, to dobrze wykonane raporty o błędach i często dobrze wykonane prośby o funkcje, a nie wszystko, co przychodzi do końca tego dorozumianego kontraktu.

— David Thornley,

1

@Aaronaught: Zapewniają bezpłatne testy tylko wtedy, gdy zgłaszają raporty o błędach, które są wystarczająco szczegółowe, aby z nimi pracować. Widziałem moją część raportów o błędach. Mogą, ale nie muszą, zapewniać dobrą reklamę. Większość osób korzystających z F / OSS nie daje nic pożytecznego, co jest w porządku, ale na pewno nie jest to jedna strona umowy.

— David Thornley,

1

@David: Czy mógłbyś przestać ograniczać rozmowę tylko do najtrudniejszych / nieproduktywnych użytkowników? Jeśli chcemy uogólnić, to uogólnienie musi dotyczyć całego użytkownika i bazy danych jako zbiorowości; publiczne udostępnienie wszystkich tych osób. W zamian za dobro, które otrzymujesz od wielu z nich, masz problemy od wielu innych. To jest życie.

— Aaronaught 18.04.18

1

@Aaronaught: Jeśli chcemy uogólnić, musimy upewnić się, że uogólniamy odpowiednio. Nie próbuję ograniczać rozmowy do najgorszych użytkowników, po prostu zaznaczając, że oni tam są. Większość rozmów wydaje się zakładać, że wszyscy użytkownicy są w pewien sposób współtwórcami, a to po prostu nieprawda. Jeśli będziemy rozmawiać tylko o użytkownikach, którzy są przydatni w projekcie, wydaje się sprawiedliwe, aby mówić tylko o członkach zespołu projektowego, którzy są na ogół uprzejmi.

— David Thornley,

2

@David: Oczywiste jest, że niektórzy użytkownicy i zewnętrzni współpracownicy pomagają, a także niektórzy powodują problemy. Oczywiście są tacy programiści, którzy są uprzejmi i profesjonalni, o ile pozwalają na to zdrowy rozsądek i dobre umiejętności zarządzania czasem, a także programiści, którzy są niegrzeczni i nieprofesjonalni z przyzwyczajenia. To pytanie dotyczyło tego, jak radzić sobie z drugą grupą programistów. Istnienie „problematycznych użytkowników” nie jest kwestionowane, ale jest to czerwony śledź, który nie służy żadnemu celowi poza wykolejeniem dyskusji poprzez stworzenie sytuacji przeciwnej - zostawmy to w spokoju.

— Aaronaught

1

Można to zrobić na kilka sposobów.

Propozycja funkcji i głosowanie. ale to wymaga czasu.
Zatrudnij firmę, która potrzebuje go do zrobienia poprawki. Oczywiście jest to najlepsze rozwiązanie, ale przygotuj się na współpracę z facetem, który tworzy oprogramowanie open source, które chcesz zaktualizować.
Ważne jest również ustalenie, dlaczego ta funkcja nie jest zaimplementowana. Często funkcja ta jest poza linią projektu oprogramowania: zespół nie chce tej funkcji, nie czuje się potrzebny lub po prostu myślą, że to nie jest dobry sposób na zrobienie czegoś. W takim przypadku powinieneś po prostu rozwidlić projekt i zrobić go sam.
Użyj zastrzeżonego oprogramowania, które robi to, co chcesz.
Pamiętaj, że oprogramowanie OOP często ułatwia proces integracji funkcji.
Zawodzenie na liście mailingowej, na irc lub na forum po prostu wkurza programistów i daje amunicję zwolennikom OSS.

— żart
źródło

0

Nic, co możesz powiedzieć, zmusi go do tego. W końcu dlaczego miałby? Z powodu życzeń jednego użytkownika? To nie jest wystarczający powód.

Ale jeśli możesz zebrać rozsądną liczbę użytkowników i podać racjonalne powody („Chcę tego” nie jest racjonalnym powodem). Dlaczego ta funkcja może być użyteczna, ogólnie i dla ciebie oraz wielu innych osób, on może po prostu zmienić zdanie .

Chociaż istnieje również szczególny przypadek, który należy wziąć pod uwagę. To dev. jest zmęczony tworzeniem aplikacji i powoli chce ją porzucić (ma inne rzeczy do zrobienia), więc powoli rezygnuje z propozycji funkcji. Prócz przekonania go do wydania kodu, w tym przypadku praktycznie nic nie możesz zrobić, nawet w odniesieniu do powyższego.

— Wieża
źródło

Alternatywnie, programista ma wystarczającą liczbę żądań funkcji, aby utrzymać go zajęty przez resztę stulecia, chciałby uwzględnić twoje, ale nie przewiduje, że wkrótce się do niego dostanie.

— David Thornley,

@David Thornley - To też.

— Wieża

0

Szczególnie projekty typu open source są przyjazne dla nagród lub finansowania rozwoju określonej funkcji, nawet jeśli nowa funkcja nie dotarła do oficjalnych wydań.

Ponadto tak, jednym z pomysłów związanych z publikowaniem oprogramowania typu open source jest, aby każdy miał prawo i obowiązek wnieść własny wkład.

W przypadku zamkniętego źródła najlepszym zasobem jest zebranie statystycznie ważnej grupy z bazy użytkowników, która chce rozwiązań takich jak te, które chcesz.

— Apalala
źródło

2

Prawo do udziału, tak, ale ostatni raz czytałem GPL nie wspominając nic o odpowiedzialności za użytkowników końcowych do podejmowania własnych składek. To trochę przesadzone, nie sądzisz?

— Aaronaught 16.04.11

0

Z mojego doświadczenia wynika, że taka odpowiedź jest zwykle udzielana, jeśli żądanie użytkownika nie pasuje do celu projektu. Zdarza się, gdy ludzie myślą, że zaimplementujesz wszystko, co ci proponują, i jeszcze więcej - za darmo, open source i wspaniałą i szczęśliwą przyszłość.

„Prześlij łatkę” jest stosunkowo niegrzeczną odpowiedzią (należy jej oczywiście unikać. Szczególnie w tej zwięzłej i ostrej formie. Istnieje wiele sposobów wyrażenia z grubsza tej samej wiadomości - na przykład „zaproś” użytkowników do pomocy, ponieważ ty nie masz czasu na samodzielne wdrożenie). Ale w tej chwili jest to wyraźny wskaźnik „przestań marnować mój czas”. W związku z tym niewiele można z tym zrobić, nie ma też odpowiedzi „kanonicznej”.

Najlepszą odpowiedzią, jaką mogę wymyślić, jest przedstawienie łatki . Zakładając, że łatka działa, przynajmniej udowodniłeś, że pomysł nie jest całkowicie nierealny. Zazwyczaj oznacza to, że osoby odpowiedzialne za projekt ponownie rozważą propozycję.

— Alexander Gessler
źródło

1

Nie sądzę, aby jakikolwiek programista odpowiedział na „prześlij łatkę” dotyczącą żądania, które nie pasuje do celu projektu. To bardziej nieuczciwe niż niegrzeczne. Albo oprogramowanie staje się wzdęte, a deweloper nienawidzi cię za to, albo nie akceptuje poprawki i skutecznie marnuje twój czas. To drugie jest bardziej prawdopodobne. Twórca naprawdę powinien szczerze powiedzieć „Nie chcemy tego zmieniać, ponieważ ____” i gotowe.

— Rei Miyasaka,

@Rei Miyasaka: Osobiście byłbym wściekły, gdy otrzymałem „prześlij łatkę”, wykonałem pracę, aby zrobić dobrej jakości łatkę, a potem powiedziano mi, że i tak nie chcą tej funkcji.

— David Thornley,

@David Tak, co? Rzuciłbym krzesło lub dwa.

— Rei Miyasaka,

0

„Prześlij łatkę” jest uzasadnionym pomysłem na pomysły, które nie pasują do celów projektu. Prawdopodobnie na dłuższą metę lepiej jest po prostu powiedzieć, że pomysł jest do kitu lub próbujesz wykorzystać projekt do czegoś, co wykracza daleko poza zamierzony zakres, ale „hej, jeśli uważasz, że to, o co pytasz, jest tak trywialne, dlaczego nie” t spróbujesz dopasować go do naszej istniejącej bazy kodu ”jest czasem odpowiedni.

Jeśli jest niewielki i naprawdę przydatny dla zamierzonych użytkowników projektu, po prostu prześlij raport o błędzie, jasno opisz problem, podaj kroki do odtworzenia, wskaż, że używasz bieżącej kompilacji nocnej, i zostaw to.

To, co może wydawać się drobną, prostą zmianą, która pomogłoby tonom użytkowników, może być ogromnym bólem w dupie, którego nikt by nie użył poza tobą. To najlepszy przypadek dla „prześlij łatkę”.

Możliwe jest również, że natknąłeś się na przypadek takiego jak notoryczny opiekun glibc, który wydaje się mieć jednotorowe zdanie, że jego system jest wszechświatem, jego interpretacja specyfikacji jest słowem boga, i to wszystko, niezależnie od tego, ile osób wolałoby inaczej.

— Kevin Peterson
źródło

Nie sądzę, żeby ktokolwiek zadałby to pytanie, gdyby wiedział, że zmiana byłaby ogromnym bólem w dupie używanym tylko przez jedną osobę. Zamiast więc „przesłać łatkę”, dlaczego nie uprzejmie i krótko wyjaśnić, dlaczego jest to tak wielka sprawa i nie można tego zrobić natychmiast.

— Pan Shickadance,

2

„Prześlij łatkę” jest naprawdę kiepskim odpychaniem, ponieważ możliwe jest, że ktoś prześle łatkę. Powinien być zarezerwowany dla osób o niskim priorytecie.

— David Thornley,

0

Sugerowałbym utworzenie projektu wdrożenia tej funkcji na stronach takich jak RentACoder / ELance / itp. I opublikowanie o tym na forum oryginalnego projektu open source. Każdy z programistów projektów open source, w tym autor, ma teraz motywację finansową do rozważenia twojego żądania.

— Renji Panicker
źródło

-1

Zarejestrowałem się tylko po to, by odpowiedzieć na to pytanie.

Czy istnieje potrzeba retorty? ta odpowiedź jest zwykle używana, gdy programista wie o problemie, ale nie uważa go za ważny.

Dam ci przykład na żywo. ubuntu zrezygnowało z obsługi systray (ale można obejść tę sytuację, umieszczając aplikację na białej liście) i dodało nowe wskaźniki aplikacji. niektóre aplikacje, takie jak Jupiter, korzystały z obsługi systray, więc programista poinformował o pracy zamiast obsługi wskaźnika aplikacji, więc poprosiłem programistę o dodanie dodatku wskaźnik aplikacji, odpowiedź brzmiała: „Prześlij nam łatki”. pytając o powód, dla którego postanowili tego nie wdrażać. było to

Nie jestem zainteresowany spędzaniem czasu na budowaniu wsparcia dla libra1ry, którego nigdy nie użyję tylko dlatego, że żąda tego ktoś, kto ma dużo pieniędzy, umieszczając na czarnej liście moje aplikacje do poprawnego działania w dystrybucji Linuksa tylko dlatego, że może.

Gdyby to był prawdziwy problem techniczny, prawdopodobnie podjąłbym działania, ale jest to wyłącznie manewr polityczny, więc nie, nie sądzę.

Nie, dodam go do białej listy

Słusznie. programista ma powód, aby nie implementować funkcji, ale jest gotowy zaakceptować łatki. to nie jest tak naprawdę niegrzeczne i obraźliwe, więc nie było potrzeby retorty.

Podsumowując: kanoniczna retorta polegałaby na przesłaniu łatki, ale jeśli nie, nie ma potrzeby retorty

— Lincity
źródło

-1

Rozpocznij nagrodę za wybraną funkcję.

Lub wyjdź i kup produkt, który twierdzi, że robi dokładnie to, czego chcesz i nadużywaj jego personelu pomocniczego, gdy odkryjesz, że marketing nie spełnia twoich oczekiwań.

— CyberFonic
źródło

-2

Najlepsze, co mogę wymyślić, to „ssać”.

Niestety, to oczywiście nie jest bardzo pomocne, ale myślę, że to tylko jedna z niefortunnych sytuacji, w których użytkownik jest całkowicie wkręcony. Brutalnie szczery apel do sumienia dewelopera to ostatni wysiłek.

Możesz spróbować zaoferować ( kaszel ) „darowizny”, aby rozwiązać Twój problem, ale obawiam się, że taka praktyka, jeśli zostanie zastosowana, doprowadzi do naprawdę złej utraty integralności w branży, ponieważ poprawki błędów nigdy nie powinny być opłacalne, ponieważ „Darmowe” lub komercyjne oprogramowanie.

— Rei Miyasaka
źródło