mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-28 14:34:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

[4.0.x] Refs #31676 -- Used term "merger" instead of "committer" in docs.

Browse source 
Follow up to caa2dd08c4.

Co-authored-by: Carlton Gibson <carlton.gibson@noumenal.es>
Backport of 653daaa60c from main
This commit is contained in:
Mariusz Felisiak 2022-03-22 11:13:36 +01:00
parent 8761407a8f
commit fa76f6b83d
11 changed files with 322 additions and 44 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/internals/contributing/writing-code/submitting-patches.txt
View file

@ -242,10 +242,10 @@ 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 permits, committers do final reviews of "Ready for checkin"
tickets and will either commit the patch or bump it back to "Accepted" if
further works need to be done. If you're looking to become a committer,
doing thorough reviews of patches is a great way to earn trust.
and interest permits, mergers do final reviews of "Ready for checkin" tickets
and will either commit the patch or bump it back to "Accepted" if further works
need to be done. If you're looking to become a merger, doing thorough reviews
of patches 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/>`_.

23
docs/internals/contributing/writing-code/working-with-git.txt
View file

@ -3,8 +3,8 @@ Working with Git and GitHub
===========================
This section explains how the community can contribute code to Django via pull
requests. If you're interested in how committers handle them, see
:doc:`../committing-code`.
requests. If you're interested in how :ref:`mergers <mergers-team>` handle
them, see :doc:`../committing-code`.
Below, we are going to show how to create a GitHub pull request containing the
changes for Trac ticket #xxxxx. By creating a fully-ready pull request, you
@ -86,9 +86,9 @@ commit them::
git commit
When writing the commit message, follow the :ref:`commit message
guidelines <committing-guidelines>` to ease the work of the committer. If
you're uncomfortable with English, try at least to describe precisely what the
commit does.
guidelines <committing-guidelines>` to ease the work of the merger. If you're
uncomfortable with English, try at least to describe precisely what the commit
does.
If you need to do additional work on your branch, commit as often as
necessary::
@ -138,11 +138,10 @@ related Trac ticket explaining what you've done. In particular, you should note
the environment in which you ran the tests, for instance: "all tests pass
under SQLite and MySQL".
Pull requests at GitHub have only two states: open and closed. The committer
who will deal with your pull request has only two options: merge it or close
it. For this reason, it isn't useful to make a pull request until the code is
ready for merging -- or sufficiently close that a committer will finish it
themselves.
Pull requests at GitHub have only two states: open and closed. The merger who
will deal with your pull request has only two options: merge it or close it.
For this reason, it isn't useful to make a pull request until the code is ready
for merging -- or sufficiently close that a merger will finish it themselves.
Rebasing branches
-----------------
@ -245,7 +244,7 @@ the public commits during the rebase, you should not need to force-push::
Your pull request should now contain the new commit too.
Note that the committer is likely to squash the review commit into the previous
Note that the merger is likely to squash the review commit into the previous
commit when committing the code.
Working on a patch
@ -263,7 +262,7 @@ to it. At this point you can run the tests or do anything else you need to
do to investigate the quality of the patch.
For more detail on working with pull requests see the
:ref:`guidelines for committers <handling-pull-requests>`.
:ref:`guidelines for mergers <handling-pull-requests>`.
Summary
=======