In che modo i contributi a un progetto open source devono essere gestiti dal / i proprietario / i?

Naviga le tue risposte
12

Quando gestisci un progetto open source (usando un servizio come GitHub) come risponderebbe 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 fonti molto più semplici, o forse sarebbe necessaria un'altra funzione utile.

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

Q2. Tutte le richieste di questo tipo dovrebbero essere respinte in conformità con le linee guida per la presentazione?

Q3. Se sì a Q2, che dire di un'idea davvero carina che è stata implementata male? È accettabile per me solo andare avanti e creare il mio?

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

    
posta Lea Hayes 21.08.2011 - 21:25
fonte

2 risposte

7

Configura, se non lo hai già fatto, un documento che descriva gli standard del progetto. Assicurati di delineare tutto che ritieni sia importante quando contribuisci con il codice al tuo progetto.

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

    
risposta data 21.08.2011 - 21:31
fonte
2

Se non ci sono troppi contributori, e questo contributo è abbastanza prezioso, puoi accettare la patch così com'è, e poi, nel prossimo commit, riscriverne alcune parti tu stesso, o riformattarlo per confermare gli standard di codifica . - Quindi, in seguito, invierai un'email al contributore, con un link a un diff delle modifiche apportate. Speriamo che il contributore studi la diff e presenti una patch migliore la prossima volta, che non è necessario modificare.

Questa potrebbe essere una buona idea, se non hai ancora scritto alcun documento Guida dei contributori o Stile di codifica . In effetti, potresti continuare in questo modo (accettare e modificare patch, inviare nuovamente i link e-mail a diffs) 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 contributori e una Guida alla Styling .

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

  • Q1: Sì, modifica l'invio, in un successivo commit
  • Q2: non applicabile (presumo che tu non abbia ancora scritto alcuna linea guida)
  • Q3: dire grazie e riscriverlo :-) (Forse è inutile applicare una patch, se, nel prossimo commit, lo riscrivi comunque in ogni caso)
risposta data 18.03.2013 - 04:47
fonte

Leggi altre domande sui tag

Qualcuno può suggerire un progetto per me scrivere per aiutarmi a capire il threading c'è un modo elegante per analizzare il processo di un ingegnere?