[docs] Add a design proposal template

[myasnikovdaniil]

Summary

Adds design-proposals/template.md as the starting point for new
proposals. Proposed as an alternative to #3 — the repo should land one
of the two.

Compared to #3, this version:

• Puts metadata at the top (Title / Author(s) / Date / Status) to
  match the requirement already stated in design-proposals/README.md.
  Adds a Status line for long-lived docs (Draft / Review / Accepted /
  Superseded).
• Consistent heading levels. Each H2 section has a single
  responsibility; sub-sections are H3 only when they belong under the
  parent (e.g. ### Non-goals under ## Goals).
• Collapses "Overview / Motivation / Users and User Stories" into
  one ## Overview + ## Context pair. The three-way split in [docs] Add a proposal template #3
  tends to produce the same paragraph written three times.
• Moves ## Alternatives considered to the end. Reviewers can't
  evaluate rejected options without first seeing the chosen design.
  Matches KEP/KubeVirt convention.
• Adds ## Scope and related proposals. Cross-proposal scoping
  comes up as soon as there is more than one proposal in flight (see
  design-proposals: tenant module overrides #4 for a live example).
• Adds ## Failure and edge cases as a first-class section rather
  than a bullet under Trade-offs. Surfaces concrete misbehaviors
  reviewers can poke at.
• Flattens "Update/Rollback Compatibility → Security → Testing"
  into peer sections. Security and Testing are not sub-concerns of
  rollback.
• Adds ## Open questions so authors have a place to park
  unresolved points instead of scattering them through the body.
• Trailing newline at EOF.

#4 was drafted against this shape and fits it naturally, which was the
main prompt for proposing this variant.

Test plan

• Render the template on GitHub and confirm section headings and
  metadata placeholders display as intended
• Scaffold a scratch proposal against the template to check the
  section order reads naturally top-down
• Compare with [docs] Add a proposal template #3 and pick one

[coderabbitai]

Warning

Rate limit exceeded

@myasnikovdaniil has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 59 minutes and 50 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 59 minutes and 50 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2fb9ec08-d0dd-47cd-8a82-dd812752c6b1

📥 Commits

Reviewing files that changed from the base of the PR and between 33dad69 and 657fe1a.

📒 Files selected for processing (1)

• design-proposals/template.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/proposal-template

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces a new Markdown template for design proposals, providing a structured format for documenting system changes. The review feedback suggests several improvements to the template, such as adding a reminder for users to rename the file, including a 'Rejected' status for proposals, and ensuring consistent document structure by using placeholders for empty sections.

[gemini-code-assist]

Add a comment at the top of the template to remind users to rename the file to README.md and place it in its own directory, as per the instructions in design-proposals/README.md.

Suggested change

	# Your proposal title
	<!-- Rename this file to README.md and place it in a sub-directory under design-proposals/ -->
	# Your proposal title

[myasnikovdaniil]

Added a reminder at the top of the template that authors should rename the file to README.md and place it in a sub-directory under design-proposals/, matching the convention stated in design-proposals/README.md. Commit: 657fe1a.

[gemini-code-assist]

Consider adding Rejected as a possible status for proposals that are not accepted. This provides a clear end state for proposals that do not move forward.

Suggested change

	- **Status:** Draft | Review | Accepted | Superseded
	- **Status:** Draft | Review | Accepted | Rejected | Superseded

[myasnikovdaniil]

Added — Status is now Draft | Review | Accepted | Rejected | Superseded. Commit: 657fe1a.

[gemini-code-assist]

Update the status transition documentation to include the Rejected state.

Suggested change

	<!-- Status transitions: Draft → Review (PR opened) → Accepted (merged)
	or Superseded (replaced by a later proposal; link it). -->
	<!-- Status transitions: Draft → Review (PR opened) → Accepted (merged),
	Rejected, or Superseded (replaced by a later proposal; link it). -->

[myasnikovdaniil]

Updated the transitions comment to include Rejected alongside Superseded. Commit: 657fe1a.

[gemini-code-assist]

To maintain a consistent document structure across all proposals, it is better to keep the "Scope and related proposals" section even if empty, using a placeholder like "None". This confirms the author has considered the scope.

Suggested change

	another, say so. Omit the section if there are no related proposals. -->
	another, say so. If there are no related proposals, state "None". -->

[myasnikovdaniil]

Keeping the omit form — a proposal that has nothing to say about scope shouldn't reserve boilerplate for it, and a literal None placeholder tends to linger past the point where it's still accurate. The existing wording already invites authors to consider related work; if they don't call any out, a reader can take that as "none."