Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the Recommendation stage, and rename CR to Recommendation #446

Closed
plehegar opened this issue Aug 17, 2020 · 10 comments
Closed

Remove the Recommendation stage, and rename CR to Recommendation #446

plehegar opened this issue Aug 17, 2020 · 10 comments
Labels
AC-review Raised during the AC review phase, or otherwise intended to be treated then. Closed: Rejected
Milestone

Comments

@plehegar
Copy link
Member

[raised by the 2020 AC Review]

It was suggested to remove the Recommendation stage, and rename CR to Recommendation (and CR Draft to Recommendation Draft). The rationale is that the proposed way to make bugfixes and new features in a Recommendation but mark them as informative is still not as good as Living Standard, and so it's possible WGs may still be reluctant to go to Rec.

@plehegar plehegar added the AC-review Raised during the AC review phase, or otherwise intended to be treated then. label Aug 17, 2020
@chaals
Copy link
Contributor

chaals commented Aug 18, 2020

It's good to have the suggestion here for completeness.

I object to the proposal. The living standard model provides an unreasonable excess of control, typically to a small group of implementors who between them have market dominance, at the expense of hearing the needs of consumers directly.

In addition, while it is important to enable updates to Recommendations, the Candidate Recommendation phase is the wrong point - this is a request for implementation experience (presumably in the general case testing both whether the new features are actually implementable in software and whether that actually meets the market need it is intended to address. (In some cases like WCAG, the latter testing is more obviously crucially important, but it generally makes sense for everything we do).

Instead, a Recommendation expresses a point at which people can go and work with a technology - which can obviously be updated as the world changes but which is a useful enough reference point to build some interoperability and broader experience of deployment beyond the immediately interested members of the Working Group that wrote it.

@dwsinger
Copy link
Contributor

I object, but for different reasons than Chaals. We have an established brand name with Recommendation, and a well-understood meaning. If we end up (and I hope we don't) with the w3C relying mostly on 'Candidate Recommendations' I don't see this as any worse (and in many respects comparable to) the IETF running on 'request for comments'.

@nigelmegitt
Copy link
Contributor

I don't see this as any worse (and in many respects comparable to) the IETF running on 'request for comments'.

I agree it's comparable, but I believe it would be much worse, given that IETF's traditional output (it's brand, if you will) is RFCs, whereas W3C's is not CRs.

@michaelchampion
Copy link

My inclination is to raise the bar for Recommendation status, not lower it. "W3C Recommendation" ideally should mean that a technology has:

  • A solid, thoroughly reviewed spec
  • Firm royalty-free patent commitments from the appropriate stakeholders
  • Multiple implementations that pass a high percentage of rigorous tests
  • Real world acceptance by many websites or services; proven track record of solving the problem it set out to address
  • Minimal dissent / Support from a substantial percentage of the engaged membership that the technology has a beneficial impact on the web's "full potential"

I'm neutral on whether W3C should become a more welcoming venue for those who want to do Living Standards, or whether it should be a venue where Living Standards / CRs / RFCs / etc. from any org, that meet the very high bar, can get the imprimatur as Recommendations.

@nigelmegitt
Copy link
Contributor

@michaelchampion you don't sound neutral: my interpretation of your comments is that you think the relevance and usefulness of W3C's output is on a downward curve and you are happy for that to continue in favour of a de facto situation where developers and users rely on less authoritative resources like unofficial tests, unreviewed specifications and sites that survey implementation status in browsers like caniuse; apologies in advance if that's the wrong interpretation: I write it in order to give you the opportunity to dispute it.

@michaelchampion
Copy link

I believe I am (currently) neutral on the topic of Living Standards at W3C. Some years ago, we pushed to make W3C more competitive with the culture that moved work to WHATWG, which did not have a clear governance model or any patent policy. Now it does, and there is a MoU describing how to ratify stable snapshots of WHATWG Living Standards as W3C Recommendations once they meet W3C's criteria.

So one way for the web community to work together would be for W3C to double down on its "brand" of creating traditional Recommendations that are proven to be interoperably implemented, stable enough to rely on for some number of years, thoroughly reviewed by a broad set of experts across the membership, and certified (in some way without a Director) that they are part of a coherent web architecture and vision. In practice, that's actually a higher bar than Recommendation status is today.

Other orgs, especially WHATWG, could produce early drafts of these standards according to their own processes, then they (or community stakeholders) could contribute them to W3C . Or W3C WGs -- notably CSS -- that have cultures that work within the W3C process but can effectively innovate and maintain, could continue as usual.

Alternatively, W3C could continue to evolve its culture to accommodate both "living" and traditional standards. That creates the kind of tensions we see in these issues, but with flexibility and goodwill we could find a way forward that respects the concerns of both "stable" and "living" proponents.

I don't have strong feelings for one approach or the other. I suspect we should see how the options added to Process 2020 that adopt parts of the WHATWG approach get used in practice before arguing about it.

@zcorpan
Copy link
Member

zcorpan commented Aug 20, 2020

@dwsinger the part "and rename CR to Recommendation" would mean that the branding would still be "Recommendation".

@dwsinger
Copy link
Contributor

dwsinger commented May 3, 2021

The IETF runs on RFCs; if we end up running on CRs it would seem to be about the same

@frivoal
Copy link
Collaborator

frivoal commented May 4, 2021

Also, while some groups have expressed no interest going beyond CR, that is not the case of all groups. I would be extremely strongly against dropping the recommendation stage altogether, and as long as we have it, the name is not available to describe something else (and even if we did retire it, this would be a drastic change to what it means, which I don't think is acceptable).

Besides, even in groups which do not plan to go beyond CR, the possibility remains open, and as the circumstances (or the group's membership) evolves, there can eventually be appetite for completing the track.

I really don't think we gain anything by tinkering with these well established names.

@dwsinger
Copy link
Contributor

we have such strong branding around our names, we should not do this. closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AC-review Raised during the AC review phase, or otherwise intended to be treated then. Closed: Rejected
Projects
None yet
Development

No branches or pull requests

7 participants