FAQ: contribuire al codice

Come posso iniziare a contribuire al codice di Django?

Grazie di avere chiesto! Abbiamo scritto un intero documento dedicato a questa domanda. E” intitolato Collaborare a Django.

Ho inoltrato un fix per un bug nel sistema di monitoraggio dei ticket diverse settimane fa, perchè state ignorando la mia patch?

Non preoccuparti, non ti stiamo ignorando!

E” importante capire che è diverso tra «un ticket sarà ignorato» e «un ticket ancora non è stato gestito». Il sistema di ticket di Django contiene centinaia di ticket aperti, che gli sviluppatori di Django devono recensire e applicare priorità.

E, soprattutto: le persone che lavorano su Django sono tutti volontari. Di conseguenza, la la quantità di tempo che abbiamo per lavorare sul framework è limitata e varia di settimana in settimana a seconda del nostro tempo libero. Se siamo impegnati, potremmo non essere in grado di dedicare a Django il tempo che vorremmo.

Il miglior modo per essere sicuri che i ticket non rimangano bloccati durante il controllo è di renderli semplici nel capire il problema e nel verificare la soluzione, anche per qualcuno che può non avere familiarità con quell’area di codice:

• Ci sono istruzioni chiare su come riprodurre il guasto? Se questo riguarda una dipendenza (come Pillow), un modulo aggiuntivo, o un database specifico, queste istruzioni sono abbastanza chiare anche per qualcuno che non sia familiare con esso?
• Se vi sono più patch attaccate al ticket, è chiaro cosa fa ciascuna? e quali possono essere ignorate? e quali sono importanti?
• La patch include uno unit test? Se no, vi è una chiara spiegazione del perché? Un test esprime sinteticamente qual’è il problema, e mostra che la patch lo risolve realmente.

Se la tua patch non ha alcuna possibilità di inclusione in Django, non la ignoreremo – semplicemente chiuderemo il ticket. Quindi se il tuo ticket è ancora aperto, non significa che ti stiamo ignorando; significa solo che ancora non abbiamo avuto tempo di guardarlo.

Quando e come posso ricordare al team una patch di cui mi preoccupo?

Un messaggio cortese e tempestivo alla mailing list è un modo per attirare l’attenzione. Per determinare il momento giusto, è necessario tenere d” occhio il programma. Se pubblichi il tuo messaggio subito prima della scadenza del termine di rilascio, probabilmente non riceverai il tipo di attenzione che desideri.

Anche garbati promemoria su IRC possono essere efficaci – di nuovo, se possibile con una temporizzazione strategica. Per esempio, durante uno sprint per la soluzione di bug sarebbe un’ottima scelta.

Un altro modo per ottenere «influenza», è aggregare insieme parecchi ticket correlati. Quando gli sviluppatori del core si siedono per risolvere un bug in un’area su cui non lavorano da un po”, possono servire alcuni minuti prima di ricordare tutti i dettagli di come funziona quell’area di codice. Se collezioni insieme più soluzioni di bug in un gruppo dello stesso tipo, crei un obiettivo interessante, perché il costo necessario per muoversi rapidamente su un’area di codice viene ripartito su più ticket.

Astieniti dall’inviare email personalmente agli sviluppatori del core, o sollevare lo stesso problema ripetitivamente. Questo tipo di comportamento non ti porterà maggiore attenzione – certamente non l’attenzione che ti serve per ottenere la soluzione del tuo bug preferito.

Ve l’ho ricordato più volte e continuate a ignorare la mia patch!

Seriamente - non ti ignoreremo. Se la tua patch non ha possibilità di inclusione in Django, chiuderemo il ticket. Per tutti gli altri ticket, abbiamo la necessità di gestire le nostre attività tramite priorità, il che vuol dire che alcuni ticket saranno gestiti prima di altri.

Uno dei criteri utilizzato per dare priorità ai bug fix è il numero di persone che sarà probabilmente colpito da un determinato bug. Bug che potenzialmente riguardano molte persone generalmente avranno priorità rispetto quelli che sono casi limite.

Un altro motivo per cui un bug potrebbe essere ignorato è se il bug è un sintomo di un problema più grande. Sebbene possiamo dedicare del tempo a scrivere, testare e applicare molte piccole patch, a volte la soluzione giusta è riscrivere da capo. Se una riscrittura o una modica di un particolare componente è stata proposta o è in corso, potresti scoprire che i bug che interessano quel componente non riceveranno la stessa attenzione degli altri. Ancora una volta, si tratta di dare delle priorità con risorse scarse. Concentrandoci sulla riscrittura, possiamo chiudere tutti i piccoli bug contemporaneamente e, si spera, impedire che altri piccoli bug compaiano in futuro.

Qualunque sia il motivo, tieni presente che sebbene ti possa colpire regolarmente un particolare bug, non necessariamente colpirà ogni singolo utente di Django. Utenti diversi usano Django in modi diversi, usando diverse parti del codice in condizioni diverse. Quando valutiamo le priorità relative, generalmente cerchiamo di considerare le esigenze dell’intera comunità, invece di dare la priorità all’impatto su un particolare utente. Ciò non significa che pensiamo che il tuo problema non sia importante, ma solo che nel tempo limitato che abbiamo a disposizione è preferibile rendere felici 10 persone piuttosto che renderne felice una sola.

Sono sicuro che il mio ticket è assolutamente perfetto al 100%, posso contrassegnarlo da solo come «Ready For Checkin»?

Scusa no. È sempre meglio avere un altro parerei su un ticket. Se hai problemi a ottenere il secondo parere, guarda le domande precedenti.