Codify governance

[jsumners-nr]

Now that this module is handled under the Node.js umbrella org with a variety of committing members, we need to codify how the project will be governed. Some things to address (with others likely missed):

1. PR approvals and merges: how many members with commit access need to approve a PR before it is merged? In my view, we need a minimum of two, with the approvers coming from individuals that are not on the same professional team as the person submitting the PR.
2. How will releases be handled: presumably we will implement some sort of automation. How will that work? Will a release be issued after every PR merge? On a new tag being created? And until then, who will be managing releases manually?

Here's what I do know. Node.js is an OpenJSF project, and so is Fastify. Fastify's governance passes all requirements:

• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/CODE_OF_CONDUCT.md
• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/CONTRIBUTING.md
• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/GOVERNANCE.md
• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/PROJECT_CHARTER.md
• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/SECURITY.md
• https://github.com/fastify/fastify/blob/9898d089791d30623c4f48a968ab0983c1721ae8/docs/Reference/LTS.md

[Qard]

For 1, that sounds fine. For 2, I think we need to have some discussions with people involved in other projects owned by the Node.js org which have release automation to figure out how we can add that effectively.

[timfish]

Looking through the Node libs published to NPM, they seem to use release-please:

• https://github.com/nodejs/node-gyp/blob/main/.github/workflows/release-please.yml
• https://github.com/nodejs/node-addon-api/blob/main/.github/workflows/release-please.yml

So we'd use the googleapis/release-please-action and for that we'd need a Github auth token with the correct permissions and an npm token for publishing.

We are currently missing a CHANGELOG.md which is a requirement.

It creates (and then updates) release PRs and relies on conventional commit messages:

• fix: which represents bug fixes, and correlates to a SemVer patch.
• feat: which represents a new feature, and correlates to a SemVer minor.
• feat!:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a SemVer major.