Discussion: conventions for self-merges #12423
Replies: 3 comments 6 replies
-
Note: I am not proposing this as a BEP since it is not really related to anything directly user-facing. I would imagine this information going in the dev guide and also potentially a Wiki page for a new contributor "onramp" |
Beta Was this translation helpful? Give feedback.
-
In general I am in favour of more explicit documentation of our processes and expectations. A few comments in no particular order:
|
Beta Was this translation helpful? Give feedback.
-
I intend and would like to create a BEP for this and then a corresponding poll on loomio but I will wait until existing BEPs are migrated to the |
Beta Was this translation helpful? Give feedback.
-
We have never had any explicitly stated conventions around merges, specifically who performs them and when. I think it would be beneficial to codify some answers to these questions so that newcomers to @bokeh/core may have clear expectations. There is a wide range of possibilities, ranging from "no-self merges allowed" to "anything goes". I believe both of these are too extreme for our needs.
A common convention I have encountered in all of my other work outside Bokeh in the last few years is: "PR authors are responsible for their own merges, once an approval is given by another team member." Given the small size and geographic distribution of the team, I think this is still (slightly) too restrictive for our situation.
I think starting from a model of unanimous consent would keep things flexible enough for us. But that assumes that everyone is given an opportunity to raise concerns beforehand. For example, for my own PRs I often state my intentions with a time box:
I have done this as a courtesy, but I would like to propose that it become the expected norm:
The other side of this is that if objections are raised, that they be addressed—either by discussion and agreement (ideally) or decision (if necessary). I believe that we owe each other due consideration of concerns.
We can certainly carve out reasonable exceptions, e.g. for build, CI, or infra related work, for docs updates (potentially), or for "emergency" situations (credential spills, etc), or anything that might reasonably be considered "trivial". In general, I think everyone can be expected to rely on judgment here. Special circumstances may always arise, but I'd like to set a baseline for standard workflows.
cc @bokeh/core for thoughts
Beta Was this translation helpful? Give feedback.
All reactions