Re: Limiting Charter extensions

On 12/22/2014 5:00 AM, Daniel Glazman wrote:
> 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.

At some point, we might want to move the discussion from the W3Process 
list to ac-forum.

This is because I am under the impression that the AC holds W3C 
accountable to make an effort to predict milestones when we bring 
forward a Charter.  And I think that it is reasonable, since they want 
to make sure that we invest the resources of the consortium 
appropriately.  It would be interesting to see if the AC would be 
willing to support Chartering groups that make no specific commitments 
(even supergroups with long histories of successful contribution).  
Additionally, in the Supergroups task force there was general consensus 
(above your objection) that proposed charters should provide information 
about expectations for progress.

 From my personal point of view,  I don't quite see the conflict that 
you see in quickly developing milestones.  I hear you unhappy about the 
long time it takes to identify milestones for the Charter.  It takes 
months to collect all of the information and that results in milestones 
that you find useless.

But I don't know why the group would spend months getting something 
useless.  Wouldn't it be easier to poll the WG to get their best effort 
input as to the most likely priorities  That would result in a set of 
milestones which presumably are as good as the ones you currently 
develop after many months.

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

This is a proposal that I believe that I am in agreement with.  In his 
response, Chaals listed some concerns with this: specifically wanting to 
create a method for the AC to weigh in on such amendments.  And I have 
some sympathy with his concerns as well.

How can I be agreeing with both you and Chaals?  Because I suspect that 
we need another level of definition before we can resolve this.

I think in most cases, we should be able to write Charters that are 
flexible enough to allow new work without further modification of the 
Charter (I hope that PSIG doesn't tell me I am completely wrong).  If 
the original writing of the Charter has some allowances for this, and 
the new work is sufficiently close to the existing scope, I believe this 
is possible.

OTOH, it is also possible to imagine "brand new work" which would 
require re-Chartering.  I'm guessing this is rare.

To test my theory, I would be interested in learning what CSS features 
could not be addressed without re-Chartering in the last three years.  
Let's see if this problem is solvable in the current system.

Btw, you will recall that in the Supergroups task force I made a 
proposal to make it easier to add deliverables.  I believe you supported 
my proposal (with some modifications).  Chaals, what happened to that 
proposal?

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

I would like to see this discussed in the PSIG and on AC-forum.

It is interesting.  Your response is on a thread which started with 
"Limiting Charter extensions".  Implicit in the original posting and the 
title is that the AC is not satisfied with the current lack of review 
that the AC has on the Chair/Team/Director quietly extending Charters.  
Yet you are calling for less oversight.  I think the fastest way to 
address this (as I said above) is to see if there are real blockers in 
the current process.

As I mentioned above, in the Supergroups task force, there was general 
support (over your objection) that proposed charters should provide 
information about expectations for progress.

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

I don't think it is at a lower level.  These requirements were taken up 
by the Supergroups task force.  In general, the task force did not 
agree.  But I believe that we can still find ways to ameliorate your 
concerns as I mentioned above.

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

Received on Monday, 22 December 2014 13:55:53 UTC