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.

I agree with Art here, although I would also add that it is possible the
W3C Rec process itself needs to be tweaked so there is an easier bridge
from non-W3C work and work from totally outside the consortium to come to
the W3C. A *lot* of people view the membership criteria as a huge hurdle
that makes the W3C a virtual no-go for some entire fields of very
important work, such as the Social Web work.

 I think the "Project Reviews" of the Team used to do this, but there's
just too much happening, and "Member Submissions" can only address
innovation happening within members. So, one possibility that's been
brought up that could happen even before a new and improved W3C
lightweight process is worked out is the idea of having communities just
post their work to the W3C. Then a "light-weight" process can provide
mailing lists and IP help so that the work can eventually go into Rec
track with full RF patent agreements. This to me is the most important
part of the process, although I'd agree that even normal W3C Rec track
should be made more agile ideally.

I also like "W3C Community Specification" rather than "Incubator Group and
"Submission", both of which don't sound quite right to me. Earlier I
thought "Public Submission" might be a good word for this. Another could
be "Draft W3C Community specification".

I think one of the most interesting facets I've seen alot is that most
draft specs I've seen since Atom is that they do "not" look like W3C
specs, but instead use the IETF stylesheets. When I ask why, usually the
answer is that the developer is not a member and seems to have no chance
of being one or is not familiar with the W3C process and thinks the IETF
is a lightweight alternative.

>
> -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 Saturday, 10 July 2010 16:47:13 UTC