W3C home > Mailing lists > Public > public-html@w3.org > March 2010

a suggestion and a request on bugs and change proposals

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 9 Mar 2010 09:07:04 -0600
Message-ID: <643cc0271003090707v25d68cbcr76a9c2a34173d52@mail.gmail.com>
To: HTMLWG WG <public-html@w3.org>
I've noticed in the dt/dd issue and now with Issue 66 that people are
providing multiple change proposals, or introducing additional changes not
necessarily reflecting on the issue at hand. These actions make it more
difficult to determine exactly what the person wants, specific to the item
under discussion. This goes counter to my assumption that when people write
a change proposal, it's in actuality a concise argument for a specific
action, and that this action is what the person prefers.

There's nothing in the Decision Process that states people only need to
write one change proposal, but come on folks: make a choice, take a stand,
provide your best argument, and tell us what you want.

In addition, and again, this is just a request, with no power or authority
and based solely on my opinion: be precise. Bugs should be for specific
changes (and I've been lax in this regard in the past, will do better in the
future). If you're writing a change proposal for an issue, focus on the
issue, not use the issue to open a doorway to an alternative universe of
changes. If you're writing a counter-proposal, write it specifically to
counter a proposal. If you want something new, create a new bug.

Case in point is Matt May's Issue 66 change proposal[1]. It's focused on the
issue, is precise, states what needs changing, and provides a
rationalization for that change. Ian wrote a counter proposal[2], rejecting
this change. Ian's counter-proposal is also precise, and provides a specific
rationalization for not making the change.

Discussions about Issue 66[3] have not always been focused, or precise.
During initial discussions after Matt provided his change proposal, people
talked about adding links to this accessibility document or that -- but
that's not specific to this issue, which was remove a section of text
related to the image alt attribute. Adding a link to an accessibility
document somewhere else in the specification is a new change, and should
have been reflected in a new bug. In the interest of seeking "consensus",
all we did is muddy the water, and we did so without reaching the consensus
that supposedly justified adding this new change.

Today, when Ian provided his first change proposal, he also provided a
second seeming counter-proposal[4] that talks about adding more text to the
section describing how the image analysis techniques would work. Now, I
haven't the foggiest which change proposal Ian wants, other than, generally,
he wants to keep the text. But which text he really wants, I haven't a clue.


Shelley

[1] http://www.w3.org/html/wg/wiki/ChangeProposals/ImageHeuristics
[2] http://lists.w3.org/Archives/Public/public-html/2010Mar/0194.html
[3] http://lists.w3.org/Archives/Public/public-html/2010Jan/0685.html
[4] http://lists.w3.org/Archives/Public/public-html/2010Mar/0195.html
Received on Tuesday, 9 March 2010 15:07:33 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC