- wayne.carr@, Michael.Champion@, szilles@
There are a couple of different threads emerging here. I'll reply, then start new threads...
12.10.2014, 20:47, "Jeff Jaffe" <jeff@w3.org>:
[adding Steve and Chaals]
On 10/9/2014 3:35 PM, Wayne Carr wrote:
On 2014-10-09 12:02, Michael Champion (MS OPEN TECH) 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.
+1 We should figure out how to make this easy to do.
Yes, this is Issue-141 [1]. Let's hope that the task force takes this up quickly. Thanks David S. for the thoughts. Anyone have other ideas?
I think the issue is badly framed.
It's pretty straightforward to file a bug on a spec - even, in general, on a recommendation. And most specs have some easy way to find the issues or bugs filed - although the precise mechanism (W3C bugzilla, something on github.org, a Tracker instance, …) varies from spec to spec.
The problem is what happens next. The goal of many people is to see standards evolve, from version to version, and under the current Process that's more painful than it should or could be.
The assumptions that seem to have underpinned e.g. some parts of the Patent Policy and W3C Process are that groups essentially produce a single version of a Recommendation, and then evaporate. This is clearly not what happens in reality (and wasn't, for the most part, when the documents were written).
There is no sense of versioning, and while the current Process tries not to obstruct groups who do it, there are a number of things that are unclear and that lack of clarity is unhelpful.
So look for a thread from me shortly on versioning, and the issues it brings up.
2. Published drafts of W3C specs should have sections annotated with information about how stable, widely accepted, widely implemented, and proven in practice the feature as defined in the spec is. It might be a good idea to flesh that list/taxonomy out and make some concrete suggestions for the process or practice.
+1 I think there's often agreement this is a good idea. It would be a good practice for WGs to adopt. It could also be something WG Charters require. Both of the first 2 are things we should let slip.
I had thought we had an open issue to address this, but I cannot find it. Does anyone recall where that went?
I believe you are thinking of AB actions 37 and 38, which are somewhat overdue.
I'll raise an issue in this group to cover the questions.
I note that the new chapter 7 already explicitly requests Working Groups to provide some information on implementation, and on the status of issues. It may be that more is useful, and it may be that we should simply provide better guidance under the rubric of "best practices".
cheers
Chaals
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at
http://yandex.com