Release Process

N.B. This is going to need fleshing out.

To make a "release" version of the guidelines:

1. Open pull request to track review. A pull request is created by a guidelines-core member to merge master onto release. This checklist should be the contents of the first comment in the pull request:

   - [ ] Version number bumped
   - [ ] DOI reserved
   - [ ] DOI updated
   - [ ] Endorsements solicited
   - [ ] Endorsements updated
   - [ ] Release tagged
   

2. Bump the version number. TODO: list places to bump it in checklist.

3. Reserve a DOI on Zenodo. Reserve a DOI on Zenodo for this release. This should be a new version of the previous document using Zenodo's DOI versioning. We do this manually rather than use Zenodo's auto-generate-on-Github-release feature so that we can include the DOI in the document itself.

4. Update DOI. Update the DOI tag in the README and any uses of the DOI in the document to use the new DOI specific to this version. TODO: put a list of places to change in the checklist.

5. Solicit endorsements. An announcement is made that a new version of the guidelines is to be released soon and to solicit endorsements of chapters / the guidelines from people. TODO: make an email template for this that links to the compiled docs and the relevant pull request, and maybe also a google form for people to submit endorsements.

6. Wait 3 weeks for endorsements.

7. Update endorsements. Update the endorsements in the repo based on the submissions.

8. Tag a release. Tag a release in Github with the version number and a brief list of changes.

Following the last step (tagging a release), Travis-CI will automatically push the release version to the guidelines-release repository.