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.

[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.