mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 14:16:09 +00:00
Code Issues 32 Releases Wiki Activity

Ensured :doc: role uses absolute targets in docs.

Browse Source
This commit is contained in:
Adam Johnson
2025-06-27 14:33:40 +01:00
committed by nessita
parent ae03f81ffa
commit 56955636e6
24 changed files with 247 additions and 237 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/internals/contributing/writing-code/coding-style.txt
View File

@@ -504,6 +504,6 @@ JavaScript style
================
For details about the JavaScript code style used by Django, see
:doc:`javascript`.
:doc:`/internals/contributing/writing-code/javascript`.
.. _editorconfig: https://editorconfig.org/

20
docs/internals/contributing/writing-code/submitting-patches.txt
View File

@@ -15,7 +15,8 @@ If you are fixing a really trivial issue, for example changing a word in the
documentation, the preferred way to provide the patch is using GitHub pull
requests without a Trac ticket.
See the :doc:`working-with-git` for more details on how to use pull requests.
See the :doc:`/internals/contributing/writing-code/working-with-git` for more
details on how to use pull requests.
"Claiming" tickets
==================
@@ -109,19 +110,20 @@ requirements:
* 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
:doc:`regression test <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.
:doc:`regression test </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 :doc:`a GitHub pull
request <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.
request </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.
* Submit patches in the format returned by the ``git diff`` command.

2
docs/internals/contributing/writing-code/working-with-git.txt
View File

@@ -142,7 +142,7 @@ When you think your work is ready to be pulled into Django, you should create
a pull request at GitHub. A good pull request means:
* commits with one logical change in each, following the
:doc:`coding style <coding-style>`,
:doc:`coding style </internals/contributing/writing-code/coding-style>`,
* well-formed messages for each commit: a summary line and then paragraphs
wrapped at 72 characters thereafter -- see the :ref:`committing guidelines