Come si dice "è open source, inviare una patch" in modo che sia amichevole?

Nelle risposte di Qual è la replica canonica a "è open source, invia una patch"? , molte persone hanno espresso l'opinione che chiedere semplicemente alle persone di inviare una patch sia arrogante e maleducato.

Ma mi sembra che come sviluppatore di qualsiasi progetto open source, vedrai molte più richieste di funzionalità sulla mailing list di quante tu possa implementare. Quindi quando un utente dice "Mi piacerebbe vedere la funzione X", la verità della questione è di solito che le possibilità che venga implementata sono piuttosto scarse se non inviano una patch da soli. Inoltre, a volte un piccolo incoraggiamento potrebbe essere tutto ciò che è necessario per trasformare un utente in un collaboratore.

D'altra parte, non vuoi spaventare i (potenziali) partecipanti allontanandoti come maleducato.

Quindi come diresti "per favore invia patch invece di chiedere funzionalità" in modo amichevole?

Aggiornamento: grazie per tutti i suggerimenti! Vedo che la maggior parte di essi richiede spiegazioni piuttosto lunghe. Ma dal momento che preferirei evitare (a) di spiegare la stessa cosa a giorni alterni (ci vuole solo troppo tempo), o (b) usare frammenti che incollo in e-mail (diventa impersonale molto velocemente), mi chiedo: qualcuno l'ha scritto in un documento a cui posso collegarmi?

(Le cose specifiche del progetto come come scrivere test, compilare il codice e inviare la patch devono ancora essere documentate ovviamente, ma penso che quei problemi tecnici dovrebbero comunque andare in CONTRIBUTING.txt.)

Non

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

• Non sarebbe dolce se [...]? Potrebbe essere possibile fare A, B e C. (Questa è un'esca per: non ho tempo ma ecco un'idea fuori specifica nel caso in cui lo faccia.)
• Ecco una patch da fare / ecco una correzione per [...].
• Sto pensando di scrivere una patch da fare [...] e potrei usare il feedback / chiunque sia interessato ad aiutare.
• Eccetera.

I programmatori che inviano una richiesta di funzionalità in genere lo fanno di solito per un motivo. Alcuni di essi includono (e so per certo che gli ultimi due accadono in WordPress, per esempio):

• Sono in profondità in altri progetti open source, cioè non hanno tempo.
• Sono cavalieri liberi e intendono mantenere le cose in quel modo.
• È molto al di là del 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 pila puzzolente di codice batsh * t ^ \ b.
• Non possono più essere disturbati perché le loro patch precedenti sono state ignorate / rifiutate, ovvero pensano che perderebbero tempo.

Più in genere, le richieste di funzionalità verranno dagli utenti finali che non potrebbero contribuire alla patch anche se lo volessero. Soprattutto se inviato al di fuori del sistema di biglietteria.

Penso che la tua priorità più importante dovrebbe essere quella di non rimandare i potenziali / esistenti collaboratori, piuttosto che cercare di reclutare attivamente nuovi. È estremamente importante e lo dico per esperienza. Ho uno strano modo di raccogliere una nuova base di codice, che prevede la lettura superficiale del codice per ottenere un certo livello di comprensione di esso, saltare nel sistema di ticketing e correggere bug dall'aspetto semplice per imparare a fondo l'interno (e archiviare nuovi mentre collaudo). Nel corso degli anni ho inondato 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 passaggi diagnostici documentati e unit test.

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

quindi dici "Siamo davvero dispiaciuti, è un'ottima idea ma siamo troppo impegnati con tutto il resto del lavoro in corso, lo aggiungeremo all'elenco, ma se ti piacerebbe davvero farlo, e vorresti darci una mano contribuendo al progetto, quindi sarebbe fantastico. Abbiamo della documentazione per aiutare i ragazzi a fare cambiamenti nel progetto, sono qui, quindi se hai le competenze e il tempo e vuoi aiutarci, quindi provaci e inviaci una patch con le tue modifiche. Potremmo dover apportare alcune modifiche quando lo otteniamo in modo che si adatti agli standard del progetto, ma ci farai un grande favore almeno dandoci un vantaggio per questo lavoro e ti adoreremo per aiutarci ".

Naturalmente, una volta che inizi a chiedere le patch, non potrai mai, mai, lasciarle sul tuo sistema di ticket troppo a lungo, se ottieni molto, le integrerai più che a fare il lavoro che facevi prima. Potrebbe non piacerti, ma è necessario se vuoi che le patch continuino ad arrivare.

Sii educato e spiega chiaramente la situazione. Che dire qualcosa del tipo:

Grazie per il tuo feedback. Troviamo la tua funzionalità molto interessante, ma nonostante i nostri sforzi per implementare le funzionalità più richieste nel nostro prodotto, non abbiamo abbastanza tempo per implementarle tutte. Se sei uno sviluppatore, puoi unirti a noi contribuendo al progetto, poiché è open source.

Vedi, non puoi semplicemente dire "Perché mi stai dando fastidio 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, potresti suggerire di partecipare al progetto e spiegare anche perché potresti non essere in grado di implementare la funzione da solo.

Un altro modo per non essere scortesi è 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à è richiesta da 10.000 utenti e un'altra è richiesta solo da 10 , ci sono possibilità che il primo venga implementato per primo.

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

Grazie per la vostra richiesta. Lo abbiamo aggiunto al nostro backlog di progetto e lo esamineremo a breve.

Si noti che a causa del volume di richieste, non possiamo garantire che tutti saranno implementati. Facciamo affidamento su volontari, quindi se sei uno sviluppatore, considera di donare parte del tuo tempo e di presentare una patch . Altrimenti, ti preghiamo di sapere che stiamo tutti lavorando sodo per superare l'arretrato e risponderemo alla tua richiesta il prima possibile.

Davvero, è stato così difficile?

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

• Metti in chiaro che non hai il tempo per farlo in questo momento o nel prossimo futuro, quindi se altri lo vogliono implementato presto, non c'è altro che fornire una patch.
• Prenditi il ​​tempo per valutare la funzionalità. Se ti piace sinceramente, non c'è nulla di male nel dirlo. Incoraggiare le persone. O se ritieni che la funzionalità sia effettivamente negativa, prenditi il ​​tempo per spiegarlo.
• Fornisci un aiuto iniziale. Nessuno conosce la base di codice come te. Non hai il tempo di farlo, ma probabilmente sai esattamente come lo faresti e da dove inizi. Entro 5-10 minuti puoi condividere la conoscenza che gli altri avrebbero bisogno di ore per capire. Anche questo aiuta a far prevalere il tuo quadro generale. Invece di avere caratteristiche aliene fissate al tuo progetto, puoi guidare i partecipanti a una bella interazione.

Ecco cosa di solito dico ...

"Questo è un suggerimento interessante e sarebbe bello se FooBarLib potesse farlo. Sfortunatamente, FooBarLib è solo un progetto per il tempo libero per me, quindi è improbabile che mi impegni a farlo nel prossimo futuro. Accolgo con favore le osservazioni a FooBarLib, quindi se sei in grado di implementarlo da solo, allora sentiti libero di inviare una patch (assicurati di leggere prima le nostre linee guida "come contribuire alle FooBarLib"). "

Oltre ai bei modi per dire "Invia una patch", fornisci anche una documentazione orientata allo sviluppatore in modo che altri perché vogliono davvero la funzionalità possano aggiornarsi facilmente sul tuo progetto. Molti progetti non sono adatti agli sviluppatori e richiedono almeno giorni per leggere migliaia di righe di codice e tonnellate di piccoli casi di test che colpiscono diverse parti del sistema per ottenere il risultato giusto.

Se fornisci aiuto ai possibili sviluppatori, saranno più che disposti 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 far accettare le patch.

Adoro il modo in cui Github incoraggia gli altri a sborsare il progetto. Possono esistere più versioni dello stesso progetto con account utente diversi. Se non ti piace la direzione in cui sto prendendo il progetto, per favore, biforcalo. Puoi facilmente inviare richieste pull ma non sei bloccato in attesa che io lo accetti.

Quindi la mia risposta è spesso, basta rovesciarla.