Going from Candidate Changes to Proposed Changes

So this explanation seems helpful. And we need wide review *and 
*implementation of the Candidate Changes /before /promoting them to 
Proposed Changes; it will be checked that we have done this.

>
>       Updating Recommendations
>
> Updating a Recommendation with a change happens in two publications:
>
>  1. Annotate the Recommendation with the candidate change and
>     republish it with Echidna. (It must be clear to everyone reading
>     the document both what the current state of the text is, and
>     exactly what it will be if the change is adopted. See README
>     <http://fantasai.inkedblade.net/style/design/w3c-restyle/2020/readme#amendment>
>     for markup conventions.)
>  2. Periodically (not more than twice a year, to avoid aggravating the
>     lawyers and the AC), collect a set of candidate changes that have
>     received wide review, are interoperably implemented, etc. and are
>     therefore at the same level of quality and completeness as the
>     rest of the Recommendation, and have your Staff Contact issue a
>     Last Call for Review of Proposed Changes. This triggers the call
>     for exclusions and kicks off the AC review period, among other things.
>  3. If no problems were found during the review, incorporate your
>     changes into document, and issue an update request
>     <https://github.com/w3c/transitions> (similar to a CR Snapshot
>     update request) to republish your Recommendation.
>
https://www.w3.org/wiki/Process2020#Updating_Recommendations

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media