Re: How should we represent the status of a spec?

I like the proposal from Chris as well. This follows the same format as
HTML5Please which many developers already know.

As far as placement on the page, I think something like this should be kept
above the fold if possible. It is pretty basic information that is very
important to developers and doesn't take much space. So having it
quickly view-able is a big plus.

-Garbee


On Fri, Feb 15, 2013 at 1:46 PM, Julee <julee@adobe.com> wrote:

> This is all great! Thanks for the clarity in your distinction between a &
> b, below, Michael. We did discuss needing to provide both types of status
> for an accurate picture.
>
> While you all are discussing a technical solution I hope usability can
> remain in the forefront. Visitors include standarnistas, testers, and so
> on. But a large proportion of users need to know whether the element can
> be used in production or not. Chris's proposal provides that usability
> factor:
> http://docs.webplatform.org/wiki/WPD:Proposals/spec_status_representation.
> We even talked at one point about providing a UI distinction based on if
> something was production-ready or not
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20387).
>
> Thanks.
>
> Julee
> ----------------------------
> julee@adobe.com
> @adobejulee
>
>
>
>
>
> -----Original Message-----
> From: "Michael Champion   (MS OPEN TECH)" <Michael.Champion@microsoft.com>
> Date: Friday, February 15, 2013 9:18 AM
> To: Tobie Langel <tobie@fb.com>, Robin Berjon <robin@w3.org>
> Cc: julee <julee@adobe.com>, "public-webplatform@w3.org"
> <public-webplatform@w3.org>
> Subject: RE: How should we represent the status of a spec?
> Resent-From: <public-webplatform@w3.org>
> Resent-Date: Friday, February 15, 2013 9:21 AM
>
> >
> >+1 to Tobie's points, with some caveats:
> >
> >There are at least two types of status different audiences need to track
> >a) Status of the spec as it moves toward standardization, and how well
> >tests against the *spec* indicate that it is clear enough to be
> >independently implemented
> >
> >b) Status of the implementations of the spec -- what percentage of
> >deployed platforms claim to implement it, and how interoperable those
> >implementations are in practice.
> >
> >To put it another way:  there are multiple ways to get interoperability
> >-- write a spec that is so clear that everyone can implement it without
> >looking at other implementations, or to start from the code (or reverse
> >engineer the bits on the wire) of some de facto reference implementation.
> > W3C's testing  focuses on the first, but the real-world interoperability
> >of technologies that aren't yet standardized often comes from a
> >combination of specs, shared code, and reverse engineering.  End users
> >who just want to know "can I use this feature with confidence" don't
> >particularly care how the feature got to be interoperable, and they don't
> >particularly care if a spec is good enough if it's not widely implemented
> >in the real world.
> >
> >The infrastructure for storing/publishing the two types of data can
> >almost certainly be shared, but there may be significant differences in
> >how the data are collected. In either case, we should TRY to minimize the
> >number of judgment calls / political decisions between the raw facts and
> >the presented data.
> >
> >________________________________________
> >From: Tobie Langel
> >Sent: Friday, February 15, 2013 5:01 AM
> >To: Robin Berjon
> >Cc: Julee; public-webplatform@w3.org
> >Subject: Re: How should we represent the status of a spec?
> >
> >On Friday, February 15, 2013 at 1:54 PM, Robin Berjon wrote:
> >> On 15/02/2013 10:00 , Tobie Langel wrote:
> >> > Maybe we should start having a cross-project conversation on the
> >>subject.
> >>
> >> I'm all for that, but I want to make sure that we don't force ourselves
> >> to shoehorn all the various ways of representing spec status into a
> >> single unified one if it turns out not to fit.
> >
> >Absolutely. There are different audiences are interested in different
> >types of status (e.g. publication status, test status, implementation
> >status, etc).
> >
> >Of course there is some overlap.
> >
> >However--and that's the part I'd like us to focus on--storing, accessing,
> >updating this information requires the same infrastructure, and it would
> >be a shame to not consider centralization, here.
> >
> >--tobie
> >
> >
> >
> >
> >
>
>
>
>