Jak sformułować „jest to oprogramowanie typu open source, prześlij łatkę”, aby było przyjazne?

18

W odpowiedziach na pytanie Co to jest kanoniczna retorta do „to open source, prześlij łatkę”? , wiele osób wyraziło opinię, że zwykłe proszenie ludzi o przesłanie łatki jest aroganckie i niegrzeczne.

Wydaje mi się jednak, że jako programista w dowolnym projekcie typu open source zobaczysz na liście mailingowej o wiele więcej żądań funkcji, niż możesz zaimplementować. Kiedy więc użytkownik mówi: „Chciałbym zobaczyć funkcję X”, prawda jest taka, że szanse na jej wdrożenie są raczej niewielkie, chyba że sami prześlą łatkę. Czasami może się przydać trochę zachęty, aby użytkownik stał się współpracownikiem.

Z drugiej strony, nie chcesz odstraszyć (potencjalnych) współpracowników, odsuwając się jako niegrzeczny.

Więc jak powiedziałbyś „prześlij łaty zamiast pytać o funkcje” w przyjazny sposób?

Aktualizacja: Dziękujemy za wszystkie sugestie! Widzę, że większość z nich wymaga dość długich wyjaśnień. Ale ponieważ wolałbym unikać (a) wyjaśniania tego samego co drugi dzień (zajmuje to zbyt wiele czasu) lub (b) używania fragmentów, które wklejam do wiadomości e-mail (robi się to bezosobowo bardzo szybko), zastanawiam się: ktoś napisał to w dokumencie, do którego mogę link?

(Specyficzne dla projektu rzeczy, takie jak pisanie testów, kompilowanie kodu i przesyłanie łaty nadal muszą być oczywiście udokumentowane, ale myślę, że te problemy techniczne powinny przejść do CONTRIBUTING.txt.)

open-source

— Jo Liss
źródło

10

Bardzo ważne, jeśli nie zamierzasz akceptować poprawek, nie proś o nie! Oznacza to, że jeśli powiesz „Prześlij łatkę”, musisz zaakceptować czystą, dobrze napisaną łatkę.

— edA-qa mort-ora-y

1

@ edA-qa - niekoniecznie każda czysta, dobrze napisana łatka - ale jeśli możesz zawetować nowe funkcje, prawdopodobnie powinieneś mieć sposób, w jaki ludzie mogą zaproponować ci te funkcje na prawdopodobnie / prawdopodobnie nie odpowiedzą, zanim zainwestują dużo czas je rozwijać.

— Steve314,

@ Steve, nie mam na myśli niezamówionych łatek, to inna historia. Mam na myśli szczególnie, jak w pytaniu, jeśli powiesz komuś, aby przesłał łatkę.

— edA-qa mort-ora-y

To tylko aroganckie i niegrzeczne, gdy naprawdę masz na myśli „to może być dobry pomysł, odejdź”. Jeśli naprawdę masz na myśli, że to zły pomysł, powiedz tak. Jeśli masz na myśli, że to naprawdę dobry pomysł, że nie masz czasu na wdrożenie, powiedz tak. I zaznacz, że byłbyś skłonny zaakceptować łatkę, która implementowała tę funkcję. (W ten sposób może ktoś rzeczywiście prześle łatkę.) Problem z powiedzeniem „prześlij łatkę” jest niejasny i lekceważący.

— David Schwartz

8

Ty nie.

O ile mi się to zdarza, kandydaci na autorów są majsterkowiczami i nie prześlą prośby o dodanie funkcji, prosząc tylko o to. Zazwyczaj będą o to prosić przy pewnym poziomie uczestnictwa:

Czy nie byłoby słodko, gdyby [...]? Może być możliwe wykonanie A, B i C. (To przynęta dla: Nie mam czasu, ale tutaj jest specjalny pomysł na wypadek, gdybyś miał.)
Oto łatka do zrobienia / oto poprawka dla [...].
Zastanawiam się nad napisaniem łatki do zrobienia [...] i mogę skorzystać z opinii / czy ktoś jest zainteresowany pomocą.
Itp.

Koderzy, którzy przesyłają żądanie funkcji, zwykle robią to z jakiegoś powodu. Niektóre z nich obejmują (i wiem na pewno, że ostatnie dwa mają miejsce na przykład w WordPress):

Są głęboko w innych projektach open source, tj. Nie mają czasu.
Są jeźdźcami na wolności i zamierzają utrzymać to w ten sposób.
To znacznie więcej niż ich umiejętności / napisane w języku, o którym nic nie wiedzą.
Używają oprogramowania z braku lepszej opcji i nie chcą zajmować się śmierdzącym stosem kodu batsh * t ^ \ b.
Nie można już im przeszkadzać, ponieważ ich wcześniejsze łatki zostały zignorowane / odrzucone, tzn. Myślą, że zmarnowaliby swój czas.

Częściej prośby o funkcje będą pochodzić od użytkowników końcowych, którzy nie mogliby udostępnić łatki, nawet gdyby chcieli. Zwłaszcza gdy zostanie złożony poza systemem biletowym.

Myślę, że Twoim najważniejszym priorytetem powinno być nie odkładanie potencjalnych / obecnych współpracowników, a nie próba aktywnego rekrutowania nowych. To niezwykle ważne i mówię to z doświadczenia. Dziwnie podchodzę do wybierania nowej bazy kodu, która polega na pobieżnym czytaniu kodu, aby uzyskać pewien poziom zrozumienia go, wskakiwaniu do systemu biletowego i naprawianiu łatwych do znalezienia błędów w celu dogłębnego poznania wewnętrznych elementów (i archiwizacji nowe jak testuję). Przez lata zalałem kilka projektów dziesiątkami biletów i łatek. Wiele razy bilety te nie zwracają uwagi na czas lub nie zwracają na nie uwagi (nawet potwierdzenia, np. Nie przestawaj!) - także wtedy, gdy dołączone są udokumentowane etapy diagnozowania i testy jednostkowe.

— Denis de Bernardy
źródło

1

Nie mogłem się więcej zgodzić. Wydaje się, że wśród projektów F / OSS panuje ogólne przekonanie, że każdy, kto prześle żądanie funkcji, jest po prostu leniwy i może przesłać łatkę / zmodyfikować własną instalację, jeśli naprawdę chce tej funkcji. Jest to bardzo odrażające dla każdego, kto po prostu nie umie programować lub nie ma czasu, ponieważ jest zaangażowany w inne projekty. Nie słowa „prześlij łatkę” są niegrzeczne, ale założenie, że użytkownik nie ma nic więcej na swoim talerzu.

— Shauna

9

Krótko mówiąc, wyjaśniasz, że nie masz nieograniczonego czasu na wykonywanie pracy za darmo. (Możesz pominąć bit „za darmo”) i że mogą wnieść swój wkład w dowolnym momencie, nie jest to „twój” projekt, to projekt każdego.

więc mówisz „Naprawdę przepraszamy, to świetny pomysł, ale jesteśmy zbyt zajęci całą pozostałą pracą, dodamy ją do listy, ale jeśli naprawdę chcesz to zrobić, i chcielibyście nam pomóc, przyczyniając się do projektu, to byłoby wspaniale. Mamy dokumentację, aby pomóc chłopakom wprowadzić zmiany w projekcie, są tutaj, więc jeśli masz umiejętności i czas i chcesz nam pomóc, to spróbuj i wyślij nam łatkę z twoimi zmianami. Być może będziemy musieli wprowadzić kilka modyfikacji, kiedy to otrzymamy, aby pasowało do standardów projektu, ale będziesz robił nam wielka przysługa, dając nam przynajmniej wsparcie dla tej pracy, a my pokochamy was za pomoc ”.

Oczywiście, kiedy zaczniesz prosić o plastry, nigdy nie będziesz mógł pozostawić ich zbyt długo w systemie biletowym, jeśli dostaniesz dużo, zintegrujesz je bardziej niż wykonując pracę, którą kiedyś wykonywałeś. Może ci się to nie podobać, ale jest to konieczne, jeśli chcesz, aby łatki się pojawiały.

— gbjbaanb
źródło

Lubię to. Być może jest to rzeczywiście coś, co najlepiej umieścić w dokumentacji, więc nie musisz go kopiować i wklejać za każdym razem, gdy musisz to wyjaśnić. A potem po prostu mówisz: „Czy chcesz wnieść łatkę? Http: //.../#contributing”

— Jo Liss

@JoLiss: Krytycznie oceniasz moją odpowiedź za to, że brzmi bezosobowo; jak uważasz, że kopiowanie i wklejanie hiperłącza do FAQ jest lepsze? Jeśli zamierzasz użyć konserwowanej odpowiedzi, użyj takiej, która wykazuje empatię lub brzmi profesjonalnie (lub obie). Ten pomysł na skrót nie jest; w rzeczywistości jest to właśnie ten rodzaj chamstwa, że oryginalne pytanie narzekał.

— Aaronaught

Ciekawe. Nie zdawałem sobie sprawy, że ludzie niekoniecznie uznaliby to za niegrzeczne, gdybyś zamieścił link. Z drugiej strony uważam, że reakcje w puszkach są bardzo bezosobowe. Być może więc najlepiej jest po prostu wpisać tego rodzaju wyjaśnienia.

— Jo Liss,

6

Bądź uprzejmy i jasno wyjaśnij sytuację. Co powiesz na coś takiego:

Dziękujemy za twoją opinię. Uważamy, że twoja funkcja jest bardzo interesująca, ale pomimo naszych starań w celu wdrożenia najbardziej pożądanych funkcji w naszym produkcie, nie mamy wystarczająco dużo czasu na ich wdrożenie. Jeśli jesteś programistą, możesz dołączyć do nas, przyczyniając się do projektu, ponieważ jest to oprogramowanie typu open source.

Widzisz, nie możesz po prostu powiedzieć „Dlaczego przeszkadzasz mi swoimi prośbami? Nie jestem tu, aby pracować dla ciebie za darmo; jeśli chcesz tę funkcję, idź i zaimplementuj ją sam”. Ta osoba może nie być programistą, może nie znać języka użytego do opracowania produktu itp.

Zamiast być niegrzecznym, możesz zasugerować uczestnictwo w projekcie, a także wyjaśnić, dlaczego możesz nie być w stanie samodzielnie wdrożyć tej funkcji.

Innym sposobem, aby nie być nieuprzejmym, jest nic nie mówić. Jeśli masz witrynę internetową, na której użytkownicy Twojej aplikacji mogą sugerować nowe funkcje i zgłaszać błędy, możesz posortować elementy według ich priorytetu: na przykład, jeśli o funkcję poprosi 10 000 użytkowników, a o inną poprosi tylko 10 , są szanse, że pierwszy zostanie wdrożony jako pierwszy.

Na takiej stronie zawsze możesz umieścić sugestię „zaimplementuj to sam” dla funkcji, które po kilku dniach lub tygodniach nie otrzymały wystarczającej liczby głosów pozytywnych od innych użytkowników.

— Arseni Mourzenko
źródło

5

Dziękuję za twoją prośbę. Dodaliśmy go do naszego portfela projektów i wkrótce go przejrzymy.

Należy pamiętać, że ze względu na liczbę żądań nie możemy zagwarantować, że każde zostanie zrealizowane. Polegamy na wolontariuszach, więc jeśli jesteś programistą, zastanów się, czy nie poświęcić trochę czasu i przesłać łatkę . W przeciwnym razie pamiętaj, że wszyscy ciężko pracujemy, aby przejść przez zaległości i jak najszybciej spełnimy Twoją prośbę.

Czy to było takie trudne?

— Aaronaught
źródło

+1 doskonała; miła, profesjonalna odpowiedź. @Jo Liss: pamiętaj, że większość ludzi po prostu chce korzystać z oprogramowania, nie poświęcając mu swojego życia.

— Steven A. Lowe

Podoba mi się jej esencja, ale osobiście uważam, że ton jest zbyt bezosobowy. Zazwyczaj nie jesteś firmą zajmującą się obsługą klienta, jesteś po prostu programistą rozmawiającym z rówieśnikiem. Nawet ludzie z 37signals unikają tego rodzaju języka .

— Jo Liss,

@JoLiss Ty się robi obsługi klienta, czy chcesz w to wierzyć lub nie. I nie mówiłeś nic o „rówieśnikach”. Możliwe, że osoba, z którą rozmawiasz, jest programistą, ale chyba, że wiesz, że tak naprawdę nie sądzę, że jest to właściwe założenie (chyba że pracujesz nad narzędziami dla programistów, ale nie określiłeś to w pytaniu). Wreszcie, faceci w 37 sygnałach rozmawiający o tym, co stanowi gówno *, jest co najmniej ironiczny.

— Aaronaught

Hm Nie jestem pewien, czy chciałbym sprawiać wrażenie, że zajmuję się obsługą klienta ... Twoja opinia, że użytkownicy niekoniecznie są rówieśnikami, jest jednak dobrze przemyślana. Re 37signals, oto kolejny post na blogu, który mówi o tonie - myślę, że nie chodzi o to, że nie powinieneś bzdur, ale o to, że nie powinieneś wyglądać jak korporacja bez twarzy. Moim zdaniem jest to dobra strategia, a jeszcze bardziej dotyczy projektów typu open source.

— Jo Liss,

2

@JoLiss: Jeśli chcesz być bardziej osobisty niż to, świetna, cała siła do ciebie - to, dla mnie, to minimalny standard, który powinieneś spełniać dzięki uprzejmości. Nie mów tylko „prześlij łatkę” - wyjaśnij, że jesteś zajęty, a nie leniwy lub bezinteresowny; przyznają, że mogą nie być w stanie przesłać łatki i nawet jeśli tak, nadal wyświadczą ci przysługę, zobowiązując się.

— Aaronaught

4

Cóż, zamiast po prostu powiedzieć „prześlij łatkę”, powinieneś rozwinąć nieco więcej.

Wyjaśnij, że nie masz na to czasu w tej chwili ani w dającej się przewidzieć przyszłości, więc jeśli inni chcą go wkrótce wdrożyć, nie ma innego sposobu niż dostarczenie łatki.
Poświęć czas na ocenę tej funkcji. Jeśli szczerze ci się to podoba, nie ma nic złego w mówieniu tego. Zachęcać ludzi. Lub jeśli uważasz, że ta funkcja jest naprawdę zła, poświęć czas na wyjaśnienie tego.
Zapewnij pomoc początkową. Nikt nie zna podstawy kodu tak jak ty. Nie masz na to czasu, ale prawdopodobnie dokładnie wiesz, jak to zrobić i od czego zacząć. W ciągu 5-10 minut możesz podzielić się wiedzą, że inni będą potrzebować godzin, aby się zorientować. Pomaga to również w dominacji Twojego dużego obrazu. Zamiast przyklejać do twojego projektu funkcje obcych, możesz poprowadzić autorów do dobrej integracji.

— back2dos
źródło

Zgadzam się z tym, ale dodam, że potrzebujesz bardzo jasnych wskazówek na temat tego, czego oczekujesz od łatki. (np. zgodne ze standardami kodowymi, testowane jednostkowo, udokumentowane). Jest to ważne, ponieważ jest bardzo prawdopodobne, że to Ty będziesz musiał wspierać tę funkcję - osoby zgłaszające łatki bardzo rzadko pozostają w pobliżu, aby naprawić swoje błędy lub zaoferować wsparcie innym użytkownikom Twojej biblioteki.

— Mark Heath

3

Oto, co zwykle mówię ...

„To interesująca sugestia i byłoby fajnie, gdyby FooBarLib mógł to zrobić. Niestety, FooBarLib to dla mnie projekt czasu wolnego, więc jest mało prawdopodobne, że zacznę to robić w najbliższej przyszłości. Z zadowoleniem przyjmuję zgłoszenia do FooBarLib, więc jeśli jesteś w stanie samodzielnie to zaimplementować, prześlij łatkę (najpierw przeczytaj nasze „wskazówki dotyczące udziału w FooBarLib”). ”

— Mark Heath
źródło

2

Oprócz miłych sposobów powiedzenia „Prześlij łatkę”, dostarcz także dokumentację zorientowaną na programistę, aby inni, którzy tak naprawdę chcą, mogą szybko przyspieszyć projekt. Wiele projektów nie jest przyjazne dla programistów i wymaga co najmniej dni odczytu co najmniej tysięcy wierszy kodu i ton małych przypadków testowych, które sprawdzają różne części systemu, aby wszystko działało poprawnie.

Jeśli zapewnisz pomoc potencjalnym programistom, chętnie udzielą pomocy. Oznacza to dobrą dokumentację kodu, dobre strony wiki wyjaśniające przepływ (lub dobry schemat UML / tablicy) oraz łatwy sposób na zaakceptowanie łatek.

— TheLQ
źródło

-2

Naprawdę podoba mi się sposób, w jaki github zachęca innych do rozwijania projektu. Wiele wersji tego samego projektu może istnieć na różnych kontach użytkowników. Jeśli nie podoba ci się kierunek, w którym podążam za projektem, proszę go rozwidlić. Możesz łatwo przesyłać żądania ściągania, ale nie utkniesz, czekając, aż je zaakceptuję.

Tak więc często odpowiadam, po prostu rozwidlaj to.

— mcotton
źródło