---
title: "Conselho aos novos voluntários"
version: 6.0
locale: pt-br
source: https://docs.djangoproject.com/pt-br/6.0/internals/contributing/new-contributors/
canonical: https://djangodocs.dev/pt-br/6.0/internals/contributing/new-contributors/
---
# Conselho aos novos voluntários

Você é um novo voluntário e não sabe o que fazer? Quer ajudar mas não sabe por onde começar? Esta seção foi feita para você.

> **Get up and running!**
>
> Se você é um novo voluntário no Django, esse  [Escrevendo sua primeira contribuição para o Django](/pt-br/6.0/intro/contributing/) tutorial te dará uma introdução as ferramentas e ao fluxo de trabalho.

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

Se você está procurando por uma referência sobre os detalhes de fazer contribuições de código, veja a documentação [Submitting contributions](/pt-br/6.0/internals/contributing/writing-code/submitting-patches/).

## Primeiros passos

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

### Triage tickets

If an [unreviewed ticket](https://code.djangoproject.com/query?status=!closed&stage=Unreviewed) reports a bug, try and reproduce it. If you can
reproduce it and it seems valid, make a note that you confirmed the bug and
accept the ticket. Make sure the ticket is filed under the correct component
area. Consider writing a patch that adds a test for the bug’s behavior, even if
you don’t fix the bug itself. See more at [How can I help with development?](/pt-br/6.0/internals/contributing/triaging-tickets/#how-can-i-help-with-triaging).

### Review patches of accepted tickets

This will help you build familiarity with the codebase and processes. Mark the
appropriate flags if a patch needs docs or tests. Look through the changes a
patch makes, and keep an eye out for syntax that is incompatible with older but
still supported versions of Python. [Run the tests](/pt-br/6.0/internals/contributing/writing-code/unit-tests/) and make sure they pass.
Where possible and relevant, try them out on a database other than SQLite.
Leave comments and feedback!

### Keep old patches up-to-date

Oftentimes the codebase will change between a patch being submitted and the
time it gets reviewed. Make sure it still applies cleanly and functions as
expected. Updating a patch is both useful and important! See more on
[Contribution checklist](/pt-br/6.0/internals/contributing/writing-code/submitting-patches/#patch-review-checklist).

### Write some documentation

Django’s documentation is great but it can always be improved. Did you find a
typo? Do you think that something should be clarified? Go ahead and suggest a
documentation patch! See also the guide on
[Escrevendo a documentação](/pt-br/6.0/internals/contributing/writing-documentation/).

> **Note**
>
> A [página de relatórios](https://code.djangoproject.com/wiki/Reports) contém links para muitas consultas úteis no Trac, incluindo
> muitas úteis na triagem de tickets e revisão de patches como sugerido acima.

### Sign the Contributor License Agreement

The code that you write belongs to you or your employer. If your contribution
is more than one or two lines of code, you have the option to sign the [CLA](https://www.djangoproject.com/foundation/cla/).
See the [Contributor License Agreement FAQ](https://www.djangoproject.com/foundation/cla/faq/) for a more thorough explanation.

## Orientações

Como um recém-chegado em um projeto gigantesco, É fácil acabar se frustrando. Aqui vão algumas dicas para fazer o seu trabalho no Django ser mais útil e recompensador.

### Pick a subject area

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

### Analyze tickets’ context and history

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

### Start small

É mais fácil obter retorno para um problema pequeno do que para um problema grande. Veja os [easy pickings](https://code.djangoproject.com/query?status=!closed&easy=1).

### Confirm support before engaging in a big task

This means getting someone else to confirm that a bug is real before you fix
the issue, and ensuring that there’s consensus on a proposed feature before you
go implementing it.

### Be bold! Leave feedback!

Sometimes it can be scary to put your opinion out to the world and say “this
ticket is correct” or “this patch needs work”, but it’s the only way the
project moves forward. The contributions of the broad Django community
ultimately have a much greater impact than that of any one person. We can’t do
it without **you**!

### Be cautious when marking things “Ready For Check-in”

If you’re really not certain if a ticket is ready, don’t mark it as such. Leave
a comment instead, letting others know your thoughts. If you’re mostly certain,
but not completely certain, you might also try asking on the
`#contributing-getting-started` channel in the [Django Discord server](https://chat.djangoproject.com) to
see if someone else can confirm your suspicions.

### Wait for feedback, and respond to feedback that you receive

Foque-se em um ou dois tickets, veja eles inteiros do começo ao fim, e repita. A estratégia da escopeta de pegar vários tickets e deixar alguns falhar pelo lado acaba fazendo mais mal do que bem.

### Be rigorous

When we say “[**PEP 8**](https://peps.python.org/pep-0008/), and must have docs and tests”, we mean it. If a patch
doesn’t have docs and tests, there had better be a good reason. Arguments like
“I couldn’t find any existing tests of this feature” don’t carry much weight.
While it may be true, that means you have the extra-important job of writing
the very first tests for that feature, not that you get a pass from writing
tests altogether.

### Be patient

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

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

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

Finally, a well-timed reminder can help. See [contributing code FAQ](/pt-br/6.0/faq/contributing/#new-contributors-faq) for ideas here.