Rethinking WG Charters and rechartering

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 Friday, 13 September 2013 13:55:12 UTC