Section 6.2 does not acknowledge Perpetual CRs

[palemieux]

Section 6.2 states:

For a technical specification, once review suggests the Working Group has met their requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to provide feedback on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice.

Suggest removing on whether the specification is appropriate as a W3C Recommendation since some CRs are not intended to become Recommendations.

[jeffjaffe]

I'm not sure why we would remove the cited text since it applies in many cases. Perhaps we can say:

"whether the specification is appropriate as a W3C Recommendation or provide any other feedback"

[palemieux]

@jeffjaffe I heard earlier today that some groups are not interested in ever achieving Recommendation and therefore the membership should not be asked/requested to provide feedback on this topic in general.

[jeffjaffe]

@palemieux some groups may not be interested, but they may change their views. HTML and DOM are interesting use cases. The WHATWG does not feel that there is a need for W3C RECs for these specs. But we've all agreed on a process where W3C is bringing them to REC - because there is a demand for that.

[palemieux]

some groups may not be interested, but they may change their views.

Perhaps... the membership should however not be asked to provide feedback (which requires work) when the group has explicitly they are not interested :)

[edit: typo]

[dwsinger]

I am inclined to leave the text. A CR should be suitable as a Rec., even if the WG doesn't intend to take advantage of that suitability.

[palemieux]

A CR should be suitable as a Rec.

@plehegar mentioned that the CR can have substantive issues opened against it, making it inappropriate for REC, right?

[dwsinger]

A CR should be suitable as a Rec.

@plehegar mentioned that the CR can have substantive issues opened against it, making it inappropriate for CR, right?

I think he said that after entering CR a spec. might have issues opened against it, and we don't require it to back out of CR. We do have some cleanliness requirement when entering; but we shouldn't be surprised if we encourage people to implement, and they find issues when doing so.

[frivoal]

Suggest removing on whether the specification is appropriate as a W3C Recommendation since some CRs are not intended to become Recommendations.

It may not be intended to become a REC, but it still out to be appropriate for becoming a REC. Choosing not to follow the steps after CR does not lower the quality expected of a CR.

I think we could replace "is appropriate" with "would be appropriate", but I don't think we should remove this altogether.

I think you might also be supportive of the following addition:

[…] while the Working Group formally collects implementation experience to demonstrate that the specification works in practice, and optionally investigates possible additional features..

[nigelmegitt]

some CRs are not intended to become Recommendations.

This point seems to have migrated here from #402, so reposting slightly edited version of #402 (comment):

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]

Also to add, I know there are groups that have a lot of specs seemingly permanently in CR status, but that should not (must not) be the intended end state. I've assumed that we accept this situation as something transient, albeit over a number of years. There's no other way this situation can be acceptable.

[nigelmegitt]

To be concrete about a proposal for discouraging perpetual CRs, one option for discussion would be as follows:

• Add a bullet to the per-Rec-track document MUST have list of WG Charters specifying the expected maximum duration in CR
• Add a bullet to the first list at Transitioning to Candidate Recommendation saying "MUST specify the deadline for transition to the next step for the specification, which SHOULD be based on the maximum CR duration specified in the Charter"
• Add a statement to "Abandoning an Unfinished Technical Report" to say "W3C MUST abandon as an Unfinished Technical Report any Candidate Recommendation that has not advanced to a next step beyond its stated deadline for such a transition."

This proposal would require WGs to state the CR exit deadline, but gives the AC the explicit opportunity to see, and comment on the proposed maximum CR period during Charter review, thus providing a strong mechanism to support the suggestion that @jeffjaffe made at #402 (comment)

It would also be possible for WGs to establish a "keep-alive" pattern by republishing a CR with modifications for example reducing the scope by marking features as at-risk, and in doing so, extending the deadline.

[dwsinger]

some CRs are not intended to become Recommendations.

This point seems to have migrated here from #402, so reposting slightly edited version of #402 (comment):

CR being the intended end state should not be acceptable.

We are trying to balance a whole load of possible undesirable aspects; documents that are kept permanently in draft because they are easier to keep up to date; recs which don't represent truth because maintaining them is a pain; documents that naturally slowly iterate and evolve; clarity for the industry as to what the approved state is, the current state, the best practice, the open questions; dealing with the W3C being famous for having no idea when things will 'finish' (if ever); and so on.

I'm not sure that I want to apply a rule that "Recommendation status is the gold standard" to every case (just as I wouldn't apply WHATWG's "Living standard is the gold standard" to every case either).

So I would rather go easy on new rules. yes, CRs need to pass various criteria, and be clear what they claim, including being suitable as a Rec. Let's see what happens, what cases arise, and so on, before we pre-emptively rule.

[palemieux]

including being suitable as a Rec.

This is the crux of the issue: suitability as a REC involves AC review and demonstrated implementation experience. Neither of which apply to a CR.

The process document need to either:

• acknowledge the fact that some TRs will remain CRs at perpetuity; or
• discourage TRs from remaining CRs at perpetuity.

I am not sure why there is resistance to making this explicit, esp. in introductory prose.

One way to discourage TRs from remaining CRs at perpetuity is to make transition to REC easier:

• AC review comments could be limited to process issues, i.e. technical comments would not be germane -- anyone wishing to contribute technically could have joined the WG
• interoperability/implementation experience could be documented, but not necessarily complete, i.e. the implementation report could contain "not implemented" features