Skip to content

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

Open
story645 wants to merge 1 commit into
matplotlib:mainfrom
story645:championing
Open

DOC: make championing pr standalone subsection and update alert procedure#32185
story645 wants to merge 1 commit into
matplotlib:mainfrom
story645:championing

Conversation

@story645

@story645 story645 commented Aug 7, 2026

Copy link
Copy Markdown
Member

PR summary

Follow up to #32113, pulls language about championing PRs into a subsection to make extra clear that it applies to doc and code PRs. Also updates the alert/contact, but I think we have too many and should maybe pull back to:

  • label PR w/ "merge w/ single review"
  • put on weekly dev call
  • post on discourse dev chat

AI Disclosure

nopes

PR quality check

  • Use an expressive title, e.g. "Fix title font property precedence"
  • New and changed code is tested
  • Plotting related features are demonstrated in an example
  • New features and API changes have release notes
  • Documentation complies with general and docstring guidelines

@story645 story645 added the Documentation: devdocs files in doc/devel label Aug 7, 2026
Comment thread doc/devel/pr_guide.rst
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

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.)

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Documentation: devdocs files in doc/devel

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants