Re: Requested addition to section 7.1

18.12.2016, 12:56, "Daniel Glazman" <daniel.glazman@disruptive-innovations.com>:
> On 18/12/2016 11:01, chaals@yandex-team.ru wrote:

>
>>  I think this overstates the case. As you suggest below, a bad judgement call on consensus is effectively a violation of the Process already. So improving the procedures used, not the rules that govern them, might well be the right solution.
>
> Not sure. A current hiatus occured precisely because the Process keeps
> the rules vague and relies on extra procedures and trust. That did not
> work well enough.

Yes, but I am not sure that putting more rules in the Process is as helpful as clarifying to the Team what we expect them to do for things that are already there...

>>  That doesn't follow, because the Process describes AC appeal as the error-correction mechanism.
>
> Sorry, I disagree. There can be an appeal when the vote is conformant to
> the Process. I don't think it was the case and I don't think the
> Process kept applying beyond that point.

My read of the appeals section - https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#ReviewAppeal in the proposed process, but it's not a radical change - is that when a decision is made, the AC can appeal it.

It is also the case that the AC can informally request the director reconsider a decision, of course.

> That said, I am not ready to call for the CSS WG Charter to be
> rescinded and submitted to vote again. But there is still a mess to
> clean, and no it's not entirely in CSS WG's hands.
>
>   - no formalized relationship between WICG and CSS WG
>   - no known constraints on incubation exit criteria from WICG
>   - "good enough" effect
>   - etc.
>
>>  That seems drastic, and probably counter-productive. Although you're free to do it of course.
>
> We have a major issue arising from a big mistake and the suggestion is
> to solve the issue in 2018 and let the CSS WG deal 'a posteriori' with
> a decision never discussed.

My suggestion is to consider whether changing the Process would help stop this, and whether dealing with it a posteriori might not be a /better/ solution - naturally alongside my suggestion that W3C learn not to make these mistakes.

>>  I generally trust that people in W3C - all across the ecosystem - try to do the right thing. And that from time to time they'll get it wrong. Indeed, that's what I do. Having people keep watch for, and try to correct problems is important. Personally, I also prefer to look for a simple solution. Part of that has resulted in me working on the Process for a few years, trying to simplify and modernise it - and alongside that, trying to promote better practice. My long experience has been that the Process was often updated attempting to "quickly" resolve something perceived as a problem, and that it often turned out we should have been looking at our practices instead, because we made the Process over-complicated, too fragile, and didn't solve the underlying problem well.
>
> Let's summarize:
>
> - 7.1.2 is tailored for technical documents, not Charters.
> - 7.1.2 is tailored for technical documents, not Process.

I disagree. I don't think the fact that substantive change is only formally defined for technical specifications makes it unclear what is a substantive change in something other than a technical specification, although a careful clarification of that section may be helpful.

> - 7.1.2 item 2 gives too much latitude to W3M for very substantive
>   changes.

I'm not so sure. 

Nitpicking, it formally gives the latitude to the director, but we all know that in many cases the work is delegated although the outcome is still his responsibility.

I also believe that it is important to have latitude to make changes, where there has been some reasonably open process of consensus gathering around a proposed resolution to an objection. I'm unhappy when that amounts to a side discussion resulting in changes that surprise other reviewers - but I think that's a failure of procedure, and I would have thought it pretty clearly violated the spirit of the process - but of course reasonable people can jusge things in different ways, as well as just getting things wrong.

> - 7.1.2 item 2 was abused.

I think, based on my understanding of the history in the specific case you cite, the team failed to act carefully enough. Something I think has happened before, and that I have complained about before.

> - Side discussions during Votes are unacceptable.

That depends on the nature of the side discussion. There are a range of side discussions that are highly inappropriate. There are others that, so long as they don't lead to a decision blindsiding the rest of the AC, seem like a reasonable preamble or accompaniment to a more open discussion.

> I am going to propose a revamp of this section in the coming days,
> modulo Christmas disruptions of course.

I look forward to the proposal. As I noted elsewhere, I hope improvements to practice make it redundant - which doesn't automatically make it a bad idea.

In the meantime since I see progress on the Team understanding the issue and improving the way they work, I'm happy to "give out some more rope" at the moment and see if things improve based on the existing discussions including this one.

cheers

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

Received on Sunday, 18 December 2016 18:17:44 UTC