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.
This commit is contained in:
parent
a5fea91d86
commit
5d0d5a3981
1 changed files with 8 additions and 5 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue