docs(design-proposals): mark merged proposals as Accepted#34
docs(design-proposals): mark merged proposals as Accepted#34Aleksei Sviridkin (lexfrei) wants to merge 1 commit into
Conversation
The process already defines the terminal status of a merged proposal. template.md records the transition Draft -> Review (PR opened) -> Accepted (merged), and README.md states that a proposal is "merged and considered accepted" once it reaches consensus. No merged proposal currently reads Accepted, so the front matter of every one of them contradicts the process that merged it. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <f@lex.la>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughFive design proposal README files update their metadata status to Accepted, replacing either Draft or Review. ChangesDesign proposal status updates
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the status of several design proposals—including ComputePlane, External database exposure, Migrate kubernetes workers to Talos, OIDC for tenant Kubernetes clusters, and Unified TLS and PKI model—from 'Draft' or 'Review' to 'Accepted'. There are no review comments, and I have no feedback to provide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
IvanHunters
left a comment
IvanHunters
left a comment
There was a problem hiding this comment.
Verdict
LGTM
Summary
Pure front-matter edit: flips the Status field of five already-merged design proposals to Accepted. No code, charts, templates, or CI touched.
The change is correct against the documented process, which is unambiguous on this point:
design-proposals/template.mddefines the lifecycle asDraft → Review (PR opened) → Accepted (merged).design-proposals/README.md(Approval Process): once a proposal gets maintainer consensus "it will be merged and considered accepted."
All five proposals are on main, i.e. merged, so all five should read Accepted. There is no defined state in the lifecycle for a merged-but-Draft proposal.
On the open question (the three Draft ones)
The PR body asks whether the three Draft proposals should stay Draft because they were "merged early and iterated on main" (e.g. compute-plane took follow-up commits). Per the documented process, no:
- The lifecycle has no "merged, iterate on main, keep Draft" branch.
Draft/Revieware pre-merge states only. - Post-merge edits are exactly what the
Proposal Driftsection covers: divergence after merge is "normal and expected," the codebase is the source of truth, and the proposal remains a reference. Drift does not send a merged proposal back toDraft.
So flipping all five to Accepted is the right call, not just the two Review ones. The current mixed Draft/Review state is drift from the process, and this fixes it.
Findings
None blocking.
Nits (non-blocking)
- Consider a short follow-up to
README.mdmaking explicit that "merged ⇒Accepted, regardless of the pre-merge status field" so this metadata drift does not recur. The template's transition comment implies it; the README could state it directly. Not required for this PR.
Caveats
- Verified only that the five edited files each changed exactly the one
Statusline and nothing else (diff confirms-Draft/-Review→+Accepted, one line per file). Correctness of the classification rests on the documented lifecycle, which I read in full (README.md+template.md). - Upgrade / fresh-install impact: N/A — documentation repo, no shipped artifacts.
2 participants
The design-proposal process already defines the terminal status of a merged proposal, but no merged proposal actually carries it.
design-proposals/template.mdrecords the transition asDraft → Review (PR opened) → Accepted (merged), anddesign-proposals/README.mdsays a proposal "will be merged and considered accepted" once it reaches consensus. Today all five merged proposals still readDraftorReview, so the front matter of every one of them contradicts the process that merged it.This flips all five to
Acceptedand changes nothing else.unified-tls-pkiexternal-database-exposurecompute-planekubernetes-nodes-splittenant-oidc-per-tenant-realmThe two
Reviewones are unambiguous: PR opened →Review, LGTM → merge →Accepted, exactly the transition the template describes.The three
Draftones I am less certain about, so I would rather ask than assume. They were merged while still markedDraftand then edited further onmain—compute-planetook two follow-up commits after its initial merge. If that is a deliberate "merge early, iterate on main" pattern andDraftis carrying real meaning there, say so and I will drop those three, leaving only my two. If it is drift, this fixes it.Summary by CodeRabbit