Come dovrei contribuire a un progetto GitHub (principalmente) abbandonato?


43

Di recente ho cercato di entrare in una collaborazione open source in GitHub e mi sono imbattuto in una situazione per la quale sono curioso di sapere quale sia il modo preferito di procedere.

Circa un mese fa, ho trovato un progetto su GitHub per una libreria che già utilizzavo da un po 'e in cui avevo trovato (e corretto) alcuni bug.

Come iniziale incursione nella collaborazione con GitHub, ho trovato il repository che sembrava avere il maggior volume di attività recenti, risolto un bug, aggiunto test unitari, inviato a GitHub e fatto una richiesta pull. Nel giro di poche ore, il manutentore del repository che ho biforcato aveva accettato il PR e si era unito a qualche altro PR di altre persone che stavano aspettando.

Spinto da questo, ho risolto altri tre bug che avevo trovato, ognuno in un ramo separato del mio repository, e ho presentato un problema e ho tirato la richiesta per ognuno separatamente.

Questo è successo poco più di un mese fa e le richieste di pull sono rimaste lì, intatte, da allora. L'utente il cui repository è stato biforcato non sembra essere molto attivo, dopo aver effettuato solo 7 contributi totali su GitHub nell'ultimo anno e quel repository non ha effettuato alcun commit da quella prima richiesta pull che ho fatto.

Quindi la mia domanda:

Come si procede in questa situazione? Idealmente, vorrei evitare di creare frammentazione della libreria andando via e facendo un sacco di modifiche nel mio repository che non vengono unite nel repository principale. Tuttavia, vorrei continuare a fare correzioni di errori e aggiungere funzionalità, ma se unisco tutto nel mio ramo master e baso tutte le nuove correzioni su quel ramo, allora se il gestore del repository che ho biforcato dovesse mai tornare indietro, avrei vinto essere in grado di dividere tutte le modifiche in richieste pull separate per ogni funzione / correzione di bug (ho letto che le richieste pull dovrebbero generalmente essere una richiesta pull per funzione o correzione bug).

Devo mantenere un ramo in linea con il repository originale, basare tutti i miei nuovi rami su quello e quindi mantenere tutti i commit uniti nel mio ramo master? Sembra che mi lascerebbe con un sacco di rami e un compito sempre più gravoso ogni volta che devo unire nuove modifiche nel mio ramo principale.

Qual è il modo tipico in cui uno dovrebbe affrontare una situazione come questa? Sembra abbastanza comune che un progetto venga appena abbandonato con i collaboratori originali non in giro per rivedere nuove richieste pull. È una situazione in cui qualcuno dovrebbe semplicemente prendere il timone e correre con esso? Sembra che creerebbe frammentazione se i partecipanti originali torneranno indietro e vorranno lavorare di nuovo sul progetto.


4
Quando trovi questa domanda interessante, potresti anche essere interessato alla proposta per un nuovo sito di scambio di stack open source .
Philipp,

Vuoi condividere ciò che è emerso dalla conversazione e-mail solo per noi curiosi curiosi? :)
winkbrace,

@winkbrace Finora, niente. Non ho ricevuto risposta, ma ho inviato l'e-mail solo due giorni fa. Farò sapere a tutti se qualcosa si sviluppa.
JLRishe,

Risposte:


39

Non ho ancora avuto questa situazione, ma è quello che vorrei provare:

Prova a contattare il proprietario

Forse hanno davvero perso interesse, ma sono disposti a trasferire il progetto a qualcun altro, in particolare a qualcuno che ha già mostrato un impegno premuroso.

Ma forse sono solo occupati con qualcos'altro (lavoro, vacanze, malattia, altri progetti) e non hanno avuto il tempo di gestire il tuo PR, ma hanno intenzione di farlo in seguito.

O forse hanno davvero smesso di lavorare permanentemente sul progetto per qualsiasi motivo.

Senza chiedere, non lo scoprirai.

Entra in contatto con la community

Sicuramente ci sono altre persone che hanno contribuito o almeno utilizzato il progetto. Verifica chi ha modificato il progetto (anche se non ha apportato alcuna modifica, potrebbe essere comunque interessato a vedere prosperare questo progetto); controlla chi ha segnalato problemi o li ha commentati. Forse c'è anche una comunità fuori da GitHub, ad esempio una mailing list, un forum o membri StackOverflow.

Alla fine mi occuperai davvero del progetto, potresti desiderare il loro supporto. E devono sapere dove si trova il nuovo repository principale.

Continua a fare buone richieste pull

Questo dimostra sia al proprietario che alla comunità che sei serio al riguardo e lasciamo che giudichino i tuoi contributi.


1
Grazie. Dopo un po 'più di ricerca, sembra che questo consiglio sia simile alle linee guida disponibili per questo tipo di situazione con i pacchetti npm . Ho appena inviato un'e-mail al proprietario e vedrò cosa risponde.
JLRishe,

È molto difficile trovare qualcuno in grado di approvare le PR per un determinato repository quando il "proprietario" del repository è in realtà un'organizzazione con dozzine di utenti.
cowlinator

15

Se il proprietario del repository originale non viene trovato da nessuna parte e assente per un considerevole, pubblicherei il mio repository come una versione diversa del progetto.

Con questo, prendi il comando dello sviluppo della biblioteca e non lasciarlo morire in un angolo senza essere mai aggiornato. Se il proprietario originale chiude mai il repository, il mondo può ancora utilizzare la versione biforcuta.


1
Sì, semplicemente forkil progetto e nel README.md, lasciare un riferimento e "grazie" al proprietario originale.
Jared Burrows,

Grazie per la tua risposta (+1). Sicuramente fai dei buoni punti. Potrei infine ricorrere a questo, ma per ora seguirò il consiglio di Oefe e vedrò se posso contattare il proprietario del repository via e-mail.
JLRishe,

Naturalmente, non lasciare che il repository cada nell'oblio. Un sacco di buon codice deve essere nascosto da qualche parte nel profondo di Github perché i proprietari originali non ci sono più.
cllamach,

Sono in una situazione simile e potrebbe essere necessario prendere questa opzione: il proprietario originale di un progetto non ha risposto ai ripetuti tentativi di contatto. È kosher mantenere il nome del progetto e continuare ad aumentare il numero di versione dall'ultima versione ufficiale? Temo che se cambio il nome, sarà più difficile da trovare per gli utenti esistenti del progetto.
Pericynthion,

1
Potrei anche essere in quella situazione. Ma il progetto originale è già registrato con Bower. Mantenere il nome significherebbe richiedere all'autore originale di annullare la registrazione per te o contattare i manutentori di Bower e chiedere loro di intervenire. Non mi interessa molto fare quest'ultimo, però. La ridenominazione potrebbe essere l'opzione migliore.
Lawrence I. Siden,

0

Poiché la maggior parte dei progetti gratuiti e open source di piccole e medie dimensioni sono attualmente ospitati su github, gitlab o simili, sarebbe possibile automatizzare parte del processo , utilizzando le loro API Web.

Supponendo che il repository originale sia arrivato https://github.com/someUserX/projectY/, il processo potrebbe essere simile al seguente:

  1. ("manuale") Contatta l'autore originale in diversi modi, almeno tramite la sua email di git committer e un problema (se abilitato).

    In caso di autorizzazione ricevuta o mancata risposta entro alcune settimane, è possibile eseguire uno script che utilizzi l'API Web hoster per eseguire passaggi come questi:

  2. crea una nuova organizzazione (GitHub) chiamata projectY, e qui fork il repository originale ->https://github.com/projectY/projectY/

  3. aggiungere l'autore originale e tutti gli autori delle richieste pull (già unite e ancora aperte) come amministratori dell'organizzazione
  4. ricreare tutte le richieste di pull (aperte) dal repository originale nel nuovo fork
  5. fare lo stesso con i problemi (aperti)
  6. notifica a tutti gli amministratori del nuovo repository
  7. crea un'ultima richiesta pull al vecchio repository, aggiungendo un avviso "abbandonato" / "archiviato" e il link al nuovo repository in cima al README

Il problema principale che vedo con questo approccio è che alcuni contributori "cattivi" potrebbero ottenere l'accesso come amministratore, ma come spiega l' evangelista del software libero Pieter Hintjens (ad esempio in questo discorso) , i cattivi impegni possono essere semplicemente annullati e non rappresentano un progetto che è vivo e potrebbe aiutare il cattivo committer a diventare buono, nel tempo.
hoijui,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.