Re: Normative references and stable documents

On Oct 9, 2014, at 12:02 , Michael Champion (MS OPEN TECH) <Michael.Champion@microsoft.com> wrote:

> It would be great to start harvesting from this set of threads some concrete suggestions for changing the formal W3C process and informal practices to address some of acknowledged problems.  Just to start things off:
>  
> 1.       Errata - Chairs and the team should more strongly encourage WGs to identify outright errors and fix them quickly, ideally inline in the published document but at least in an errata document.  Jeff’s blog acknowledges that W3C can learn from WHATWG on this, and we need to make it happen.

I would very much like to see this automated.  I think that being able to find a list of issues/bugs that the WG agrees ought to be addressed would be valuable.  This, IMHO, can be a living list; I don’t see any value to having it carefully administered and static, as its whole point is to warn your about issues that the WG agrees ought to be considered in a revision.

To that end, why can’t the errata list be automatic?  Two easy ideas (and I am sure there are more):

1) the issue tracker has ‘products’. Why is there not a product for the CR/PR/Rec., and the errata list is simply a list of the issues against that product?
2) Alternatively, if the group is using bugzilla, why isn’t there a product for the CR/PR/Rec, and bugs that are agreed errata are tagged with a suitable keyword?
3) … (more modern people can think of many other ways)

Errata agility for all!

> 3.       We could revisit the very thorny question of how to ensure that owners of specs and products that depend on a W3C spec actually review changes early in the process before changes are set in stone.  Hixie’s proposal that specs and dependencies be changed in lockstep is interesting but could not possibly scale up to include all stakeholders at Web scale. And as Daniel Glazman has pointed out, this simply doesn’t work for many enterprises who want to control the rhythm of  their own infrastructure and app updates themselves. But I’m sure we can do better than we do now.

It is very hard, in general to assess how much dependency there is on something, and even harder to enumerate who is depending.

> 4.       Jeff’s blog mentioned that Community Groups – which do not require broad consensus to proceed, but do not produce “standards” – are a way to develop specs more quickly. Indeed, the whole point of the blog was to muse on the right balance between strong editors (that some CGs have) driving “lazy consensus” (to adopt the Apache term) and traditional W3C “broad consensus.” Should we discuss how CGs and WGs fit together in the W3C culture and process, continue to let them evolve independently from the process doc and team’s oversight, more strongly encourage specs to be incubated in CGs before a WG is chartered to standardize them, or what?

I really think that CGs are a good place to incubate from vague idea and half-formed specs., to something that can be standardized.  Putting dates in charters for this stage is a triumph of hope over experience.

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 9 October 2014 22:47:00 UTC