BEP 11: Merge Policy
| BEP 11 | Merge Policy |
|---|---|
| Authors | Bryan Van de Ven |
| Status | WIP |
| Discussion | https://github.com/bokeh/bokeh/discussions/12423 |
This document describes required policies for merging Pull Requests in the Bokeh repository.
The Bokeh project has never had any explicitly stated conventions around merges, specifically who performs them and when. It would be beneficial to codify our policies so that newcomers to @bokeh/core may have clear expectations.
There is a wide range of possibilities adopted by Open Source projects, ranging from "no-self merges allowed" to "two approvals required" to "anything goes". All of these are too extreme for our needs. Another common convention 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 Bokeh core team, this is still slightly too restrictive.
BEP 11 proposes that @bokeh/core team members are responsible for merging their own Pull Requests, once one of these conditions is met:
- At least one review and approval is given, with no outstanding changes requested
- A notice of intention to merge has been stated with a reasonable timebox
Self-merges (and only self-merges) are the default expectation for @bokeh/core team members.
The ideal for most Pull Requests is to receive at least one review and approval from another @bokeh/core team members prior to merging.
Bokeh is primarily a volunteer Open Source effort, so it is not always guaranteed that a reviewer is readily available. In such a case, Bokeh Core Team members may move to merge their Pull Request without an approval. However, others must first be given an opportunity to raise questions or concerns. The Pull Request author should leave a new comment with a timeboxed statement of intent to merge. For example,
I intend to merge this PR tomorrow morning (PST) unless there is comment before then.
The timebox should be at least 36 hours to account for geographic disparity.
Pull requests that are related to build, CI, or infrastructure often have iteration cycle times in the hours or days. At the same time, issues for build, CI, and infrastructure matters are often urgent. Pull Requests that relate only to these areas may forego the requirements above.
| Date | Change |
|---|