Re: Limiting Charter extensions

> On Dec 22, 2014, at 8:40 , Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote:
> 
> On 22/12/14 14:55, Jeff Jaffe wrote:
> 
>> It is interesting.  Your response is on a thread which started with
>> "Limiting Charter extensions".
> 
> Yes. Because the CSS WG had to use several times such extensions... The
> time needed to prepare a new charter took us beyond limits. In fact,
> I think that the two or three last times we rechartered, the CSS WG
> was in fact unchartered a few months.

CSS is (almost) unique (ouch, I know I shouldn’t qualify ‘unique’).

I think we need to decide whether we need to adjust the process so that it works for everyone, including CSS, or whether CSS will continue to be an edge case.  Yes, it’s a ‘supergroup’ but it’s different from HTML and WebApps right now.  HTML, if it fragments the HTML spec. into little pieces, could become more like CSS, however.

Why do we have charters?
* the members pay for the operation of the w3c, and they’d like to know what they are paying for
* members of working groups and their employers need to know what their expected RF commitment is
* to a lesser extent (but at least to some extent) the WG itself needs to know what they have agreed to do, not do, focus on, put on the back burner, and so on (we don’t want excessive arguments in the WGs over what’s in scope, or important)

I think this thread started on the assumption we ought to be able to set an envelope like this fairly readily.  But the supergroups pose challenges:
* CSS has a fairly clear technical scope, but it’s not clear what specs will actually make progress
* HTML has, in theory, a well-defined technical space (the markup language) but it’s constantly evolving in interesting ways
* WebApps has a rather vague technical scope (IMHO, “some sort of support for web-applications”) but fewer active specs.


For other groups, the expectation that every few years we take a look and make sure the supertanker is headed the right way, roughly, seems reasonable.

So, what is supposed to happen when a charter expires?  I rather think that the AC and staff need to decide between “we’re going to re-charter, so any extension or over-run needed is acceptable” and “we expect to close this group”, but I can’t think that there is ever *automatic* action. So the fear of ‘running un-chartered and then being automatically closed’ is unfounded.  Run un-chartered and the staff and AC might start raising their eyebrows and so on, yes.


So, initially, what do we want to do with the non-super groups?  What’s the motivation for change here?


David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 23 December 2014 00:57:53 UTC