Re: Ideas on simplification of process and operations

Hi Arnaud, All,

For better or worse (and IMHO, I think it is mostly for the better), the 
W3C Process "is what it is" for very good reasons and I haven't seen 
evidence there is a strong need for major changes (e.g. removing the 
implementation requirement or lightening the LC comment response process 
as suggested below) to the Rec-track process.

However, I do think it would be helpful (e.g. to recruit new work to the 
Consortium) if there was a separate (non-Rec track) light-weight, 
community-driven process to focus on getting consensus on a "spec". But, 
that appears to be the role of the Incubator Activity. If this group 
hasn't done so already, perhaps it would be useful to review the XG 
process to see if its process could be re-worked such that it would be 
"good enuf" to attract the other groups we want to bring to the W3C.

-Art Barstow

On 7/6/10 8:03 PM, ext Arnaud Le Hors wrote:
> 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 <http://www.w3.org/2005/10/Process-20051014> 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
>

Received on Wednesday, 7 July 2010 11:45:21 UTC