"Candidate Recommendation" is no longer an accurate term #402
Comments
|
@palemieux I think it's hard to say that they will never become Recommendations. It's entirely possible that some specs that are under active evolution for many years in CR eventually stabilize enough to shift into REC status. RECs are still malleable, there's just a bit more process around making changes to ensure they continuously meet the additional criteria. And there's still some value in viewing a REC, which requires two interoperable implementations, as the end state for a standard to strive for, rather than settling for a CR, which has lesser qualifications. |
What about specifications that a WG indicate will never become a REC? [edit: for clarity] |
|
I'm a bit ambivalent about this. Yes, for some groups, CR will be the intended end state, which makes the name not really appropriate. At the same time, for some other groups, CR will continue to fulfill the role it's always had, and for them it's still right. So "Candidate Recommendation" isn't perfectly descriptive of all the case it'll be used in. But I am not sure that fixing this is actually a good idea. There's a bunch of existing expectations and institutional knowledge about what it means for a spec to be at CR, and changing names would mess with that. It's not like there's no precedent with odd names for standards that are more grounded in history than in current practices. "Request For Comments" is somewhat weird and doesn't really reflect what those documents actually are. But we all know what it means, so it's there to stay. |
This comment was marked as outdated.
This comment was marked as outdated.
|
I think it is more than merely a naming issue. The CR SotD states: Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. [...] It is inappropriate to cite this document as other than work in progress. Does this still apply to technical reports that remain CRs at perpetuity? In other words, should external organizations not reference specifications that are intended to remain CRs at perpetuity? |
|
The comment about maturity is more important than the naming issue and I think it does matter. A document that doesn't get proper W3C review, but is published by a Working Group on their own with no broader endorsement is a Note. A document that does have that is a Recommendation. CR is neither one nor the other. |
|
Yes, the status question is important. We are getting closer to the IETF 'RFC' status; formally 'requests for comment' but actually what the internet runs on. CRs have more status than Notes, just as standards-track RFCs do — they are on the way to becoming standards. But they are not Recs, just as most RFCs are not Standards. |
@palemieux I agree that this is more than a naming issue. I don't think that anyone on the AB or Process CG wants to confer the same "status" to a CR as we do to REC. There are reviews that are not yet done (e.g. AC Review) so it is impossible to state that these documents have the consensus and endorsement of the W3C Community. There was an ac-forum discussion about how there is continued value to the REC status. Clearly, there will be groups that are more focused on having patent commitments and an updated view of the WGs consensus. Indeed, some may not proceed to REC. If they take that choice, they are choosing that their document doesn't need to have endorsement of W3C. That will apply in some cases. Your question about whether perpetual CRs may be referenced is therefore more complicated. Our documents are referenced all the time; even CG documents are referenced. So the issue is not whether they are allowed to be referenced. The question is what does a reference "mean". Hence, if a group wants to reference a W3C specification that is a stable reference and has the consensus of the W3C Community, they should not reference a perpetual CR. But in other cases, groups might want to reference a perpetual CR. |
|
@palemieux are you concerned that there may be specs that you want to reference as RECs, but will never get there? It seems to me, that if some in the community need a spec to get to the full REC level, that requirement should be surfaced to the WG (e.g. in the AC review of the Charter); and in that case most WGs would respect that requirement and not leave things in CR in perpetuity. |
|
@jeffjaffe My concern is with lack of clarity with what it means for a Technical Report to remain at CR at perpetuity. This concern applies to both (a) external parties that wish to reference the Technical Report and (b) W3 groups that need to choose the right path for their Technical Report. In particular:
To be sure, I do not object to adapting the requirements for publishing consensus documents within W3C. I am particularly excited by the idea of simplifying the maintenance of Recommendations. |
This comment was marked as outdated.
This comment was marked as outdated.
frivoal
added
the
AC-review
@jeffjaffe this is a worrying statement! I've never seen a Charter say "these are Rec track documents but we never intend to get to Rec". The working assumption of anyone reviewing a Charter has got to be that it is the WG's intention to get to Rec, rather than the other way around. Otherwise what's the point of having the document on the Rec track at all? Analogously, if someone says "I plan to go to the store to buy ice cream" then would you respond to say "ok go ahead, but do make sure you return with ice cream"? Concretely, it is very difficult to imagine any change to a Charter that would somehow add a stronger requirement for getting to Rec. Do you have something specific in mind? |
Sorry to be blunt @frivoal but CR being the intended end state should not be acceptable. This is like saying "the intended state is permanent lack of clarity about the status of this work in the industry". W3C should never support this as an end state for a Rec track document. Even in the "Rec snapshot of continually updated document" model there are at least fixed points of clarity. |
|
@nigelmegitt I think your response to Florian answers your question to me. In your response to Florian you state that CR should never be the intended end state. But Pierre points out that some groups might do exactly that. In some respects, that happens today - we unfortunately have many specs that have languished in CR for too long. My simple response is that if a stakeholder sees that happening - a spec stuck in perpetual CR - and if they need (e.g. for referenceability) that the spec go through full W3C endorsement - they have an opportunity to drive for such a commitment in Charter review. For example, they can object unless a particular mature snapshot be taken immediately to PR. |
|
@jeffjaffe sorry I don't follow: how would Charter review, when there may only be an FPWD, or a mere concept for a specification, be an effective time to press for a push to Rec?
There's some relief here due to the slightly reduced typical Charter period, which means that re-Charters have to happen typically every 2 years or less. Let's imagine that during a re-Charter, an existing spec that has been in CR for a long time were highlighted and a request made to add some language to the Charter asking the WG to push ahead for CR exit. That still doesn't make anything happen, as far I can tell. |
|
@nigelmegitt I agree that for a new spec that is in FPWD, an AC rep should not complain that it has been in perpetual CR for too long. That is not the right time to object. You are correct, that the time to catch it is when a spec has been in perpetual CR for too many years (from the pov of the AC reviewer). You are also correct that an AC reviewer cannot force a perpetual CR into REC in P2020 any more so than they can today. But I believe that if the AC community expresses their view that this is needed, that the W3C would find a way to bring the spec to REC - much as we are bringing WHATWG Review Drafts of HTML to REC. |
|
Also, as @fantasai has pointed out, while the process to maintain a "living standard" at REC is heavier than it is for a CR, P2020 makes that possible too. Groups that favor a living standards approach have no less interest than everybody else in high quality specifications (and the criteria about the spec itself for getting to CR are as high as for REC, the difference is in terms of implementation experience and AC review). So once a spec is good enough to go to REC, and the rate of change is low enough because the technology is mature, and there is demand for a REC, it's not completely out of the range of possibility that "living standards" oriented group could still go to REC, and continue maintaining the spec in that state. It just isn't their priority (and isn't expected to be for quite a while). But that path remains open. |
|
Given that (a) you can maintain in Rec as well as in CR and (b) anyone can ask/push for a Rec transition if it's needed, I would surmise that the reason a document stays in CR semi-permanently is because the WG and the community are comfortable with it. There are some documents where there is a gentle trickle of updates and no obvious updates that are 'more significant' and would by themselves trigger a Rec. transition. But anyone can ask, and the AC could (effectively) insist. |
|
@frivoal wrote:
@dwsinger wrote:
The problem I think we have is that specs are staying in CR, and being normatively referenced, when they clearly are not verified as being good enough to go to REC, because the CR Exit Criteria have not been met, but that the WG is comfortable with the situation. That does not equate to the community being comfortable as well, but it's hard to gauge the impact of this. My guess is that folk will vote with their feet and the W3C will lose relevance. That's why it's a Process issue. I agree with @palemieux at #402 (comment) and I don't think the solution is to promote CR to being the new acceptable end state. |
Maybe the document is good enough to go to Rec but the WG chooses not to. We shouldn't guess. They may feel the time isn't right, or that there is no particular time that is more right.
But there are other ways the community can vote with their feet as well, and the W3C lose relevance. The high nail today is that we suck at staying current, and doing maintenance, and the community is voting with their feet and finding ugly workarounds.
I don't think we're either promoting it or deprecating it. We've had long-lived CRs for years; we're not changing that. We've had the ability to ask for a Rec. transition to occur; we're not changing that either. |
Has the process CG documented the reasons WGs do not to proceed to REC?
If a perpetual CR in an acceptable end state, then the process should make this explicit. |
Not formally, but in my experience WGs don't go to REC because of one or more of:
Taking a spec to REC is a lot of work. The AC can stamp its feet and say anything it wants in the charter, but a WG isn't going to take the spec to REC unless someone puts in the work. However, if some community wants that work to happen, I'm sure any WG would be happy to support such efforts. Everyone wants better quality specs, tests, and implementations. |
@dwsinger The suggestion here is that the spec has passed all the exit criteria but the WG deliberately delays requesting transition to PR. I can buy that for a matter of weeks, but not months or years. Are there any examples?
@fantasai exactly right. My proposal at #406 (comment) would change the dynamic by moving the cost or penalty of inaction to the WG, where currently it is a reputational cost to W3C as a whole. The hope would be that this encourages (funding of) work to address the open issues or the QA work, since the alternative is to reduce the value of the existing investment.
If this is genuinely holding up specs then it sounds like the WG is holding their spec up to a higher standard than is required for getting to Rec - my understanding is that CR exit criteria must minimally demonstrate implementability of each feature, and that the implementation report need not consider interoperability per se. This could be another point to address via a clarification in the Process.
Sorry, I think this is unrealistic. There's barely any chance that a community wanting a spec to be a Rec, e.g. to get a clearer view of its status, will step in and start doing QA work in it, since they will always expect the community that owns the spec to do that. |
I think we've had cases where the spec. as it is, actually could go to Rec. but that the WG feels it shouldn't until some feature or missing functionality is addressed. I don't know. It would take team/chair conversations to find examples. |
|
The SOTD doesn't ask that external organizations NOT reference; it says it's inappropriate to reference other than as a work in progress. That's true for an evolving CR, aka Living Standard. There is no such thing as "perpetual"; all we know is the current state and the past; the future is uncertain. I don't see a problem with a slightly quaint term; no more quaint than the IETF 'requesting comment'. And it's not even wrong; it could be proposed to move to recommendation. I don't think either suggestion is appropriate: changing the name CR would be moving away from a term we are known for an know well. Calling CRs Recommendations would be... wrong/strange. But we should pay close attention to the SOTD boilerplate. I believe that the SOTD is the place to fix this. |
@dwsinger These two sentences seem to highlight a possible difference of world view: getting to alignment might really help us to move forward:
|
We already support normative references to WHATWG HTML Living Standards when that is the most appropriate reference. |
In general, I think any possible replacement we might consider could be misinterpreted in some way. But I think Candidate Recommendation is relatively more prone to being misinterpreted than Working Group Specification.
That’s not a possible misinterpretation that had occurred to me, no. But to me at least, it anyway doesn’t seem like a misinterpretation that would happen very commonly. And even when it did happen that some person initially misinterpreted it like that — it’d be a one-time misinterpretation that would get dispelled very quickly, in a moment when they Aha! realized what it actually meant. Contrast that to Candidate Recommendation being prone to a very different kind of ongoing misinterpretation — which goes on creating problems and confusion that can’t be cleared up in someone’s mind in a single Aha! moment of realization.
That seems like a bit of stretch. I at least find it very unlikely that anyone in practice would imagine a “draft” Working Group… |
Not good, because an implicit goal of the proposal — based on trying to get some resolution among at least the set of people who have commented here — is: completely stop using Recommendation to refer to stages/states that aren’t actually Recommendations (that is, things that aren’t formally/fully endorsed by the W3C organizationally — the W3C membership).
Something relatively-more arcane/esoteric like that doesn’t seem to me at least like it’d be a choice that’s likely to reduce confusion. That feels like it’d increase confusion — it would increase the amount of time/documentation we’d need to spend explaining what we mean. Working Group Specification, on the other hand, is something that we and others already use informally when referring, well, to the specifications that our working groups produce. We don’t need to explain to people what it means — it doesn’t increase confusion, and doesn’t have the problem of being inaccurate at all. |
I definitely see your point there. However it seems like Last Call for Comments and Implementations (or similar) would be a bit unwieldy. But regardless, it’d be a non-starter as far as trying to resolve to issue-author/commenter satisfaction the problem in the issue description here — and which is further amplified on in some of the discussion comments: Which is, we need something that’s also accurate in the face of the “living standard” or “evergreen” option that W3C now provides. And for that, Last Call for Comments and Implementations seems at least as inaccurate as Candidate Recommendation was. |
Also, Working Draft → Working Group Draft (sort of) Fixes #402
That’s actually not the most-precise way to describe what we need. A perhaps-more-precise way to describe what we need is:
And so, given all that, we need something that’s also accurate in the face of that “does not intend to advance their documents to Recommendation” option that the W3C allows as a choice for WGs. |
|
So, the term Candidate Recommendation objectively is not accurate in the face of the facts outlined in #402 (comment). And beyond being not accurate in that case, Candidate Recommendation is actually actively misleading — and arguably even actively harmful — in that, for example and to quote verbatim some words from a related discussion elsewhere, it can (mis)leading people into assuming wrong conclusions such as “the document is heading towards a W3C-wide consensus”. But it is impossible for “does not intend to advance their documents to Recommendation” specifications to at the same time also ”heading towards a W3C-wide consensus” specifications. So rather than a Candidate Recommendation, a more-accurate name for those cases would be something like: But a name like Not Headed for Recommendation — or whatever actual less-silly name we might try to find to accurately name that case — would of course not all accurately cover the other case — the case of specifications which really are “heading towards a W3C-wide consensus” or “heading towards Recommendation”. Hence, we really need a single name that can at least not inaccurately describe either case — and that can at least not be actively misleading and at least not arguably even actively harmful. And Working Group Specification seems to satisfy those requirements. |
|
I agree with the intent to separate the 'document headed to REC', namely a Candidate Recommendation, from a 'living something until whenever we decide to move on', which has no specific name. But IMHO it's not just a naming issue. The expectations need to be clearer in terms of wide review of substantive changes and also implementation requirements (currently basically no requirement at all after publishing a CRS for the first time). |
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, 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. |
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. |
|
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. |
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. |
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 #402 (comment) for example. |
|
Could somebody with the relevant powers re-open this issue? |
"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. |
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. |
…eration Fixes #402. This change makes “Candidate Recommendation” an accurate term even in the case where a Working Group has indicated they don’t intend to advance to REC.
|
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. |
@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. |
|
@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. |
|
@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? |
|
@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. |
|
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. |
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:
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”. |
|
If you add the 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:
I believe this meets all the requirements for an "evergreen" or "living" spec that you outlined @sideshowbarker - did I miss any? |
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:
The text was updated successfully, but these errors were encountered: