Qual è la netiquette per la forking di progetti open source di altre persone? [duplicare]

Suppongo che tu ti stia riferendo a un progetto ospitato su un servizio DVCS (ad esempio GitHub) in cui la biforcazione e la fusione sono il modo normale di fare le cose ...

It is easy to fork and change the code, but that isn't good enough.

Abbastanza buono per cosa?

Se lo fai solo a tuo vantaggio, non è un gioco da ragazzi. Fare quello che ti piace. Ma fallo tranquillamente in modo da non sminuire il progetto da cui hai forgiato.

Se lo fai per il beneficio di altre persone, la forking e la modifica quando non hai intenzione di unire è probabilmente una brutta cosa:

• Ineviterai inevitabilmente le persone che lavorano sul progetto originale.

• Stai creando una situazione in cui lo sforzo degli sviluppatori si sviluppa inevitabilmente in modo più sottile. È inefficiente.

• Stai creando incertezza e confusione per gli utenti. Quale versione dovrebbero usare? A chi dovrebbero fidarsi per continuare a lavorare sulla loro forcella? Per fare le cose correttamente?

A meno che tu non abbia davvero, davvero un buon motivo per mantenere un fork pubblico a lungo termine, dovresti sempre mirare a unirmi al passato. E per poter accettare le tue richieste di pull, devi seguire le linee guida scritte del progetto per i contributi. Se non ci sono linee guida, considera le parti migliori della base di codici esistente come esempio. (Se c'è documentazione, aggiungila / aggiorna. Se ci sono test unitari, includi test unitari per le tue modifiche.) Se non altro, fare queste cose renderà più probabile le tue richieste di pull che saranno accettate.

Un'altra strategia per far accettare le tue richieste pull è di discutere su cosa intendi fare con lo sviluppatore principale e discutere di eventuali problemi ... prima di iniziare la codifica. E ascolta quello che dice. Sii educato, sii deferente, sii paziente. Non essere un prima donna .

I asked about how to maintain healthy project fork which doesn't look dead and has proper documentation that states what its intent is.

Beh, il mio primo consiglio sarebbe NON ... a meno che tu non abbia una buona ragione. Le forchette pubbliche a lungo termine non sono salutari, per le ragioni di cui sopra.

Oltre a ciò, mantenere una forcella sana è come mantenere un progetto sano. Ad esempio, scrivi la documentazione, mantieni l'attività, fornisci supporto, recluta altri contributori ... hai uno scopo e un piano.

Maybe you do not want to send pull requests back to the original project or maybe your addition is something that won't be merged back

Allora è così.

Perché dovresti preoccuparti di incorporare le tue modifiche nel progetto originale se non sei preoccupato di unire o tirare? Salvalo per gente seria. Questo è particolarmente vero se non hai intenzione di ridistribuire la tua forcella, o solo di distribuirla all'interno della tua organizzazione.

In breve, sii un serio contributore o no.

Se sei serio nell'essere un contributore, il modo migliore per avvicinarti è contattare il proprietario del progetto. In genere, ti consentono di effettuare richieste di pull quando hai dimostrato di essere degno di fiducia apportando modifiche utili. Il proprietario del progetto può dirti cosa si aspetta in termini di documentazione adeguata, programmi di rilascio e simili.