W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

Re: Snapshots

From: Brian Kardell <bkardell@gmail.com>
Date: Sat, 4 Oct 2014 11:34:35 -0400
Message-ID: <CADC=+jdfQNcf82KB4EOqhmJSN8zGKAkE5hOcwj2f37aBEA_woQ@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: Chris Wilson <cwilso@google.com>, "public-w3process@w3.org" <public-w3process@w3.org>
On Fri, Oct 3, 2014 at 7:03 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 10/03/2014 03:53 PM, Chris Wilson wrote:
>>
>> Yes, I think that's helpful; they're not currently binding in any way,
>> and they don't really indicate "consensus" (unless "ready for
>> implementation" really means "we all talked it out, hugged, and we think
>> it's good now."  There should also be a status that says "this is baked,
>> done, shipped, and is incredibly unlikely to change."  (AKA really
>> long-term normative).
>
>
> Even that's not complete.  There also should be a status for: (1) not yet
> widely reviewed, (2) one or more implementers tried to implement this, and
> decided to pull it, but it remains in the spec, (3) authoring advice that is
> widely ignored as the authors that ignore it find the results to be useful.
>
> I can provide examples of each of these categories, and suggest many more
> categories, but that will quickly go off topic; instead I will suggest that
> the right 80/20 balance is struck with two documents types:
>
> Working Drafts: for those that can tolerate change, but want to see the
> likely future direction, and ideally want to comment on it and influence the
> direction.
>
> Recommendations: as Chris said "this is baked, done, shipped, and is
> incredibly unlikely to change."
>
> At the moment, the WHATWG is focused primarily on the first type, and yet
> people are asking why the documents that they produce can't be treated like
> Recommendations; where the obvious answer is that the specific specification
> in question doesn't meet that bar.
>
> In the recent past, this has been addressed by co-branding a number of
> specifications once they reach the point where they are "baked, done, etc.".
>
I think that perhaps we're talking past one another.  I mentioned
statuses on sections, this is considerably more granular.  To
illustrate, have a look at
https://html.spec.whatwg.org/multipage/forms.html#number-state-(type=number)
and the corresponding
http://www.w3.org/TR/html5/forms.html#number-state-(type=number).
Note in the WHATWG version on the right (at least on a desktop) there
is a thing listing implementation status and related bugs.  This is
sort of one of the key issues as I see it, that some specs are very
substantial and we gain progressive agreement - I don't think that
there is any spec (unless it was something really basic like beacon
maybe) which is just 'implemented'.  Often, "specs" (I'll explain the
quotes) like HTML have many features of varying degrees of
agreement/usefulness.  I say specs because it's not limited to drafts
or REC or anything else - in practice it is just a true statement that
there are features even in RECs which are actually not implemented
anywhere - or are universally implemented in disagreement with the
spec.

The aim of a standard is wide implementation and interoperability -
and reference.  Developers need to be able to look at a spec and get a
sense of what's what, I'd offer than any AC reviewing the spec for
progress really should have the ability to do the same in order to
make sensible decisions and that, it's just generally helpful for a
whole number of reasons.  I'd personally like to see W3C attempt an
easy way to track like this.



-- 
Brian Kardell :: @briankardell :: hitchjs.com
Received on Saturday, 4 October 2014 15:35:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:12 UTC