W3C home > Mailing lists > Public > public-w3process@w3.org > December 2014

Re: Limiting Charter extensions

From: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Date: Mon, 22 Dec 2014 11:00:16 +0100
Message-ID: <5497EBB0.6030404@disruptive-innovations.com>
To: public-w3process@w3.org
On 21/12/14 23:56, Jeff Jaffe wrote:

> If prioritization is in the hands of the implementers, why not use the
> re-chartering exercise as an opportunity to have a focused discussion
> with the implementers what the priorities are?
>
> It seems you would need that anyways, because otherwise the WG will not
> be working on the relevant priorities.

Because nobody can say what are going to be the priorities in more than
6 months time? They depend on the market, on the browser war, on so many
variables that we've never been able, in 16 years of modularization of
CSS, to do that accurately. We've tried to query, in full
confidentiality, the implementors about that. They responded positively,
it took a lot of time to aggregate the data, and we still had to discuss
the results for months. In the long run, the resulting list was almost
useless, and the priorities we did set were shuffled several times along
the course of that Charter.

The priorities are much better defined by the activity inside www-style,
and that's exactly how we gather the agendas of our conference calls.
Even if a document is listed by a Charter as "high priority" and even if
the chairs and W3M send the Group messages that the document is "high
priority", there is nothing we can do if the _real_ industrial priority
of the moment for the implementors is something else. We've seen that
happen multiple times in the past.

Furthermore, the CSS WG is a very innovative WG, with new documents
emerging all the time. The fact they're not chartered is a blocker,
giving a bad signal about our (W3C) ability to cope with new stuff.
In theory and full respect of the process, new documents require charter
amendments, a bureaucratic system I have been warning about for years,
still unfixed.

What I think we need for a supergroup like the CSS WG: we need
pragmatism.

1. a Charter defining the scope of the WG, the way it works, the
    chairs, the staff contact, the mandatory liaisons.
2. an other document listing all the documents it works on, and the
    extra liaisons on a per-document basis
3. a super-light process to add or remove a document to/from that list,
    for example a WG resolution, period. I repeat: nothing more
    complicated than that. The members of the WG would take the question
    back to their AC, have two weeks for that; two weeks later, consensus
    or not. Done.
4. extending the lifetime of the WG would be only a question of
    prompting the ACs about the existing Charter and the current list of
    documents. Of course, updating the Charter's contents would still
    be possible.

Let me finish by something important: the Process currently requires
ETAs for specs. It does not require ETAs for process changes. In
the current case, we're 15 months after the initial description of the
problem and we're still totally unable to give an ETA for a lighter
supergroup process. So why do you think this is simpler at the lower
level?

(taking a few days off, not sure I'll be contributing to this thread
  again before friday)

</Daniel>
Received on Monday, 22 December 2014 10:00:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:25 UTC