Propose change to PR merging policy. #14867
Conversation
|
👍 but going to leave for now to give others in @matplotlib/developers a chance to take a look |
| - 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. |
There was a problem hiding this comment.
I'm not sure about "and on the dev mailing list"; I rarely see day-to-day pings (as opposed to long-term, more architectural things) happen there.
There was a problem hiding this comment.
I think it doesn't cost much to send an email.
There was a problem hiding this comment.
I mean that I don't see it happening regularly...
There was a problem hiding this comment.
I'm fine either way, but let's see what @tacaswell thinks?
As discussed during the dev call.
| 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. |
There was a problem hiding this comment.
So, if I am reading this correctly, does this mean that a core dev can effectively put a "hold" on merging a PR? If so, I think that should be made explicit. Will there be a label for that, or does one just need to leave a comment?
There was a problem hiding this comment.
Well, you can always reject a PR. Or you can just say, "I don't want to reject this PR myself, but I think it is complex enough that I ask for a second positive review before it gets merged." (the "or simply request etc.").
You can probably just remove the "merge-with-single-review" label to signal that.
|
Overall, I am fine with this idea. It would be nice if we had some sort of tool that helped us track this "champion" process, so that we could see how often this happens, who is doing the championing, and for whom. Also, on the flip side, to know how often PRs are getting "held up". |
|
Oh, and should we have some sort of provision about typical holidays where we might expect a significant number of devs to be away from their computers for a week or two at a time? I just want to make sure that no responses around the winter holidays isn't taken to mean a lack of objection. |
|
I don't mind changing the one-week interval (originally suggested by @tacaswell) to a two-week interval (having a variable interval depending on the time of year seems overengineered). |
|
@dopplershift currently most PRs are merged within a week or remain open semi indefinitely, so 2 weeks might be a sweet spot? @WeatherGod I think most of those metrics might be available via the github api. |
|
I think the social stigma attached to being involved in a bad PR is substantial enough that we can trust folks to no abuse this. i.e. waiting a bit longer if it is holidays. I think folks can also use their judgement about the scope of the PR, and the number of likely people interested/qualified to say anything about it. Some obscure PGF change can probably be handled by a couple of folks without burdening a third to check and merge. A major user facing change would presumably get more attempts at getting feedback |
|
I have the data for "time opened" per pull request, and it's a power law. Things that are open for more than one week are typically opened for more time than that. IMO, it would be reasonable to add that the person championing the PR can not be the author of the PR. |
|
@NelleV's last comment is hilarious given it's been open for an additional 26 days :) |
As discussed during the dev call.
attn @tacaswell
PR Summary
PR Checklist