Process should ask or maybe require folks requesting a document transition to CR to describe why/how they think the document is likely to exit CR

[hober]

(This might be a retread of #32 or #172; if so, apologies.)

As @palemieux said in #402 (emphasis his),

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

Sometimes specs languish in CR for years because they don't meet the criteria for transition to REC. Sometimes it's relatively well understood in the wider community that a spec will not meet those criteria; that CR is as far as it will go. (See also #443.) It can be difficult to get people who have put lots of effort into a spec over a long period of time to accept that & agree to park the document as a Note. We are all human, and the sunk cost fallacy is extremely easy to fall into.

I think it could help if, when a document transition to CR is requested, the requestor is expected or encouraged to state why/how they think the document is likely to exit CR. We're often focused on the transition directly in front of us, the move to REC is off in the future somewhere, so it's easy to avoid seeing roadblocks in your future that are beyond your current time horizon.

[cwilso]

I can't tell if this is about community acceptance (#32), implementation experience (also #32), specs of poor quality or that are just dead ends (#172), or perpetual-CR-mode (#402/#443) (aka "IF you expect to exit CR"). It's certainly a plus to ask for introspection; sometimes that answer is going to be factors outside the WG's control.

[dwsinger]

I like the general idea: tell us about how and when you expect to exit CR, if ever. But then I ask: is this just busy-work, because if there are no 'bad answers' to the question, and no consequences for a bad answer or even a non-answer ("we have no idea"), why bother to ask?

[frivoal]

I kind of agree with @dwsinger. Also, it seems to me that this can already be addressed by the team during a transition request to CR, by requesting a Status Section that actually says something meaningful about the status.

[dwsinger]

It sounds like this might be a good template or /guide issue?

[plehegar]

The Process currently say that a CR must document how adequate implementation experience will be demonstrated and must specify the deadline for comments. For example, the recent CSS conditional CR update says:
[[
This document is intended to become a W3C Recommendation; it will remain a Candidate Recommendation at least until 15 January 2021 to gather additional feedback.
]]
https://www.w3.org/TR/2020/CR-css-conditional-3-20201208/

In addition, there is a section regarding exit criteria (common in all CSS drafts btw).

That sentence doesn't say anything about the next stage expectations, except for the implementation experience exit criteria.

Are we looking for more information?

[dwsinger]

Surely anyone can object to a CR transition "there is no way you'll ever exit, so why enter?", and we could deal with this on a case-by-case basis. Perhaps some team action at CR to encourage "how do we intend/expect to exit" would be good? Not a Process issue?

[samuelweiler]

We should not clutter the Process with this. @hober, I suggest you instead file a PR against https://github.com/w3c/transitions/tree/main/.github/ISSUE_TEMPLATE ?

[css-meeting-bot]

The Revising W3C Process CG just discussed Process should requre CR transition to document plan for CR exit, and agreed to the following:

• RESOLVED: Close #462

The full IRC log of that discussion

<fantasai> Subtopic: Process should requre CR transition to document plan for CR exit
<fantasai> github: https://github.com//issues/462
<fantasai> weiler: [describes issue]
<plh> zakim, move to next agendum
<Zakim> agendum 2 -- Community Groups and Business Groups should be incorporated into the Process -- taken up [from plh]
<fantasai> various: let's close
<fantasai> RESOLVED: Close #462
<wseltzer> +1 to close without change

[nigelmegitt]

I see that @hober did not respond here, but also was not prompted to.

This is a key issue for resolving #443. I'd like to see more emphasis on WGs stating their plans and requirements for CR exit either towards 1) PR or 2) Discontinued Draft. At the moment CR exit criteria are only set for progressing to PR.

In particular I would like this emphasis to expose if WGs think that perpetual CR is an acceptable state, and to explain why, so that there is an opportunity for objections up-front.

I see perpetual CRs as damaging to the web ecosystem because we permit normative references to them, but at the same time they disincentivize implementation: as time elapses the excitement around a CR diminishes, and if the penalty for that is negligible then W3C ends up with a bunch of potentially poor specifications lingering without scrutiny. We therefore have a risk of building an ecosystem based on foundations that have not been demonstrated to be implementable, even less so interoperable. That's not good for the web, and it's not good for W3C.

[nigelmegitt]

Also worth noting that if folk want a "living standard" model, then P2020 should allow them to do that by showing different features at different maturity levels. Much better to have the living standard be at Rec than CR.

[dwsinger]

I'm fine with the course being pursued, but I want to note that CRs are almost precisely a request to implement, get interoperable experience, and so on, so I am not sure where

at the same time they disincentivize implementation

comes from. They are supposed to incentivize implementation...

[nigelmegitt]

They are supposed to incentivize implementation...

Yes, that was the original intent. But if a WG is saying "we're putting this CR out there and expect it to be in CR forever", that's effectively saying "this is ready to implement, but we're done with it and we don't actually care if anyone implements it or not, because we don't plan to take it any further".

[dwsinger]

ah, right "even if we get interoperable implementations we don't intend to carry it to Rec" doesn't encourage implementation. got it.