---
title: "Submitting contributions"
version: 6.0
locale: pt-br
source: https://docs.djangoproject.com/pt-br/6.0/internals/contributing/writing-code/submitting-patches/
canonical: https://djangodocs.dev/pt-br/6.0/internals/contributing/writing-code/submitting-patches/
---
# Submitting contributions

We’re always grateful for contributions to Django’s code. Indeed, bug reports
with associated contributions will get fixed *far* more quickly than those
without a solution.

## Correções de ortografia e mudanças triviais na documentação

Se você está corrigindo um problema realmente trivial, por exemplo, mudando uma palavra na documentação, a melhor maneira de providenciar o patch é usando um pull request sem um ticket no Trac associado.

See [Trabalhando com Git e GitHub](/pt-br/6.0/internals/contributing/writing-code/working-with-git/) for more
details on how to use pull requests.

## “Reinvindicando” tickets

Em um projeto open-source com voluntários espalhados por todo o mundo, é importante gerenciar a comunicação de forma eficiente de modo que o trabalho não seja duplicado e voluntários possam ser o mais eficiente quanto possível.

Por tanto, nossa política é que os voluntários “reinvindiquem” os tickets de modo a permitir que os desenvolvedores do projeto saibam que aquele bug em específico ou funcionalidade está sendo atendida.

Se você identificou uma contribuição que você gostaria de fazer e se você é capaz de fazer essa correção (capacidade aqui mensurada pelas suas abilidades para programar, conhecimento de como o Django funciona internamente e tempo disponível), reinvindique ele seguindo os passos abaixo:

- [Log in using your GitHub account](https://code.djangoproject.com/github/login) or [create an account](https://www.djangoproject.com/accounts/register/) in our ticket
  system. If you have an account but have forgotten your password, you can
  reset it using the [password reset page](https://www.djangoproject.com/accounts/password/reset/).
- If a ticket for this issue doesn’t exist yet, create one in our
  [ticket tracker](https://code.djangoproject.com/). Remember that proposals for new features should follow
  the [process for suggesting new features](/pt-br/6.0/internals/contributing/bugs-and-features/#requesting-features).
- If a ticket for this issue already exists and has been accepted, make sure
  nobody else has claimed it. To do this, look at the “Owned by” section of
  the ticket. If it’s assigned to “nobody,” then it’s available to be claimed.
  Otherwise, somebody else may be working on this ticket. Either find another
  bug/feature to work on, or contact the developer working on the ticket to
  offer your help. If a ticket has been assigned for weeks or months without
  any activity, it’s probably safe to reassign it to yourself. If a ticket
  hasn’t been approved yet, join the conversation.
- Log into your account, if you haven’t already, by clicking “GitHub Login”
  or “DjangoProject Login” in the upper left of the ticket page. Once logged
  in, you can then click the “Modify Ticket” button near the bottom of the
  page.
- Claim the ticket by clicking the “assign to” radio button in the “Action”
  section. Your username will be filled in the text box by default.
- Finally, click the “Submit changes” button at the bottom to save.

> **Note**
>
> If your change is not [trivial](#trivial-change), you have the option
> to sign and submit a [Contributor License Agreement](https://www.djangoproject.com/foundation/cla/) clarifying the status
> of your contribution. This ensures that the Django Software Foundation has
> clear license to your contribution.

### Responsabilidade de quem reinvindicou um Ticket

Quando você reinvindicar um ticket, você terá a responsabilidade de trabalhar nele em uma quantidade de tempo razoável. Se você não tem tempo para trabalhar nele, ou abra mão dele ou nem se quer faça a reinvindicação do ticket em primeiro lugar!

Se não existir sinal de progresso em um ticket reinvindicado em particular por uma semana ou duas, outros desenvolvedores podem pedir para você abrir mão da reinvindicação do ticket de modo que ele não esteja mais monopolizado e alguém mais possa reinvindicá-lo novamente.

Se você reinvindicou um ticket e está demorando um bom tempo (dias ou semanas) para programar, mantenha todo mundo atualizado postando comentários no ticket. Se você não fornecer atualizações regulares, e você não responder a um pedido por relatório de progresso, a sua reinvindicação ao ticket poderá ser revogada.

Como sempre, mais comunicação é melhor do que menos comunicação.

### Quais tickets devem ser reinvindicados?

Going through the steps of claiming tickets is overkill in some cases.

In the case of small changes, such as typos in the documentation or small bugs
that will only take a few minutes to fix, you don’t need to jump through the
hoops of claiming tickets. Submit your changes directly and you’re done!

It is *always* acceptable, regardless of whether someone has claimed it or not,
to link proposals to a ticket if you happen to have the changes ready.

## Contribution style

Certifique-se de que qualquer contribuição que você fizer preencha pelo menos os requisitos abaixo:

- The code required to fix a problem or add a feature is an essential part
  of a solution, but it is not the only part. A good fix should also include a
  [regression test](/pt-br/6.0/internals/contributing/writing-code/unit-tests/) to
  validate the behavior that has been fixed and to prevent the problem from
  arising again. Also, if some tickets are relevant to the code that you’ve
  written, mention the ticket numbers in some comments in the test so that one
  can easily trace back the relevant discussions after your patch gets
  committed, and the tickets get closed.
- If the code adds a new feature, or modifies the behavior of an existing
  feature, the change should also contain documentation.

When you think your work is ready to be reviewed, send [a GitHub pull
request](/pt-br/6.0/internals/contributing/writing-code/working-with-git/). If you can’t
send a pull request for some reason, you can also use patches in Trac. When
using this style, follow these guidelines.

- Envie os patches dentro do formato retornado por um comando `git diff`.
- keAnexe os patches a um ticket dentro do  [ticket tracker](https://code.djangoproject.com/), usando o botão “attach file”. Por favor *não* coloque o patch na descrição do ticket ou dentro de um comentário a não ser que seja um patch de uma linha.
- Nomeie o arquivo de patch com a extensão `.diff`; isso permitirá que o rastreador de tickets aplique o estilo de formatação de sintaxe correto, o que ajuda muito.

Independentemente da maneira pela qual você irá enviar o seu trabalho, siga os passos a seguir:

- Make sure your code fulfills the requirements in our [contribution
  checklist](#patch-review-checklist).
- Marque a caixa “Has patch” no ticket e certifique-se de que as caixas “Needs documentation”, “Needs tests”, and “Patch needs improvement” não estão marcadas. Isso fará com que o ticket seja exibido na pilha “Patches needing review” na  [Development dashboard](https://dashboard.djangoproject.com/).

## Contributions which require community feedback

A wider community discussion is required when a patch introduces new Django
functionality and makes some sort of design decision. This is especially
important if the approach involves a [deprecation](#deprecating-a-feature)
or introduces breaking changes.

The following are different approaches for gaining feedback from the community.

### The new feature ideas tracker

If you have an idea for a new feature, please create a new proposal (or join an
existing discussion) following the [process for suggesting new features](/pt-br/6.0/internals/contributing/bugs-and-features/#requesting-features). You should explain the need for the change, go into
details of the approach and discuss alternatives.

### The Django Forum

You can propose a change (that is not a new feature idea) on the
[Django Forum](https://forum.djangoproject.com/). You should explain the need for the change, go into details of
the approach and discuss alternatives.

Please include a link to such discussions in your contributions.

### Third party package

Django does not accept experimental features. All features must follow our
[deprecation policy](/pt-br/6.0/internals/release-process/#internal-release-deprecation-policy). Hence, it can
take months or years for Django to iterate on an API design.

If you need user feedback on a public interface, it is better to create a
third-party package first. You can iterate on the public API much faster, while
also validating the need for the feature.

Once this package becomes stable and there are clear benefits of incorporating
aspects into Django core, the next step is to propose its inclusion by
following the [process for suggesting new features](/pt-br/6.0/internals/contributing/bugs-and-features/#requesting-features).

### Django Enhancement Proposal (DEP)

Similar to Python’s PEPs, Django has [Django Enhancement Proposals](https://github.com/django/deps) or DEPs. A
DEP is a design document which provides information to the Django community, or
describes a new feature or process for Django. They provide concise technical
specifications of features, along with rationales. DEPs are also the primary
mechanism for proposing and collecting community input on major new features.

Before considering writing a DEP, it is recommended to first open a discussion
following the [process for suggesting new features](/pt-br/6.0/internals/contributing/bugs-and-features/#requesting-features).
This allows the community to provide feedback and helps refine the proposal.
Once the DEP is ready, the [Steering Council](/pt-br/6.0/internals/organization/#steering-council) votes on
whether to accept it.

Some examples of DEPs that have been approved and fully implemented:

- [DEP 181: ORM Expressions](https://github.com/django/deps/blob/main/final/0181-orm-expressions.rst)
- [DEP 182: Multiple Template Engines](https://github.com/django/deps/blob/main/final/0182-multiple-template-engines.rst)
- [DEP 201: Simplified routing syntax](https://github.com/django/deps/blob/main/final/0201-simplified-routing-syntax.rst)

## Depreciando uma funcionalidade

There are a couple of reasons that code in Django might be deprecated:

- Se a funcionalidade foi melhorada ou modificada de modo a não ser mais compatível com versões anteriores, a antiga funcionalidade ou comportamento pode ser depreciada.
- Algumas vezes o Django inclui um backport de uma biblioteca Python que não está incluída na versão do Python suportada atualmente pelo Django. Quando o Django não precisa mais dar suporte a versão antiga do Python que não fornece a biblioteca, essa biblioteca será depreciada no Django.

As the [deprecation policy](/pt-br/6.0/internals/release-process/#internal-release-deprecation-policy)
describes, the first release of Django that deprecates a feature (`A.B`)
should raise a `RemovedInDjangoXXWarning` (where XX is the Django version
where the feature will be removed) when the deprecated feature is invoked.
Assuming we have good test coverage, these warnings are converted to errors
when [running the test suite](/pt-br/6.0/internals/contributing/writing-code/unit-tests/#running-unit-tests) with warnings enabled:
`python -Wa runtests.py`. Thus, when adding a `RemovedInDjangoXXWarning`
you need to eliminate or silence any warnings generated when running the tests.

O primeiro passo é remover qualquer uso do comportamento depreciado no próprio Django. Depois você pode silenciar os warnings nos testes que testam o comportamento depreciado usando o decorator `ignore_warnings`, na classe ou diretamente nos testes:

1. Em um teste em particular:

   ```
   from django.test import ignore_warnings
   from django.utils.deprecation import RemovedInDjangoXXWarning

   @ignore_warnings(category=RemovedInDjangoXXWarning)
   def test_foo(self): ...
   ```
2. Para um caso de teste inteiro:

   ```
   from django.test import ignore_warnings
   from django.utils.deprecation import RemovedInDjangoXXWarning

   @ignore_warnings(category=RemovedInDjangoXXWarning)
   class MyDeprecatedTests(unittest.TestCase): ...
   ```

You should also add a test for the deprecation warning:

```
from django.utils.deprecation import RemovedInDjangoXXWarning

def test_foo_deprecation_warning(self):
    msg = "Expected deprecation message"
    with self.assertWarnsMessage(RemovedInDjangoXXWarning, msg) as ctx:
        # invoke deprecated behavior
        ...
    self.assertEqual(ctx.filename, __file__)
```

It’s important to include a `RemovedInDjangoXXWarning` comment above code
which has no warning reference, but will need to be changed or removed when the
deprecation ends. This could include hooks which have been added to keep the
previous behavior, or standalone items that are unnecessary or unused when the
deprecation ends. For example:

```
import warnings
from django.utils.deprecation import RemovedInDjangoXXWarning, django_file_prefixes

# RemovedInDjangoXXWarning.
def old_private_helper():
    # Helper function that is only used in foo().
    pass

def foo():
    warnings.warn(
        "foo() is deprecated.",
        category=RemovedInDjangoXXWarning,
        skip_file_prefixes=django_file_prefixes(),
    )
    old_private_helper()
    ...
```

Finalmente, existem algumas atualizações na documentação do Django para fazer:

1. Se a funcionalidade existente está documentada, marque ela como depreciada na documentação usando a anotação `.. deprecated:: A.B`. Inclua uma curta descrição e uma nota sobre o caminho para atualizar se possível.
2. Adicione uma descrição de comportamento depreciado, e o caminho de atualização se possível, para as notas da release atual (`docs/releases/A.B.txt`) abaixo do header “Features deprecated in A.B”.
3. Adicione uma nova entrada na linha do tempo de depreciação (`docs/internals/deprecation.txt`) abaixo da versão apropriada descrevendo qual código será removido.

Once you have completed these steps, you are finished with the deprecation.
In each [feature release](/pt-br/6.0/internals/release-process/#term-Feature-release), all
`RemovedInDjangoXXWarning`s matching the new version are removed.

The `django.utils.deprecation` module provides some helpful deprecation
utilities, such as a `@deprecate_posargs` decorator to assist with converting
positional-or-keyword arguments to keyword-only. See the inline documentation
in the module source.

## Testing with a Django project

It’s important to test local changes using a Django project. This allows
ensuring that the changes behave as expected in a real environment, especially
for user-facing features such as templates, forms, or the admin.

To do this:

1. Create a virtual environment and [install the cloned copy of Django in
   editable mode](/pt-br/6.0/intro/contributing/#intro-contributing-install-local-copy).
2. Set up a Django project outside the source tree (you can use the [first
   part of the tutorial](/pt-br/6.0/intro/tutorial01/) for guidance).

With this setup, any changes made to the Django checkout will take effect
immediately in the test project, allowing manual testing of contributions
against a new or existing app.

## JavaScript contributions

For information on JavaScript contributions, see the [Patches JavaScript](/pt-br/6.0/internals/contributing/writing-code/javascript/#javascript-patches)
documentation.

## Optimization patches

Patches aiming to deliver a performance improvement should provide benchmarks
showing the before and after impact of the patch and sharing the commands for
reviewers to reproduce.

### `django-asv` benchmarks

[django-asv](https://github.com/django/django-asv/) monitors the performance of Django code over time. These
benchmarks can be run on a pull request by labeling the pull request with
`benchmark`. Adding to these benchmarks is highly encouraged.

## Contribution checklist

Use this checklist to review a pull request. If this contribution would not be
[considered trivial](#trivial-change), first ensure it has an accepted
ticket before proceeding with the review.

If the pull request passes all the criteria below and is not your own, please
set the “Triage Stage” on the corresponding Trac ticket to “Ready for checkin”.
If you’ve left comments for improvement on the pull request, please tick the
appropriate flags on the Trac ticket based on the results of your review:
“Patch needs improvement”, “Needs documentation”, and/or “Needs tests”. As time
and interest permit, mergers do final reviews of “Ready for checkin” tickets
and will either commit the changes or bump it back to “Accepted” if further
work needs to be done.

If you’re looking to become a member of the [triage & review team](https://www.djangoproject.com/foundation/teams/#triage-review-team), doing
thorough reviews of contributions is a great way to earn trust.

Looking for a patch to review? Check out the “Patches needing review” section
of the [Django Development Dashboard](https://dashboard.djangoproject.com/).

Looking to get your pull request reviewed? Ensure the Trac flags on the ticket
are set so that the ticket appears in that queue.

### Todos os tickets

- O pull request é um commit único esmagado com uma mensagem que segue o nosso  [formato de mensagens de commit](/pt-br/6.0/internals/contributing/committing-code/#committing-guidelines)?
- Are you the patch author and a new contributor? Please add yourself to the
  [AUTHORS](https://github.com/django/django/blob/stable/6.0.x/AUTHORS) file. At your option, submit a
  [Contributor License Agreement](https://www.djangoproject.com/foundation/cla/).
- Does this have an accepted ticket on Trac? All contributions require a ticket
  unless the [change is considered trivial](#trivial-change).

### Todo código muda

- Does the [coding style](/pt-br/6.0/internals/contributing/writing-code/coding-style/) conform to our
  guidelines? Are there any  `black`, `blacken-docs`, `flake8`,
  `isort`, or `zizmor` errors? You can install the [pre-commit](/pt-br/6.0/internals/contributing/writing-code/coding-style/#coding-style-pre-commit) hooks to automatically catch these errors.
- Se a mudança não é compatível com versões anteriores de modo algum, existe um aviso nas notas de release (`docs/releases/A.B.txt`)?
- Is Django’s test suite passing?
- If there is a [code coverage report](/pt-br/6.0/internals/contributing/writing-code/unit-tests/#code-coverage-on-pull-requests)
  comment on the pull request, have you reviewed the missing coverage in
  context (considering database/platform-specific limitations)?
- If the change affects the Django admin or rendered HTML output, has
  [accessibility testing](/pt-br/6.0/internals/contributing/accessibility/#accessibility-testing-baseline) been done?

### Documentação

- A documentação é gerada sem erros (`make html`, ou `make.bat html` no Windows, do diretório `docs`)?
- A documentação segue as regras de estilo e escrita em [Escrevendo a documentação](/pt-br/6.0/internals/contributing/writing-documentation/)?
- Existem quaisquer [erros de ortografia](/pt-br/6.0/internals/contributing/writing-documentation/#documentation-spelling-check)?

### Bugs

- Existe um teste de regressão apropriado (o teste deve falhar antes da correção ser aplicada)?
- If it’s a bug that [qualifies for a backport](/pt-br/6.0/internals/release-process/#supported-versions-policy) to the stable version of Django, is there a
  release note in `docs/releases/A.B.C.txt`? Bug fixes that will be applied
  only to the main branch don’t need a release note.

### Novas funcionalidades

- Existem testes para “exercitar” todo o código recém-criado?
- Existe uma nota de release em `docs/releases/A.B.txt`?
- Existe documentação para a funcionalidade e ela está [anotada de modo apropriado](/pt-br/6.0/internals/contributing/writing-documentation/#documenting-new-features) com `.. versionadded:: A.B` ou `.. versionchanged:: A.B`?

### Depreciando uma funcionalidade

Veja o guia depreciando uma funcionalidade.