FAQ: Aportando código

¿Cómo puedo empezar a aportar código para Django?

¡Gracias por preguntar! Hemos redactado un documento entero para esta pregunta. Se titula Contribuyendo con Django.

I submitted a bug fix several weeks ago. Why are you ignoring my contribution?

¡No se preocupe: No lo estamos ignorando!

Es importante entender que existe una diferencia entre «un ticket siendo ignorado» y «un ticket que aún no ha sido atendido». El sistema de tickets de Django contiene cientos de tickets abiertos, de diferentes grados de impacto en la funcionalidad del usuario final y que los desarrolladores de Django necesitan revisar y priorizar.

Además de eso: las personas que trabajan en Django son todos voluntarios. Como resultado, el tiempo que tenemos para trabajar en el framework es limitado y variará de semana en semana dependiendo de nuestro tiempo libre. Si estamos ocupado, es posible que no podamos emplear tanto tiempo en Django como quisiéramos.

La mejor forma de asegurarse de que los tickets no se queden en el camino a ser revisados es que sea muy fácil tanto entender el problema como comprobar el parche, incluso para alguien que puede no estar familiarizado con esa área del código:

• ¿Existen instrucciones claras sobre cómo reproducir el bug? Si esto afecta alguna dependencia (como Pillow), un módulo de contribución o una base de datos específica, ¿son lo suficientemente claras esas instrucciones incluso para alguien que no está familiarizado con ello?
• 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.

Los recordatorios gentiles por IRC también pueden funcionar, de nuevo, estratégicamente cronometrado si es posible. Por ejemplo, durante un sprint de corrección de errores sería un buen momento.

Otra forma de obtener tracción es juntar varios tickets relacionados. Cuando alguien se sienta a revisar un error en un área que no ha tocado por un tiempo, puede tomar unos minutos recordar todos los detalles finos de cómo funciona esa área de código. Si recopila varias correcciones de errores menores juntas en un grupo temático similar, se convierte en un objetivo atractivo, ya que el costo de ponerse al día en un área de código se puede distribuir en varios tickets.

Por favor, absténgase de enviar correos electrónicos a cualquier persona de manera personalmente o de plantear el mismo problema una y otra vez. Este tipo de comportamiento no le ganará ninguna atención adicional – ciertamente no la atención que necesita para que se aborde su problema.

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 de los criterios usados para priorizar la corrección de errores es el número de personas que son afectadas por un determinado bug. Los bugs que tienen el potencial de afectar a muchas personas generalmente tienen mayor prioridad respecto a los casos extremos.

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.

Cualquiera sea la razón, tenga en cuenta que, si bien puede encontrar un error en particular con regularidad, no necesariamente todos los usuarios de Django podrían tener el mismo error. Diferentes usuarios usan Django de diferentes maneras, enfatizando diferentes partes del código bajo diferentes condiciones. Cuando evaluamos las prioridades relativas, generalmente tratamos de considerar las necesidades de toda la comunidad, en lugar de priorizar el impacto en un usuario en particular. Esto no significa que pensemos que su problema no es importante, solo que en el tiempo limitado que tenemos disponible, siempre nos equivocaremos al hacer felices a 10 personas en lugar de hacer feliz a una sola persona.

Estoy seguro de que mi boleto es absolutamente 100% perfecto, ¿puedo marcarlo como «Listo para el checkin» yo mismo?

Lo siento, no. Siempre es mejor tener otro conjunto de ojos en un ticket. Si tiene problemas para obtener ese segundo conjunto de ojos, consulte las preguntas anteriores.