Jak powinienem przyczynić się do (przeważnie) porzuconego projektu GitHub?


43

Niedawno próbowałem nawiązać współpracę z oprogramowaniem typu open source w GitHub i natknąłem się na sytuację, w której jestem ciekawy, jaki jest preferowany sposób postępowania.

Mniej więcej miesiąc temu znalazłem projekt na GitHub dla biblioteki, z której korzystałem już od jakiegoś czasu, w której znalazłem (i naprawiłem) kilka błędów.

Jako wstępną próbę współpracy z GitHub znalazłem repozytorium, które wydawało się mieć najwyższy wolumen ostatniej aktywności, naprawiłem jeden błąd, dodałem testy jednostkowe, wysłałem do GitHub i wysłałem żądanie ściągnięcia. W ciągu kilku godzin opiekun repozytorium, który rozwiesiłem, zaakceptował PR i połączył kilka innych PR od innych osób, które również czekały.

Zainspirowany tym, naprawiłem trzy kolejne znalezione przeze mnie błędy, każdy w osobnej gałęzi mojego repozytorium, i zgłosiłem problem i ściągałem osobno dla każdego z nich.

To było nieco ponad miesiąc temu i od tamtej pory prośby o przyciągnięcie są nietknięte. Użytkownik, którego repo, które przygotowałem, nie wydaje się być bardzo aktywny, ponieważ w ubiegłym roku wniósł tylko 7 całkowitych wkładów do GitHub, i to repo nie miało żadnych zatwierdzeń od czasu pierwszej prośby ściągnięcia.

Więc moje pytanie:

Jak postępować w tej sytuacji? Idealnie, chciałbym uniknąć tworzenia fragmentacji biblioteki, odchodząc i wprowadzając całą masę zmian w moim własnym repozytorium, które nie są scalone w repozytorium nadrzędnym. Niemniej jednak chciałbym nadal wprowadzać poprawki błędów i dodawać funkcje, ale jeśli scalę wszystko z moją gałęzią master i opręę wszystkie nowe poprawki z tej gałęzi, to jeśli opiekun repo, który rozwinęłem, kiedykolwiek powróci, wygrałem nie będę w stanie podzielić wszystkich zmian na osobne żądania ściągania dla każdej funkcji / poprawki błędu (przeczytałem, że żądania ściągania powinny ogólnie obejmować jedno żądanie ściągnięcia na funkcję lub poprawkę błędu).

Czy powinienem zachować gałąź, która jest w zgodzie z pierwotnym repo, oprzeć wszystkie moje nowe gałęzie od tej, a następnie zachować scalanie wszystkich zatwierdzeń w gałęzi master? Wygląda na to, że zostawiłoby mi to całą masę oddziałów i coraz bardziej uciążliwe zadanie za każdym razem, gdy potrzebuję scalić nowe zmiany w mojej głównej gałęzi.

Jaki jest typowy sposób podejścia do takiej sytuacji? Wydaje się dość powszechne, że projekt zostanie po prostu porzucony, a pierwotni współautorzy nie będą w pobliżu, aby przejrzeć nowe żądania ściągania. Czy jest to sytuacja, w której ktoś powinien po prostu wziąć ster i biegać z nim? Wygląda na to, że spowodowałoby to fragmentację, gdyby pierwotni autorzy wrócili i chcieli ponownie pracować nad projektem.


4
Gdy uznasz to pytanie za interesujące, możesz być również zainteresowany propozycją nowej witryny wymiany stosów open source .
Philipp

Chcesz podzielić się tym, co wyszło z rozmowy e-mail tylko dla nas ciekawskich obserwatorów? :)
winkbrace

@winkbrace Do tej pory nic. Nie otrzymałem odpowiedzi, ale wysłałem e-mail dwa dni temu. Dam wam wszystkim znać, jeśli coś się rozwinie.
JLRishe,

Odpowiedzi:


39

Nie miałem jeszcze takiej sytuacji, ale spróbuję:

Spróbuj skontaktować się z właścicielem

Może naprawdę stracili zainteresowanie, ale są gotowi przekazać projekt komuś innemu, w szczególności komuś, kto wykazał się już znacznym zaangażowaniem.

Ale być może są po prostu zajęci czymś innym (praca, wakacje, choroba, inne projekty) i nie mieli czasu zajmować się twoim PR, ale planujesz to zrobić później.

A może naprawdę przestali pracować nad projektem z jakiegokolwiek powodu.

Bez pytania nie dowiesz się tego.

Skontaktuj się ze społecznością

Z pewnością są inni ludzie, którzy przyczynili się do projektu lub przynajmniej z niego skorzystali. Sprawdź, kto rozwidlił projekt (nawet jeśli nie wprowadził żadnych zmian, nadal mogą być zainteresowani rozwojem tego projektu); sprawdź, kto zgłosił problemy lub skomentował je. Być może istnieje także społeczność spoza GitHub, np. Lista mailingowa, forum lub członkowie StackOverflow.

Jestem przekonany, że ostatecznie przejmiesz projekt, możesz potrzebować ich wsparcia. Muszą wiedzieć, gdzie znajduje się nowe repozytorium główne.

Kontynuuj składanie dobrych wniosków

To pokazuje zarówno właścicielowi, jak i społeczności, że poważnie o tym myślisz, i pozwólmy im ocenić Twój wkład.


1
Dziękuję Ci. Po nieco więcej poszukiwań wygląda na to, że ta rada jest podobna do wytycznych dostępnych dla tego rodzaju sytuacji z pakietami npm . Właśnie wysłałem e-mail do właściciela i zobaczę, na co on / on odpowiada.
JLRishe

Bardzo trudno jest znaleźć kogoś, kto może zatwierdzić PR dla konkretnego repozytorium, gdy „właścicielem” repozytorium jest organizacja z dziesiątkami użytkowników.
cowlinator

15

Jeśli właściciela oryginalnego repozytorium nie ma nigdzie i nie ma go przez dłuższy czas, opublikowałbym własne repozytorium jako inną wersję projektu.

Dzięki temu przejmujesz kierownictwo rozwoju biblioteki i nie pozostawiasz jej, by umarła w kącie, bez konieczności jej aktualizacji. Jeśli pierwotny właściciel kiedykolwiek zamknie repozytorium, świat nadal będzie mógł korzystać z wersji rozwidlonej.


1
Tak, po prostu forkprojekt i w README.md, pozostaw odniesienie i „dziękuję” pierwotnemu właścicielowi.
Jared Burrows

Dziękuję za odpowiedź (+1). Zdecydowanie robisz dobre punkty. Mogę w końcu się do tego odwołać, ale na razie zastosuję się do rady Oefe i sprawdzę, czy mogę skontaktować się z właścicielem repozytorium za pośrednictwem poczty elektronicznej.
JLRishe

Oczywiście, po prostu nie pozwól, aby repozytorium popadło w zapomnienie. Wiele dobrego kodu musi być ukryte gdzieś głęboko w Github, ponieważ pierwotnych właścicieli już nie ma.
cllamach

Jestem w podobnej sytuacji i być może będę musiał skorzystać z tej opcji - pierwotny właściciel projektu nie odpowiedział na wielokrotne próby kontaktu. Czy koszerne jest zachowanie nazwy projektu i dalsze zwiększanie numeru wersji od ostatniej oficjalnej wersji? Martwię się, że jeśli zmienię nazwę, trudniej będzie znaleźć istniejących użytkowników projektu.
pericynthion

1
Ja też mogę być w takiej sytuacji. Ale oryginalny projekt jest już zarejestrowany w Bower. Zachowanie nazwiska oznaczałoby konieczność pozyskania go przez oryginalnego autora lub skontaktowanie się z opiekunami Bower i poproszenie ich o interwencję. Nie dbam jednak o to drugie. Zmiana nazwy może być najlepszą opcją.
Lawrence I. Siden,

0

Ponieważ większość małych i średnich projektów bezpłatnych i open source jest obecnie hostowana na github, gitlab lub podobnym, możliwe byłoby zautomatyzowanie niektórych procesów przy użyciu ich interfejsów API sieci Web.

Zakładając, że jest oryginalne repo https://github.com/someUserX/projectY/, proces może wyglądać następująco:

  1. („instrukcja”) Skontaktuj się z oryginalnym autorem na różne sposoby, przynajmniej poprzez jego adres e-mail git committera i problem (jeśli jest włączony).

    W przypadku otrzymania pozwolenia lub braku odpowiedzi w ciągu kilku tygodni można uruchomić skrypt, który użyłby interfejsu API sieci Web hostów do wykonania następujących czynności:

  2. utwórz nową organizację (GitHub) o nazwie projectY, aw niej rozwiąż oryginalne repo ->https://github.com/projectY/projectY/

  3. dodaj oryginalnego autora i wszystkich autorów żądań ściągnięcia (już scalonych i nadal otwartych) jako administratorów organizacji
  4. ponownie utworzyć wszystkie (otwarte) żądania ściągania z oryginalnego repozytorium w nowym rozwidleniu
  5. zrób to samo z (otwartymi) problemami
  6. powiadamia wszystkich administratorów o nowym repozytorium
  7. utwórz ostatnie żądanie ściągnięcia do starego repozytorium, dodając powiadomienie „porzucone” / „zarchiwizowane” i link do nowego repozytorium na README

Głównym problemem, jaki widzę w tym podejściu, jest to, że niektórzy „źli” współpracownicy mogą uzyskać dostęp administratora, ale jak wyjaśnia ewangelista Wolnego Oprogramowania Pieter Hintjens (na przykład w tym wykładzie ) , złe zobowiązania można po prostu cofnąć i nie stanowią żadnego wątku projekt, który jest żywy i może z czasem pomóc złoczyńcy.
hoijui
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.