Come si pronuncia "è open source, invia una patch" in modo che sia amichevole?

In breve, spieghi che non hai tempo illimitato per fare il loro lavoro gratuitamente. (Puoi saltare il bit "gratuito") e che possono contribuire ogni volta che lo desiderano, non è il "tuo" progetto, il suo progetto di tutti.

quindi dici "Siamo davvero dispiaciuti, è una grande idea ma siamo troppo occupati con tutti gli altri lavori in corso, lo aggiungeremo alla lista, ma se ti piacerebbe davvero questo in, e ti piacerebbe darci una mano contribuendo al progetto, sarebbe meraviglioso. Abbiamo della documentazione per aiutare i ragazzi a fare le modifiche al progetto, sono qui, quindi se hai le competenze e il tempo e vuoi aiutarci, quindi ti preghiamo di provarci e inviarci una patch con le tue modifiche. Potremmo dover apportare alcune modifiche quando lo otteniamo in modo che si adatti agli standard del progetto, ma sarai facendoci un grande favore almeno dandoci un vantaggio per questo lavoro e ti ameremo per averci aiutato ".

Ovviamente, una volta che inizi a chiedere le patch, non puoi mai, mai, lasciarle sul sistema dei biglietti troppo a lungo, se ne ottieni molte, le integrerai più del lavoro che hai usato per . Potrebbe non piacerti, ma è necessario se vuoi che le patch continuino ad arrivare.

Resta educato e spiega chiaramente la situazione. Che dire di qualcosa tipo:

Thank you for your feedback. We find your feature very interesting, but despite our efforts to implement most requested features in our product, we do not have enough time to implement them all. If you're a developer, you can join us by contributing to the project, since it's open source.

Vedi, non puoi semplicemente dire "Perché mi infastidisci con le tue richieste? Non sono qui per lavorare gratis per te, se vuoi questa funzione, vai e implementala tu stesso". La persona potrebbe essere un non sviluppatore, potrebbe non conoscere la lingua utilizzata per sviluppare il prodotto, ecc.

Quindi, invece di essere scortese, puoi suggerire di partecipare al progetto e anche spiegare perché potresti non essere in grado di implementare la funzione da solo.

Un altro modo per non essere maleducati è non dover dire nulla. Se si dispone di un sito Web in cui gli utenti dell'applicazione possono suggerire nuove funzionalità e segnalare bug, è possibile ordinare gli articoli in base alla loro priorità: ad esempio se una funzionalità viene richiesta da 10 000 utenti e un'altra viene richiesta solo da 10 , ci sono possibilità che il primo venga implementato per primo.

Su questo sito web, puoi sempre inserire un suggerimento "implementalo tu stesso" per le funzionalità che, dopo alcuni giorni o settimane, non hanno ricevuto abbastanza voti da altri utenti.

Non lo fai.

Nella misura in cui l'ho sperimentato, i contributori candidati sono esperti e non invieranno una richiesta di funzionalità semplicemente richiedendola. Normalmente lo richiedono già con un certo livello di partecipazione:

• Non sarebbe dolce se [...]? Potrebbe essere possibile fare A, B e C. (Questo è esca per: non ho tempo ma qui è una idea spec out se lo fai.)
• Ecco una patch da fare / Ecco una soluzione per [...].
• Sto pensando di scrivere una patch per [...] e potrei usare il feedback / chiunque sia interessato a dare una mano.
• Etc.

I coder che inviano una richiesta di funzionalità a titolo definitivo lo fanno per una ragione. Alcuni di essi includono (e so per certo che gli ultimi due si verificano in WordPress, ad esempio):

• Sono al centro di altri progetti open source, cioè non hanno tempo.
• Sono free-riders e intendono mantenere le cose in questo modo.
• È ben oltre il loro livello di abilità / scritto in una lingua di cui non sanno nulla.
• Usano il software per mancanza di un'opzione migliore, e non vogliono avere a che fare con una puzzolente pila di codice batsh * t ^ \ b.
• Non possono più essere infastiditi perché le loro patch precedenti sono state ignorate / rifiutate, cioè pensano che stiano perdendo il loro tempo.

Più in genere, le richieste di funzionalità arriveranno dagli utenti finali che non hanno potuto fornire la patch anche se volevano. Soprattutto se inviati al di fuori del sistema di ticketing.

Penso che la tua priorità più importante dovrebbe essere quella di non rimandare potenziali / esistenti contributori, piuttosto che cercare di reclutarne di nuovi. È estremamente importante, e lo dico per esperienza. Ho un modo strano di prendere una nuova base di codice, che implica una lettura sommaria del codice per ottenere un certo livello di comprensione, saltare nel sistema di bigliettazione e correggere bug dall'aspetto semplice per imparare a fondo gli interni (e archiviare nuovi come testare). Nel corso degli anni ho allagato alcuni progetti con dozzine di biglietti e patch. Molte volte questi biglietti riceveranno poca o nessuna attenzione tempestiva (nemmeno un riconoscimento, ad esempio, continuate così!) - anche quando vengono forniti con i passaggi diagnostici e i test unitari documentati.

Thank you for your request. We have added it to our project backlog and will be reviewing it shortly.

Please note that due to the volume of requests, we cannot guarantee that every one will be implemented. We rely on volunteers, so if you are a developer, please consider donating some of your time and submitting a patch. Otherwise, please know that we are all working hard to get through the backlog and will get to your request as soon as possible.

Davvero, è stato così difficile?

Bene invece di dire "invia una patch", dovresti elaborare un po 'di più.

• Spiega che non hai tempo per farlo in questo momento o nel prossimo futuro, quindi se gli altri lo vogliono implementare presto, non c'è modo di fornire una patch.
• Prenditi il tempo necessario per valutare la funzione. Se ti piace sinceramente, non c'è nulla di male a dirlo. Incoraggiare le persone. Oppure, se pensi che la funzione sia effettivamente negativa, prenditi il tempo di spiegarla.
• Fornire un aiuto iniziale. Nessuno conosce la base di codice come fai tu. Non hai il tempo di farlo, ma probabilmente sai esattamente come lo faresti e dove avresti iniziato. Entro 5-10 minuti puoi condividere la conoscenza che altri avrebbero bisogno di ore per capire. Questo aiuta anche la tua grande immagine a prevalere. Invece di avere caratteristiche aliene imbullonate al tuo progetto, puoi guidare i contributori ad una bella intera.

Ecco cosa dico in genere ...

"That's an interesting suggestion and it would be cool if FooBarLib could do that. Unfortunately, FooBarLib is just a spare time project for me so it is unlikely that I will get round to doing that in the near future. I welcome submissions to FooBarLib, so if you are able to implement this yourself, then feel free to submit a patch (make sure you read our "how to contribute to FooBarLib" guidelines first)."

Oltre ai bei modi per dire "Invia una patch", fornisci anche una documentazione orientata agli sviluppatori in modo che gli altri perché davvero vogliono che la funzionalità possa diventare più veloce nel tuo progetto. Molti progetti non sono amichevoli per lo sviluppatore e richiedono giorni almeno per la lettura di migliaia di righe di codice e tonnellate di piccoli casi di test che prendono spunto da diverse parti del sistema per avere ragione.

Se fornisci aiuto ai possibili sviluppatori, saranno più che disponibili a fornire aiuto. Ciò significa una buona documentazione del codice, buone pagine wiki che spiegano il flusso (o un buon diagramma UML / lavagna) e un modo semplice per accettare le patch.

Adoro il modo in cui Github incoraggia gli altri a sborsare il progetto. Più versioni dello stesso progetto possono esistere con diversi account utente. Se non ti piace la direzione in cui sto portando il progetto, ti preghiamo di forarlo. Puoi facilmente inviare richieste di pull ma non sei bloccato aspettandomi di accettarlo.

Quindi la mia risposta è spesso, basta forchetta.