I agree with the discussion wholeheartedly, which for the sake of keeping things tidy and confirming my own understanding I summarize as follows: - If you want to change something and are in doubt, raise an issue - For anything else, a PR is a good way to go, although an issue isn't harmful, especially if it's about a typographical matter - What I'm missing is a release strategy, which may need to be addressed elsewhere. I propose something inspired by Git Flow, roughly as follows: - `master` is the current release. - `next` is the next release, an "editor's draft", if you will. - If you want to make a change, make a branch based on `next` and implement it. Then send a PR to merge it back into `next` or ask for help. - When a change has been approved, it's merged into `next`. - When we make a release, we merge `next` into `master` and tag that.
Perhaps more refinement is possible - we discussed at the meeting having some kind of a beta version of a next release for a time. This would be compatible with this workflow (which is one of many possible ones, but fairly simple and IMHO straightforward). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/130#issuecomment-398843638
