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.

Another way to get traction is to pull several related tickets together. When someone sits down to review a bug in an area they haven’t touched for a while, it can take a few minutes to remember all the fine details of how that area of code works. If you collect several minor bug fixes together into a similarly themed group, you make an attractive target, as the cost of coming up to speed on an area of code can be spread over multiple tickets.

Please refrain from emailing anyone personally or repeatedly raising the same issue over and over again. This sort of behavior will not gain you any additional attention – certainly not the attention that you need in order to get your issue addressed.

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.