i agree with @ChrisBarker-NOAA
I am in favour of instructing contributors to propose all changes to `master` and tagging releases as they are created. Branches are not required for managing the document in its normal work flow (though they may be useful for occasions such as where an updated 'point release' is required to an existing release). This is for administrators of the repository to manage, not for contributors to have to negotiate. I think that managing branches for each 'next version' will cause maintenance problems and confusion for contributors. There are already loads of branches within this repository, which can/will lead to further confusion, especially if we ask contributors to understand why these branches are there and which one to pick. I recommend keeping the use of branches limited to repository administrators and pointing all contributions and contributors at `master`. I also recommend ensuring that accepted changes are merged to master as soon as they are approved, so that further changes are being made with respect to the latest approved changes. I am fairly clear on the benefits of this approach and concerned about the risks of pointing contributors at branches and holding off merging agreed changes to some future time. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-412933788
