In che modo i contributi a un progetto open source devono essere gestiti dai proprietari?

Quando gestisci un progetto open source (usando un servizio come GitHub) come risponderesti a quanto segue:

Qualcuno ha gentilmente inviato una patch per aggiungere una nuova funzionalità o risolvere un problema. Si verifica una delle seguenti situazioni:

Il codice sorgente non soddisfa una o più convenzioni di denominazione, ecc.
Sento che il codice sorgente potrebbe essere migliorato in un certo modo. Forse lo stesso effetto può essere ottenuto con una fonte molto più semplice, o forse sarebbe necessaria un'altra caratteristica utile.

Q1. È accettabile per me modificare la fonte inviata? (è possibile su GitHub?)

Q2. Tutte queste comunicazioni devono essere respinte in conformità con le linee guida per la presentazione?

Q3. Se sì a Q2, che ne pensi di un'idea davvero chiara che è stata implementata male? È accettabile per me andare avanti e crearne uno mio?

Voglio incoraggiare il contributo, ma allo stesso tempo è importante mantenere un certo standard.

open-source github

— Lea Hayes
fonte

Risposte:

Imposta, se non l'hai già fatto, un documento che descriva gli standard del progetto. Assicurati di delineare tutto ciò che ritieni importante quando contribuisci con il codice al tuo progetto.

Quindi, rispondi alla persona che ha fornito i dettagli del codice che apprezzi molto il contributo e che desideri includere la patch, ma ci sono alcuni problemi. Fornisci un link al documento e cita i problemi particolari che vedi. Quindi, chiedi a quella persona di risolvere i problemi e inviare nuovamente il codice.

— Jeremy Heiler
fonte

Penso che il kernel Linux abbia una sorta di area "cambiamenti che necessitano miglioramenti" per questo scenario.

— seppo0010,

A lungo termine, andrà a beneficio del progetto e della comunità nel suo complesso se si convincono le persone a migliorare i propri contributi. Ma è assolutamente bene reimplementare la funzionalità da soli, a condizione che tu sia educato al riguardo.

— David Schwartz,

Ho visto alcuni progetti che automatizzano alcune di queste cose ogni volta che richiedi un pull.

— Andrew T Finnell,

Solo una nota per coloro che usano GitHub, se si nomina il documento a cui si fa riferimento sopra CONTRIBUTING, verrà mostrato un collegamento a questo documento quando si invia una richiesta pull. Può aiutare a risparmiare un po 'di tempo in anticipo se le persone possono risolvere da sole i problemi più comuni.

— Michael Mior,

Se non ci sono troppi collaboratori e questo contributo è piuttosto prezioso, è possibile accettare la patch così com'è e quindi, nel prossimo commit, riscriverne parti da soli o riformattarla per confermare gli standard di codifica. - Quindi, in seguito, invierai un'email al collaboratore, con un collegamento a un diff delle modifiche apportate. Si spera che il collaboratore studierà quindi il diff e invierà una patch migliore la prossima volta, che non è necessario modificare.

Questa potrebbe essere una buona idea, se non hai ancora scritto alcun documento sulla Guida dei contributori o sullo stile di codifica . In effetti, potresti continuare in questo modo (accettare e modificare patch, inviare e-mail a collegamenti differenziali per un po ') per un po', fino a quando non avrai notato quali errori fanno la maggior parte dei contributori. E poi includi solo quegli errori in una Guida dei collaboratori e in una Guida allo stile .

Se fai le cose in questo modo, le risposte a Q1-Q3 sarebbero:

Q1: Sì, modifica l'invio, in un commit successivo
Q2: Non applicabile (ho assunto che tu non abbia ancora scritto alcuna linea guida)
Q3: Ringrazia e riscrivi :-) (Forse è inutile applicare una patch, se, nel prossimo commit, la riscrivi completamente comunque)

— KajMagnus
fonte