Proposal: BEP PRs should come from branches on the main repository

[effigies]

In the Derivatives BEP (#109), we've run into the situation where the person proposing the BEP as a PR from their own fork has to step back from engagement, and it's not hard to imagine that this might happen again in the future, for any number of reasons. Beyond that, there are a lot of reasons not to make an individual contributor a bottleneck, not least the burden this places on that contributor to be responsive to debates that they aren't directly involved in. There's also an implication of authority that many moderators wouldn't want to project.

We're moving the Derivatives BEP into a branch, which puts the BEP into the same editorial purview as the specification as a whole, whose rules are a matter of community consensus and gives the BEP leads and @sappelhoff flexibility to do maintenance work, such as resolving merge conflicts, and resolve deadlocks.

I propose that we make this the general rule, and use the following process when a BEP gets to PR stage:

1. A new branch is created from master with the BEP name or number (getting the attention of someone with the power to make it, if necessary)
2. An initial PR against that branch translates the draft spec into Markdown. All debate on this PR should be stylistic (e.g., "I think this section fits better in this other file.").
3. Once the initial PR is merged, the full BEP PR is created from the BEP branch to master. Any additional decisions and debates happen here.

If people agree, I can formalize this in CONTRIBUTING, if that seems appropriate.

cc @bids-standard/bep_leads

[teonbrooks]

for search ease among the branches, the branch should be named after the bep number, e.g. BEP001

[satra]

@effigies - i think even with the current situation github would allow us (unless the PR tree gets complex), to close a PR and reopen a separate one with exactly the same content, unless the PR originator deletes the project/account.

therefore, my suggestion would be we can keep things flowing the normal github way for initial BEPs, since they may come from community. also this will ensure that the BEP can track and be mergeable/updatable to master by the originators.

but i don't have a strong inclination either way.

[tyarkoni]

I also don't have a strong feeling either way, but I don't think it's a terrible idea to make all BEP proposals go through the existing set of contributors. The bar can be set low, but at least someone already involved should be willing to sign off on consideration of a new BEP. Otherwise there's the potential for people to spend time working on PRs that aren't ever going to make it in. We should encourage discussion of potential extensions before anyone starts to put in serious work on them.

[effigies]

To synthesize the above contributions into an updated process:

1. With a new BEP proposal, open an issue where the scope of the BEP and whether it should even be considered is discussed. The content can remain in a Google Doc until ready for reformatting.
2. When a new branch is created (with name BEP0XX in the future), the creator of that branch is indicating that they think it's ready to bring to the group at large. This should not go against a consensus not to consider in the issue.
3. An initial PR against that branch translates the draft spec into Markdown. All debate on this PR should be stylistic (e.g., "I think this section fits better in this other file.").
4. On merge, the moderators of that BEP should be given some level of privileges to accept pull requests into that branch. If we can do this via GitHub rules, then cool. If not, then
5. The full BEP PR is created from the BEP branch to master. Any additional decisions and debates happen here.

There are extreme objections such as "The proposal as written will break consistency", which I might consider allowing at stage 3, forcing a return to drafting outside of GitHub. Or that may be fine to handle at stage 5.

To be clear, this is for large BEPs. Smaller things can still use the usual PR process, but the big ones might require multiple rounds of PRs and take a while to finalize, and I think having them in the main repo is good for visibility of discussions.