"Candidate Recommendation" is no longer an accurate term

[palemieux]

The term Candidate Recommendation accurately and literally describes the state of a technical report that is expected to become a Recommendation.

Process 2020 explicitly contemplates technical reports remaining Candidate Recommendation at perpetuity, but being regularly revised (as a Candidate Recommendation Snapshot or Candidate Recommendation Draft).

The term Candidate Recommendation hardly describes these specifications, which will never become Recommendations.

Suggest either:

• selecting a different term to identify these technical reports that never become Recommendations; or
• change the Recommendation criteria such that these technical reports are considered Recommendations.

[dwsinger]

Serious consideration should be put into revisiting this issue.

The arguments by @palemieux in the issue description and in his other comments are objectively compelling, and specifically the statement “"Candidate Recommendation" is no longer an accurate term” is objectively correct.

Organizational inertia seems to be the only thing collectively making us (me too) want to keep clinging to the Candidate Recommendation term despite the strong evidence we have for the confusion and potential for confusion it creates.

I think maintaining consistent and known naming is a strong reason not to change names. For example, it's pretty clear no-one (or very few) comment on IETF RFCs – indeed, the whole internet runs on them, with very few becoming internet standards. For better or worse, our specs are known as "recommendations" and we should not diverge casually.

[TallTed]

I don't think changing "CR Draft" to "Working Group Specification" makes sense.

With everything else in play here, "CR Draft" might reasonably be changed to "Working Group Specification Draft".

Naturally, this then collides with "Working Group Draft" changing to "Working Group Draft", which I just suggested in a nearby thread would be better to become "Working Group Specification Draft".

There are too many threads discussing approximately the same points. If the name of any document status is going to change, that change must be considered in context of all the other names. If multiple names are going to change, those changes must be considered together, i.e., in context of all the other names including changes. Changing any number of status names without putting those changes in full context of all status names will continue to result in collisions like those above.

[caribouW3]

it’s just “living something”, with intentionally nothing else conceived to ever move on to, but instead a plan to just indefinitely continue maintaining that “living something”, at the stage with whatever name we label that for them in our process.

Nothing in the process prevents from maintaining a REC forever (quite the contrary, with all the possible classes of changes it proposes), so groups staying in CR forever also intentionally stay away from the "go to REC" step. This issue is not meant to debate about that, although choosing a naming for those specs should, if possible, clearly convey that the interop criteria have not been verified.

[nigelmegitt]

, so groups staying in CR forever also intentionally stay away from the "go to REC" step. This issue is not meant to debate about that, although choosing a naming for those specs should, if possible, clearly convey that the interop criteria have not been verified.

Several folk have read the issue title and thought it was only about naming, but to me it's clear that's not really the core of the issue. It is at least in part about debating the impact of perpetual CRs and how to express that scenario in our publications - see https://github.com/w3c/process/issues/402#issuecomment-632781320 for example.

[hober]

Could somebody with the relevant powers re-open this issue?

[frivoal]

To be clear about one thing: In many or most of the actual WG cases I’m aware of, there’s no “until whenever we decide to move on” — that is, it’s just “living something”, with intentionally nothing else conceived to ever move on to

"ever" is a long time, significantly longer than the typical 2-year charter. A CR not currently intending to move to REC might change in a subsequent charter. And while the AC has been happy to bless charters which contain an explicit statement that the WG under that charter does not intend to move to REC, I think you'd get a different kind of feedback if the statement was about documents that cannot ever go there.

[sideshowbarker]

And while the AC has been happy to bless charters which contain an explicit statement that the WG under that charter does not intend to move to REC, I think you'd get a different kind of feedback if the statement was about documents that cannot ever go there.

You’re clearly right

But did I suggest somewhere that any WG charter should contain an explicit statement saying “we won’t ever go to REC”?

I personally at least would never put such an explicit statement in a charter — because in general, I want WGs to have more choices and flexibility with what they do with the process, not less.

So yeah, I agree with you 100% it’d make zero sense to put “we won’t ever go to REC” in a charter.

Furthermore, I’d personally even prefer not being required to put even that “does not intend to advance their documents to Recommendation” language into charters — because as far as I can see, the process doc as currently already gives WGs the right to do that if they so choose; the process doc doesn’t require them to have that language in their charter in order for the WG to exercise that choice, that right.

So yeah, what I’d prefer ideally is that we completely drop even that “does not intend to advance their documents to Recommendation” language from charters.

[rossberg]

Speaking as the editor of the WebAssembly spec, I have to agree with @sideshowbarker. The Wasm WG has been switching to the "evergreen" model with version 2, which IIUC, in terms of W3C process means that it has no intention of ever moving the doc out of "candidate" status again.

Yet, don't forget that 98% of the target audience of such a standard are not familiar with the idiosyncrasies of W3C. They will see the document marked "candidate" and conclude that this is not the real thing they should use or cite, when in fact it is. They will only find the vastly outdated Wasm 1.0 as a proper Recommendation and conclude that it still is the current official standard. I regularly observe similar misunderstandings about the Wasm standard's status.

So yes, the label of "candidate recommendation" is actively misleading and harmful when it comes to the evergreen model.

AFAICS that does not mean that there's a need to rename any of the current status labels. From my naive perspective, it would suffice to introduce an additional one to stick on evergreen/living standards while keeping the others alone.

[nigelmegitt]

IIUC, in terms of W3C process means that it has no intention of ever moving the doc out of "candidate" status again

@rossberg What is stopping you from making it an updateable Recommendation, i.e. one that allows new features, and then making update requests to change the Recommendation in-place? Then you could be out of "candidate" and the target audience will see that it has the stamp of "W3C Recommendation" while also being able to see updates, either proposed or agreed.

[rossberg]

@nigelmegitt, well, my understanding is that the evergreen option exists. So isn't that question besides the point? The Wasm WG (and apparently other WGs) decided to go with it for various technical, procedural and practical reasons. Given that the option exists, the branding of the documents produced by it should obviously reflect it in a suitable manner, regardless of other considerations.

[nigelmegitt]

@rossberg I think I'm querying what you mean by "the evergreen option" - it's not an actual process term as far as I know, and my understanding is that an updateable Rec should be accepted as an "evergreen" spec.

So the question is, what is stopping you from using that approach - is it only because your understanding of "evergreen option" is an everlasting CR, which is a definitional issue, or is there something about Updateable Rec that you are predicting will cause difficulties?

[rossberg]

@nigelmegitt, isn't the fact that it is not a process term yet (or some equivalent) the very problem that this issue is about? The process appears to have the option that we colloquially refer to as the "evergreen" or "living" spec (that is not an Updateable Rec IIUC) and that various WGs opt for, and I assume folks in this discussion have a common understanding of what it means technically (better than I do). Yet W3C terminology does not adequately reflect and acknowledge its existence. That is not helpful to the target audience.

[nigelmegitt]

In my understanding, Updateable Rec is the option for having an "evergreen" or "living" spec. It's your assertion @rossberg that it is not, but I don't know why you are asserting that - hence my question.

[sideshowbarker]

In my understanding, Updateable Rec is the option for having an "evergreen" or "living" spec.

To clarify a couple things:

“Updateable Rec” — like “evergreen spec” or “living spec” — also isn’t a term that’s defined in the Process document. It’s your assertion that there is such a thing that has the characteristics you describe.

But whatever it may be, it is strictly and objectively not the option for having an “evergreen” or “living” spec — because there is another thing that the Process doc does actually explicitly define with the term Candidate Recommendation Draft, at https://www.w3.org/policies/process/#candidate-recommendation-draft, and about which the Process doc says this:

the process requirements are minimized so that the Working Group can easily keep the specification up to date

And that Candidate Recommendation Draft thing is the only thing about which the Process doc uses that language — and the Process doc doesn’t use any language similar to that to describe any other thing.

So one can imagine that editors of specifications and other stakeholders in working groups may find the qualities of “process requirements are minimized” and “can easily keep the specification up to date” to be desirable qualities — and that it’s quite understandable and quite reasonable that their groups might make a decision to choose the option that the Process document highlights as having those qualities.

And one can also imagine that anybody in a group which has made that choice may not be super interested in being asked after the fact to provide any rationale for having made that understandable and reasonable choice rather than choosing some other thing that the Process doc doesn’t describe as having the qualities of “process requirements are minimized” and “can easily keep the specification up to date”.

[nigelmegitt]

If you add the updateable-rec class to the SOTD of a Respec document, it changes it into a Recommendation that "allows new features", and you're right, I used the class name as a shorthand for the actual Process definition.

Recommendations of this kind can be updated in place with Candidate Additions that are marked up as such, still with minimal process requirements - they require a working group decision. There's even a specific note about this:

Note: Annotating changes in this way allows more mature documents such as Recommendations and Candidate Recommendations to be updated quickly with the Working Group’s most current thinking, even when the candidate amendments have not yet received sufficient review or implementation experience to be normatively incorporated into the specification proper.

I believe this meets all the requirements for an "evergreen" or "living" spec that you outlined @sideshowbarker - did I miss any?