chore: define CONTRIBUTING.md with release instructions

mflendrich commented 4 years ago

closes #23

Not to be merged before #38 because the instructions from CONTRIBUTING.md expect the artifact (introduced in #38) to be present on CI runs.

mflendrich commented 4 years ago

The release instructions are based on my experience from releasing v0.4.0. We can battle-test the instructions with our next release.

Also, these instructions come with a lot of potential for automation. See #21 #40 . We've made the choice to start with a manual (yet well-defined) release workflow that we can go through several times before we automate.

rainest commented 4 years ago

Generally looks good. Two things I'd like to raise:

Between maintainer steps 5 and 10, does it make sense to formalize that as "do the release in 5, but use the GH Pre-release feature to mark it as an RC" and then "assuming nothing went wrong and everything is merged upstream, mark the release gold after 10 is done"?
The conventional commit format more or less aligns with what we're doing already, and moving to a community standard format is good, but our current landscape across the Kong org's OSS projects isn't entirely consistent. Has there been any broader discussion around targeting some standard as the eventual standard across all our OSS projects? @guanlan or @hishamhm perhaps you could weigh in here: I don't know if there have been similar discussions around trying to make our OSS contribution guidelines more consistent across our projects--as-is it's fairly fragmented across teams.

mflendrich commented 4 years ago

does it make sense to formalize that as "do the release in 5, but use the GH Pre-release feature to mark it as an RC" and then "assuming nothing went wrong and everything is merged upstream, mark the release gold after 10 is done"

I would say "no" because at that point the release is already validated by CI, and there's no (apparent to me) scope for validation happening after that step.

Has there been any broader discussion around targeting some standard as the eventual standard across all our OSS projects?

No, my thinking was that leading by example (+ the right announcement) could be more effective. Also, defragmentation of contributing guidelines is imo out of scope.

mflendrich commented 4 years ago

@rainest can we merge this now?

Kong / kong-operator

chore: define CONTRIBUTING.md with release instructions #43