Improve Contributing docs and set a release schedule

[bircni]

This PR updates CONTRIBUTING.md for clarity (code review, maintainers, PR workflow)

Suggestion

• majors about every three months, with a more predictable cadence from v1.26 onward.
• target dates such as v1.26.0 (April 2026), v1.27.0 (June 2026), v1.28.0 (September 2026), v1.29.0 (December 2026).
• announce feature freeze two weeks before each release.

Other doc changes

• Reviewing PRs: separate guidance for reviewers vs authors; small edits to maintaining PRs, merge queue, commit messages, co-authors.
• Maintainers: clearer subsections; links to GitHub Docs for 2FA / GPG.
• Split the Contributing.md into more useful markdown files

[bircni]

Replaces #36686

[wxiaoguang]

• Add AI Contribution Policy to CONTRIBUTING.md #36651 (comment)

---

By the way, I was thinking about splitting the CONTRIBUTING.md into different files.

There are too many contents mixed together in CONTRIBUTING.md, many of them are for maintainers only, not needed by contributors.

In my mind, some files:

1. CONTRIBUTING.md: only contains the useful information for new contributors, and link to other files
2. docs/guideline-frontend.md
3. docs/guideline-backend.md
4. docs/community-governance.md
5. docs/release-management.md

Otherwise, the all-in-one file which has more than thousand of lines (wrapping....) is difficult to read, and the useful information can be easily ignored (for example: don't rebase+force-push)

[bircni]

• Add AI Contribution Policy to CONTRIBUTING.md #36651 (comment)

By the way, I was thinking about splitting the CONTRIBUTING.md into different files.
There are too many contents mixed together in CONTRIBUTING.md, many of them are for maintainers only, not needed by contributors.
In my mind, some files:

1. CONTRIBUTING.md: only contains the useful information for new contributors, and link to other files
2. docs/guideline-frontend.md
3. docs/guideline-backend.md
4. docs/community-governance.md
5. docs/release-management.md

Otherwise, the all-in-one file which has more than thousand of lines (wrapping....) is difficult to read, and the useful information can be easily ignored (for example: don't rebase+force-push)

Done

[silverwind]

We can do a slightly less-than-perfect 1.26.0 now, bug fixes will happen regardless and the more often we release, the easier they are to backport because branches diverge over time.

[silverwind]

Maybe make it a bit less verbose overall, it seems quite big.

The plan is good, I hope it will be followed. We should also look into automating the release process as much as possible. Maybe with a release.sh script or similar. Currently there seem to be too many manual steps.

[bircni]

All this was nearly 100% copied into other files not fully reviewed again
Will recheck that all

[bircni]

@lunny @wxiaoguang @silverwind I added the following:

How is the release handled?

• The release manager will tag the release candidate (e.g. v1.26.0-rc1) and publish it for testing in the first week of the release month.
• If there are no major issues, the release manager will check with the other maintainers and then tag the final release (e.g. v1.26.0) in the one or two weeks following the release candidate.

I think it's ready for merge and to apply the new scheduling

[DaanSelen]

I like the idea!
I do also like the idea of instead of 1.x.x such as 1.26.1 why not do a date based version? 2026.01.patch? Or would that not fix? Its just my two cents.

[TheFox0x7]

Ref issue for version numbering: #27574
It's really not in scope of this I feel.