Re: CfC: Adopt Proposed Decision Policy

Maciej Stachowiak wrote:
> 
> 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 would be quite prepared to declare consensus on any document which has 
had adequate review and no remaining open issues or bugs.

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

Shelley, perhaps I'm jetlagged, but I simply don't understand this 
statement.  Given that it is essentially impossible to prevent an edit 
(not just by Ian, but by pretty much anybody), I don't understand how 
getting an edit changed can be any harder than something that is 
essentially impossible.

Particularly, as I see previous edits being changed every time I look at 
the subversion/cvs logs.

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

I don't see how the solution proposed above addresses the perceived 
deficiency (stopping edits from happening).

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

It just occured to me that *theoretically* this places the editor in a 
position of creating a denial of service attack -- simply by not 
responding.  Note: I said theoretically; the reason this never occurred 
to me before as I don't expect this ever to happen in this working group.

My preference for how to handle purely theoretical issues is to address 
them if and when they actually occur by adjusting the process at that time.

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

Assuming that we have an editor that keeps on top of things (i.e., we 
don't have the theoretical issue mentioned above), I don't see how the 
process of requesting that people create a bug report makes it 
materially harder to raise a tracker issue.

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

I agree with this.  And would add that we should only fine tune it based 
on actual experience, and not speculatively based on what might happen.

> 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

- Sam Ruby

Received on Monday, 2 November 2009 05:00:54 UTC