¿Es un nuevo colaborador y no sabe qué hacer? ¿Quiere ayudar pero simplemente no sabe cómo empezar? Esta sección es para usted.
\n\nThis page contains more general advice on ways you can contribute to Django,\nand how to approach that.
\nSi usted está buscando una referencia sobre cómo hacer contribuciones, consulte la documentación Submitting patches.
\nStart with these steps to discover Django’s development process.
\nClasificación de tickets
\nSi un ‘ticket no revisado’ informa de un bug, intente reproducirlo. Si puede reproducirlo y si parece válido, indique que usted corroboró el bug y acepta el ticket. Asegúrese de que el ticket se archive en el área del componente correcto. Considere escribir un parche que añada una prueba para el comportamiento del bug, incluso si usted no corrige el bug. Vea más en :ref: ‘Cómo puedo ayudar con la clasificación’ para más información.
\n** Busque tickets aceptados y revise los parches para familiarizarse con la base de código y el proceso**
\nSeleccione las banderas apropiadas si un parche necesita documentación o pruebas. Revise los cambios que realiza un parche, y esté pendiente de la sintaxis que no sea compatible con versiones anteriores, pero aún soportadas de Python. : doc: `Ejecute las pruebas </internals/contributing/writing-code/unit-tests> ` y asegúrese de que pasen. Siempre que sea posible y pertinente, pruébelas en una base de datos distinta de SQLite. ¡Deje comentarios y sugerencias!
\n** Mantenga actualizados los parches anteriores**
\nOftentimes the codebase will change between a patch being submitted and the\ntime it gets reviewed. Make sure it still applies cleanly and functions as\nexpected. Updating a patch is both useful and important! See more on\nSubmitting patches.
\n** Escriba algo de documentación **
\nDjango’s documentation is great but it can always be improved. Did you find\na typo? Do you think that something should be clarified? Go ahead and\nsuggest a documentation patch! See also the guide on\nWriting documentation.
\n\n** Firme el Acuerdo de Licencia del Colaborador**
\nEl código que escribe pertenece a usted o su jefe. Si su contribución es más de una o dos líneas de código, es necesario firmar el ALC. Consulte las “preguntas frecuentes sobre el Acuerdo de Licencia del Colaborador” para una explicación más detallada.
\nComo principiante en un proyecto grande, es fácil experimentar frustración. Estos son algunos consejos para hacer su trabajo en Django más útil y gratificante.
\n** Elija un área temática que le interese, con la que esté familiarizado o sobre la que usted quiera aprender**
\nUsted todavía no tiene que ser un experto en el área que desea trabajar; usted se convierte en un experto a través de sus constantes contribuciones al código.
\nAnalice el contexto y el historial de los tickets
\nTrac isn’t an absolute; the context is just as important as the words.\nWhen reading Trac, you need to take into account who says things, and when\nthey were said. Support for an idea two years ago doesn’t necessarily mean\nthat the idea will still have support. You also need to pay attention to who\nhasn’t spoken – for example, if an experienced contributor hasn’t been\nrecently involved in a discussion, then a ticket may not have the support\nrequired to get into Django.
\nEmpiece de a poco
\nEs más fácil recibir comentarios y sugerencias sobre un problema pequeño que sobre uno grande. Vea los tickets presa fácil.
\n** Si usted va a participar en una gran tarea, asegúrese primero de que su idea tenga apoyo**
\nThis means getting someone else to confirm that a bug is real before you fix\nthe issue, and ensuring that there’s consensus on a proposed feature before\nyou go implementing it.
\n** ¡Sea valiente! ¡Deje un comentario!**
\nSometimes it can be scary to put your opinion out to the world and say «this\nticket is correct» or «this patch needs work», but it’s the only way the\nproject moves forward. The contributions of the broad Django community\nultimately have a much greater impact than that of any one person. We can’t\ndo it without you!
\nPeque de precavido al marcar cosas Listas para Registrar
\nSi realmente no está seguro si un ticket está listo, no la marque como tal. En cambio deje un comentario, informándole a los demás lo que piensa. Si usted está casi seguro, pero no del todo, también podría intentar preguntar en el IRC para ver si alguien más puede confirmar sus sospechas.
\nEspere por retroalimentación y responda a los comentarios que reciba
\nConcéntrese en uno o dos tickets, analícelos de principio a fin y repita el proceso. La táctica de la escopeta consistente en aceptar muchos tickets y dejar de lado algunos termina haciendo más daño que bien.
\n** Sea riguroso **
\nCuando decimos «:pep:` 8`, y debe tener documentación y pruebas «, lo decimos en serio. Si el parche no tiene documentación y pruebas, debe haber una buena razón. Argumentos como «No pude encontrar ninguna prueba existente de esta funcionalidad» no tienen mucho peso, ya que si bien puede ser cierto, eso significa que tiene el trabajo extra importante de escribir las primeras pruebas para esa funcionalidad, no es que está exento del todo de escribir las mismas.
\nBe patient
\nIt’s not always easy for your ticket or your patch to be reviewed quickly.\nThis isn’t personal. There are a lot of tickets and pull requests to get\nthrough.
\nKeeping your patch up to date is important. Review the ticket on Trac to\nensure that the Needs tests, Needs documentation, and Patch needs\nimprovement flags are unchecked once you’ve addressed all review comments.
\nRemember that Django has an eight-month release cycle, so there’s plenty of\ntime for your patch to be reviewed.
\nFinally, a well-timed reminder can help. See contributing code FAQ for ideas here.
\n