[INFRA] Update release protocol

[effigies]

Started amending the release protocol in #234, found that it could be made clearer with explicit git commands. Then felt that it could stand some more comprehensive revision.

The three substantial changes I'm proposing are:

1. Merging other pull requests is permitted during a pull request if the discussants agree that the pull requests should be merged before a release. In particular, this is intended to allow for edits that restore consistency without forcing the pull request to be deleted and re-started at some later date.
2. Releases should be given annotated tags (see [INFRA] Use annotated tags for releases #229).
3. Cleanup of the changelog should be made in the release branch, as it won't get demolished by the changelog generator. (See some discussion in Allow modification of the changelog post merge #164.)

As a subsidiary to change 2, if we want to use GitHub releases at all is kind of an open question at this point. We can continue doing so if people like them, but there's no technical advantage and we haven't been putting much effort thus far into making them informative documents.

To see this document rendered: https://github.com/effigies/bids-specification/blob/process/release/Release_Protocol.md

Leaving this PR as a draft for now because I haven't finished (e.g., I haven't incorporated change 3), but I would like to get comments on the issues raised above before investing more time.

[sappelhoff]

+1 for the proposed changes, thank you for the clarification work and integrating annotated tags.

As a subsidiary to change 2, if we want to use GitHub releases at all is kind of an open question at this point. We can continue doing so if people like them, but there's no technical advantage and we haven't been putting much effort thus far into making them informative documents.

I agree that currently the GitHub releases do not add much. However, once we start to integrate with Zenodo to generate DOIs for the spec, the releases will become meaningful, because they will trigger a new archiving on Zenodo.

related to: #66

[franklin-feingold]

Re: the 3 changes -

1. I think that sounds good to me. We may want to constrain and identify these type of cases (or at least an example) to be more clear what is meant. The PR can be opened before and merged after a PR so not to lose the comments and history of work.

2. LGTM. I have no strong opinion with GitHub releases. Seemed like an easy quick way to see a historical record, but not concerned if we decide against. Zenodo could change that work process decision.

3. With the release cleanup - so the cleanup happens in the branch and then it is committed over? The commit would allow for the generation to be skipped and then could correspond with the same day of Release to be most up to date in stable.

Thank you for putting this together!

[effigies]

Alright, finished this. LMK what you think.

[franklin-feingold]

Thank you for putting together! Looks good to me! Will be good to see in practice for the next release and iterate if need be

[effigies]

Cool. Thanks for the review.