Re: CfC: Adopt Proposed Decision Policy

On Wed, Oct 28, 2009 at 3:33 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> There's been a fair amount of discussion about the Decision Policy[1], and
> we've already starting putting parts of it into practice. After consulting
> with my co-Chairs, we believe it is time to formally propose the policy for
> adoption by the group. Specifically:
>
> ** RESOLUTION: HTML Working Group to adopt the proposed Decision Policy at
> http://dev.w3.org/html5/decision-policy/decision-policy.html **
>
> Note: this doesn't mean this policy is locked in forever. The Chairs are
> committed to reviewing the policy and making adjustments as we go.
>
> f you object to this resolution, please indicate your objection by Tuesday,
> November 10, 2009(*). If you object, please give a reason. It doesn't have
> to be a very good reason, but it should be a reason that you believe in. If
> there are no objections by the stated date, this resolution will become a
> Working Group Decision by unanimous consent.
>
> Regards,
> Maciej
>
> * - I'm making the period for objections longer than the customary week to
> give people some time before and after TPAC to give their input.
>
>

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

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.

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.

Regards

Shelley

Received on Sunday, 1 November 2009 13:47:52 UTC