-
Notifications
You must be signed in to change notification settings - Fork 120
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
Comments
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. |
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'. |
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. |
My inclination is to raise the bar for Recommendation status, not lower it. "W3C Recommendation" ideally should mean that a technology has:
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. |
@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. |
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. |
@dwsinger the part "and rename CR to Recommendation" would mean that the branding would still be "Recommendation". |
The IETF runs on RFCs; if we end up running on CRs it would seem to be about the same |
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. |
we have such strong branding around our names, we should not do this. closing |
[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.
The text was updated successfully, but these errors were encountered: