Re: Ideas on simplification of process and operations

On 7 Jul 2010, at 12:00 PM, Lawrence Rosen wrote:

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

Yes, thanks Arnaud!

More comments below, but I could see trying to address the 'slowness'  
concern by identifying the "most time-consuming" aspects of process  
(generally) and trying to reduce them, either on the "Classic" track  
or by reducing them in an incubator track, or both.

Some points of slowdown include:

  * Implementation schedules of software developers
  * Public accountability
  * Pre-charter company discussions (which Larry cites below).

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

I believe that's a reasonable characterization of some of the slowdown  
that can precede charter review.
>
> Are these four steps in the current W3C process supposed to result  
> in a working group scoping document?
>
> a. Submission/Workshop/AC discussion

Those are three ways for generating discussion that can lead to a  
charter. They are not mandatory for the creation of a charter.

> b. Director announces development of Activity proposal or WG charter
> c. W3C members review
> d. Director approval

Yes, that's the process for W3C launching a new group after its  
charter has been reviewed by the Membership.

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

My answer should be "We should make it as easy as possible to start an  
incubator group, but no easier."

There are lots of ways we could make it easy for customers while still  
maintaining some quality control. Here are some of the dials we can  
adjust. I've marked with [XG] the settings of our current Incubator  
Activity. Obviously to reach more people we would be adjusting our  
Incubator Activity to meet the needs of a broader audience. The  
statements below are surely incomplete but this is a rough  
approximation:

Charter requirement:

    a) None
    b) Charter required
    c) Charter required, must have minimal support by peers (e.g., 3  
people must sign on)
    d) Charter required, must have minimal support by peers, W3C staff  
must give ok [XG]

Initial copyright-related commitments:
    a) None
    b) W3C Document License  [XG]
    c) MIT or other open license

Initial patent-related commitments:
    a) None
    b) Disclosure requirement over deliverables
    c) Non-assert, no license commitment
    d) RAND for the group's deliverables
    e) RF if the group's deliverables are taken up by a W3C Working  
Group [XG]
    f) RF for the group's deliverables

There are other start-up costs as well that we can adjust (but doing  
so has a cost):

  * Cost of participation (e.g., membership fee)
  * Resource allocation (e.g., time to set up wiki, mailing lists,  
etc. since these are staff-managed resources.

I am sure people could come up with other options for all of the above  
categories. There are also mid-process costs like handling comments,  
publication requirements, review periods, etc.

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

I'm not sure I understand the comment. I wouldn't want to say "you  
can't have a document until you have an implementation" any more than  
I would want to say "you can't have an implementation before you have  
a document." Whether you call that document a "standard" is another  
story. I wouldn't want to call something a standard that doesn't have  
any implementation experience.

I probably need to understand better what you mean by "graduating to  
publication status." You may mean "move to the standards track."

Here are some statements we want to address through some fair processes:

* "I don't want to review the specification until it's very stable; I  
don't have time for multiple reviews."
* "I don't want to start implementing until the specification is  
stable."
* "I have deployed code already and can't make changes, so I don't  
want the spec to change (e.g., as a result of community review)."
  * "I want to start implementing from day one, and to write the spec  
at the same time; the specification should be a live document that  
reflects the current state of implementations."

There are many other statements and desires as well, of course. I  
expect that we can do a better job than the current W3C process at  
satisfying diverse needs, and two processes (classic, incubator) may  
help get us there, but I haven't yet heard the full plan. That's what  
we're working on. :)

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

Thanks for that summary; I've been meaning to get a better  
understanding of the OWF approach (and signed up to that mailing list  
today, btw).

Given your description above, I have a couple of questions:

  * How do you establish what an "actual contribution" is? The W3C  
Patent Policy Working Group avoided having to answer that question in  
the resulting W3C patent policy.

  * Given that people make contributions at different times, it sounds  
like in the worst case scenario, someone contributes the "last part of  
a specification" and the people writing the specification would  
probably want to wait the 45 days to see whether the contributor opted  
out for any part. My guess is that the 45-day window is probably  
significantly shorter than the total specification development time,  
but it could potentially add some time to the spec development process.

   * I am assuming that some parties will wait until the spec is  
"complete" before they sign the non-assert for the entire  
specification. Is there any expectation that they will be expected to  
do so within a particular time window? It seems to me reasonable for  
the group to be able to say "We're done and we expect everyone to sign  
the non-assert real soon now" for a limited time.

  * What happens if a contributor chooses not to sign the non-assert?  
Obviously, that would be bad PR. In the W3C incubator group process,  
some organizations have said "We won't join an incubator group where  
there's a chance that someone might pull an IPR stunt after a year's  
investment." Do you have a way to mitigate that concern? Or do you  
think it won't happen?

  _ Ian


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

--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447

Received on Friday, 9 July 2010 22:37:40 UTC