Skip to content

DOC: make championing pr standalone subsection and update alert procedure #32185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
story645 wants to merge 1 commit into
base: main
Choose a base branch
from
+13 −11
Open

DOC: make championing pr standalone subsection and update alert procedure #32185

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 13 additions & 11 deletions doc/devel/pr_guide.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -251,17 +251,19 @@ Some explicit rules following from this:
subdirectories of :file:`doc/api/next_api_changes`, and significant new
features have an entry in :file:`doc/user/whats_new`.

- If a PR already has a positive review, a core developer (e.g. the first
reviewer, but not necessarily) may champion that PR for merging. In order
to do so, they should ping all core devs both on GitHub and on the dev
mailing list, and label the PR with the "Merge with single review?" label.
Other core devs can then either review the PR and merge or reject it, or
simply request that it gets a second review before being merged. If no one
asks for such a second review within a week, the PR can then be merged on
the basis of that single review.

A core dev should only champion one PR at a time and we should try to keep
the flow of championed PRs reasonable.
Championing Pull Requests
^^^^^^^^^^^^^^^^^^^^^^^^^
If a PR already has a positive review, a core developer (e.g. the first reviewer, but
not necessarily) may champion that PR for merging. In order to do so, they should label
the PR with the "Merge with single review?" label and ping core devs on GitHub, the
weekly development meeting, the development channel on discourse and the dev mailing
list. Other core devs can then either review the PR and merge or reject it, or simply
request that it gets a second review before being merged. If no one asks for such a
second review within a week, the PR can then be merged on the basis of that single

@melissawm melissawm Aug 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we be explicit and say

Suggested change
second review within a week, the PR can then be merged on the basis of that single
second review within a week, the PR can then be merged by any maintainer on the basis of that single

Just to clarify we don't necessarily need to wait for the champion to do it. (Also, I'm using maintainer as an umbrella for core dev/other roles in the project but feel free to use core dev everywhere if that's more precise here.)

@story645 story645 Aug 11, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintainer is accurate - anyone with commit rights can merge

@story645 story645 Aug 11, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which I should update the whole paragraph with maintainer. We don't really have a distinction at the moment, though maybe we should

review.

A core dev should only champion one PR at a time and we should try to keep the flow of
championed PRs reasonable.

.. _pr-automated-tests:

Expand Down
Loading