This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11637 - Disallow abusing the Decision Policy by escalating editorial bugs
Summary: Disallow abusing the Decision Policy by escalating editorial bugs
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: working group Decision Policy (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Paul Cotton
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-01 20:20 UTC by Ms2ger
Modified: 2011-03-13 22:58 UTC (History)
11 users (show)

See Also:


Attachments

Description Ms2ger 2011-01-01 20:20:07 UTC
Allowing editorial bugs to be escalated to Issues wastes the time of the Working Group and does not help the specification move forward. Bug 8784, bug 10718 and bug 11124 are clear proof that action preventing this abuse is required.
Comment 1 Aryeh Gregor 2011-03-06 02:05:59 UTC
I suggest that this be accomplished by setting a slightly higher standard for Change Proposals that don't make any conformance classes change.  For instance, the chairs might require that such proposals clearly explain who will benefit from the proposed change (specification readers? editors of other specifications?), and at least briefly explain what specific benefit they'll get.  This will at least help prevent Change Proposals like Julian's in ISSUE-127, which don't even try to explain who will benefit or how.  If the proposal suggests a conformance class change, that at least means we can figure out who's affected, and presumably figure out how, so such an added requirement isn't necessary.
Comment 2 Julian Reschke 2011-03-06 11:52:47 UTC
(In reply to comment #1)
> I suggest that this be accomplished by setting a slightly higher standard for
> Change Proposals that don't make any conformance classes change.  For instance,
> the chairs might require that such proposals clearly explain who will benefit
> from the proposed change (specification readers? editors of other
> specifications?), and at least briefly explain what specific benefit they'll
> get.  This will at least help prevent Change Proposals like Julian's in
> ISSUE-127, which don't even try to explain who will benefit or how.  If the
> proposal suggests a conformance class change, that at least means we can figure
> out who's affected, and presumably figure out how, so such an added requirement
> isn't necessary.

I don't think this is helpful, as it will lead to arguments about whether a bug is editorial or not.

ISSUE-127 is not; it does affect the registration procedure for link relations.
Comment 3 Aryeh Gregor 2011-03-08 00:32:07 UTC
(In reply to comment #2)
> I don't think this is helpful, as it will lead to arguments about whether a bug
> is editorial or not.

If someone has escalated a bug, then we are already having an argument.  It would be nice if we could *end* the more clear-cut arguments quickly, by allowing the chairs to reject meritless change proposals without having to request counter-proposals and do a survey first.


In that light, let me make a different suggestion.  When someone submits a change proposal, the chairs may choose to consider it immediately on its technical merits.  In doing so, they would use an extremely lax standard: they should only reject it if it presents so little evidence or reasoning that they feel they'd reject it after a survey even if there were no meaningful arguments presented against it.  This might be the case for a Change Proposal that provides no evidence or reasoning at all that it has any desirable effects (including almost any CP asking for only aesthetic changes).

If the chairs rejected a change proposal like this, it would be the same as if they rejected it for having missing sections: the proposer would be allowed to revise and re-submit it, subject to the usual deadlines.

The chairs would of course be free to go ahead with a full survey whenever they liked.  This change would only allow them to save the Working Group's time and their own in cases where they felt there would be no possible way for the Change Proposal to succeed.  Currently, by contrast, it seems the chairs only ensure that Change Proposals have the correct sections before accepting them.  Of course, members of the Working Group might want to suggest that the chairs invoke the procedure on some particular Change Proposal, but they wouldn't be obliged to.

It might make sense to wait for the WG decision on at least one pending issue that's alleged to be frivolous.  If the chairs issue a decision that rejects a Change Proposal essentially because it makes no case for the change at all, it would provide evidence that a policy adjustment would be useful.
Comment 4 Henri Sivonen 2011-03-09 07:42:47 UTC
(In reply to comment #2)
> I don't think this is helpful, as it will lead to arguments about whether a bug
> is editorial or not.

A bug is editorial if there'd be no code changes required to implementations that were conforming before the change to make them conforming to the spec after the change (all conformance classes considered). 

The clearest case is when even the CP writer agrees that there are no conformance changes. Whenever the CP writer puts "None" in the "Conformance class changes" section, the Chairs should throw out the ISSUE, in my opinion. 

When the Decision Policy was being sold to participants of the WG suspecting Denial of Productivity vulnerabilities in the Policy, Sam wrote:
"At some point, every process has to rely on at least some person or 
persons operating in good faith (otherwise, it it turtles all the way down)."
http://lists.w3.org/Archives/Public/public-html/2009Oct/0263.html

When ISSUE escalators clearly aren't exercising sufficient restraint and respect of the group's time when considering what to escalate, I think it would be appropriate for the Chairs to practice more good-faith discretion in throwing out editorial ISSUEs as opposed to applying the heavy procedure to editorial issues.
Comment 5 Henri Sivonen 2011-03-09 08:25:52 UTC
(In reply to comment #4)
> The clearest case is when even the CP writer agrees that there are no
> conformance changes. Whenever the CP writer puts "None" in the "Conformance
> class changes" section, the Chairs should throw out the ISSUE, in my opinion. 

"None" makes sense in a counter-proposal, of course.
Comment 6 Julian Reschke 2011-03-09 09:36:12 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > I don't think this is helpful, as it will lead to arguments about whether a bug
> > is editorial or not.
> 
> A bug is editorial if there'd be no code changes required to implementations
> that were conforming before the change to make them conforming to the spec
> after the change (all conformance classes considered). 
> ...

See? We already disagree about what's "editorial". A change to registration requirements/procedures does not affect implementations directly, but it's also not simply "editorial".
Comment 7 Paul Cotton 2011-03-09 19:10:42 UTC
The WG Chairs do not believe it is appropriate for us to start judging bugs or issues to determine if they are "editorial" or not.  We do not believe that this is a role the Chairs should take on since we believe that this kind of evaluation is very subjective and would simply lead to too many appeals of such decisions.

In addition we believe the current Decision Policy is working appropriately.  If the Editor deems a requested change to be inappropriate and if the bug originator disagrees then the originator can escalate the bug and the WG then deals with the matter.

ISSUE-109 is an example of the Decision Policy working on something that some WG members "might" have thought was an "editorial change":
http://lists.w3.org/Archives/Public/public-html/2011Mar/0161.html 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9437 

The resolution of ISSUE-109 demonstrates that the WG can decide on matters such as titles and introductory text based on the principle of selecting the proposal that draws the weakest objections.

The resolution of ISSUE-107 also demonstrates that the current Decision Policy works in a case where the Editor thought the requested change was editorial.
Bug 8784 which was initially resolved as WONTFIX, Julian escalated it, provided a proposal, no counter proposal was provided, and ultimately Julian's proposal was adopted by amicable consensus by the WG.

For these reasons the Chairs do not believe that the Decision Policy should be modified to change how "editorial"  bugs/issues are handled.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no Decision Policy change
Rationale: See above response.
Comment 8 Aryeh Gregor 2011-03-09 20:45:27 UTC
(In reply to comment #4)
> The clearest case is when even the CP writer agrees that there are no
> conformance changes. Whenever the CP writer puts "None" in the "Conformance
> class changes" section, the Chairs should throw out the ISSUE, in my opinion. 

FWIW, I don't agree with this.  In some cases, it's fair to debate editorial changes.  To take a clear-cut case, if the editor were to insert an example or note that some working group members thought was severely misleading or incorrect, it would be fair to have a Change Proposal.  I don't think we should have a blanket ban on editorial issues.

I'm not really surprised by the chairs' decision.  If it turns out to be a significant problem, though, we can always revisit it.
Comment 9 Ian 'Hixie' Hickson 2011-03-10 07:21:40 UTC
(In reply to comment #7)
> ISSUE-109 is an example of the Decision Policy working on something that some
> WG members "might" have thought was an "editorial change"

On the contrary, ISSUE-109 is an example of how someone wasted many hours of valuable working group member time that could have been spent on substantial issues. ISSUE-109 is exactly the kind of thing for which the chairs should be showing restraint, and is a perfect existence proof for the concerns Aryeh, Ms2ger, and Henri have described in this bug.

REOPENing in light of this information apparently not being previously known by the chairs (as demonstrated by comment 7). I considered marking this TrackerIssue, but I suspect that that would actually end up wasting even more working group time...
Comment 10 steve faulkner 2011-03-11 09:39:01 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > ISSUE-109 is an example of the Decision Policy working on something that some
> > WG members "might" have thought was an "editorial change"
> 
> On the contrary, ISSUE-109 is an example of how someone wasted many hours of
> valuable working group member time that could have been spent on substantial
> issues. ISSUE-109 is exactly the kind of thing for which the chairs should be
> showing restraint, and is a perfect existence proof for the concerns Aryeh,
> Ms2ger, and Henri have described in this bug.
> 
> REOPENing in light of this information apparently not being previously known by
> the chairs (as demonstrated by comment 7). I considered marking this
> TrackerIssue, but I suspect that that would actually end up wasting even more
> working group time...

ISSUE-109 is exactly the kind of thing for which the you as the editor should be
showing restraint, and is a perfect existence proof that the you want control of every word and sentence in the HTML5 specification, that is not a W3C editor's role, you are not sole author of HTML5. If issue 109 is as insubstantial as you claim you should not have insisted upon having your way.You should have accepted the change and moved on instead of wasting many hours of valuable working group member time.
Comment 11 Aryeh Gregor 2011-03-11 21:48:33 UTC
(In reply to comment #9)
> On the contrary, ISSUE-109 is an example of how someone wasted many hours of
> valuable working group member time that could have been spent on substantial
> issues.

While I'm inclined to agree, it's fairly evident that the chairs do not, since they ruled in favor of the change proposal in ISSUE-109.  This suggests they think the change was worthwhile.  Given that, they don't accept the premise of your argument here, so I don't know why you think there's any point in reopening the bug.
Comment 12 Paul Cotton 2011-03-13 22:58:55 UTC
Ian wrote:
>ISSUE-109 is exactly the kind of thing for which the chairs should be
showing restraint, and is a perfect existence proof for the concerns Aryeh,
Ms2ger, and Henri have described in this bug.

The Chairs disagree with your characterization of ISSUE-109 as was stated in our decision.  And as we stated in our decision we are NOT going to get into the subjective "game" of deciding what bug/issue is editorial and which is not.

Aryeh wrote:
>This suggests they think the change was worthwhile.

You should NOT read this into any decision from the co-chairs.  Our role is to find the proposal for an issue that causes the least amount of dissent amongst WG members.  Our role is NOT to choose the proposal that we like or think "worthwhile".

I am RESOLVING this issue (again).

/paulc