W3C home > Mailing lists > Public > public-vision-newstd@w3.org > July 2010

Re: Ideas on simplification of process and operations

From: Charles McCathieNevile <chaals@opera.com>
Date: Sat, 10 Jul 2010 15:45:57 +0200
To: "Arnaud Le Hors" <lehors@us.ibm.com>, "Robin Berjon" <robin@robineko.com>
Cc: public-vision-newstd@w3.org
Message-ID: <op.vfmq6vcdwxe0ny@widsith.local>
On Wed, 07 Jul 2010 12:15:42 +0200, Robin Berjon <robin@robineko.com>  

> Hi Arnaud,
> thanks for this good overview.


> On Jul 7, 2010, at 02:03 , Arnaud Le Hors wrote:
>> Interestingly enough, as indicated here, only two of those steps have a  
>> defined minimum time frame.
>> An immediate idea for shortening the process would be to consider  
>> reducing some of these. However, I don't know that there is so much to  
>> gain that this would make W3C more attractive to those ad hoc groups  
>> out there.
> I don't think that that would be the best plan either. If we try to bend  
> the current process to meet those new needs I think we'll end up making  
> everyone unhappy.


>> Rather I think this stresses the point I made on the call that the  
>> heaviness comes from other built-in constraints. In particular, the  
>> ones I highlighted in the above list is probably the most time  
>> consuming constraint: "WG MUST formally address any substantive review  
>> comment", which is compounded by the requirement to prove to the  
>> Director that this has been done.
>> In my experience as co-chair of the XML Core WG, this was very time  
>> consuming and burdensome for the WG for little gain. To be fair, I may  
>> have forgotten the good out of this exercise but, at this point all I  
>> can recall is that it forced us to prepare to refute any claims that  
>> the WG hadn't listened to public comments (claims typically made by  
>> discontent people who hadn't got their requests for changes endorsed by  
>> the WG). But I think this may be too high a price to pay for that.
> LC can be gruelling when you're faced with a comment DDoS, but on the  
> other hand if we don't have LC we don't get (all) comments. I think we  
> might help groups by introducing some exceptions to the strict handling.  
> For instance, comments that duplicate ones already made shouldn't have  
> to be tracked, just replied to with a pointer to the duplication.

This is already feasible.

> And in extreme cases where comments are more nefarious than helpful
> perhaps invert the burden of proof to place it on the commenter.

The problem is who decides a comment is nefarious...

> But again, that's for the "Classic" track.

Nonetheless that is within our scope. The point of this group is not ust  
about attracting the lightweight developments, but also things that are  
currently done at OASIS, or where groups set up their own organisation  
(e.g. JIL/WAC). And they are more likely to go for the classic process.

>> I know the requirement for implementations is often questioned but, as  
>> indicated above, when there already are implementations available this  
>> may be skipped. The W3C didn't have this step in the beginning and it  
>> was added because fixing errors found while implementing the spec after  
>> it had been published as a rec was too costly. Removing this  
>> requirement would be going back to where we started so, do we really  
>> want to do that?
> No, that would be a terrible idea.


>> ... I would venture that to be really attractive to the crowd we are  
>> targeting, we'd have to offer a radically different process such as:
>> Call for participation (based on some general idea of what the problem  
>> at hand is) & development of charter/requirement doc
>> Draft work
>> Last call/review
>> "Final" spec
>> With a quick revision cycle.
> I like that, and I like "W3C Community Specification". Presumably we  
> would enforce some minimal pubrules? And I take it that such a  
> specification would offer no IP protection?

I think there is no way such a spec can offer IP protection. It seems  
pretty much the XG process, except the XG is allowed to recycle itself.  
Personally I get concerned about specs being developed and promoted  
without IP protection - the Web is a more complicated place than it was 15  
years ago, and we *know* that there are a lot of IP traps laid now ;(

Some more examples from the past:

   There was some effort to convince the people behind it to standardise  
FOAF at W3C, which was resisted. I think we should just ask danbri and  
libby what they think.

   The "W3C date/time format" (a trivial subset of the relevant ISO  
standard) is in very wide use, and yet its development consisted of a  
couple of people writing a couple of pages and publishing them as a note -  
something still perfectly possible within the existing process.

   This was taken to W3C, and despite a process that included an IP problem  
and subsequent process wrangling, a spec developed within the W3C Patent  
Policy has got wide implementation. It could be argued that it would have  
gone faster elsewhere (although there are strong arguments that the  
slowdown wasn't related to W3C at all, but to other issues to do with  

File I/O
   This was first brought to W3C. It took a couple of *years* to get broad  
interest - so it languished. Not through a process issue, but because the  
market doesn't move nearly as fast as people often claim it does.

It might be that the problem is less one of process, and more one of  
"marketing" - explaining how the process works in practice. I certainly  
hear a lot of total garbage spouted about W3C process and the burden it  
imposes, from people who clearly have no real idea. Clarifying the  
requirements and possiblities in a document designed to be read easily for  
a rough answer (i.e. not the process document, which is designed to be  
read carefully and give a clear and precise answer) may go some way to  
helping understand what people can do at W3C.


Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Saturday, 10 July 2010 13:46:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:40 UTC