mirror of
https://github.com/django/django.git
synced 2024-12-23 01:25:58 +00:00
c4c076223e
This improves accessibility for screen reader users, see WCAG SC 1.3.1 Info and Relationships: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html
168 lines
6.5 KiB
Plaintext
168 lines
6.5 KiB
Plaintext
===========================
|
|
Advice for new contributors
|
|
===========================
|
|
|
|
New contributor and not sure what to do? Want to help but just don't know how
|
|
to get started? This is the section for you.
|
|
|
|
.. admonition:: Get up and running!
|
|
|
|
If you are new to contributing to Django, the :doc:`/intro/contributing`
|
|
tutorial will give you an introduction to the tools and the workflow.
|
|
|
|
This page contains more general advice on ways you can contribute to Django,
|
|
and how to approach that.
|
|
|
|
If you are looking for a reference on the details of making code contributions,
|
|
see the :doc:`/internals/contributing/writing-code/index` documentation.
|
|
|
|
First steps
|
|
===========
|
|
|
|
Start with these steps to discover Django's development process.
|
|
|
|
Triage tickets
|
|
--------------
|
|
|
|
If an `unreviewed ticket`_ 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 :ref:`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. :doc:`Run the tests
|
|
</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
|
|
:doc:`writing-code/submitting-patches`.
|
|
|
|
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 :doc:`writing-documentation`.
|
|
|
|
.. note::
|
|
|
|
The `reports page`_ contains links to many useful Trac queries, including
|
|
several that are useful for triaging tickets and reviewing patches as
|
|
suggested above.
|
|
|
|
.. _reports page: https://code.djangoproject.com/wiki/Reports
|
|
|
|
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 need to sign the `CLA`_. See the
|
|
`Contributor License Agreement FAQ`_ for a more thorough explanation.
|
|
|
|
.. _CLA: https://www.djangoproject.com/foundation/cla/
|
|
.. _Contributor License Agreement FAQ: https://www.djangoproject.com/foundation/cla/faq/
|
|
.. _unreviewed ticket: https://code.djangoproject.com/query?status=!closed&stage=Unreviewed
|
|
|
|
|
|
Guidelines
|
|
==========
|
|
|
|
As a newcomer on a large project, it's easy to experience frustration. Here's
|
|
some advice to make your work on Django more useful and rewarding.
|
|
|
|
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
|
|
-----------
|
|
|
|
It's easier to get feedback on a little issue than on a big one. See the
|
|
`easy pickings`_.
|
|
|
|
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 IRC to see if someone
|
|
else can confirm your suspicions.
|
|
|
|
Wait for feedback, and respond to feedback that you receive
|
|
-----------------------------------------------------------
|
|
|
|
Focus on one or two tickets, see them through from start to finish, and repeat.
|
|
The shotgun approach of taking on lots of tickets and letting some fall by the
|
|
wayside ends up doing more harm than good.
|
|
|
|
Be rigorous
|
|
-----------
|
|
|
|
When we say ":pep:`8`, 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 :ref:`contributing code FAQ
|
|
<new-contributors-faq>` for ideas here.
|
|
|
|
.. _easy pickings: https://code.djangoproject.com/query?status=!closed&easy=1
|