La cui responsabilità è una patch di correzione di errori?

Per quanto mi riguarda, se trovi un bug o hai una richiesta di miglioramento, non sei un contributore al progetto e hai inviato un rapporto sui difetti attraverso i canali appropriati, hai finito. In termini di restituzione alla comunità, chiunque utilizzi un progetto open source e trovi un difetto dovrebbe segnalarlo.

Cercare di trovare una soluzione, progettarla e implementarla è un vantaggio per il progetto. Se lo hai fatto, potrebbe essere una buona idea inviarlo, tramite una richiesta di pull o magari inviando delta di file al team di sviluppo insieme al rapporto sui difetti o alla richiesta di miglioramento per dare loro qualcosa su cui lavorare. Tuttavia, non hanno l'obbligo di accettare il tuo contributo al progetto.

Aspettarsi che un utente contribuisca alle patch sembra sbagliato, per me. È abbastanza facile partecipare a una discussione su un problema, ma è un investimento molto più lungo per trovare una soluzione. Nessun progetto dovrebbe aspettarsi che i non contributori diventino contributori solo per risolvere un singolo problema.

Procedi finché sei disposto a tollerarlo. Sarebbe bello sistemare la tua patch e condividerla con il mondo nel trunk principale, ma se il maintainer non lo fa Lo voglio, scrollando le spalle. Puoi postare da qualche parte il tuo problema e la patch per affrontarla, in modo che altri nella stessa barca possano cercare una soluzione.

E non sei senza problemi. La tua patch non sarà nel prossimo aggiornamento. Quindi dovrai ripetere e sperare che funzioni o massaggiarlo al suo posto, ogni volta che prendi una nuova versione. Quindi, far sì che il progetto principale possa salvarti, e la tua azienda, tempo a lungo termine.

È un dolore per te, ma stai contribuendo alla comunità. Sicuramente apprezzo tutti i contributori che lavorano. Non è come un software di qualità solo magicamente genesi delle masse. Qualcuno deve fare il lavoro. (Quindi chi è fantastico? Sei fantastico). Se non ti senti all'altezza, annuncia alla community che mentre apprezzi la discussione su come dovrebbe essere, sei semplicemente troppo occupato per farlo. Voglio dire, cosa faranno? Taglia i tuoi salari?

C'è un principio che rende la cultura open source più facile da capire: la persona che fa il lavoro decide su cosa lavorare. Questo è uno dei suoi appelli rispetto ai lavori diurni degli sviluppatori. La tua priorità numero 1 potrebbe essere # 50 sul loro backlog. Se non risolvi la tua richiesta di pull, alla fine probabilmente risulterà in alto e loro si prenderanno cura di esso. Tuttavia, se lo rendi abbastanza facile per loro, si prenderanno cura di esso ora.

L'altro motivo per cui ti chiedono di risolvere la tua richiesta di pull è più magnanimo. Vogliono che tu ottenga credito per il tuo contributo, per quanto piccolo possa essere. Se esegui il fixing, il tuo nome è quello nel campo dell'autore del commit. La maggior parte delle persone è orgogliosa del proprio contributo a voler vedere tutto, quindi il modus operandi predefinito dei maintainer è di lasciarli.

Per quanto riguarda la tua responsabilità nei confronti del tuo datore di lavoro, se la tua azienda fa affidamento su questo codice non stai facendo un cattivo servizio. I datori di lavoro conoscono il vantaggio di un lavoratore che impiega tempo ad affinare i suoi strumenti.

AFAIK, il metodo open source è che la responsabilità di correggere i bug è lasciata a colui che si preoccupa abbastanza del bug per gestire l'onere per assicurarsi che sia corretto. A seconda delle circostanze, ho fatto di tutto, dal semplice ignorare un problema a combattere (fornendo patch e discussioni in modo che fossero accettate) per assicurarmi che fosse stato corretto.

Tutto è giusto, non lasciare che le persone che gestiscono il progetto si aspettino la cosa sbagliata da te (vale a dire dare loro la speranza che risolverai il problema correttamente con le opzioni di discussione e poi non fare nulla), probabilmente sono a conoscenza di più problemi di quanti ne possano gestire autonomamente e cercheranno di farne un contributore ricorrente, se possibile.

Il bug originale potrebbe riguardare solo te, quindi è molto nel tuo interesse ottenere la submission facendo tutto ciò che è necessario per rendere la tua patch conforme. Altrimenti la prossima versione che tiri (perché hai bisogno di altre correzioni) mancherà la tua correzione.

Non vuoi mantenere un elenco di patch che devi applicare ogni volta che tiri una nuova copia del progetto - è solo troppo disturbo. Prendi un po 'di tempo extra e fallo riparare in modo permanente, così non dovrai più occupartene.

Per uno sviluppatore open source, ci sono due tipi di problemi:

• (a) problemi senza patch
• (b) problemi causati da una patch

Penso che la maggior parte dei manutentori / sviluppatori di pacchetti open source AMA l'idea di aiutare a ottenere un contributore non-core in grado di accelerare con le loro patch.

Il loro obiettivo principale, tuttavia, è la riduzione al minimo del numero di problemi di tipo b. Ecco perché la barra è impostata piuttosto in alto.

Alcuni lo superano. Diventano contributori, o forse anche contributori principali. Altri si arrendono. C'è una certa natura darwiniana nell'Open Source - la sopravvivenza del più adatto.

Ti incoraggio a premere e sputare il tuo contributo al punto in cui la squadra lo accetta. Una volta che hai fatto alcuni contributi, si fideranno ancora di te, ma dovresti comunque assicurarti che i tuoi contributi siano impeccabili.

Il risultato finale è assolutamente valsa la pena. Roba come essere in grado di dire "Do I code? Yes ... Stai correndo qualcosa che ho scritto, ogni giorno."