RE: Ideas on simplification of process and operations

Arnaud, thanks for that summary of the W3C process. For someone like me who
is rather new to W3C, it was very helpful. 

 

I've been told that one of the burdensome aspects of the current W3C process
is the requirement for an up-front working group scoping document.
Apparently, for some, the requirement to define the scope of the innovation
desired in the specification is itself often an impediment to innovation. It
can lead to intense and interminable arguments among potential contributors
before actual work can start, and it can allow companies to build fences
around their own patent portfolios so as to stifle both innovation and
competition. 

 

Are these four steps in the current W3C process supposed to result in a
working group scoping document?

 

a. Submission/Workshop/AC discussion 
b. Director announces development of Activity proposal or WG charter 
c. W3C members review 
d. Director approval 



How much of this part of the process can be simplified or eliminated for
these incubating standards?

 

As for the latter phases of the W3C process, some of this reflects a perhaps
antiquated view that specifications and their implementations proceed in
series rather than in parallel. Would it not be simpler to set the rule, at
least for incubator standards, that anything that may graduate to
publication status must already have an implementation in software.

 

2. Last Call announcement - at least 3 weeks, and from then on: WG MUST
formally address any substantive review comment 
3. Call for Implementations - Note: The Director MAY permit the WG to skip
this step if the entrance criteria for the next step have already been
satisfied.

 

The current W3C process also reflects a desire by members that their patent
commitments may be withdrawn at specific checkpoints (e.g., Last Call) in
the process. In Open Web Foundation, we're developing a Contributor License
Agreement that allows a straightforward 45-day opt out for patent claims
relating to a patent owner's actual contributions to a specification, and
allows contributors to postpone their patent commitments for the rest of the
specification until they voluntarily sign an OWF Agreement that contains a
non-assert for that entire specification. Our hope is that this will
eliminate some of the process delays, such as those in W3C, surrounding the
commitment to royalty-free licensing of patents. If patents become less of a
concern, perhaps innovation will be faster.

 

/Larry

 

 

From: public-vision-newstd-request@w3.org
[mailto:public-vision-newstd-request@w3.org] On Behalf Of Arnaud Le Hors
Sent: Tuesday, July 06, 2010 5:03 PM
To: public-vision-newstd@w3.org
Subject: Ideas on simplification of process and operations

 

In response to: [NEW] ACTION: Arnaud will write down a few ideas on
simplification of  
process and operations (to start by fleshing out comments on this call) 

Let me first set the record straight. I didn't quite say: "there are some
things in the current process that we should revisit." 
I said "things [...] we might revisit". 

I also said: "it's heavy but it's there for a reason" and I certainly stand
by that. Changes to lighten up the process will come at a cost. The cost
will primarily be to lose some rigor, which in turns may lead to lower
quality. However, just like for everything else, it's a matter of finding
the right balance. Maybe the current process is too strict and excessively
burdensome. Maybe relaxing some constraints would significantly ease up the
process while not significantly impacting the quality. This is what I think
we need to focus on. 

Finally, I also believe that "there's flexibility in how you carry out the
process" and there may be room for improvement in just how we execute the
process without even changing it. However, I kind of doubt this would be
sufficient to attract the kind of work we're interested in here. 

With this being said, I thought to get us started we should look at
<http://www.w3.org/2005/10/Process-20051014> the current process and what
the timeline to produce a rec is, from start to finish. Ian will correct me
if I'm wrong here but, it looks like this: 

   a. Submission/Workshop/AC discussion 
   b. Director announces development of Activity proposal or WG charter 
   c. W3C members review 
   d. Director approval 
   e. Call for participation / Work start 
   1. Publication of the First Public Working Draft. 
   2. Last Call announcement - at least 3 weeks, and from then on: WG MUST
formally address any substantive review comment 
   3. Call for Implementations - Note: The Director MAY permit the WG to
skip this step if the entrance criteria for the next step have already been
satisfied. 
   4. Call for Review of a Proposed Recommendation - at least four weeks,
Director MUST formally address any substantive issue raised by AC 
   5. Publication as a Recommendation. 

Interestingly enough, as indicated here, only two of those steps have a
defined minimum time frame. I'd appreciate if the team members could provide
us with additional info on how long is typically allocated to the steps
under their control such as the initial review and director approval,
announcements, etc. A recent example might be useful in this regard. 

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. 

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. 

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? 

Now, I was asked to come up with ideas to simplify the process and I realize
there isn't much in any of what I discussed so far. So, detaching myself
from the current process and all the reasons behind the existence of each
step, 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 would stay away from calling what's thus produced a Rec and find a brand
new name, a la "W3C Community Specification", that can then be submitted to
initiate the formal process. This, I suspect, would more likely appeal to
the mass. 
--
Arnaud  Le Hors - Program Director, Global Open Standards, IBM Open Source &
Standards Policy