Grazie di avere chiesto! Abbiamo scritto un intero documento dedicato a questa domanda. E” intitolato Collaborare a Django.
\nNon preoccuparti, non ti stiamo ignorando!
\nE” 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à.
\nE, 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.
\nIl 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:
\nCi 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\ndoes, which ones can be ignored and which matter?
Does the change include a unit test? If not, is there a very clear\nexplanation why not? A test expresses succinctly what the problem is,\nand shows that the branch actually fixes it.
If your contribution is not suitable for inclusion in Django, we won’t ignore\nit – we’ll close the ticket. So if your ticket is still open, it doesn’t mean\nwe’re ignoring you; it just means we haven’t had time to look at it yet.
\nA polite, well-timed message in the forum/branch is one way to get attention.\nTo determine the right time, you need to keep an eye on the schedule. If you\npost your message right before a release deadline, you’re not likely to get the\nsort of attention you require.
\nGentle reminders in the #contributing-getting-started channel in the\nDjango Discord server can work.
Another way to get traction is to pull several related tickets together. When\nsomeone sits down to review a bug in an area they haven’t touched for\na while, it can take a few minutes to remember all the fine details of how\nthat area of code works. If you collect several minor bug fixes together into\na similarly themed group, you make an attractive target, as the cost of coming\nup to speed on an area of code can be spread over multiple tickets.
\nPlease refrain from emailing anyone personally or repeatedly raising the same\nissue over and over again. This sort of behavior will not gain you any\nadditional attention – certainly not the attention that you need in order to\nget your issue addressed.
\nSeriously - we’re not ignoring you. If your contribution is not suitable for\ninclusion in Django, we will close the ticket. For all the other tickets, we\nneed to prioritize our efforts, which means that some tickets will be\naddressed before others.
\nUno 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.
\nAnother reason that a bug might be ignored for a while is if the bug is a\nsymptom of a larger problem. While we can spend time writing, testing and\napplying lots of little changes, sometimes the right solution is to rebuild. If\na rebuild or refactor of a particular component has been proposed or is\nunderway, you may find that bugs affecting that component will not get as much\nattention. Again, this is a matter of prioritizing scarce resources. By\nconcentrating on the rebuild, we can close all the little bugs at once, and\nhopefully prevent other little bugs from appearing in the future.
\nQualunque 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.
\nScusa no. È sempre meglio avere un altro parerei su un ticket. Se hai problemi a ottenere il secondo parere, guarda le domande precedenti.
\n