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 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