Re: CfC: Adopt Proposed Decision Policy

On Nov 1, 2009, at 5:47 AM, Shelley Powers wrote:

>
> There are problems with this procedure, which will, most likely, arise
> regarding the issue of named entities.
>
> On the one hand, you have the individual who wants a change in the
> document; on the other, you have an editor willing to make the change.
> But no where in this do you have consensus of the group.

I think you may be drawing an unwarranted assumption about the issue  
of entities in XHTML. The reason we're discussing it on public-html is  
because Ian did not want to make the change without discussion.[1] You  
are right though that the policy allows an initial editor's decision  
to be made based on an incoming comment, if the editor agrees.

> In fact, no where in this, do you anything preventing the editor  
> from making
> changes, even if there isn't consensus of the group, and as we've come
> to learn it's much more difficult to get an edit changed then to
> prevent an edit in the first place.

Indeed, the policy is all about how Working Group members can get  
edits to happen (including reverts of past edits). At this time, it  
does not attempt to prevent any edits from happening. The goal of the  
policy is to let every member of the Working Group do meaningful work  
that will affect our deliverables. Making it easy to prevent things is  
not a goal.

>
> If we add more steps in the procedure, though, then that causes
> significant overhead when all the bug is, is to fix a typo.
>
> I would suggest we add one more change: that if a person who sees a
> bug has reason to believe that the bug represents a significant change
> to the document, they can immediately escalate the bug to an issue.
> Even if the "bug" is something everyone agrees on, it should still be
> discussed in the group, not decided between the one person submitting
> the bug, and the editor. The latter is not much more than what we have
> now, if the two are in agreement.

One thing I'd like to clarify: anyone can escalate a bug to a tracker  
issue once there is an editor's response, it doesn't have to be the  
originator. So if someone makes a spec comment that leads to a change,  
and a third party doesn't like that change, they can escalate to the  
tracker.

What the process does not provide for is a way to escalate to the  
tracker before the editor of the relevant draft has weighed in. I'm  
hesitant to change that at this time, for a few reasons:

1) Historically, it's been too easy to raise a tracker issue and thus  
create an obligation on the Working Group, without a clear path to  
resolving the issue or a willingness to follow through on the part of  
the issue raiser. Part of the goal of the policy is to make it less  
likely that tracker issues are raised speculatively.

2) Per our charter[2], we're expected to typically let an editor make  
an initial proposal, before escalating matters to the full Working  
Group. The proposed decision policy tries to be consistent with this.

3) The policy has been through many rounds of revision and is now up  
for a Lazy Consensus resolution. If the policy is changed further,  
then I'll feel obliged to restart the clock on the Call for Consensus,  
delaying the possible adoption of the decision policy. I think the  
policy is enough of an improvement over the status quo ante that I  
personally would rather start using it, and fine tune it later once we  
have more experience.

That being said, I'll try to discuss this issue with my co-chairs  
during TPAC week.

For the named entity issue, once there are bugzilla bugs, my  
suggestion to you would be to encourage the editor to reject the  
comment, and if that doesn't happen and you don't like the outcome,  
escalate it to the tracker.

> It's a little more cumbersome, but that's the problem with using using
> a bug database to track what could be significant changes to the
> specification. However, with the ability to bypass the
> commenter-editor response and immediately escalate an item to issue,
> hopefully we'll have the ability to ensure that significant or
> controversial changes to the specification are at least fully
> discussed, with proposal and counter-proposal to the group.

Certainly any issues where someone makes the effort to escalate it  
will be discussed by the whole group before the spec moves forward in  
maturity level.

Regards,
Maciej

[1] http://krijnhoetmer.nl/irc-logs/whatwg/20091030#l-588
[2] http://www.w3.org/2007/03/HTML-WG-charter#decisions

Received on Monday, 2 November 2009 00:50:55 UTC