This document explains how to prepare to contribute to Django. It is intended\nfor use during sprints, or by people who are already familiar with contributing\nto Python open source projects.
\nThis guide assumes you're familiar with:
\nGit (see Bekerja dengan Git dan GitHub)
Managing multiple versions of Python
Python dependency management, including virtual environments
The concept of running tests and building documentation
If any of these are unfamiliar, see Writing your first contribution for Django for a longer,\nstep-by-step tutorial.
\nFork the repository on GitHub, clone your fork to your machine, and\nconfigure a remote reference to Django's upstream repository:
\nLinux / macOS
$ git clone https://github.com/YourGitHubName/django.git\n$ cd django\n$ git remote add upstream https://github.com/django/django.git\nWindows
...\\> git clone https://github.com/YourGitHubName/django.git\n...\\> cd django\n...\\> git remote add upstream https://github.com/django/django.git\nConfirm you're using a compatible version of Python, then set up a virtual environment:
\n$ # This needs to be >= 3.12\n$ python -V\n$ python -m venv ~/.virtualenvs/djangodev\n$ source ~/.virtualenvs/djangodev/bin/activate\nIf you are not using a Unix-like system, see the platform-specific\ninstructions.
\nInstall the dependencies to run the tests and build the documentation:
\nLinux / macOS
$ python -m pip install -U pip\n$ python -m pip install -e . -r tests/requirements/py3.txt -r docs/requirements.txt\nWindows
...\\> py -m pip install -U pip\n...\\> py -m pip install -e . -r tests\\requirements\\py3.txt -r docs\\requirements.txt\nInstall pre-commit hooks so that formatting and linting run automatically\nbefore each commit:
\nLinux / macOS
$ python -m pip install pre-commit\n$ pre-commit install\nWindows
...\\> py -m pip install pre-commit\n...\\> pre-commit install\nSee Pemeriksaan pra-komitmen for further details.
\nRun the tests:
\nLinux / macOS
$ ./tests/runtests.py\nWindows
...\\> tests\\runtests.py\nSee Menjalankan satuan percobaan for more information. While tests will all\npass in CI, they may not on every person's local environment. For example,\nthe test suite is only guaranteed to pass on the latest point release of\neach supported Python version. It's possible you may encounter errors using\nan earlier point release.
\nIf you have a small number of failures, it may be worth investigating\nwhether they are known issues, or using the django-docker-box project to run the tests. Since this is a\nsprint, it may be more valuable for you to work on the issue at hand rather\nthan investigating a weird machine configuration problem. Make a note of the\nfailing tests before you start, so you can tell whether a later failure was\ncaused by your changes.
\nBuild the documentation:
\nLinux / macOS
$ cd docs && make html && cd ..\nWindows
...\\> cd docs && make.bat html && cd ..\nFinding a workable ticket is a challenging task. It's important to read this\nsection before attempting to do so.
\nWhen looking over tickets, it's a good idea to keep your search to accepted\ntickets created in the last five years. Older tickets are old for a reason:\nthey are usually still open because they are hard, contentious, or both.\nYou're welcome to try one, but expect it to require a high degree of\nperseverance.
\nConsider using the component filter option in Trac to limit your search to\nareas you have used before. If you've used forms in a few Django apps, consider\nfiltering down to the forms component. Similarly, if you've never worked with\ngeospatial projects, it's probably wise to avoid django.contrib.gis. For\nexample, here are the tickets for the documentation component.
There are two recommended ways to find a ticket:
\nLook at the easy pickings.
Use the vulture method.
The vulture method is the process of looking for accepted tickets that haven't\nbeen touched in six months or longer. The ideal ticket has a PR linked to it\nthat has a code review with explicit requests for changes and the author has\nnot responded in at least six months on the PR and on the ticket. Before taking\none over, leave a comment on both the ticket and the PR letting the author know\nthat you are continuing their work.
\nYou can view the list of possibly vulture-able tickets here. The filters\nthat are applied are:
\nTriage stage = Accepted
Patch needs improvement = Yes
Created = between 5 years ago and today
Modified = between 5 years ago and 6 months ago
When you find a ticket, make yourself the owner by clicking the "Modify Ticket"\nbutton near the bottom of the page, selecting the "assign to" radio button in\nthe "Action" section, and clicking "Submit changes". Your username will be\nfilled in the text box by default. See Tiket "Meminta" for the full\ndocumentation.
\nHow you create your branch depends on whether the ticket already has work\nattached to it.
\nWith the ticket claimed, create a branch for your work, replacing\nTicketNumber with the actual Trac ticket number:
Linux / macOS
$ git fetch upstream\n$ git checkout -b ticket_TicketNumber upstream/main\nWindows
...\\> git fetch upstream\n...\\> git checkout -b ticket_TicketNumber upstream/main\nWhen your work is ready, push the branch to your fork and open a pull request.\nSee Mengajukan bantuan for the full\nprocess.
\nIf you're continuing the work from someone else's pull request on GitHub,\nthings can be tricky. You need to pull their branch, but then push it to your\nGitHub repository fork.
\nRun the following, replacing PRNumber and TicketNumber with the actual\npull request and Trac ticket numbers:
Linux / macOS
$ git fetch upstream pull/PRNumber/head:ticket_TicketNumber\n$ git checkout ticket_TicketNumber\n$ git push origin ticket_TicketNumber\nWindows
...\\> git fetch upstream pull/PRNumber/head:ticket_TicketNumber\n...\\> git checkout ticket_TicketNumber\n...\\> git push origin ticket_TicketNumber\nFor example, to continue PR 8000 for ticket 123, run:
\nLinux / macOS
$ git fetch upstream pull/8000/head:ticket_123\n$ git checkout ticket_123\n$ git push origin ticket_123\nWindows
...\\> git fetch upstream pull/8000/head:ticket_123\n...\\> git checkout ticket_123\n...\\> git push origin ticket_123\nWhen preparing your commit, please review our committing guidelines, specifically how to credit co-authors.
\n