Re: Revised Decision Policy for discussion

On Mon, May 16, 2011 at 5:41 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> The following proposed revision of the Decision Policy resolves nearly all outstanding bugs, including such frequent requests as defining the process for reopening an issue, and defining the process to be followed for the LC Review period. Comments welcome:
>
> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html

I notice that there's no way for a bug filer to withdraw the bug.  I
suggest the description of the INVALID state say that it can also be
used by the bug filer to withdraw it.  I've convinced people at least
once that their bug is incorrect and asked them to resolve it INVALID
so as not to have to take up the editor's time, in cases where it's
not clearly junk or spam.

There doesn't appear to be any option to disagree with the editor's
handling of an issue but not escalate it to an issue.  People might
not want to escalate to an issue because they don't think it's worth
the time, for instance.  I suggest that an additional substep of step
5 be added allowing commenters to add the Disagree keyword immediately
if they don't want to reopen or raise as an issue, but still want to
express their disagreement.

Some typos: "Pesponses", "Escalted", "beoyond", "issuescan",
"decisopn".  Also "w3c.org" instead of "w3.org".  (The former has the
same A record as the latter, but it's not the standard domain name,
and it has different MX records.)


I notice that there's nothing specific about what changes the editor
is allowed to make, beyond "Although editors may field issues through
other forums if they wish, we will require editors to address all
bugzilla bugs."  Does this mean that there are no specific limitations
on what changes the editor can make, or just that this document
doesn't cover them?  In particular, I'd like to know whether the
editor will remain free to make substantive changes provided they
prove uncontroversial -- except if they would force us to return to
Working Draft, of course.  For example, adding a specification for a
previously-undocumented JavaScript property where no one but
implementers is likely to care about the details of how it's
specified.

Received on Tuesday, 17 May 2011 00:27:59 UTC