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

Change Proposals and Counter-Proposals (was Re: Issues 89 through 97)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 18 Jan 2010 12:04:49 -0800
Cc: HTMLWG WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>
Message-id: <1084F56C-1DD4-4665-AF92-5F3A228BC768@apple.com>
To: Shelley Powers <shelley.just@gmail.com>

On Jan 18, 2010, at 6:40 AM, Shelley Powers wrote:

> On Sun, Jan 17, 2010 at 5:45 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> 
>> On Jan 17, 2010, at 6:35 AM, Shelley Powers wrote:
>> 
>>> I'd like a small extension, and have you set the date for March 1st.
>>> Considering that the response to the bugs took over two months for at
>>> least one, and the number of change proposals I have to write, I don't
>>> think my request is unreasonable.
>> 
>> March 1st is a little over a month and a half. That sounds reasonable to me. I put you down as the volunteer for this batch with the stated deadline. For now we're not setting any other deadlines (either for counter-proposals or for any other issues).
>> 
>> See issue status page for updates: <file:///Users/mjs/Work/src/html5/status/issue-status.html>.
>> 
> 
> Thanks.
> 
> I would like ensure, though, that the group is instructed that all
> proposals, in support of zero-edits and otherwise, are also due this
> time.

We are not so instructing the group at this time. If you'd like to propose a change in how we run the Change Proposal process, then please let's make that a separate thread instead of tying it to the due date on your specific issues.

> 
> There is nothing in procedure allowing the concept of
> "counter-proposal" and a full month for these to be written. This puts
> a double burden on those who want to challenge the current document,
> as well as the editor's decision.
> 
> The editor can, seemingly, add new material at the wish of _a_
> implementor, and the only way we can counter this is to file a bug,
> wait for wontfix, then do a proposal. But, rather than folks writing a
> proposal to support the existing document, they wait to see what we
> write, and then write one specifically counter to us. But we are,
> then, not given time to write our own counter to the counter. Of
> course not, because all of the proposals should be written at one
> time, and then have a period to discuss all of them.

Actually, the one time we got far enough in the process for this to matter, Manu Sporney had a chance to write a "counter to the counter" by updating his original Change Proposal. I recall that when he was offered this opportunity, you complained about it.

> 
> So, though I thank you for letting me have a couple of extra weeks, I
> would rather we not brush my concerns away about our not following the
> Decision Process. We did not follow the Decision Process with
> Microdata. We did not follow it with the dt/dd proposal. Evidently,
> the same is in store for everything else.

Step 6 of the process indicates that the chairs may "ask for a new round of proposals". We have been doing that habitually, and before posting any kind of poll, for every issue. This is for two reasons. First, many of the older issues do not have any rationale for the way the spec is currently; they predate the current Decision Policy, and never had any kind of recorded rationale from the editor or anyone else. It is only fair that if we ask an participant to provide full rationale for a Change Proposal, then someone should have to write the rationale for the way the spec is without the change. Second, it is much easier to focus discussion and draw conclusions when both pro and con arguments are gathered in a document.

By the letter of the Decision Policy, the Chairs could, if we chose, simply assess consensus on the Change Proposals we do get, and in some cases Change Proposals would just be adopted or rejected outright, regardless of whether there is a counter. We have not done things that way because it seems less fair and less likely to reflect the will of the Working Group than the actual process.

We could, as you suggest, ask for "no change" Change Proposals at the same time as Change Proposals that do call for a change, rather than waiting. We have not been doing that for two reasons. First, we think a counter-proposal or alternative proposal should have the chance to be informed by the original Change Proposal. In the case of the dt/dd issue, I feel that worked out well. If we had called for counters right off the bat, I suspect someone would have chosen to defend the status quo. But apparently, most of the Working Group was persuaded by your Change Proposal's rationale, and therefore only alternatives that agreed on the problem but had different solutions were submitted. Second, part of the reason for the Change Proposal process is to limit the ability of a single person or a small group of people to create excess work for the group and cause delay simply by raising a lot of Issues, without intending to follow through. The way you show that you are serious about following through is by writing a Change Proposal. At that point, we *do* expect the group to do work. In addition, we hope that the work of both Change Proposals and Counter-Proposals encourage everyone to do their best to resolve issues in a mutually agreeable way without escalation.


> Now is the time to remind people that if they want to write zero-edit
> proposals for any of these issues, they have until March 1st, and that
> no proposal will be accepted after that point.
> 
> I didn't write the Decision process, you chairs did. All I'm asking is
> that you follow your own procedure.

With due respect, I don't agree with your interpretation of the Decision Policy, or that your suggested way of doing things would lead to better outcomes for the group. Thus, no such deadline is being set at this time. The Chairs will discuss your suggested change together, however, and we'll let the Working Group know if there are any changes.

Regards,
Maciej
Received on Monday, 18 January 2010 20:05:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:59 GMT