Ticket #35894: issue35894.diff

File issue35894.diff, 36.0 KB (added by Baptiste Mispelon, 9 days ago)

  • .github/pull_request_template.md 

    From 4d10225a61e325825b4de7eeccbff89e2c3d4f9c Mon Sep 17 00:00:00 2001
From: Baptiste Mispelon <bmispelon@gmail.com>
Date: Wed, 6 Nov 2024 22:19:17 +0100
Subject: [PATCH] Fixed #35894 -- renamed patch to pull request

---
 .github/pull_request_template.md              |  2 +-
 .github/workflows/new_contributor_pr.yml      |  4 +-
 CONTRIBUTING.rst                              |  8 +-
 docs/internals/_images/triage_process.svg     |  2 +-
 .../contributing/bugs-and-features.txt        |  2 +-
 .../contributing/committing-code.txt          |  7 +-
 docs/internals/contributing/localizing.txt    |  6 +-
 .../contributing/new-contributors.txt         | 57 ++++++-------
 .../contributing/triaging-tickets.txt         | 84 +++++++++----------
 .../writing-code/coding-style.txt             |  4 +-
 .../contributing/writing-code/index.txt       |  2 +-
 ...bmitting-patches.txt => pull-requests.txt} | 48 ++++++-----
 .../writing-code/working-with-git.txt         | 12 +--
 docs/internals/git.txt                        |  2 +-
 docs/internals/release-process.txt            |  2 +-
 docs/intro/contributing.txt                   | 10 +--
 16 files changed, 127 insertions(+), 125 deletions(-)
 rename docs/internals/contributing/writing-code/{submitting-patches.txt => pull-requests.txt} (92%)

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 6c43c1c99adc..dfa9384c8616 100644
    a b Provide a concise overview of the issue or rationale behind the proposed changes  
    99#### Checklist
    1010- [ ] This PR targets the `main` branch. <!-- Backports will be evaluated and done by mergers, when necessary. -->
    1111- [ ] The commit message is written in past tense, mentions the ticket number, and ends with a period.
    12 - [ ] I have checked the "Has patch" ticket flag in the Trac system.
     12- [ ] I have checked the "Has pull request" ticket flag in the Trac system.
    1313- [ ] I have added or updated relevant tests.
    1414- [ ] I have added or updated relevant docs, including release notes if applicable.
    1515- [ ] I have attached screenshots in both light and dark modes for any UI changes.

  • .github/workflows/new_contributor_pr.yml 

    diff --git a/.github/workflows/new_contributor_pr.yml b/.github/workflows/new_contributor_pr.yml
index 3e0119ebdc2f..36b5936aed37 100644
    a b jobs:  
    1818          pr-message: |
    1919            Hello! Thank you for your contribution 💪
    2020
    21             As it's your first contribution be sure to check out the [patch review checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist).
     21            As it's your first contribution be sure to check out the [pull request review checklist](https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/pull-requests/#contribution-checklist).
    2222
    23             If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has patch"_ flag and include a link to this PR in the ticket!
     23            If you're fixing a ticket [from Trac](https://code.djangoproject.com/) make sure to set the _"Has pull request"_ flag and include a link to this PR in the ticket!
    2424
    2525            If you have any design or process questions then you can ask in the [Django forum](https://forum.djangoproject.com/c/internals/5).
    2626

  • CONTRIBUTING.rst 

    diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index 4b2ab363660d..f27b0acbc807 100644
    a b As an open source project, Django welcomes contributions of many forms.  
    66
    77Examples of contributions include:
    88
    9 * Code patches
     9* Pull requests
    1010* Documentation improvements
    11 * Bug reports and patch reviews
     11* Bug reports and code reviews
    1212
    1313Extensive contribution guidelines are available in the repository at
    1414``docs/internals/contributing/``, or online at:
    … … Trac tickets will be closed!** `Please file a ticket`__ to suggest changes.  
    2020
    2121__ https://code.djangoproject.com/newticket
    2222
    23 Django uses Trac to keep track of bugs, feature requests, and associated
    24 patches because GitHub doesn't provide adequate tooling for its community.
    25 Patches can be submitted as pull requests, but if you don't file a ticket,
    26 it's unlikely that we'll notice your contribution.
    2723
    2824Code of Conduct
    2925===============

  • docs/internals/_images/triage_process.svg 

    diff --git a/docs/internals/_images/triage_process.svg b/docs/internals/_images/triage_process.svg
index 6fbf1cbcc7f2..9babf2f4e8a4 100644
    a b  
    264264        <rect x="72" y="522" width="342" height="36" fill="white"/>
    265265        <path d="M 414 558 L 72 558 L 72 522 L 414 522 Z" stroke="#595959" stroke-linecap="round" stroke-linejoin="round" stroke-dasharray="4.0,4.0" stroke-width="1"/>
    266266        <text transform="translate(76 526)" fill="#595959">
    267           <tspan font-family="Helvetica" font-size="12" fill="#595959" x="7.241211" y="11">The ticket has a patch which applies cleanly and includes all </tspan>
     267          <tspan font-family="Helvetica" font-size="12" fill="#595959" x="7.241211" y="11">The ticket has a pull request which includes all </tspan>
    268268          <tspan font-family="Helvetica" font-size="12" fill="#595959" x="26.591797" y="25">needed tests and docs. A merger can commit it as is.</tspan>
    269269        </text>
    270270      </g>

  • docs/internals/contributing/bugs-and-features.txt 

    diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index c59f79e6b871..73d3e39c4073 100644
    a b are a few additional guidelines to follow:  
    7171  capturing a *brief* screencast. If your software permits it, capture only
    7272  the relevant area of the screen.
    7373
    74 * If you're offering a patch that changes the look or behavior of Django's
     74* If you're proposing a change that changes the look or behavior of Django's
    7575  UI, you **must** attach before *and* after screenshots/screencasts.
    7676  Tickets lacking these are difficult for triagers to assess quickly.
    7777

  • docs/internals/contributing/committing-code.txt 

    diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 91c6d21beb56..f6f4711436c9 100644
    a b contribute code to Django, look at :doc:`writing-code/working-with-git` instead.  
    1111Handling pull requests
    1212======================
    1313
    14 Since Django is hosted on GitHub, patches are provided in the form of pull
    15 requests.
     14Django is hosted on GitHub and uses pull requests (PRs) for contributions.
    1615
    1716When committing a pull request, make sure each individual commit matches the
    1817commit guidelines described below. Contributors are expected to provide the
    … … line.  
    7473When rewriting the commit history of a pull request, the goal is to make
    7574Django's commit history as usable as possible:
    7675
    77 * If a patch contains back-and-forth commits, then rewrite those into one.
     76* If a PR contains back-and-forth commits, then rewrite those into one.
    7877  For example, if a commit adds some code and a second commit fixes stylistic
    7978  issues introduced in the first commit, those commits should be squashed
    8079  before merging.
    … … Django's commit history as usable as possible:  
    8988* Tests should pass and docs should build after each commit. Neither the
    9089  tests nor the docs should emit warnings.
    9190
    92 * Trivial and small patches usually are best done in one commit. Medium to
     91* Trivial and small changes usually are best done in one commit. Medium to
    9392  large work may be split into multiple commits if it makes sense.
    9493
    9594Practicality beats purity, so it is up to each merger to decide how much

  • docs/internals/contributing/localizing.txt 

    diff --git a/docs/internals/contributing/localizing.txt b/docs/internals/contributing/localizing.txt
index 112a74dd9e2a..4d9f848daa01 100644
    a b the date, time and numbers formatting particularities of your locale. See  
    6161The format files aren't managed by the use of Transifex. To change them, you
    6262must:
    6363
    64 * :doc:`Create a pull request<writing-code/submitting-patches>` against the
     64* :doc:`Create a pull request<writing-code/pull-requests>` against the
    6565  Django Git ``main`` branch, as for any code change.
    6666
    6767* Open a ticket in Django's ticket system, set its ``Component`` field to
    68   ``Translations``, set the "has patch" flag, and include the link to the pull
    69   request.
     68  ``Translations``, set the "has pull request" flag, and include the link to
     69  the pull request.
    7070
    7171.. _Transifex: https://www.transifex.com/
    7272.. _Django project page: https://app.transifex.com/django/django/

  • docs/internals/contributing/new-contributors.txt 

    diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index c728abccd6ca..d126b8a6751a 100644
    a b Triage tickets  
    2727If an `unreviewed ticket`_ reports a bug, try and reproduce it. If you can
    2828reproduce it and it seems valid, make a note that you confirmed the bug and
    2929accept the ticket. Make sure the ticket is filed under the correct component
    30 area. Consider writing a patch that adds a test for the bug's behavior, even if
    31 you don't fix the bug itself. See more at :ref:`how-can-i-help-with-triaging`
     30area. Consider writing a test for the bug's behavior, even if you don't fix the
     31bug itself. See more at :ref:`how-can-i-help-with-triaging`
    3232
    33 Review patches of accepted tickets
    34 ----------------------------------
     33Review pull requests of accepted tickets
     34----------------------------------------
    3535
    3636This will help you build familiarity with the codebase and processes. Mark the
    37 appropriate flags if a patch needs docs or tests. Look through the changes a
    38 patch makes, and keep an eye out for syntax that is incompatible with older but
    39 still supported versions of Python. :doc:`Run the tests
     37appropriate flags if a pull request needs docs or tests. Look through the
     38files changed in the PR, and keep an eye out for syntax that is incompatible
     39with older but still supported versions of Python. :doc:`Run the tests
    4040</internals/contributing/writing-code/unit-tests>` and make sure they pass.
    4141Where possible and relevant, try them out on a database other than SQLite.
    4242Leave comments and feedback!
    4343
    44 Keep old patches up-to-date
    45 ---------------------------
     44Keep old pull requests up-to-date
     45---------------------------------
    4646
    47 Oftentimes the codebase will change between a patch being submitted and the
    48 time it gets reviewed. Make sure it still applies cleanly and functions as
    49 expected. Updating a patch is both useful and important! See more on
    50 :doc:`writing-code/submitting-patches`.
     47Oftentimes the codebase will change between a pull request being submitted and
     48the time it gets reviewed. Make sure there are no merge conflicts and that the
     49code still functions as expected. Updating a pull request is both useful and
     50important! See more on :doc:`writing-code/pull-requests`.
    5151
    5252Write some documentation
    5353------------------------
    5454
    5555Django's documentation is great but it can always be improved. Did you find a
    5656typo? Do you think that something should be clarified? Go ahead and suggest a
    57 documentation patch! See also the guide on :doc:`writing-documentation`.
     57documentation pull request! See also the guide on :doc:`writing-documentation`.
    5858
    5959.. note::
    6060
    6161  The `reports page`_ contains links to many useful Trac queries, including
    62   several that are useful for triaging tickets and reviewing patches as
     62  several that are useful for triaging tickets and reviewing pull requests as
    6363  suggested above.
    6464
    6565  .. _reports page: https://code.djangoproject.com/wiki/Reports
    … … Be bold! Leave feedback!  
    118118------------------------
    119119
    120120Sometimes it can be scary to put your opinion out to the world and say "this
    121 ticket is correct" or "this patch needs work", but it's the only way the
     121ticket is correct" or "this pull request needs work", but it's the only way the
    122122project moves forward. The contributions of the broad Django community
    123123ultimately have a much greater impact than that of any one person. We can't do
    124124it without **you**!
    … … wayside ends up doing more harm than good.  
    141141Be rigorous
    142142-----------
    143143
    144 When we say ":pep:`8`, and must have docs and tests", we mean it. If a patch
    145 doesn't have docs and tests, there had better be a good reason. Arguments like
    146 "I couldn't find any existing tests of this feature" don't carry much weight.
    147 While it may be true, that means you have the extra-important job of writing
    148 the very first tests for that feature, not that you get a pass from writing
    149 tests altogether.
     144When we say ":pep:`8`, and must have docs and tests", we mean it. If a pull
     145request doesn't have docs and tests, there had better be a good reason.
     146Arguments like "I couldn't find any existing tests of this feature" don't carry
     147much weight. While it may be true, that means you have the extra-important job
     148of writing the very first tests for that feature, not that you get a pass from
     149writing tests altogether.
    150150
    151151Be patient
    152152----------
    153153
    154 It's not always easy for your ticket or your patch to be reviewed quickly. This
    155 isn't personal. There are a lot of tickets and pull requests to get through.
     154It's not always easy for your ticket or pull request to be reviewed quickly.
     155This isn't personal. There are a lot of tickets and pull requests to get
     156through.
    156157
    157 Keeping your patch up to date is important. Review the ticket on Trac to ensure
    158 that the *Needs tests*, *Needs documentation*, and *Patch needs improvement*
    159 flags are unchecked once you've addressed all review comments.
     158Keeping your pull request up to date is important. Review the ticket on Trac to
     159ensure that the *Needs tests*, *Needs documentation*, and *Pull request needs
     160improvement* flags are unchecked once you've addressed all review comments.
    160161
    161162Remember that Django has an eight-month release cycle, so there's plenty of
    162 time for your patch to be reviewed.
     163time for your contribution to be reviewed.
    163164
    164165Finally, a well-timed reminder can help. See :ref:`contributing code FAQ
    165166<new-contributors-faq>` for ideas here.

  • docs/internals/contributing/triaging-tickets.txt 

    diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index 7987d63e9a61..5e43ba27d410 100644
    a b Triage workflow  
    3636Unfortunately, not all bug reports and feature requests in the ticket tracker
    3737provide all the :doc:`required details<bugs-and-features>`. A number of
    3838tickets have proposed solutions, but those don't necessarily meet all the
    39 requirements :ref:`adhering to the guidelines for contributing <patch-style>`.
     39requirements :ref:`adhering to the guidelines for contributing <contribution-style>`.
    4040
    4141One way to help out is to *triage* tickets that have been created by other
    4242users.
    … … By way of example, here we see the lifecycle of an average ticket:  
    7070  incorrect implementation).
    7171
    7272* Bob reviews the pull request, marks the ticket as "Accepted", "needs tests",
    73   and "patch needs improvement", and leaves a comment telling Alice how the
    74   patch could be improved.
     73  and "pull request needs improvement", and leaves a comment telling Alice how
     74  the pull request could be improved.
    7575
    7676* Alice updates the pull request, adding tests (but not changing the
    7777  implementation). She removes the two flags.
    7878
    79 * Charlie reviews the pull request and resets the "patch needs improvement"
    80   flag with another comment about improving the implementation.
     79* Charlie reviews the pull request and resets the "pull request needs
     80  improvement" flag with another comment about improving the implementation.
    8181
    8282* Alice updates the pull request, fixing the implementation. She removes the
    83   "patch needs improvement" flag.
     83  "pull request needs improvement" flag.
    8484
    8585* Daisy reviews the pull request and marks the ticket as "Ready for checkin".
    8686
    … … Beyond that there are several considerations:  
    114114
    115115* **Accepted + No Flags**
    116116
    117   The ticket is valid, but no one has submitted a patch for it yet. Often this
    118   means you could safely start writing a fix for it. This is generally more
    119   true for the case of accepted bugs than accepted features. A ticket for a bug
    120   that has been accepted means that the issue has been verified by at least one
    121   triager as a legitimate bug - and should probably be fixed if possible. An
    122   accepted new feature may only mean that one triager thought the feature would
    123   be good to have, but this alone does not represent a consensus view or imply
    124   with any certainty that a patch will be accepted for that feature. Seek more
    125   feedback before writing an extensive contribution if you are in doubt.
     117  The ticket is valid, but no one has submitted a pull request for it yet.
     118  Often this means you could safely start writing a fix for it. This is
     119  generally more true for the case of accepted bugs than accepted features. A
     120  ticket for a bug that has been accepted means that the issue has been
     121  verified by at least one triager as a legitimate bug - and should probably be
     122  fixed if possible. An accepted new feature may only mean that one triager
     123  thought the feature would be good to have, but this alone does not represent
     124  a consensus view or imply with any certainty that a pull request will be
     125  accepted for that feature. Seek more feedback before writing an extensive
     126  contribution if you are in doubt.
    126127
    127 * **Accepted + Has Patch**
     128* **Accepted + Has Pull Request**
    128129
    129130  The ticket is waiting for people to review the supplied solution. This means
    130   downloading the patch and trying it out, verifying that it contains tests
    131   and docs, running the test suite with the included patch, and leaving
    132   feedback on the ticket.
     131  checking out the pull request and trying it out, verifying that it contains
     132  tests and docs, checking that all the automated tests on the pull request are
     133  passing, and leaving feedback on the ticket.
    133134
    134 * **Accepted + Has Patch + Needs ...**
     135* **Accepted + Has Pull Request + Needs ...**
    135136
    136137  This means the ticket has been reviewed, and has been found to need further
    137   work. "Needs tests" and "Needs documentation" are self-explanatory. "Patch
    138   needs improvement" will generally be accompanied by a comment on the ticket
    139   explaining what is needed to improve the code.
     138  work. "Needs tests" and "Needs documentation" are self-explanatory. "Pull
     139  request needs improvement" will generally be accompanied by a comment on the
     140  ticket explaining what is needed to improve the code.
    140141
    141142Ready For Checkin
    142143-----------------
    143144
    144145The ticket was reviewed by any member of the community other than the person
    145 who supplied the patch and found to meet all the requirements for a
     146who submitted the pull request and found to meet all the requirements for a
    146147commit-ready contribution. A :ref:`merger <mergers-team>` now needs to give
    147148a final review prior to being committed.
    148149
    149 There are a lot of pull requests. It can take a while for your patch to get
     150There are a lot of pull requests. It can take a while for yours to get
    150151reviewed. See the :ref:`contributing code FAQ<new-contributors-faq>` for some
    151152ideas here.
    152153
    … … high-level ideas or long-term feature requests.  
    158159
    159160These tickets are uncommon and overall less useful since they don't describe
    160161concrete actionable issues. They are enhancement requests that we might
    161 consider adding someday to the framework if an excellent patch is submitted.
    162 They are not a high priority.
     162consider adding someday to the framework if an excellent contribution is
     163submitted. They are not a high priority.
    163164
    164165Other triage attributes
    165166=======================
    166167
    167168A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
    168169
    169 Has patch
    170 ---------
     170Has pull request
     171----------------
    171172
    172173This means the ticket has an associated solution. These will be reviewed to
    173174ensure they adhere to the :doc:`documented guidelines
    174 <writing-code/submitting-patches>`.
     175<writing-code/pull-requests>`.
    175176
    176177The following three fields (Needs documentation, Needs tests,
    177 Patch needs improvement) apply only if a patch has been supplied.
     178Pull request needs improvement) apply only if a pull request has been supplied.
    178179
    179180Needs documentation
    180181-------------------
    181182
    182 This flag is used for tickets with patches that need associated
     183This flag is used for tickets with pull requests that need associated
    183184documentation. Complete documentation of features is a prerequisite
    184185before we can check them into the codebase.
    185186
    186187Needs tests
    187188-----------
    188189
    189 This flags the patch as needing associated unit tests. Again, this
     190This flags the pull request as needing associated unit tests. Again, this
    190191is a required part of a valid contribution.
    191192
    192 Patch needs improvement
    193 -----------------------
     193Pull request needs improvement
     194------------------------------
    194195
    195196This flag means that although the ticket *has* a solution, it's not quite
    196 ready for checkin. This could mean the patch no longer applies
    197 cleanly, there is a flaw in the implementation, or that the code
    198 doesn't meet our standards.
     197ready for checkin. This could mean the pull request has merge conflicts, there
     198is a flaw in the implementation, or that the code doesn't meet our standards.
    199199
    200200Easy pickings
    201201-------------
    … … If you do close a ticket, you should always make sure of the following:  
    296296A ticket can be resolved in a number of ways:
    297297
    298298* fixed
    299       Used once a patch has been rolled into Django and the issue is fixed.
     299      Used once a pull request has been merged and the issue is fixed.
    300300
    301301* invalid
    302302      Used if the ticket is found to be incorrect. This means that the
    … … Then, you can help out by:  
    356356  sparse to be actionable, or when they're feature requests requiring a
    357357  discussion on the `Django Forum`_ or |django-developers|.
    358358
    359 * Correcting the "Needs tests", "Needs documentation", or "Has patch"
     359* Correcting the "Needs tests", "Needs documentation", or "Has pull request"
    360360  flags for tickets where they are incorrectly set.
    361361
    362362* Setting the "`Easy pickings`_" flag for tickets that are small and
    … … Then, you can help out by:  
    377377* Verify if solutions submitted by others are correct. If they are correct
    378378  and also contain appropriate documentation and tests then move them to the
    379379  "Ready for Checkin" stage. If they are not correct then leave a comment to
    380   explain why and set the corresponding flags ("Patch needs improvement",
     380  explain why and set the corresponding flags ("Pull request needs improvement",
    381381  "Needs tests" etc.).
    382382
    383383.. note::
    … … the ticket database:  
    396396* Please **don't** promote your own tickets to "Ready for checkin". You
    397397  may mark other people's tickets that you've reviewed as "Ready for
    398398  checkin", but you should get at minimum one other community member to
    399   review a patch that you submit.
     399  review a pull request that you submit.
    400400
    401401* Please **don't** reverse a decision without posting a message to the
    402402  `Django Forum`_ or |django-developers| to find consensus.

  • docs/internals/contributing/writing-code/coding-style.txt 

    diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index 20605aef5684..b5e29c5cfd63 100644
    a b Miscellaneous  
    489489  silence the flake8 warning.
    490490
    491491* Systematically remove all trailing whitespaces from your code as those
    492   add unnecessary bytes, add visual clutter to the patches and can also
     492  add unnecessary bytes, add visual clutter to the pull request and can also
    493493  occasionally cause unnecessary merge conflicts. Some IDE's can be
    494494  configured to automatically remove them and most VCS tools can be set to
    495495  highlight them in diff outputs.
    … … Miscellaneous  
    497497* Please don't put your name in the code you contribute. Our policy is to
    498498  keep contributors' names in the ``AUTHORS`` file distributed with Django
    499499  -- not scattered throughout the codebase itself. Feel free to include a
    500   change to the ``AUTHORS`` file in your patch if you make more than a
     500  change to the ``AUTHORS`` file in your pull request if you make more than a
    501501  single trivial change.
    502502
    503503JavaScript style

  • docs/internals/contributing/writing-code/index.txt 

    diff --git a/docs/internals/contributing/writing-code/index.txt b/docs/internals/contributing/writing-code/index.txt
index 72cc26452460..7b09972a35bd 100644
    a b our documentation also contains useful guidance on specific topics:  
    2525.. toctree::
    2626   :maxdepth: 1
    2727
    28    How to submit a patch to Django for new and/or fixed behavior <submitting-patches>
     28   How to submit a pull request to Django for new and/or fixed behavior <pull-requests>
    2929   How to write and run tests </topics/testing/overview>
    3030   How to run Django's unit tests <unit-tests>
    3131   How to work with Git and GitHub <working-with-git>

  • .txt 

    diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/pull-requests.txt
similarity index 92%
rename from docs/internals/contributing/writing-code/submitting-patches.txt
rename to docs/internals/contributing/writing-code/pull-requests.txt
index c3d0e1745f29..7968394b315a 100644
    old new Typo fixes and trivial documentation changes  
    1212============================================
    1313
    1414If you are fixing a really trivial issue, for example changing a word in the
    15 documentation, the preferred way to provide the patch is using GitHub pull
    16 requests without a Trac ticket.
     15documentation, the preferred way is to open a pull request on GitHub without a
     16Trac ticket.
    1717
    1818See the :doc:`working-with-git` for more details on how to use pull requests.
    1919
    … … hoops of claiming tickets. Submit your changes directly and you're done!  
    9898It is *always* acceptable, regardless whether someone has claimed it or not, to
    9999link proposals to a ticket if you happen to have the changes ready.
    100100
     101.. TODO: link
     102
    101103.. _patch-style:
    102104
    103105Contribution style
    … … requirements:  
    112114  fixed and to prevent the problem from arising again. Also, if some tickets
    113115  are relevant to the code that you've written, mention the ticket numbers in
    114116  some comments in the test so that one can easily trace back the relevant
    115   discussions after your patch gets committed, and the tickets get closed.
     117  discussions after your pull request gets merged, and the tickets get closed.
    116118
    117119* If the code adds a new feature, or modifies the behavior of an existing
    118120  feature, the change should also contain documentation.
    … … Trac. When using this style, follow these guidelines.  
    133135
    134136Regardless of the way you submit your work, follow these steps.
    135137
     138.. TODO: link
     139
    136140* Make sure your code fulfills the requirements in our :ref:`contribution
    137141  checklist <patch-review-checklist>`.
    138142
    139 * Check the "Has patch" box on the ticket and make sure the "Needs
    140   documentation", "Needs tests", and "Patch needs improvement" boxes aren't
    141   checked. This makes the ticket appear in the "Patches needing review" queue
    142   on the `Development dashboard`_.
     143* Check the "Has pull request" box on the ticket and make sure the "Needs
     144  documentation", "Needs tests", and "Pull request needs improvement" boxes
     145  aren't checked. This makes the ticket appear in the "Pull requests needing
     146  review" queue on the `Development dashboard`_.
    143147
    144148.. _ticket tracker: https://code.djangoproject.com/
    145149.. _Development dashboard: https://dashboard.djangoproject.com/
    … … Regardless of the way you submit your work, follow these steps.  
    147151Contributions which require community feedback
    148152==============================================
    149153
    150 A wider community discussion is required when a patch introduces new Django
     154A wider community discussion is required when a change introduces new Django
    151155functionality and makes some sort of design decision. This is especially
    152156important if the approach involves a :ref:`deprecation <deprecating-a-feature>`
    153157or introduces breaking changes.
    … … In each :term:`feature release <Feature release>`, all  
    306310JavaScript contributions
    307311========================
    308312
     313.. TODO: link/ref
     314
    309315For information on JavaScript contributions, see the :ref:`javascript-patches`
    310316documentation.
    311317
    312 Optimization patches
     318Optimization changes
    313319====================
    314320
    315 Patches aiming to deliver a performance improvement should provide benchmarks
    316 showing the before and after impact of the patch and sharing the commands for
     321Changes aiming to deliver a performance improvement should provide benchmarks
     322showing the before and after impact of the change and sharing the commands for
    317323reviewers to reproduce.
    318324
    319325.. _django-asv-benchmarks:
    … … benchmarks can be run on a pull request by labeling the pull request with  
    327333
    328334.. _django-asv: https://github.com/django/django-asv/
    329335
    330 .. _patch-review-checklist:
    331 
    332336Contribution checklist
    333337======================
    334338
    … … If the pull request passes all the criteria below and is not your own, please  
    340344set the "Triage Stage" on the corresponding Trac ticket to "Ready for checkin".
    341345If you've left comments for improvement on the pull request, please tick the
    342346appropriate flags on the Trac ticket based on the results of your review:
    343 "Patch needs improvement", "Needs documentation", and/or "Needs tests". As time
    344 and interest permits, mergers do final reviews of "Ready for checkin" tickets
    345 and will either commit the changes or bump it back to "Accepted" if further
    346 work needs to be done.
     347"Pull request needs improvement", "Needs documentation", and/or "Needs tests".
     348As time and interest permits, mergers do final reviews of "Ready for checkin"
     349tickets and will either commit the changes or bump it back to "Accepted" if
     350further work needs to be done.
    347351
    348352If you're looking to become a member of the `triage & review team
    349353<https://www.djangoproject.com/foundation/teams/#triage-review-team>`_, doing
    350354thorough reviews of contributions is a great way to earn trust.
    351355
    352 Looking for a patch to review? Check out the "Patches needing review" section
    353 of the `Django Development Dashboard <https://dashboard.djangoproject.com/>`_.
     356Looking for a pull request to review? Check out the "Pull requests needing
     357review" section of the `Django Development Dashboard`_.
    354358
    355359Looking to get your pull request reviewed? Ensure the Trac flags on the ticket
    356360are set so that the ticket appears in that queue.
    357361
     362.. _Django Development Dashboard: https://dashboard.djangoproject.com/
     363
    358364Documentation
    359365-------------
    360366
    … … All tickets  
    405411
    406412* Is the pull request a single squashed commit with a message that follows our
    407413  :ref:`commit message format <committing-guidelines>`?
    408 * Are you the patch author and a new contributor? Please add yourself to the
    409   :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
     414* Are you the pull request author and a new contributor? Please add yourself to
     415  the :source:`AUTHORS` file and submit a `Contributor License Agreement`_.
    410416* Does this have an accepted ticket on Trac? All contributions require a ticket
    411417  unless the :ref:`change is considered trivial <trivial-change>`.
    412418

  • docs/internals/contributing/writing-code/working-with-git.txt 

    diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index 579543f8767f..d4e7d3bcae70 100644
    a b Your pull request should now contain the new commit too.  
    281281Note that the merger is likely to squash the review commit into the previous
    282282commit when committing the code.
    283283
    284 Working on a patch
    285 ==================
     284Working on a pull request
     285=========================
    286286
    287 One of the ways that developers can contribute to Django is by reviewing
    288 patches. Those patches will typically exist as pull requests on GitHub and
    289 can be easily integrated into your local repository:
     287One of the ways that developers can contribute to Django is by reviewing pull
     288requests on GitHub. Those pull requests can be easily integrated into your
     289local repository:
    290290
    291291.. code-block:: shell
    292292
    … … can be easily integrated into your local repository:  
    295295
    296296This will create a new branch and then apply the changes from the pull request
    297297to it. At this point you can run the tests or do anything else you need to
    298 do to investigate the quality of the patch.
     298do to investigate the quality of the pull request.
    299299
    300300For more detail on working with pull requests see the
    301301:ref:`guidelines for mergers <handling-pull-requests>`.

  • docs/internals/git.txt 

    diff --git a/docs/internals/git.txt b/docs/internals/git.txt
index 7329fe0bbcbc..0814e3718af2 100644
    a b If you're going to be working on Django's code (say, to fix a bug or  
    8080develop a new feature), you can probably stop reading here and move
    8181over to :doc:`the documentation for contributing to Django
    8282</internals/contributing/index>`, which covers things like the preferred
    83 coding style and how to generate and submit a patch.
     83coding style and how to generate and submit a pull request.
    8484
    8585Stable branches
    8686===============

  • docs/internals/release-process.txt 

    diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt
index a845faf33070..b6170c86ae48 100644
    a b page for the current state of support for each version.  
    131131* The current development branch ``main`` will get new features and bug fixes
    132132  requiring non-trivial refactoring.
    133133
    134 * Patches applied to the main branch must also be applied to the last feature
     134* Commits from the main branch must also be included in the last feature
    135135  release branch, to be released in the next patch release of that feature
    136136  series, when they fix critical problems:
    137137

  • docs/intro/contributing.txt 

    diff --git a/docs/intro/contributing.txt b/docs/intro/contributing.txt
index 0900fdae37e4..bcccc2a13c43 100644
    a b information on contributing that you should probably take a look at:  
    581581
    582582* You should make sure to read Django's documentation on
    583583  :doc:`claiming tickets and submitting pull requests
    584   </internals/contributing/writing-code/submitting-patches>`.
     584  </internals/contributing/writing-code/pull-requests>`.
    585585  It covers Trac etiquette, how to claim tickets for yourself, expected
    586586  coding style (both for code and docs), and many other important details.
    587587* First time contributors should also read Django's :doc:`documentation
    … … with writing tests, you can also look at the list of  
    611611`easy tickets that need tests`__. Remember to follow the guidelines about
    612612claiming tickets that were mentioned in the link to Django's documentation on
    613613:doc:`claiming tickets and submitting branches
    614 </internals/contributing/writing-code/submitting-patches>`.
     614</internals/contributing/writing-code/pull-requests>`.
    615615
    616616__ https://code.djangoproject.com/query?status=new&status=reopened&has_patch=0&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
    617617__ https://code.djangoproject.com/query?status=new&status=reopened&needs_better_patch=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority
    … … What's next after creating a pull request?  
    622622
    623623After a ticket has a branch, it needs to be reviewed by a second set of eyes.
    624624After submitting a pull request, update the ticket metadata by setting the
    625 flags on the ticket to say "has patch", "doesn't need tests", etc, so others
    626 can find it for review. Contributing doesn't necessarily always mean writing
    627 code from scratch. Reviewing open pull requests is also a very helpful
     625flags on the ticket to say "has pull request", "doesn't need tests", etc, so
     626others can find it for review. Contributing doesn't necessarily always mean
     627writing code from scratch. Reviewing open pull requests is also a very helpful
    628628contribution. See :doc:`/internals/contributing/triaging-tickets` for details.
Back to Top