Re: CfC: Adopt Proposed Decision Policy

On Sun, Nov 1, 2009 at 10:59 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> 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 agree, I would also. I'm not asking for a change in how we form consensus.

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

It is not the editing that is the issue, but the reluctance to make
changes once the editor has committed time and effort into making a
change.

It is easier to argue against something which has no effort expended
on it, then to argue against something that has received a significant
investment of time.

But as you and Maciej have stated: Ian can do make any edit he wants anyway.

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

True, it is more a philosophical concern than anything can be possibly
implemented in this group, given that Ian can make any edit he wants.

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

I'm confused.

This procedure was supposedly being put in place in order to ensure
that problems don't arise, and folks were asked to provide comments
before a deadline of November 11.

Now, you all are telling me that we should wait until problems arise,
and then address the issue. And, as Maciej stated further down this
message, if I continue expressing a comment, or ask for modification
in the procedure, everything has to go back to the beginning, the
clock is reset.

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

I may have missed the time when Ian actually made a proposal _before_
editing the HTML5 specification rather than after.

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

Perhaps next time you should refrain from asking for comments if you
have no interest in hearing them.

I withdraw my comment.

Shelley

Received on Monday, 2 November 2009 12:49:37 UTC