There have been at least two recent working group charters that have opted to continuously update CR drafts without intending to move to the Rec stage:
Both charters mention that new features need (at least an intent for) two implementations, tests, and implementation reports
When things progress to Rec, there is a well-defined point where the implementation report shows whether two or more implementations are interoperable, and we have a well-defined process for dropping features that do not meet this requirement.
I think it’s unclear when (or if!) features should be dropped from a continuously-updated CR. I think it would be good to have some loose guidance that each group can adapt for their own workflows. Perhaps something like:
Features without two implementations, tests, and a passing implementation report should be marked at-risk before updating CR
Features that continue to be at-risk at a CR update should be re-evaluated, and dropped from the CR if it has become less likely that they will ever pass an implementation report.
There have been at least two recent working group charters that have opted to continuously update CR drafts without intending to move to the Rec stage:
https://w3c.github.io/charter-drafts/sw-2020.html https://www.w3.org/2021/03/proposed-bbtt-wg-charter.html
Both charters mention that new features need (at least an intent for) two implementations, tests, and implementation reports
When things progress to Rec, there is a well-defined point where the implementation report shows whether two or more implementations are interoperable, and we have a well-defined process for dropping features that do not meet this requirement.
I think it’s unclear when (or if!) features should be dropped from a continuously-updated CR. I think it would be good to have some loose guidance that each group can adapt for their own workflows. Perhaps something like: