Re: Web standards, Openness and Transparency

On August 12, 2014 at 10:56:13 AM, Chris Wilson (cwilso@google.com) wrote:
> On Tue, Aug 12, 2014 at 7:43 AM, Marcos Caceres wrote:
>  
> > 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 (and updated srcset).
> > Editors adding features into a spec without consensus is clearly bad and
> > leads to a lot of confusion/frustration.
> >
>  
> Yeah, I'd actually written out that example and then deleted it.


Group members, please contribute others please! 


> > Agree. Though specs like WHATWG HTML have per-section stability markers - though they can be deceiving.
> >
>  
> s/can be/usually are. :)

It would be possible to address this maybe through using both qualitative and quantitive signals (e.g., test coverage, implementations). Again, the WHATWG spec does provide some of this - though the "ready for implementation" (or similar, can't remember exactly what it says) signal can be deceiving. 

Having said the above, and as you point out, this is a problem for large specs. Determining what a large spec is, is another problem...  
 
> > > > > 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).
> > >...
> >
> > Ok, making this mandatory in the templates would be great.
> >
>  
> That's what I've had in mind as part of that "graveyard of /TR" item.

[speaking about "open w3c"...] we probably need to drag in the W3C team people trying to sort this out (I think that's PLH). It would be great to get a status update on where all this is at. I'm worried that we might be doing duplicate work here by even discussing this stuff.   

> >
> > > > 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).
> >
>  
> There's a big difference between digging through thousands of commits in a
> repo and having a clear "oh, that's how these things worked together in v6."

Yeah, the "V6" is a problem (and it's not clear to me why someone would be looking at an obsolete version? what's the use case for non-editors?) - I personally wouldn't want want to use such explicit markers in my specs. However, people could do that: it's simple enough to tag a release in Git.

Received on Tuesday, 12 August 2014 17:23:36 UTC