Re: "Living Standards"

(Disclaimer: the following is how *I* see the "living standard" working - I don't know if others share this definition/view, and don't claim to know what it is… no one has ever actually told me what a living standard is, so I've imagined what it would mean for me.)  




On Tuesday, 27 December 2011 at 16:04, Charles McCathieNevile wrote:

> Hi folks,
>  
> In this still fairly small group there are some proponents of the "living
> standard" model where documents are never finished.
>  

I think this "never finished" stuff is a misconception/fabrication and not part of a definition of a living standard (or just as much of a definition of a static recommendation).  

Let me again give the XML 1.0 example (which comes from the Recommendation/static world). XML 1.0 is "never finished" so long as there are "Editions" being worked on, forever. The only difference in a living standards model would be that the "Editions" are not present: the document is just updated when an issue is found and a list of changes is maintained. That's all… well, and email would go out too, I supposed - letting people know that something has changed.  

Lets be crystal clear: both models are practically identical. The only difference is that there is no W3C song and dance (or labelling of a new edition and hurrah! on the W3C front page… though nothing would preclude that from happening periodically for marketing/outreach reasons). There is just a simple list of changes ("On the 18th of January, we fixed a typo in section X and clarified the Foo algorithm."). This allows for things to be fixed quickly without having to bug the Pub team and everyone always gets the latest fixes without having specs stagnating on CVS/HG.   

To also be crystal clear: the rest of the W3C Process still applies: WD, LC, CR, PR, REC… all that goodness is all fine and good. However, it's viewed more as a "phase", than something relating to some static frozen document (more details/rationale below).  

> Some people (me, for
> example) think that stable Recommendations are a valuable service to the
> community.
>  
> But I do suspect a serious
> discussion about why we believe what we do could be a useful exercise,
> because there seems to be a lot of common ground in things we think
> should be improved, and that we each have some perspective and insight
> that the others don't - and sharing that would be a constructive thing to
> do.
>  


Ok, here is my go:  

I think having specs stagnating in CVS/HG after /TR/ publication is a bad thing (the moment someone sends me feedback and I do something about it on CVS/HG, whatever is in /TR/ is out of date - see the HTML5 document's Big Red Note, which tried to overcome this issue).  

Why I want living standards: As an editor, I would like to have changes I make to a document reflected in the /TR/ space in real time. So long as I stick to the rules for the current status of the document, this should be no problem. For example, if I am in CR, I, as an editor, should not add new normative requirements… or if I do, the WG should be able to drop back to Last Call - OR make a clear note that the spec will be returning to Last Call, etc.  

So, in a living standards model, being in a "Phase" means you can do whatever you like so long as you stick to the rules of that phase… And the Director or WG would still have to give you the ok to proceed to the next phase on the Rec Track.  

Let me give you a recent example. In the Widgets Interface spec I published on the 13 December 2011, it was pointed out to me on the 15th of December by a concerned implementer that there was a mistake in one of the examples [1]. I accidentally wrote:

  if (event.storageArea === widget.localStorage) {  

And I should have written:  

  if (event.storageArea === *widget.preferences*) {

So, although there is a mistake in the spec that caused an implementer some concern (I was asked, "did you change the name of the attribute?"), I have to wait up to 1 month (or more, in most cases) before I can fix it on /TR/ (because of the publication freeze over xmas and because it would be huge pain to call for another CR just to fix a wee typo or two, etc… or because the exit criteria has not been met)… which means potentially more people becoming unnecessarily confused. As a slightly OCD-standards-editing-nerd, that's very frustrating: I want to push my change to TR now, and not in a month….

Do you see now what the main frustration is? As an editor, I don't have control over the spec… and in this day and age, with computer and internets, it just seems outrageous that I can't fix that typo without having to email a bunch of people and go through some painful process.   

Just addressing the problem above would go a long way. Call it what you want ("living standard… standard of living?"), but a lot of us just want our changes to be reflected more quickly (or in real-time) on /TR/. It's not that much to ask, is it? No one wants to violate the process: Editors just want to stop being violated by not being able to update our specs on TR when there are stupid little typos without going through the republication process.     
   


> So here beginneth the thread, and I'll explain in a reply some things I  
> think are better about the living standards model (obviously, the current  
> model is far from perfect, and I think there is a bunch of good thinking  
> behind "living standards" even if I think the conclusion is wrong) and
>  


I'm not sure what conclusion you've derived; please share. Do you have a pointer to a definition of a living spec by someone else?  
  
>  
> some things I think are important about the stable version world. Maybe we  
> end up with something everyone thinks are improvements - which doesn't  
> mean the discussion is over, but that we can propose them to W3C in the  
> meantime, and if they really have broad consensus we can at least make  
> things better before we get to where we want to be.
>  


I hope, at least, that makes it clear what I want - it's not that much: just want to fix stuff quickly and hopefully only maintain one spec. I don't want to violate the W3C process; I don't want to keep piling on new features willy nilly, I don't want a spec that grows forever. And I don't think people who advocate for a living standard want that either.   

It might be helpful to know what you want too :)  
  

[1] http://www.w3.org/TR/widgets-apis/#example-comparing-storage-areas


--  
Marcos Caceres

http://datadriven.com.au

Received on Wednesday, 28 December 2011 01:40:24 UTC