Re: Rethinking WG Charters and rechartering

Daniel,

Thanks.  You have started a great thread.  Nearly 50 thoughtful posts 
looking to address your issue and looking at the problem from all angles.

I don't want to stop the discussion, so I hope people continue to post.  
But I did want to share that the AB took up this topic at its 
face-to-face meeting last week and decided that we need to address it.  
That doesn't mean an instant answer, but we will start a task force soon 
to look at a variety of these issues related to Supergroups.  It will be 
led by Chaals and we will be looking for volunteers who can devote the 
time to help analyze various alternatives and bring forward a proposal 
to change.

More details when we publish a summary and minutes of the AB meeting - 
probably some time next week.

Jeff

On 9/13/2013 9:54 AM, Daniel Glazman wrote:
> Dear ACs, AB, W3C Staff and Chairs,
>
> This message is about rechartering long-term Working Groups like the
> CSS Working Group, a currently complex and highly time-consuming
> process that I feel is not adapted any more for such Groups. The
> formal process of rechartering has, at least from my point of the
> view, the following goals:
>
> 1. set/modify the scope of the Group
> 2. list the specs developed in the course of the charter and allow
>    patent review of scope and specs
> 3. set expected milestones in the course of the charter
> 4. set expected deliverables in the course of the charter
> 5. allow management and control by both Staff and ACs of the activity
>    being done in the Group
>
> (I didn't mention Liaisons above on purpose)
>
> Writing the above takes a lot, really a lot, and too often too much
> time. As an example, previous rechartering of the CSS Working Group
> took six months, using considerable confcall and ftf time, impacting
> drastically the co-chairs and Staff contacts.  Furthermore, setting
> milestones is extremely difficult since reaching these milestones
> highly depend on vendors' strategies, test suites' development and
> code implementations that can deeply change in the two or three years
> of existence of a charter.
>
> For a Group like the CSS Working Group, the scope almost never
> changes; the list of documents we work on includes several new
> proposals per year even if they remain in Editor's Draft state; the
> fact they remain in ED until we recharter tend to make vendors ship
> non-standardized features. We keep them as ED until next charter
> period because charter amendment is too painful. We care about the
> milestones only when we write the Charter because of the reasons
> outlined above. The list of deliverables is I think a criterion that
> is not representing correctly the success or failure of an WG's
> activity. Let's take again the example of the CSS Working Group:
>
>   SUCCESS: moved from 10 active contributors to more than 30!!!
>   SUCCESS: Authors' community adopting our new features at fast pace
>   SUCCESS: did not release a single REC or PR between '98 and '08;
>            several RECs and PRs between '08 and now but not necessarily
>            the ones that are listed as deliverables in the course of
>            the Charter...
>   SUCCESS: many new proposals on the table
>   SUCCESS: new members outside of the browser industry
>   SUCCESS: new well established liaisons
>   FAILURE: some specs taking more time than expected
>   FAILURE: vendor prefixes are still our official preferred solution
>            for experimental implementations but they're not optimal
>   FAILURE: we have many, many documents on the radar, all submitted and
>            accepted by the Group's membership
>   ISSUE:   establishing the list of priorities of the WG requires
>            strategic/confidential data from the vendors and that's
>            (very) difficult to get
> and so on....
>
> All in all, the current Charter's format is unadapted to a Group like
> ours and the rechartering or charter amendment process is too complex
> and time-consuming. I understand that one of the reasons why a WG like
> the CSS WG has to go through this very formal rechartering process is
> because it was, a few years ago, a failing WG. This is not the case
> any more.
>
> Both as the co-chairman of the CSS WG and the AC-Rep for Disruptive
> Innovations, I have the feeling that we now need to discriminate
> better between long-term Working Groups like HTML or CSS on one hand,
> and Groups created to perform one task or one set of tasks only before
> a shutdown on the other. For the latter ones, the current form of
> Charter process is probably ok. For the former ones, I suggest the
> drastic following changes:
>
> 1. initial Charter process identical to current process
> 2. no expected milestones, they're close to random anyway
> 3. no list of deliverables, the ideal set of deliverables is the list
>    of actively maintained documents...
> 4. list of documents actively maintained
> 5. "rechartering" implies a change of WG name, Scope or co-chairs,
>    process then identical to current process.
>
>    if no "rechartering", it is a "charter update" that implies only
>    the submission by the WG, based on minuted consensus, of a new list
>    of actively maintained documents to W3M no longer than 7 days after
>    consensus. W3M updates Charter and notifies ACs for review of the
>    proposed Charter within 48 hrs. Without formal objection, the
>    updated Charter is tacitly adopted after 4 weeks. W3M and WG
>    address non objecting comments until both WG and commenter are
>    happy with answer or there is evidence commenter has not responded
>    to changes on his request.
>
>    An update request sent by a WG to W3M must have a companion
>    document listing all documents actively maintained by the WG at the
>    time of the request, from Editor's Draft to REC. The document
>    should display for each document:
>      - if it was started since the last charter update
>      - its current status (including Test Suite's status)
>      - if it is dropped in the update, reasons why it is dropped
>    That companion document is sent to ACs "for information"
>    with the update notification.
>
> 6. A WG must be rechartered or have its charter updated at least every
>    three years. That process must start at least two months before the
>    update deadline.
>
> Such a process still allows patent review, management and control of
> the WG while *drastically* simplifying Charter management. Addition of
> a document to or removal of a document from the list of actively
> maintained specs is simple and fast. Charter update is not
> time-consuming. Management and control implies a better observation of
> the WG by W3M but I don't think it's an abnormal thing...
>
> Even if you feel the above is not what should be done, I wish the
> current message could trigger not only a discussion, but also a change
> in the *very near* future. The CSS WG is currently rechartering and
> the process involved is just *overkill* every two or three years
> (remember, six months of efforts last time...). We just cannot
> continue like that.
> If a change of the magnitude proposed above is implementable in the
> coming months, I am ready to ask for a Charter extension for the CSS
> WG in order to benefit from the change.
>
> </Daniel>
>
>

Received on Wednesday, 25 September 2013 00:16:43 UTC