W3C home > Mailing lists > Public > www-archive@w3.org > September 2013

Re: Rethinking WG Charters and rechartering

From: L. David Baron <dbaron@dbaron.org>
Date: Sat, 14 Sep 2013 06:17:25 -0700
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: w3c-ac-forum@w3.org, www-archive@w3.org
Message-ID: <20130914131725.GA25249@crum.dbaron.org>
I strongly agree with Daniel's message.  I believe it may be useful
for a super-group (HTML, CSS, WebApps) charter to document
priorities (and maybe even document disagreement about priorities),
but I don't think a list of fake deadlines for deliverables makes
sense.  (And that's despite my position that we could benefit from
more cutting of difficult pieces in order to ship specs.)

An alternative to documenting priorities in one big discussion,
perhaps, is to allow working group members to disagree about
priorities when actual prioritization happens in practice.  One
example of such prioritization is how to allocate meeting time.  (I
suspect it's useful for the chairs to have observed the discussion
about priorities in order to do that well, but I don't think it
requires that the group reach agreement about priorities.)  Another
example of actual prioritization is my response to a question as to
whether I was going to do the work needed to advance
css3-conditional from CR to PR, and my response was that I was
prioritizing that work lower than the edits needed to get
css3-transitions and css3-animations to Last Call; nobody in the
group responded to my saying that with the suggestion that my
priorities should be the other way around.

On Friday 2013-09-13 15:54 +0200, Daniel Glazman wrote:
> 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.

Six months, you claim?  I couldn't find evidence of a recent CSS
rechartering that was that fast.  The last three:

  discussion started on or before 2005-02-28:
  http://www.w3.org/mid/BE48E522.55319%25tantek@cs.stanford.edu
  charter announced 2006-06-28:
  http://www.w3.org/mid/44A2FE14.4050003@w3.org
  ==> 16 months, 0 days

  discussion (under new chairs) started on or before 2008-04-15:
  http://www.w3.org/mid/0CB208C5034ED243871C102FD3043F77081FD69210@G6W0268.americas.hpqcorp.net
  charter announced 2008-12-03:
  http://www.w3.org/mid/1228325152.16562.101.camel@localhost
  ==> 7 months, 18 days

  discussion started on or before 2010-08-23:
  http://www.w3.org/mid/4C7CF525.9070605@inkedblade.net
  charter announced 2011-12-14:
  http://www.w3.org/mid/7FB41DD8-58BC-41E6-A178-A96931573426@w3.org
  ==> 15 months, 21 days

So other than the unusually fast rechartering right after you and
Peter took over chairing the group, the norm seems more like 16
months.

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

I think the idea of distinguishing here is a good one, but I don't
think I agree with the distinction that you've drawn.  I think the
major/minor distinction might just be a subjective distinction best
left to the discretion of the team.

For example, I don't think a change of chair should require a full
rechartering.  (I don't think it currently requires a new charter.)
Likewise, changes to things like the decision process, communication
procedures, confidentiality, or other rules of the working group
needs to fit in to one category or the other.

Might the reality be that the major/minor distinction ends up being
simply whether it's been a long time since the last update, and the
bulk of the substance of the charter needs to be revisited?

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

Received on Saturday, 14 September 2013 20:09:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:23 UTC