w3c / standards-track

Best Practices for Bringing Work to the W3C Recommendation Track
https://www.w3.org/Guide/standards-track/
9 stars 16 forks source link

Document and analyze obsolete RECs #25

Open msporny opened 7 years ago

msporny commented 7 years ago

This request comes from the following email thread:

https://lists.w3.org/Archives/Member/w3c-ac-forum/2016OctDec/0143.html

In that thread there was an assertion that "aspirational standards" often do not make good RECs. There were two problems that the discussion raised. The first was that it was clear that there were varying definitions for "aspirational standard", which is documented as an issue here: https://github.com/w3c/standards-track/issues/23. The second was that there did not seem to be any solid research data, although there does exist anecdotal evidence, that supports the various theories around why standards fail.

The REC Track Readiness Criteria should be based on data, especially criteria that is intended to increase the success of a group. This requires that the W3C:

  1. Research and document past W3C successes and failures.
  2. Derive additional W3C Rec Track Readiness Criteria from that research and include it in the REC Track Readiness Criteria document.
  3. Seek consensus among the W3C Membership for the new readiness criteria.

Assertions that specs fail for specific reasons, without the data to back up those assertions, will continue to be met with skepticism until this is done.

I suggest that the first step is to document which specifications are clear failures and which ones are clear successes (up to the AB to define the criteria of what a 'success' and 'failure' is). The second step may be to interview the Chairs/Editors of the groups (if they're still around) to ask them why they think they failed or succeeded.

tantek commented 7 years ago

I would suggest starting with analyzing all W3C RECs before the requirement of going through CR.

I hypothesize that more than half of those were partially or nearly completely aspirational (normative spec feature text describing a behavior that has no evidence of implementation, e.g. prototyping, with actual running code).

The other half of this, documenting which specs are obsolete, is now open for anyone to nominate, per the current W3C Process. Thus that documentation is better done as part of the W3C Process, not in this issue.