diff --git a/docs/internals/_images/triage_process.graffle b/docs/internals/_images/triage_process.graffle index 291c0397f7..67bdbfb600 100644 Binary files a/docs/internals/_images/triage_process.graffle and b/docs/internals/_images/triage_process.graffle differ diff --git a/docs/internals/_images/triage_process.pdf b/docs/internals/_images/triage_process.pdf index f731e3e584..558553e2dd 100644 Binary files a/docs/internals/_images/triage_process.pdf and b/docs/internals/_images/triage_process.pdf differ diff --git a/docs/internals/_images/triage_process.svg b/docs/internals/_images/triage_process.svg index 787f5ca647..2b5e0d3ced 100644 --- a/docs/internals/_images/triage_process.svg +++ b/docs/internals/_images/triage_process.svg @@ -1,3 +1,282 @@ - + -2013-04-08 16:32ZCanevas 1Calque 1Closed ticketsresolutionOpen ticketstriage stateReady for CheckinAcceptedUnreviewedduplicatefixedinvalidneedsinfoworksformewontfixcompletedstoppedin progressTicket triagers CommittersstatusThe ticket was already reported, was already rejected, isn't a bug, doesn't contain enough information, or can't be reproduced.The ticket is a bug and should be fixed.The ticket has a patch which applies cleanly and includes all needed tests and docs. A core developer can commit it as is. + + + + + + + + + + + + + + + + + + + + + Canevas 1 + + + Calque 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Closed tickets + resolution + + + + + + + Open tickets + triage state + + + + + + + Ready for + Checkin + + + + + + + Accepted + + + + + + + Unreviewed + + + + + + + duplicate + + + + + + + fixed + + + + + + + invalid + + + + + + + needsinfo + + + + + + + worksforme + + + + + + + wontfix + + + + + + + + + + + + completed + + + + + + stopped + + + + + + in progress + + + + + + + + Ticket triagers + + + + + + + + Mergers + + + + + + status + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + The ticket was already reported, was + already rejected, isn't a bug, doesn't contain + enough information, or can't be reproduced. + + + + + + + + + + + + + The ticket is a + bug and should + be fixed. + + + + + + + + + + + + + The ticket has a patch which applies cleanly and includes all + needed tests and docs. A merger can commit it as is. + + + + + + + + + + + + + + diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt index 35a3ad13ce..ed94ee9609 100644 --- a/docs/internals/contributing/committing-code.txt +++ b/docs/internals/contributing/committing-code.txt @@ -2,7 +2,7 @@ Committing code =============== -This section is addressed to the committers and to anyone interested in knowing +This section is addressed to the mergers and to anyone interested in knowing how code gets committed into Django. If you're a community member who wants to contribute code to Django, look at :doc:`writing-code/working-with-git` instead. @@ -16,9 +16,9 @@ requests. When committing a pull request, make sure each individual commit matches the commit guidelines described below. Contributors are expected to provide the -best pull requests possible. In practice however, committers - who will likely -be more familiar with the commit guidelines - may decide to bring a commit up -to standard themselves. +best pull requests possible. In practice however, mergers - who will likely be +more familiar with the commit guidelines - may decide to bring a commit up to +standard themselves. You may want to have Jenkins or GitHub actions test the pull request with one of the pull request builders that doesn't run automatically, such as Oracle or @@ -90,7 +90,7 @@ Django's commit history as usable as possible: * Trivial and small patches usually are best done in one commit. Medium to large work may be split into multiple commits if it makes sense. -Practicality beats purity, so it is up to each committer to decide how much +Practicality beats purity, so it is up to each merger to decide how much history mangling to do for a pull request. The main points are engaging the community, getting work done, and having a usable commit history. @@ -192,8 +192,8 @@ Django's Git repository: Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main. There's a `script on the wiki - `_ - to automate this. + `_ to + automate this. If the commit fixes a regression, include this in the commit message: @@ -211,7 +211,7 @@ Nobody's perfect; mistakes will be committed. But try very hard to ensure that mistakes don't happen. Just because we have a reversion policy doesn't relax your responsibility to aim for the highest quality possible. Really: double-check your work, or have it checked by -another committer, **before** you commit it in the first place! +another merger, **before** you commit it in the first place! When a mistaken commit is discovered, please follow these guidelines: @@ -231,10 +231,9 @@ When a mistaken commit is discovered, please follow these guidelines: * If the problem is small (a feature commit after feature freeze, say), wait it out. -* If there's a disagreement between the committer and the - reverter-to-be then try to work it out on the |django-developers| - mailing list. If an agreement can't be reached then it should - be put to a vote. +* If there's a disagreement between the merger and the reverter-to-be then try + to work it out on the |django-developers| mailing list. If an agreement can't + be reached then it should be put to a vote. * If the commit introduced a confirmed, disclosed security vulnerability then the commit may be reverted immediately without diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt index 3bd02044d3..fe37a20da5 100644 --- a/docs/internals/contributing/triaging-tickets.txt +++ b/docs/internals/contributing/triaging-tickets.txt @@ -55,7 +55,7 @@ Since a picture is worth a thousand words, let's start there: We've got two roles in this diagram: -* Committers: people with commit access who are responsible for making the +* Mergers: people with commit access who are responsible for making the final decision to merge a patch. * Ticket triagers: anyone in the Django community who chooses to @@ -84,7 +84,8 @@ By way of example, here we see the lifecycle of an average ticket: * Daisy reviews the pull request and marks the ticket as "Ready for checkin". -* Jacob, a committer, reviews the pull request and merges it. +* Jacob, a :ref:`merger `, reviews the pull request and merges + it. Some tickets require much less feedback than this, but then again some tickets require much much more. @@ -142,8 +143,8 @@ Ready For Checkin The ticket was reviewed by any member of the community other than the person who supplied the patch and found to meet all the requirements for a -commit-ready patch. A committer now needs to give the patch a final -review prior to being committed. +commit-ready patch. A :ref:`merger ` now needs to give the patch +a final review prior to being committed. There are a lot of pull requests. It can take a while for your patch to get reviewed. See the :ref:`contributing code FAQ` for some diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 048261e554..c05b83d6ab 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -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 `_. diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt index 1a70579845..1c9b660c07 100644 --- a/docs/internals/contributing/writing-code/working-with-git.txt +++ b/docs/internals/contributing/writing-code/working-with-git.txt @@ -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 ` 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 ` to ease the work of the committer. If -you're uncomfortable with English, try at least to describe precisely what the -commit does. +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 `. +:ref:`guidelines for mergers `. Summary ======= diff --git a/docs/internals/contributing/writing-documentation.txt b/docs/internals/contributing/writing-documentation.txt index 9ea20d0095..97fc87ac15 100644 --- a/docs/internals/contributing/writing-documentation.txt +++ b/docs/internals/contributing/writing-documentation.txt @@ -31,8 +31,8 @@ Django from the source code repository (see :ref:`installing-development-version`). The development version has the latest-and-greatest documentation, just as it has latest-and-greatest code. We also backport documentation fixes and improvements, at the discretion of the -committer, to the last release branch. That's because it's highly advantageous -to have the docs for the last release be up-to-date and correct (see +merger, to the last release branch. That's because it's highly advantageous to +have the docs for the last release be up-to-date and correct (see :ref:`differences-between-doc-versions`). Getting started with Sphinx diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt index 5e6e18fc13..ca096e6690 100644 --- a/docs/internals/howto-release-django.txt +++ b/docs/internals/howto-release-django.txt @@ -100,8 +100,8 @@ any time leading up to the actual release: #. As the release approaches, watch Trac to make sure no release blockers are left for the upcoming release. -#. Check with the other committers to make sure they don't have any - uncommitted changes for the release. +#. Check with the other mergers to make sure they don't have any uncommitted + changes for the release. #. Proofread the release notes, including looking at the online version to :ref:`catch any broken links ` or reST errors, and diff --git a/docs/internals/release-process.txt b/docs/internals/release-process.txt index 7e899026dc..a845faf330 100644 --- a/docs/internals/release-process.txt +++ b/docs/internals/release-process.txt @@ -226,9 +226,9 @@ The release candidate marks the string freeze, and it happens at least two weeks before the final release. After this point, new translatable strings must not be added. -During this phase, committers will be more and more conservative with -backports, to avoid introducing regressions. After the release candidate, only -release blockers and documentation fixes should be backported. +During this phase, mergers will be more and more conservative with backports, +to avoid introducing regressions. After the release candidate, only release +blockers and documentation fixes should be backported. In parallel to this phase, ``main`` can receive new features, to be released in the ``A.B+1`` cycle. diff --git a/docs/intro/whatsnext.txt b/docs/intro/whatsnext.txt index 254a0c5eaf..ca55b12d7a 100644 --- a/docs/intro/whatsnext.txt +++ b/docs/intro/whatsnext.txt @@ -211,9 +211,9 @@ We follow this policy: been released yet, or "New in version X.Y" for released versions. * Documentation fixes and improvements may be backported to the last release - branch, at the discretion of the committer, however, once a version of - Django is :ref:`no longer supported`, that version - of the docs won't get any further updates. + branch, at the discretion of the merger, however, once a version of Django is + :ref:`no longer supported`, that version of the + docs won't get any further updates. * The `main documentation web page`_ includes links to documentation for previous versions. Be sure you are using the version of the docs