From 099ddc5a612987bb32a927829e955a38150417be Mon Sep 17 00:00:00 2001 From: Stephen Rosen Date: Thu, 25 Jun 2026 22:02:19 -0500 Subject: [PATCH 1/4] Add section to PR guide on titles and descriptions Add a short section to the PR guide which covers good titles and descriptions, at a summary level. The priority here is (in presentation order): - explain the rationale / why we care - demonstrate how a PR title should look - give some hint as to what a good description will look like Explaining how to write good technical prose for a PR description is considered out of scope, which limits the content of the PR description section. --- getting-started/pull-request-lifecycle.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index 47f1100c2b..d840f0e04e 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -203,6 +203,24 @@ should do to help ensure that your pull request is accepted. #. Proper :ref:`documentation ` additions/changes should be included. +Write good titles and descriptions +---------------------------------- + +Reviewers want to be able to understand roughly what your pull request does +before reading the changes. + +The title should be a sentence or phrase in the imperative which says what the +pull request does in short form. It should start with ``gh-NNNNNN:``, for pull +requests which close open issues. +For example, ``gh-12345: Fix bug when spam module is served with eggs``. + +The pull request description field should be a detailed summary. +This is a great place to note caveats, provide links to references, and explain +decisions made in the pull request. +Avoid over-explaining: simpler descriptions are easier to read, so make sure not +to write large descriptions for simple changes. + + .. _news-entry: .. _what-s-new-and-news-entries: From 5e6548c19fc716ca27486c9f0d587dfe75059d6c Mon Sep 17 00:00:00 2001 From: Stephen Rosen Date: Fri, 26 Jun 2026 18:49:48 -0500 Subject: [PATCH 2/4] Update getting-started/pull-request-lifecycle.rst Co-authored-by: Stan Ulbrych --- getting-started/pull-request-lifecycle.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index d840f0e04e..cac264d0c8 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -210,8 +210,8 @@ Reviewers want to be able to understand roughly what your pull request does before reading the changes. The title should be a sentence or phrase in the imperative which says what the -pull request does in short form. It should start with ``gh-NNNNNN:``, for pull -requests which close open issues. +pull request does in short form. Pull requests attached to issues should +be linked by putting the issue number in the title (``gh-NNNNNN:``). For example, ``gh-12345: Fix bug when spam module is served with eggs``. The pull request description field should be a detailed summary. From cc6006870e8a5d5a598722eb58f04014e41ba264 Mon Sep 17 00:00:00 2001 From: Stephen Rosen Date: Fri, 26 Jun 2026 19:09:16 -0500 Subject: [PATCH 3/4] Move "good-pull-request-metadata" section down Give this section a referenceable label, and place it in the "Submitting" section rather than "Writing good pull requests". Keep the content largely the same, but add a new trailing sentence to note that `#NNNNN` syntax can link issues. This replaces a note from "Submitting" that was mostly redundant with the new section. --- getting-started/pull-request-lifecycle.rst | 43 ++++++++++++---------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index cac264d0c8..a580259818 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -203,23 +203,6 @@ should do to help ensure that your pull request is accepted. #. Proper :ref:`documentation ` additions/changes should be included. -Write good titles and descriptions ----------------------------------- - -Reviewers want to be able to understand roughly what your pull request does -before reading the changes. - -The title should be a sentence or phrase in the imperative which says what the -pull request does in short form. Pull requests attached to issues should -be linked by putting the issue number in the title (``gh-NNNNNN:``). -For example, ``gh-12345: Fix bug when spam module is served with eggs``. - -The pull request description field should be a detailed summary. -This is a great place to note caveats, provide links to references, and explain -decisions made in the pull request. -Avoid over-explaining: simpler descriptions are easier to read, so make sure not -to write large descriptions for simple changes. - .. _news-entry: .. _what-s-new-and-news-entries: @@ -521,9 +504,7 @@ This will get your changes up to GitHub. Now you want to `create a pull request from your fork `__. -If this is a pull request in response to a pre-existing issue on the -`issue tracker`_, please make sure to reference the issue number using -``gh-NNNNN:`` prefix in the pull request title and ``#NNNNN`` in the description. +See :ref:`the section below on writing good titles and descriptions `. If this is a pull request for an unreported issue (assuming you already performed a search on the issue tracker for a pre-existing issue), create a @@ -543,6 +524,28 @@ A detailed commit history allows reviewers to view the diff of one commit to another so they can easily verify whether their comments have been addressed. The commits will be squashed when the pull request is merged. +.. _good-pull-request-metadata: + +Write good titles and descriptions +---------------------------------- + +Reviewers want to be able to understand roughly what your pull request does +before reading the changes. + +The title should be a sentence or phrase in the imperative which says what the +pull request does in short form. +Pull requests attached to issues should be linked by putting the issue number in +the title (``gh-NNNNNN:``). +For example, ``gh-12345: Fix bug when spam module is served with eggs``. + +The pull request description field should be a detailed summary. +This is a great place to note caveats, provide links to references, and explain +decisions made in the pull request. +Avoid over-explaining: simpler descriptions are easier to read, so make sure not +to write large descriptions for simple changes. + +Use ``#NNNNN`` in the description to refer to and link relevant issues. + Converting an existing patch from b.p.o to GitHub ================================================= From a44616a6d425de4c8c7505e90e5b701ece01d6a3 Mon Sep 17 00:00:00 2001 From: Stephen Rosen Date: Fri, 24 Jul 2026 15:30:35 -0500 Subject: [PATCH 4/4] Refactor the PR "submitting" section per review Refactor the section slightly to separate the high-level instructions from subsections for setting title and description (pre-existing) and filing issues (new as a section). Also remove an instruction to use #-num linkages. Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com> --- getting-started/pull-request-lifecycle.rst | 41 ++++++++++------------ 1 file changed, 18 insertions(+), 23 deletions(-) diff --git a/getting-started/pull-request-lifecycle.rst b/getting-started/pull-request-lifecycle.rst index a580259818..16e50133f2 100644 --- a/getting-started/pull-request-lifecycle.rst +++ b/getting-started/pull-request-lifecycle.rst @@ -501,28 +501,25 @@ list anything), you will want to push your branch to your fork:: This will get your changes up to GitHub. -Now you want to +Once your changes are pushed, you may `create a pull request from your fork `__. -See :ref:`the section below on writing good titles and descriptions `. - -If this is a pull request for an unreported issue (assuming you already -performed a search on the issue tracker for a pre-existing issue), create a -new issue and reference it in the pull request. Please fill in as much -relevant detail as possible to prevent reviewers from having to delay -reviewing your pull request because of lack of information. - -If this issue is so simple that there's no need for an issue to track -any discussion of what the pull request is trying to solve (for example, fixing a -spelling mistake), then the pull request needs to have the "skip issue" label -added to it by someone with commit access. - -Your pull request may involve several commits as a result of addressing code -review comments. Please keep the commit history in the pull request intact by -not squashing, amending, or anything that would require a force push to GitHub. -A detailed commit history allows reviewers to view the diff of one commit to -another so they can easily verify whether their comments have been addressed. -The commits will be squashed when the pull request is merged. +But first, read the following guidance to ensure your pull request has proper metadata. + +File an issue if necessary +-------------------------- + +If the change is so simple that there's no need for an issue to track any +discussion of what the pull request is trying to solve (for example, fixing a +spelling mistake), then the pull request will need to have the ``skip issue`` +label added to it by someone with commit access. + +However, most changes need to have an issue filed first. + +Search the issue tracker to check if the issue has already been reported. +If there is no existing issue, create a new one. +Please try to make your report a clear description of the issue, such that it +can be fully understood without reference to your pull request. .. _good-pull-request-metadata: @@ -538,14 +535,12 @@ Pull requests attached to issues should be linked by putting the issue number in the title (``gh-NNNNNN:``). For example, ``gh-12345: Fix bug when spam module is served with eggs``. -The pull request description field should be a detailed summary. +The pull request description field should be a succinct summary. This is a great place to note caveats, provide links to references, and explain decisions made in the pull request. Avoid over-explaining: simpler descriptions are easier to read, so make sure not to write large descriptions for simple changes. -Use ``#NNNNN`` in the description to refer to and link relevant issues. - Converting an existing patch from b.p.o to GitHub =================================================