From 5d0d5a3981f08cbf515a4f0a54e5550c7782a8ef Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Thu, 6 May 2021 13:41:08 +0100 Subject: [PATCH] Clarify what happens when a concern is raised during FCP (#3180) It wasn't entirely clear what should happen to the FCP timer (and state) when a concern is raised during FCP. After some discussion, we agreed that when a concern is raised: 1. FCP will continue to not conclude until at least 5 days have passed, but once those 5 days are up it *still* won't conclude until all concerns raised during FCP are resolved. 2. If a concern warrants a large enough change in the document, then the Spec Core Team may consider cancelling FCP and restarting the timer in order for people to have some time to think about and review the new changes. --- content/proposals.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/content/proposals.md b/content/proposals.md index 28cb670c..d724f308 100644 --- a/content/proposals.md +++ b/content/proposals.md @@ -245,10 +245,13 @@ is as follows: 75% of the members of the Spec Core Team agree on its outcome, and all existing concerns have been resolved. - The FCP will then begin and last for 5 days, giving anyone else some - time to speak up before it concludes. On its conclusion, the - disposition of the FCP will be carried out. If sufficient reasoning - against the disposition is raised, the FCP can be cancelled and the - MSC will continue to evolve accordingly. + time to speak up before it concludes. If sufficient reasoning + against the disposition is provided, a member of the Spec Core Team can + raise a concern and block FCP from completing. This will not reset or + pause the 5 day FCP timer, but FCP will not conclude until all concerns have + been resolved. If sufficient change in the MSC is required to resolve those + concerns, FCP might be cancelled and reproposed. Once FCP has concluded, + the disposition of the FCP will be carried out. - Once the proposal has been accepted and merged, it is time to submit the actual change to the Specification that your proposal reasoned about. This is known as a spec PR. However in order for the spec PR @@ -373,7 +376,7 @@ be merged without the Spec Core Team focusing on them specifically. ## Implementing a proposal -As part of the proposal process the spec core team will require evidence +As part of the proposal process the Spec Core Team will require evidence of the MSC working in order for it to move into FCP. This can usually be a branch/pull request to whichever implementation of choice that proves the MSC works in practice, though in some cases the MSC itself will be