{"title":"Consejos para los nuevos colaboradores","version":"5.2","locale":"es","docname":"internals/contributing/new-contributors","url":"/es/5.2/internals/contributing/new-contributors/","canonical":"https://djangodocs.dev/es/5.2/internals/contributing/new-contributors/","summary":"¿Es un nuevo colaborador y no sabe qué hacer? ¿Quiere ayudar pero simplemente no sabe cómo empezar? Esta sección es para usted. Get up and running! Si es un nuevo…","html":"

Consejos para los nuevos colaboradoresLink to this heading#

\n

¿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\n

This page contains more general advice on ways you can contribute to Django,\nand how to approach that.

\n

Si usted está buscando una referencia sobre cómo hacer contribuciones, consulte la documentación Submitting contributions.

\n
\n

Primeros pasosLink to this heading#

\n

Start with these steps to discover Django’s development process.

\n
\n

Triage ticketsLink to this heading#

\n

Si 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
\n
\n

Review patches of accepted ticketsLink to this heading#

\n

This will help you build familiarity with the codebase and processes. Mark the\nappropriate flags if a patch needs docs or tests. Look through the changes a\npatch makes, and keep an eye out for syntax that is incompatible with older but\nstill supported versions of Python. Run the tests and make sure they pass.\nWhere possible and relevant, try them out on a database other than SQLite.\nLeave comments and feedback!

\n
\n
\n

Keep old patches up-to-dateLink to this heading#

\n

Oftentimes 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 contributions.

\n
\n
\n

Write some documentationLink to this heading#

\n

Django’s documentation is great but it can always be improved. Did you find a\ntypo? Do you think that something should be clarified? Go ahead and suggest a\ndocumentation patch! See also the guide on Writing documentation.

\n\n
\n
\n

Sign the Contributor License AgreementLink to this heading#

\n

El 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.

\n
\n
\n
\n

DirectricesLink to this heading#

\n

Como 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
\n

Pick a subject areaLink to this heading#

\n

This should be something that you care about, that you are familiar with or\nthat you want to learn about. You don’t already have to be an expert on the\narea you want to work on; you become an expert through your ongoing\ncontributions to the code.

\n
\n
\n

Analyze tickets” context and historyLink to this heading#

\n

Trac isn’t an absolute; the context is just as important as the words. When\nreading Trac, you need to take into account who says things, and when they were\nsaid. Support for an idea two years ago doesn’t necessarily mean that the idea\nwill still have support. You also need to pay attention to who hasn’t spoken\n– for example, if an experienced contributor hasn’t been recently involved in\na discussion, then a ticket may not have the support required to get into\nDjango.

\n
\n
\n

Start smallLink to this heading#

\n

Es más fácil recibir comentarios y sugerencias sobre un problema pequeño que sobre uno grande. Vea los tickets presa fácil.

\n
\n
\n

Confirm support before engaging in a big taskLink to this heading#

\n

This 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 you\ngo implementing it.

\n
\n
\n

Be bold! Leave feedback!Link to this heading#

\n

Sometimes 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 do\nit without you!

\n
\n
\n

Be cautious when marking things «Ready For Check-in»Link to this heading#

\n

If you’re really not certain if a ticket is ready, don’t mark it as such. Leave\na comment instead, letting others know your thoughts. If you’re mostly certain,\nbut not completely certain, you might also try asking on the\n#contributing-getting-started channel in the Django Discord server to\nsee if someone else can confirm your suspicions.

\n
\n
\n

Wait for feedback, and respond to feedback that you receiveLink to this heading#

\n

Concé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
\n
\n

Be rigorousLink to this heading#

\n

When we say «PEP 8, and must have docs and tests», we mean it. If a patch\ndoesn’t have docs and tests, there had better be a good reason. Arguments like\n«I couldn’t find any existing tests of this feature» don’t carry much weight.\nWhile it may be true, that means you have the extra-important job of writing\nthe very first tests for that feature, not that you get a pass from writing\ntests altogether.

\n
\n
\n

Be patientLink to this heading#

\n

It’s not always easy for your ticket or your patch to be reviewed quickly. This\nisn’t personal. There are a lot of tickets and pull requests to get through.

\n

Keeping your patch up to date is important. Review the ticket on Trac to ensure\nthat the Needs tests, Needs documentation, and Patch needs improvement\nflags are unchecked once you’ve addressed all review comments.

\n

Remember that Django has an eight-month release cycle, so there’s plenty of\ntime for your patch to be reviewed.

\n

Finally, a well-timed reminder can help. See contributing code FAQ for ideas here.

\n
\n
","rootId":"advice-for-new-contributors","toc":[{"title":"Primeros pasos","anchor":"first-steps","children":[{"title":"Triage tickets","anchor":"triage-tickets","children":[]},{"title":"Review patches of accepted tickets","anchor":"review-patches-of-accepted-tickets","children":[]},{"title":"Keep old patches up-to-date","anchor":"keep-old-patches-up-to-date","children":[]},{"title":"Write some documentation","anchor":"write-some-documentation","children":[]},{"title":"Sign the Contributor License Agreement","anchor":"sign-the-contributor-license-agreement","children":[]}]},{"title":"Directrices","anchor":"guidelines","children":[{"title":"Pick a subject area","anchor":"pick-a-subject-area","children":[]},{"title":"Analyze tickets” context and history","anchor":"analyze-tickets-context-and-history","children":[]},{"title":"Start small","anchor":"start-small","children":[]},{"title":"Confirm support before engaging in a big task","anchor":"confirm-support-before-engaging-in-a-big-task","children":[]},{"title":"Be bold! Leave feedback!","anchor":"be-bold-leave-feedback","children":[]},{"title":"Be cautious when marking things «Ready For Check-in»","anchor":"be-cautious-when-marking-things-ready-for-check-in","children":[]},{"title":"Wait for feedback, and respond to feedback that you receive","anchor":"wait-for-feedback-and-respond-to-feedback-that-you-receive","children":[]},{"title":"Be rigorous","anchor":"be-rigorous","children":[]},{"title":"Be patient","anchor":"be-patient","children":[]}]}],"breadcrumbs":[{"docname":"internals/index","title":"Django internals","url":"/es/5.2/internals/"},{"docname":"internals/contributing/index","title":"Contribuyendo con Django","url":"/es/5.2/internals/contributing/"}],"prev":{"docname":"internals/contributing/index","title":"Contribuyendo con Django","url":"/es/5.2/internals/contributing/"},"next":{"docname":"internals/contributing/writing-code/index","title":"Contributing code","url":"/es/5.2/internals/contributing/writing-code/"},"formats":{"html":"/es/5.2/internals/contributing/new-contributors/","markdown":"/es/5.2/internals/contributing/new-contributors.md","json":"/es/5.2/internals/contributing/new-contributors.json"},"source":"https://github.com/django/django/blob/stable/5.2.x/docs/internals/contributing/new-contributors.txt","official":"https://docs.djangoproject.com/es/5.2/internals/contributing/new-contributors/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}