Re: Limiting Charter extensions

+ peter.linss@

Hi Daniel,

(Peter, question at the end)

25.12.2014, 22:52, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>:
> On 25/12/14 13:59, chaals@yandex-team.ru wrote:
>> šI am not convinced that it is overkill for supergroups like CSS.
>
> Were you writing this as an AC or as an AB?

Both, actually.

> If you wore your AB hat, I am not asking you to be convinced or not, I
> am asking you to take that feedback, from both the WG and a co-chair of
> the WG, under account as an AB Member supposed to represent all ACs.

I hear the feedback. I am suggesting that there is a simpler way to do this, so it isn't overkill.

> 35 CSS WG members meeting in Paris last year said, consensually, this
> is overkill. I think the Staff contacts of our Group can testify the
> process was overkill. I also think they already did it in
> the past. And did you really read what dbaron wrote here in this
> mailing-list?

Yes.

> We did what we did because the Process instructed us to determine
> estimates for deliverables and priorities. We prompted W3M about it,
> and the obligation to do it was confirmed, twice.
>> šI have gone through it several times with webapps, which is comparable, and I think the actual burdens imposed by the process are reasonable, and not excessive.
>
> Your opinion is for WebApps. I disagree entirely for the CSS WG and
> I never dared - and will never dare - expressing an opinion for other
> Groups, in particular a WG I'm not a member of.

OK. But unless we can get people who express opinions for more than one group, we're never going to be able to solve this problem sensibly. (See the blind men and the elephant).

> There are a lot of areas where the process is excessive and gives a bad
> opinion of W3C to many spec contributors. This is one. We had to
> spend countless hours of meetings and calls for each rechartering, up to
> the point Members had enough (and I can easily understand them)...

I understand this. I am suggesting, as a chair of Webapps and as a former staff contact for a few groups, that you could make it simpler and still meet the process requirements - which were confirmed a year ago by the AC at large as what they want.

> Contributing to W3C costs a lot, and the time of individual contributors
> is best spent ON SPECS, not on process.

Sure. That's why I spend my company's money trying to make the process simpler.

> Let me repeat: the whole WG and the co-chairs reported a big issue 15
> months ago and I still have to "convince" you to listen to our WG's
> feedback? Seriously?

No, I am listening to your feedback. I am trying to find a solution. As I understand things, your suggestion of not giving any information about milestones - incidentally the same proposal that Art and I made from Webapps - has already been rejected by the AC as a whole. I am looking for something that won't get rejected but also won't force Working Groups to spend ridiculous amounts of time on process requirements.

>> šSo if these things are really just a guess (and I agree they are) why do you make a lot of effort to agree on them? The process doesn't require anywhere that you spend months trying to predict the future, just that you set some rough expectations.
>
> Why do you make assumptions like that? The first time we
> rechartered, we tried to do it really well. Took a year. Second time,
> and because of that first experience, we decided to do it roughly.

I make the assumption, because you said as much, that you spend a lot of time trying to come up with what are really just rough guesses.

I don't think it is an assumption that people can make a rough guess and decide it's as near as they really know, in a short time - because I have seen it done, often.

> Still took months. I am saying there is no way for a group of 15
> active organizations to find a consensus on even the priorities
> of 70 specs in only a few hours of work, in a context of browser war.

I agree (and already agreed). But since the Process requirements don't actually mention that information, and we agree you can't get it in any meaningful sense, I don't know why you are spending time trying. My suggestion is that you don't, and focus on the actual requirements - a rough estimate of when milestones might be delivered.

> Put it in another way: the global $$$ cost of our recharterings is
> truly shocking, and I am saying this is because of the Process
> constraints. Can we please stop wasting $$$ and be pragmatic again?

That is what I am trying to do. One constraint is the cost of you following the Process, but another is the fact that the Process is an agreement of the W3C members, and blowing off that agreement has its own significant costs.

>> šI believe the upshot of the discussion at that time was that AC reps appreciate getting at least your guesstimates, even if we understand they may turn out to be wildly wrong.
>
> Sorry, this is probably me, but I cannot understand how one can
> "appreciate" data that "may turn out to be wildy wrong" or how
> such data can be useful to anyone. Unreliable data are not only
> useless but potentially dangerous.

They are indeed potentially dangerous. As an AC rep, I look at data about what people expect to deliver, and generally consider it a "terminus post quem" - i.e. a minimum estimate that is probably optimistic. That's more useful than me trying to come up with a minimum guess of when things might be done.

And I note that there are groups who deliver roughly on time (EXI, HTML5 have done this) as well as groups whose estimates I don't even bother reading.

> Ok, AC-Reps expect data. There are only two possibilities here: it
> is OR it is not possible to provide them with data. I am saying
> that, in the general case of our WG, it is not.

Nonsense. The question is the quality of data.

> We can easily give a list of documents, yes. But even prioritizing
> 70 documents in 3 categories will take hours of work and probably
> three iterations. Make an educated guess about my opinion here...

Sure. And I agree that trying to pick priorities is a waste of time.

That said, you could probably come up with a timeline for milestones that represents the best guess of the relevant editors, and write it down, in a fairly short amount of time. Webapps does this for most of 50 specs in an hour of meeting time, and that's the information that goes into the charter.

>> I don't think anyone suggested you should spend a lot of time trying to pin them down to perfection, and I don't see anything in the Process that requires you to do so.
>>
>> šIt strikes me as reasonable that there is some effort required in maintaining a list of deliverables for a group whose scope is very broad, and it seems that there are good reasons for having such groups. But if the expected milestones are a big cost in maintaining that list, I think you're doing it wrong. Ask the editors, and unless someone disbelieves them, that should be it.
>
> We tried several approaches in the last decade. None of them worked.
> There are different reasons: confidentiality, industrial practices
> (have you ever heard Apple say what their priorities will be six
> months later?), time to get feedback from AC-Reps and Legal,
> and so on. Even a VERY rough estimate takes months to evaluate.
> Do you understand this fuels the "W3C is irrelevant" comments?

Yes. On the other hand, so does "oh, we'll do it when we get around to it, we don't really want to work to a schedule, or deliver any time *this* decade". Somewhere in the middle of that is a sweet spot we are looking for.

> Of course, nobody suggested we spend a lot of time on rechartering!
> But we were told we HAVE to provide estimates or prioritization

As far as I can tell from reading the Process, you currently have to provide rough estimates. As far as I can tell from reading tealeaves, the AC list, etc, the members generally believe that should not be changed. I think that makes more sense than providing prioritisation for the reasons we have agreed on already. Note that I am only about 0.25% of the AC reps, and probably only represent a few per cent of those who actually commented on the topic.

> even
> if we said it takes too much time to do it. In short, this means one or
> both of the following items:
>
> ššš1. you don't work well on this, better execution would cost less time.
> ššš2. we don't care; "dura lex sed lex".
>
> All your message lets me think you're on the "both" side.

Yes, as it happens I am. BUT

At the same time, I am suggesting that there is a fairly simple path to reducing the expense of doing this to a point where it is reasonable and meets what can reasonably be expected. I think you are working far too hard, to do far more than can reasonably be, and more importantly more than actually is, expected.

> My personal feeling is that I am fed up with having to detail and
> explain an costly issue like this one.

I understand the issue. The question is what solution will be accepted by the AC. As I understand things they were asked, and I believe a lot of those who replied also understand the issue.

> I will fully randomize the
> priorities' or time estimates' section of our next rechartering and
> submit it "as is" for AC vote.

That strikes me as the second most irresponsible choice possible, essentially giving a %^#$&%* you to the 90% of the membership who are not in CSS. (The most irresponsible IMHO is that of groups that just don't actually recharter, and I think that is a long way worse).

If this is the formal position of the CSS chairs, I'd like to know. 

If it's just an expression of the level of frustration you have, I understand, but I repeat: I believe you are trying too hard to do something impossible, and that it would be acceptable for you to spend far less effort doing a far rougher job of guessing sensibly at when deliverables might happen, and submitting that "as is".

cheers

Chaals

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

Received on Friday, 26 December 2014 01:10:44 UTC