Re: Limiting Charter extensions

22.12.2014, 13:01, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>:
> 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?

Right. This seems a sound reason for not spending a lot of time on the discussion...

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

Exactly. Companies change priorities quite rapidly.

It makes more sense to set out the deliverables, and be clear that their priority within the group will depend on who works on them.

I have similar experience within webapps, where I pointed out to a group of companies using a particular technology that it looked like there would be no movement for some time, unless they stepped up and did the work, which would mean declaring they were using these technologies (which in fact was about as open a secret as there is).

A year or so later when my predictions had come true, representatives would ask me if there was any chance of getting the technologies updated again - to which I replied that if they wanted to do the work they didn't do before, it might be possible. But harder.

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

You mean, based on what people are actually working on this week/month? That makes a lot of sense.

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

Indeed.

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

I believe that rechartering to add deliverables is the right thing to do. In paticular by the members of the Working Group, but also by the members of W3C who are currently not in the group, and by the rest of the world.

To explain the last point: If adding a new deliverable brings a new member into the group, who provides a new patent commitment and implements some more technology, I think we are Doing The Right Thing™

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

Which is what we have.

> 2. an other document listing all the documents it works on, and the
>     extra liaisons on a per-document basis

Currently that is a chapter in the charter. I would be happy to split charters into two pieces, if that is helpful...

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

This would essentially mean a change in the Process, so that the deliverables could be altered by a consensus of the *members* of the WG, as expressed by their AC reps. I don't think I have a fundamental objection to that, assuming there is an opportunity for the AC at large to appeal.

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

If the charter review has been announced to the membership each time, then a review of the working methods etc within 3 years seems feasible.

At which point I think there is a proposal that is workable.

But there is an issue here that I believe is really unresolved. There are some people who consider that when a new charter is created for an existing group, under the Patent Policy that is an entirely new group, which affects the carry-over of patent commitments. There are others who believe that a group of the same name, a continuously evolved but recognisably continuous set of deliverables, roughly the same people, and with a charter that says "this is the Nth charter of the group, changes from the last charter include…" actually implies that the group is the same group for the purposes of the Patent Policy and Process.

I believe it is relatively straightforward to clarify this either way in the process, if the membership can come to consensus on what they want it to say. As far as I know, neither PSIG, nor the AB, nor the AC, nor the process Task Force have ever actually reached such a consensus - and that issue is 4 or 5 years old at least.

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

Indeed, as far as I can tell most of the members still haven't looked seriously at the issues.

> So why do you think this is simpler at the lower level?

Because the required quality threshold for "ETA" is "a quick guess". The serious delay seems to be in taking decisions - in WGs, in W3C internal review, when the Director considers the AC review.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Monday, 22 December 2014 11:43:16 UTC