Label strategy

[tisonkun]

Currently, we have these sorts of labels:

1. Issue's or PR's area, i.e., which component it is related.

We don't have a top-down component taxonomy, so adding when we meet one:

• A-build
• A-ci
• A-cluster
• A-docs
• A-scripting
• A-security
• A-site
• A-transaction

I removed area "server" cause many issues and PRs can be related with "server", especially we don't develop our client. Such a label is too vague to help sorting.

2. Issue's type, i.e., what action is expected to do.

• bug to be fixed.
• crash to be fixed - this is one kind of bug, but common and critical that deserves special attention.
• enhancement - generic development task.
• feature adds new feature.
• question - new questions should be opened to Discussions. Keep it for a while for migration.

I removed type "fix" since we should only sorting types on issues, but PRs associated with issues. If we want to sort PRs by their modification, we can use a semantic PR solution (https://github.com/Ezard/semantic-prs).

3. Maintenance labels

• good first issue
• help wanted

Other labels require a revisit to work out a clear definition:

• major decision maybe we require the author to write a proposal for significant changes instead of a label.
• need-cherry-pick how to? A cherry-picking strategy at least sorted by target versions (this is a downside of GitHub issue as a tracking system, though).
• release notes this can work. Combined with milestone, the RM know what to include or highlight in the release notes. But do we write release note now?

[git-hulk]

release notes this can work. Combined with milestone, the RM know what to include or highlight in the release notes. But do we write release note now?

It looks better to write the release note when tagging the release notes label because whoever adds the tag should know precisely why we need to call out the change in the new release.

cc @PragmaTwice @torwig @enjoy-binbin

[torwig]

@git-hulk Do we have a dedicated file or something to write release notes to?

[enjoy-binbin]

major decision: Usually small PR we can merge directly (one person), if there are some major changes, such as breaking changes, introduction of new features, important bug fixes, etc., we need multiple people to make decisions or reach a consensus

need-cherry-pick: This is a bit redundant, if we use projects to manage it (we add all the PRs that need to be picked to a certain project (when PR was raised and we find out it should be picked, we add it), and review the project to avoid missing things when realeasing). see: https://github.com/orgs/apache/projects/278 and #1622

release notes: I saw some unimportant PRs in the report when we last released 2.5.0 (https://github.com/apache/kvrocks/releases/tag/v2.5.0). For some PRs, such as those that need to be known to users, such as major changes, new features, important bug fixes, etc., we can add tags and add explanations when releasing them (for example, if there is a sudden security issue, you can highlight it and then let users to upgrade ASAP)

[mapleFU]

Seems we don't have a A-transaction part, other look goods to me