What to slash Re: Proc Doc: time to Slash and Burn, Divide and Conquer, or what?

On Thu, 23 May 2013 16:35:56 +0400, Arthur Barstow <art.barstow@nokia.com>  
wrote:

> [ Sorry for the cross-posting, especially to a Member confidential list.

Good. I hate cross-posting. I replied to the public list - I will tell the  
people on the other list where to find the discussion and how to  
participate...

The process document [1] is under the W3C license. I don't have permission  
to re-distribute a derivative work here, so I'll just refer to things in  
it. And I'll break this discussion into separate sub-threads...

> I just scanned the Process Document's (PD) Table of Contents [ToC] and  
> it seems like it could use some refactoring to enable more frequent  
> updates and clarifications - you know, in case we want the Consortium to  
> be more "agile", and in case we don't want to wait another 8 years for a  
> PD update ;).

:) Yes. I (and others) have done some experimentation. I don't think  
publishing here without permission is "fair use", but I believe sending a  
copy of what I have to individuals on request for the purpose of review  
and discussion is OK.

> Here is my first off-the-top-of-my head pass at a refactoring ...
>
> First, differentiate information that should be continuously updated  
> versus information that needs to "stable" where a course "stability  
> test" would be something like "gee, if I change X, it's really going to  
> screw up what WG Y is doing so we need to be really careful about  
> applying X without seeking broad consensus on the change".

Actually first there is some content that I think can just be removed, as  
unnecessary.

The Process basically documents some agreed obligations. At the moment it  
contains a lot of explanation and advice too, and while some of that is  
valuable I would prefer to trim the text and make those clearer. From my  
own experiments I think it is possible to cut the size of the document  
substantially without making any substantive change.

There are also some specific provisions that I don't think are necessary  
to define at all (I'll talk about splitting the document in a separate  
message).

Activities. (Most of chapter 5, but some of that talks about chartering  
WGs/IGs and is still necessary)
These are internal details of how W3C organises itself. There is no real  
reason for even the members to care about the particular management  
structure used, just whether it works or not. If W3C wants to use  
activities forever, so be it, if they want to change tomorrow, I don't see  
a problem.

Good Standing. (Used in chapter 3 "decision making" and defined in 6.2.1.7)
Some groups want to have rules about participation requirements, others  
couldn't care less. Having a set of rules in the Process document is  
overly constraining the former, and irrelevant to the latter. So this can  
go, except one line requiring proposed charters to define any specific  
participation requirements beyond those applicable to all  
members/team/"invited experts".

Working group "heartbeat" requirement (6.2.7)
Working groups should publish "regularly" - a statement that belongs in  
chapter 7 (life cycle of a spec). The rest can go.

Coordination Groups. (6.3)
These are just Working Groups whose deliverables are defined in terms of  
other working groups talking to each other. Some parts of W3C still uses  
them, some parts don't. I believe that the parts that do can happily  
charter them them as ordinary working groups, so the section in the  
document can go.

[1] <http://www.w3.org/2005/10/Process-20051014/>

cheers

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Thursday, 23 May 2013 13:56:54 UTC