RE: Spec organizations and prioritization

>process to meet some arbitrary date. We have the Process Document in place for
>a reason (and having _at least_ two independent implementations passing tests
>for every feature is what makes W3C RECs of high quality).
>
>Yes, we must not violate our process to meet some arbitrary date.

I'm not so sure about that :)

It isn't good if it takes so long to update key specs like html that the official recommendation winds up being 15 years old before being replaced.  While the current path can create a high quality spec, in the meantime the official spec really no longer is the spec - and that goes on for years - so we're all surviving without any real REC.  I think the question should be can we improve on that.

The real Spec now is the Editor's draft with each implementer deciding which parts are good enough to implement and content creators estimating which parts are supported enough to use.  That's obviously been pretty successful with widespread implementation.  It seems hard to believe there isn't a spec in there somewhere that could be extracted.

One approach would be to drop the testing requirement for now.  If there are multiple, large implementations that seem to be compatible for a feature that would be enough.

Areas that have no major issues are marked stable.  Areas that have major issues are marked "Experimental" and "Informative" if they aren't going to be fixed before REC and marked as an Issue if they are.

Fix the major issues -- go to Proposed Rec with it (including the Experimental Informative parts in it so people can see what is being worked on for the future - no patent obligations for those) and get a REC by a particular date - like a year from now.

Put out another version a year later updating and fixing it.  html5 (2013.09). And again html5 (2014.09) ...

Each would be guided by what is actually implemented broadly enough.

You get real RECs.  Not perfect, but as good as what is being implemented now (drafts) and without having the official REC not be HTML5 at all.  (and I don't think this would violate the process, just violate the current expectations).

Received on Friday, 23 March 2012 17:37:44 UTC