According to https://github.com/bids-standard/bids-specification/blob/master/DECISION-MAKING.md#rules PRs should not be merged sooner than 5 days from the last commit. Right now this rule needs to be manually observed by members with write permissions.
We could automate this by creating a bot that will a) give a request changes review to PRs younger than 5 days and remove it when the 5 day period passes b) merge mergeable PRs.
Killing two birds with one stone -- I think a bot will clear up any ambiguity about when that 5-day clock starts ! :+1:
I wonder if we could write a rule for Policy Bot.
Investigating if we can do this with mergify.io https://github.com/Mergifyio/mergify-engine/issues/349
Based on discussion in #150, it sounds like we should write rules for disapproval that will only be lifted after 5 days from oldest commit. That way the merging reviewer will still be able to ensure that the PR title is correct for the changelog. Unless anyone else has another suggestion for how to approach this issue !
That way the merging reviewer will still be able to ensure that the PR title is correct for the changelog.
+1, this would be more robust instead of automatically merging after 5 days if 2 approving reviews,
Hello! I'm just passing through while exploring OSS x Neuroscience, but I did a bit of research last night and found Mergeable, a Probot plugin. I'm not sure if this will serve your needs completely, since it doesn't seem compatible with PushEvents (which, I'm pretty sure, is the particular event you need to be watching for/timing) but perhaps it could be modified slightly to handle those! If folks are interested, I can do some more exploring this weekend.
Thank you @gallexi for raising Mergeable! I was just preparing a comment to propose that too! I found the pro's of Mergeable is the days old feature and that it can detect the 2 approvals. The one thing it is missing (as you mentioned) is the merge aspect. This would more than likely have to be used with another tool (like mergify). A potential workflow could be: Policy bot would provide the disapproval until a cue (like a comment) is given by Mergeable to change that to an approval and then the other tool (like mergify) can merge it. A concern is over enginnering is. What do we think about this or other suggestions? This is what I saw as a potential solution and gallexi if you would like to explore further, that sounds good, thank you!
Side note: The tool we have implemented for generating the changelog (github changelog generator) allows for PR titles to be changed after a merge and it will be represented correctly in the changelog on the next merged PR (this is the action that triggers a changelog build).
I've looked more into Mergeable, as well as probot-scheduled-merge, and ended up coming upon semantic pull requests, which, despite not having anything to do with time on its own, I think could actually be pretty easily modified to fit the goal here!
I'll see if I can get a proof of concept up, but the general idea is that it would return a "pending" checks status until the latest commit (and, I assume we also want the PR itself) is older than 5 days. Then, it will return "success"!
Does that sound reasonable?
I am excited to see that proof of concept @gallexi! :-)
The semantic pull requests could also be used to automate what Chris suggested here regarding enforcement of PR Titles that will lead to a clean changelog
Thank you @gallexi for looking into this and I am also excited to see the proof concept!
Most helpful comment
I've looked more into Mergeable, as well as probot-scheduled-merge, and ended up coming upon semantic pull requests, which, despite not having anything to do with time on its own, I think could actually be pretty easily modified to fit the goal here!
I'll see if I can get a proof of concept up, but the general idea is that it would return a "pending" checks status until the latest commit (and, I assume we also want the PR itself) is older than 5 days. Then, it will return "success"!
Does that sound reasonable?