Re: Web standards, Openness and Transparency

On August 12, 2014 at 10:32:54 AM, Chris Wilson (cwilso@google.com) wrote:
> On Tue, Aug 12, 2014 at 7:17 AM, Marcos Caceres wrote:
>  
> > On August 11, 2014 at 3:51:54 PM, Chris Wilson (cwilso@google.com) wrote:
> > > > Note that I'm not EXACTLY advocating for this; I actually think
> > > directly using living documents in /TR is not a good idea.
> >
> > Can you provide the rationale as to why?
> >
>  
> Perhaps it's my impression of what most people mean by "living document".
> There are different degrees of "baked", and I've seen some things go in to
> living documents that I don't think necessarily represent rough consensus;

Yes, I think we need to list those explicitly because they pose a threat to having living standards on TR. When things go bad, they go really bad. For example:  

* srcset in HTML and the huge fight we (the RICG) had to have for 2 years to get that removed from HTML in favor of <picture> (and updated srcset). Editors adding features into a spec without consensus is clearly bad and leads to a lot of confusion/frustration. 

<please add others>

> that makes it quite hard (particularly in a large specification) to tell
> what's implemented everywhere, what's pretty solidly agreed upon, and what
> is just a roughed-out idea.

Agree. Though specs like WHATWG HTML have per-section stability markers - though they can be deceiving.

> You could, of course, use editors' drafts here, and have the living
> document always represent rough consensus (i.e. EDs are branches) - and I
> certainly agree we need a faster update cycle in /TR, and
> I think of specs like software in this sense. We have a fast release cycle
> for Chrome - at the same time, we have different channels, and they are
> different levels of done. Yes, we want
>  
> >
> > > It *IS*
> > > a good idea to make sure /TR documents always POINT to the current
> > > spec or effort (yes, including pointing to editor's drafts).
> >
> > This is what we have today, no?
> >
>  
> Absolutely not. There are some specifications that do this, it's true -
> but many do not. For example, a couple of weeks ago I was trying to dig up
> information about the "TV" media type. I started with CSS2. I dug through
> a lot of (unlinked) specs (e.g. CSS3 media queries, HTML) before
> discovering the new CSS Media Queries level 4 document, which effectively
> completely replaces the bit I was interested in. None of the specs in /TR
> hinted that there was superceding work going on.
>  
> (There ARE definitely counter-examples here.)

Ok, making this mandatory in the templates would be great. 

> > I think redefining history of specs is bad.
> >
> > Not sure what this means. Can you provide an example?
> >
>  
> Any time you simply rev in-place without significant versioning, you're
> effectively changing history.

But all specs are worked using a version control system - so you always have history? Are you saying that specs should provide a link to their commit history? (if yes, many specs do - but yes, it would be nice if this was a mandatory thing).

Received on Tuesday, 12 August 2014 14:44:20 UTC