Add policy for maintainer takeover of stale PRs - #159
Conversation
fe56f73 to
3088529
Compare
| requests. However, life priorities change, and sometimes a contributor may | ||
| become unresponsive before a pull request is fully ready to be merged. | ||
|
|
||
| If a pull request is nearly complete but requires some final adjustments (such |
There was a problem hiding this comment.
| If a pull request is nearly complete but requires some final adjustments (such | |
| To focus on delivering bugs/features faster, maintainers may take over (assist with) contributor PRs. If a PR is close to completion, a maintainer may first request the author make the needed diffs to the commit(s) and/or by asking the author if they need/want the assist. |
There was a problem hiding this comment.
Some concerns about this wording:
- "Take over (assist with)" -- I don't think these are the same thing. Taking over a PR because the author is unresponsive, and assisting an active author are different actions with different etiquette. Conflating them risks the policy being read as license to grab PRs from contributors who are still engaged with us
- "May first request the author make the needed diffs" -- this assumes the author is responsive, which contradicts the premise of this section. The reason we needed this policy is for authors that aren't replying
I'm also not sure I agree with the premise of this being to deliver bugs or features faster (see the above comment on "Fast Tracking"). If we want to include this then we probably need another round of review to ensure we're all on the same page.
There was a problem hiding this comment.
I'm also not sure I agree with the premise of this being to deliver bugs or features faster
Commented above, but there's value in both here. It can often be faster for a maintainer to just fix trivial issues in a PR rather than requesting the author does it (which fits the "fast tracking" bit). The unresponsive case is also important.
There was a problem hiding this comment.
nod .. value in both... and with my first read it read, to me, like it was for both cases but primarily to un-stick.
Wasn't clear in the reading that this was just about reducing the aged PR list to a manageable size. So separating the two tasks seems like a good way to go.
| become unresponsive before a pull request is fully ready to be merged. | ||
|
|
||
| If a pull request is nearly complete but requires some final adjustments (such | ||
| as addressing minor review nits or resolving merge conflicts), and the original |
There was a problem hiding this comment.
| as addressing minor review nits or resolving merge conflicts), and the original |
There was a problem hiding this comment.
These examples mirror the style of other sections in this guide and help readers understand what counts as "nearly complete"
|
|
||
| If a pull request is nearly complete but requires some final adjustments (such | ||
| as addressing minor review nits or resolving merge conflicts), and the original | ||
| author is not responding to comments, a maintainer may choose to take over the |
There was a problem hiding this comment.
| author is not responding to comments, a maintainer may choose to take over the |
There was a problem hiding this comment.
Unresponsive authors were the original premise for this proposal. Including this provides necessary context for why we would choose to take over a PR.
There was a problem hiding this comment.
author may not be able to respond or disagrees with the review.. or the notice just got lost in the mail bin. Best to always be nice to the contributor. Didn't seem to need to be said. I don't want to read, I took over this PR because you (the author) didn't respond fast enough. Prefer the wording we love your diffs and are following it up with ___ to accelerate the merge.
There was a problem hiding this comment.
I think as long as author agrees with this option, maintainer can take over their work if there is no response.
There was a problem hiding this comment.
@fuweid that is a GitHub permissions feature that allows a maintainer to push to the contributor's remote. I think it's a little independent from the policy though; we can always push to our own remotes and create new PRs in order to carry the work forward.
| If a pull request is nearly complete but requires some final adjustments (such | ||
| as addressing minor review nits or resolving merge conflicts), and the original | ||
| author is not responding to comments, a maintainer may choose to take over the | ||
| pull request to ensure the work is not lost and can be merged. |
There was a problem hiding this comment.
| pull request to ensure the work is not lost and can be merged. |
There was a problem hiding this comment.
I think this line is consistent with the narrative style of this guide and re-iterates that we value the author's contributions
Adds a section to the contributing guide outlining the process for maintainers to take over stale pull requests. This ensures valuable contributions are not lost when an author becomes unresponsive, while preserving original author credit and providing transparency on modifications, as discussed at the 2026 containerd Maintainer Summit. Assisted-by: Antigravity Signed-off-by: Chris Henzie <chrishenzie@gmail.com>
3088529 to
3705f15
Compare
|
Received offline feedback from @dims:
Updated to include a specific line for this. |
7 participants
Adds a section to the contributing guide outlining the process for maintainers to take over stale pull requests. This ensures valuable contributions are not lost when an author becomes unresponsive, while preserving original author credit and providing transparency on modifications, as discussed at the 2026 containerd Maintainer Summit.
Assisted-by: Antigravity