From 099ddc5a612987bb32a927829e955a38150417be Mon Sep 17 00:00:00 2001 From: Stephen Rosen Date: Thu, 25 Jun 2026 22:02:19 -0500 Subject: [PATCH 1/3] 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 47f1100c2..d840f0e04 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/3] 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 d840f0e04..cac264d0c 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/3] 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 cac264d0c..a58025981 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 =================================================