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.
I submitted a bug fix several weeks ago. Why are you ignoring my contribution?¶
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?
If there are several branches linked to the ticket, is it clear what each one does, which ones can be ignored and which matter?
Does the change include a unit test? If not, is there a very clear explanation why not? A test expresses succinctly what the problem is, and shows that the branch actually fixes it.
If your contribution is not suitable for inclusion in Django, we won’t ignore it – we’ll close the ticket. So if your ticket is still open, it doesn’t mean we’re ignoring you; it just means we haven’t had time to look at it yet.
When and how might I remind the team of a change I care about?¶
A polite, well-timed message in the forum/branch is one way to get attention. To determine the right time, you need to keep an eye on the schedule. If you post your message right before a release deadline, you’re not likely to get the sort of attention you require.
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.
But I’ve reminded you several times and you keep ignoring my contribution!¶
Seriously - we’re not ignoring you. If your contribution is not suitable for inclusion in Django, we will close the ticket. For all the other tickets, we need to prioritize our efforts, which means that some tickets will be addressed before others.
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.
Another reason that a bug might be ignored for a while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little changes, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.
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.
