Contribuyente nuevo y no sabes qué hacer? Quieres ayudar pero simplemente no sabes cómo empezar? Esta es la sección para ti.
Get up and running!
Si eres nuevo en la contribución a Django, el tutorial Escribiendo tu primera contribución para Django te dará una introducción a las herramientas y al flujo de trabajo.
Esta página contiene consejos más generales sobre formas en que puedes contribuir a Django, y cómo abordarla.
Si estás buscando una referencia sobre los detalles de hacer contribuciones de código, consulta la documentación Contribuir código.
Comienza con estos pasos para descubrir el proceso de desarrollo de Django.
Si un ticket no revisado informa un error, intenta reproducirlo. Si puedes reproducirlo y parece válido, haz una nota en la que confirmes el error y aceptas el ticket. Asegúrate de que el ticket esté archivado bajo la área correcta del componente. Considera escribir una parche que agregue una prueba para el comportamiento del error, incluso si no fijas el error mismo. Consulta más en ¿Cómo puedo ayudar con el triage?
Esto te ayudará a familiarizarte con la base de código y los procesos. Marca las banderas adecuadas si un parche necesita documentación o pruebas. Revisa los cambios que hace un parche, y ten en cuenta el lenguaje sintáctico incompatible con versiones antiguas pero aún soportadas de Python. Ejecuta las pruebas y asegúrate de que pasen. Donde sea posible y relevante, intenta probarlas en una base de datos diferente a SQLite. Deja comentarios y retroalimentación!
A menudo el código base cambiará entre la presentación de un parche y el momento en que se revise. Asegúrate de que todavía aplica limpiamente y funciona como se espera. Actualizar un parche es tanto útil como importante! Consulta más información en escribiendo-código/enviando-parches.
La documentación de Django es excelente pero siempre puede mejorarse. ¿Encontraste un error tipográfico? ¿Crees que algo debería aclararse? ¡Vamos adelante y sugiere una parche de documentación! Consulta también la guía en escribiendo-documentación.
Nota
La página de informes contiene enlaces a muchas consultas útiles de Trac, incluyendo varias que son útiles para triar tickets y revisar parches tal como se sugiere arriba.
El código que escribas pertenece a ti o a tu empleador. Si tu contribución es más de una o dos líneas de código, debes firmar el CLA. Consulta la FAQ del Acuerdo de Licencia de Contribución para una explicación más detallada.
Como nuevo en un proyecto grande, es fácil experimentar frustración. Aquí tienes algunos consejos para hacer que tu trabajo en Django sea más útil y gratificante.
Este debería ser algo en lo que te importe, con el que estés familiarizado o al que quieras aprender. No necesitas ya ser un experto en la área en la que deseas trabajar; te conviertes en experto a través de tus contribuciones continuadas al código.
Trac no es una verdad absoluta; el contexto es tan importante como las palabras. Al leer Trac, debes tener en cuenta quién dice algo y cuándo se dijo. El apoyo a una idea hace dos años no significa necesariamente que la idea todavía tenga apoyo. También debes prestar atención a quién no ha hablado – por ejemplo, si un contribuyente experimentado no ha estado recientemente involucrado en una discusión, entonces un ticket puede no tener el apoyo necesario para entrar en Django.
Es más fácil obtener retroalimentación sobre un problema pequeño que sobre uno grande. Consulta los easy pickings.
Esto significa obtener a alguien más para confirmar que un bug es real antes de arreglarlo, y asegurarte de que haya consenso sobre una característica propuesta antes de implementarlo.
A veces puede ser asustadizo poner tu opinión a la vista del mundo y decir «este ticket está correcto» o «esta parche necesita trabajo», pero es la única forma en que el proyecto avanza. Las contribuciones de la comunidad Django amplia finalmente tienen un impacto mucho mayor que el de cualquier persona individual. No podemos hacerlo sin tú!
Si realmente no estás seguro si un ticket está listo, no lo marques como tal. Deja un comentario en su lugar, informando a los demás de tus pensamientos. Si estás casi seguro, pero no completamente seguro, también puedes intentar preguntar en el canal #contributing-getting-started del servidor Discord de Django para ver si alguien más puede confirmar tus sospechas.
Centra tu atención en uno o dos tickets, veles hasta el final y repite. El enfoque de escopeta de tomar muchos tickets y dejar algunos caer por el camino acaba haciendo más daño que bien.
Cuando decimos «PEP 8, y debe tener documentación y pruebas», queremos decirlo en serio. Si una corrección no tiene documentación ni pruebas, mejor que haya una buena razón. Argumentos como «No pude encontrar ninguna prueba existente de esta característica» no tienen mucho peso. Si es cierto, eso significa que tienes el trabajo importante de escribir las primeras pruebas para esa característica, no que te eximas de escribir pruebas en absoluto.
No siempre es fácil que tu ticket o corrección sea revisada rápidamente. Esto no es personal. Hay muchos tickets y solicitudes de extracción para pasar por alto.
Es importante mantener tu corrección actualizada. Revisa el ticket en Trac para asegurarte de que las banderas Needs tests, Needs documentation y Patch needs improvement estén desmarcadas una vez hayas abordado todos los comentarios de revisión.
Recuerda que Django tiene un ciclo de liberación de ocho meses, por lo que hay tiempo suficiente para que tu corrección sea revisada.
Finalmente, una recordatorio bien dirigido puede ayudar. Consulta FAQ del código contribuido para ideas aquí.
may 31, 2026