Retire Proposed Recommendation

[frivoal]

As discussed in #861, the Proposed Recommendation phase of the REC track exists only to support an AC Review during the transition of a document from CR to REC. We can simplify the Process a good deal by doing away with Proposed Recommendation entirely, and doing the AC Review on the CR that we want to promote to REC. Then, if the AC Review is successful (in addition to the other criteria), we could publish the REC directly.

This Pull Request does just that. It keeps all the criteria that were present at the CR→PR transition, as well those of the PR→REC transition, and combines them into a CR→REC transition.

This allows for a simplification of terminology, a simplification of Process text, a reduction in the number of states described in the REC track diagram, and a reduction of work needed by the WG and the Team (one transition to request instead of two, one less publication to make); all without any changes about what is expected of a Recommendation.

---

Preview | Diff

[chaals]

Looks like a good draft (on a skim of the github diff rather than a very careful review, so faar).

[TallTed]

Editorial language improvements.

[frivoal]

Editorial language improvements.

All accepted. Thanks!

[frivoal]

From the AB's last meeting:

RESOLUTION: The AB is interested in pursuing the retirement of the Proposed Recommendation Phase, and asks the Process CG to work out the details.

[nigelmegitt]

This also made me wonder: can Registries actually include any content that, if changed, would count as a Class 4 change?

[nigelmegitt]

Would it be worth keeping a stub definition for this, in case people are looking at old PRs on /history and want to know what they are?

[frivoal]

The id is reserved, so that links will still land in a reasonably relevant place. That place does not mention Proposed Recs explicitly though:
https://github.com/w3c/process/pull/868/files#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985R3885

I see your point, but at the same time, because Proposed Recs are only an transient state, it's not that common for people to be reading them once the relevant AC Review has closed.

We don't keep a stub definition for Last Call Working Draft either.

Maybe we could add an Appendix to the Process listing all the TR statuses that no longer exist, with pointers to older version of the Process that still had them? Not sure if this would be useful, or just make the Process longer for little benefit.

[nigelmegitt]

Looking back through /history I see that some SOTDs include a hyperlink from the maturity stage term to its definition in the applicable Process document, e.g. XML1.1 PR but others do not, e.g. HTML5 PR. For those that do not, it would be useful to include this appendix.

[frivoal]

As discussed on the Process CG call this week, I've created a pull request to handle this kind of stub definitions: #898.
If that PR is adopted, I'll add an entry there for Proposed Rec in this PR.

[nigelmegitt]

Except for removal of at-risk features.

[frivoal]

True. However, is that too much detail for an example? We could add it as a parenthetical, but I am not sure if it really brings clarity.

[nigelmegitt]

I don't think it's too much detail. Without mentioning this, it looks like the example contradicts the Process, and that could be confusing for some group later if they do want to remove at-risk features at this stage.

[nigelmegitt]

This is too broad a restriction - it is permitted if going back to CR and then to Rec, but reading this, it looks like that route is also blocked.

[frivoal]

It is indeed blocked, and that's not new (this text is moved, not introduced).

• Prior to Process 2020, if a document has made it to REC, you cannot add new features to it, even by going back to CR or WD. You must start a new one. See https://www.w3.org/2019/Process-20190301/#revised-rec:

  To make changes which introduce a new feature or features, W3C must follow the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

• From Process 2020 onward:
  • the same is true of specs that do not carry the "allows new feature" text. See https://www.w3.org/2020/Process-20200915/#revised-rec-features:

    To make changes which introduce a new feature to a Recommendation that was not approved for accepting new features, W3C must create a new technical report, following the full process of advancing a technical report to Recommendation beginning with a new First Public Working Draft.

  • specs that do carry the "allows new feature text" can gain new features, but that text must be added prior to the spec reaching REC for the first time. See https://www.w3.org/2020/Process-20200915/#transition-pr:

    A Proposed Recommendation may identify itself as intending to allow new features (class 4 changes) after its initial publication as a Recommendation, as described in § 6.2.11.4 Revising a Recommendation: New Features. Such an allowance cannot be added to a technical report previously published as a Recommendation that did not allow such changes.

The goal is to provide a guarantee to external users: as has always been the case, if you see a REC that does not carry any mention about allowing new features (and no pre-2020 REC has that), you can depend on subsequent publications of the same REC not adding new features. Whether this is a good idea is something we can debate, but that's orthogonal to this Pull Request, so if you want a discussion on this topic, I'd request filing a new issue.

[nigelmegitt]

Oh, right, I think the confusion here is that you (and the Process) would consider a new version of an existing REC to be a new REC (which is technically correct), whereas a lot of readers would think of it as the same REC with some additional features. Perhaps it would be helpful to add a note here that features can be added to existing RECs that do not "allow new features" by generating a new version.

[nigelmegitt]

I cannot apparently un-resolve this comment thread, but that's what I'd like to do right now, given my previous comment.

[frivoal]

I cannot apparently un-resolve this comment thread, but that's what I'd like to do right now, given my previous comment

Done.

Perhaps it would be helpful to add a note here that features can be added to existing RECs that do not "allow new features" by generating a new version.

That statement exists as the last paragraph/sentence of https://www.w3.org/policies/process/#revised-rec-features. I am hesitant to make the Process longer by having various parts repeat what other parts already say. Short notes in the right context pointing to longer requirements elsewhere can helpful on occasion, but here I'm not sure how to have something that's useful enough while keeping things short enough.

[nigelmegitt]

I think a useful note here would be a reminder that new versions (with new version numbers) of existing Recs count as new technical reports. That's not present in the linked section on new features either.

[TallTed]

Editorial, grammar and such

[plehegar]

One clarification might needed. To elevate a Note to a Statement, we have "During this review period, the Note must not be updated."

Is the Working Group allowed to update the CR while the review is ongoing ?

[nigelmegitt]

One clarification might needed. To elevate a Note to a Statement, we have "During this review period, the Note must not be updated."

Is the Working Group allowed to update the CR while the review is ongoing ?

[at first I was confused by this because the Note track is orthogonal to the Rec track, but on third reading I understood that you're using the quoted text as an example to carry across into the Rec track]

My reading of the bullets in §6.3.9 is that certain changes are possible, but I guess your question is more about when they can be made?:

• must show that all issues raised during the Candidate Recommendation review period have been formally addressed.
• must identify any substantive issues raised since the close of the Candidate Recommendation review period.
• must not have made any substantive changes to the document since the most recent Candidate Recommendation Snapshot, other than dropping features identified at risk.
• may have removed features identified in the Candidate Recommendation Snapshot document as at risk without republishing the specification as a Candidate Recommendation Snapshot.

[frivoal]

Is the Working Group allowed to update the CR while the review is ongoing ?

The review needs to be on a specific dated version of the document, I don't think a moving target can be reviewed. https://www.w3.org/policies/process/drafts/#ACReviewAfter provides some avenues for (limited) changes after the review, but to me, the review itself must be on a specific version.

Do you think additional text is needed to call that out? The current text seems sufficient to me, but we could add a simple explicit clause, like:

[=Working Groups=] must not [=publish=] any updated version while the [=AC Review=] is ongoing. If the review surfaces any desirable change, they must be handled according to the provisions of [[#ACReviewAfter]].

[tantek]

Good overall simplification (removing Proposed Recommendation), and specific simplifications, plus fixes to a bunch of details/nits.

I could see places for further improvement, however, this PR (so to speak) is worth merging in on its own merits, and then we can suggest additional improvements.