Clarify Final Comment Period status in the core/README - #1979
Conversation
There was a problem hiding this comment.
Pull request overview
Clarifies the CAP lifecycle wording in core/README.md by making the Final Comment Period (FCP) explicitly indicate its intended disposition (Acceptance vs Rejection), reducing ambiguity in CAP statuses across the spec docs.
Changes:
- Replaces the ambiguous “FCP: [Acceptance/Rejection]” terminology with “Final Comment Period: [Acceptance/Rejection]” and clarifies the transition outcomes.
- Updates the CAP-0085 entry in
core/README.mdto use the new explicit FCP disposition. - Synchronizes CAP-0085’s preamble
Statusfield with the README index entry.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| core/README.md | Clarifies workflow/status terminology and updates CAP-0085’s indexed status to include intended FCP disposition. |
| core/cap-0085.md | Updates the CAP preamble Status to match the README’s explicit “Final Comment Period: Acceptance” status. |
|
I would just replace it with "Final Comment Period" as this is how we've been using in the past and how it's referenced in the document anyways |
Removed the disposition from the FCP status. Those will now have to be inferred from the discussion thread. |
anupsdf
changed the title
Pull request was converted to draft
| intended disposition. After one week has passed, during which any new concerns should be | ||
| addressed, the CAP will head towards its intended disposition [**Acceptance/Rejection**] or go | ||
| back into a Draft state. | ||
| intended disposition of Acceptance or Rejection for the Final Comment Period, or go back into a |
There was a problem hiding this comment.
the reference to "Acceptance or Rejection" is misleading the next state is called "Final Comment Period" or "Draft"
There was a problem hiding this comment.
Yeah, its not very clear. The way I understood this workflow is that before rejecting a CAP, we want it to move to Final Comment Period for a week. Since, we don't have a sub-status field there is no way to capture the intended disposition of acceptance/rejection when a CAP is in Final Comment Period.
Should we change the workflow so that rejected proposals go from Awaiting Decision to Rejected instead of parking in FCP for a week?
There was a problem hiding this comment.
I think it's important to give poor disposition proposals the same week to volley final arguments as popular ones. That way, we have a full history of why something failed, and we can move on from it with confidence.
I also think we should add a line explaining the edge case of moving from FCP to Draft, which has historically been around blocking changes. Like: "...back into a Draft state, if, for instance, implementation depends on other new CAPs."
There was a problem hiding this comment.
Another option would be to add a Notes (or Comments or Remarks) field to the CAPs that can capture the intended disposition of acceptance or rejection for CAPs going from Awaiting Decision to Final Comment Period. This would help in both cases,
- Capturing the rejection reason when CAPs are in FCP but headed towards Rejected, and
- Capturing comments when moving from FCP to Draft.
Thoughts?
what
Clarify Final Comment Period: Acceptance or Rejection in the core/README.
why
To remove ambiguity around the status of CAPs.