Re: Ideas on simplification of process and operations

Hi Arnaud,

thanks for this good overview.

On Jul 7, 2010, at 02:03 , Arnaud Le Hors wrote:
> 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. 

I agree that this is a good idea (though not for this target audience). I think that having a strict process but giving chairs a good sense of which parts must be adhered to at all times and which can be relaxed is very useful. It's good to relax the rules when a group is being productive, but have the possibility of being strict when trouble arises.

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

I don't know if there really is a typical time frame here. It can be quick (e.g. Web Notifications) or it can drag on forever (e.g. the initial work on Web APIs). I guess it also depends on whether there's a workshop.

> 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. And in extreme cases where comments are more nefarious than helpful perhaps invert the burden of proof to place it on the commenter. But again, that's for the "Classic" track.

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

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

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 7 July 2010 10:16:18 UTC