- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sun, 01 Nov 2009 16:50:10 -0800
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
On Nov 1, 2009, at 5:47 AM, Shelley Powers wrote: > > 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. I think you may be drawing an unwarranted assumption about the issue of entities in XHTML. The reason we're discussing it on public-html is because Ian did not want to make the change without discussion.[1] You are right though that the policy allows an initial editor's decision to be made based on an incoming comment, if the editor agrees. > 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. Indeed, the policy is all about how Working Group members can get edits to happen (including reverts of past edits). At this time, it does not attempt to prevent any edits from happening. The goal of the policy is to let every member of the Working Group do meaningful work that will affect our deliverables. Making it easy to prevent things is not a goal. > > 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. One thing I'd like to clarify: anyone can escalate a bug to a tracker issue once there is an editor's response, it doesn't have to be the originator. So if someone makes a spec comment that leads to a change, and a third party doesn't like that change, they can escalate to the tracker. What the process does not provide for is a way to escalate to the tracker before the editor of the relevant draft has weighed in. I'm hesitant to change that at this time, for a few reasons: 1) Historically, it's been too easy to raise a tracker issue and thus create an obligation on the Working Group, without a clear path to resolving the issue or a willingness to follow through on the part of the issue raiser. Part of the goal of the policy is to make it less likely that tracker issues are raised speculatively. 2) Per our charter[2], we're expected to typically let an editor make an initial proposal, before escalating matters to the full Working Group. The proposed decision policy tries to be consistent with this. 3) The policy has been through many rounds of revision and is now up for a Lazy Consensus resolution. If the policy is changed further, then I'll feel obliged to restart the clock on the Call for Consensus, delaying the possible adoption of the decision policy. I think the policy is enough of an improvement over the status quo ante that I personally would rather start using it, and fine tune it later once we have more experience. That being said, I'll try to discuss this issue with my co-chairs during TPAC week. For the named entity issue, once there are bugzilla bugs, my suggestion to you would be to encourage the editor to reject the comment, and if that doesn't happen and you don't like the outcome, escalate it to the tracker. > 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. Certainly any issues where someone makes the effort to escalate it will be discussed by the whole group before the spec moves forward in maturity level. Regards, Maciej [1] http://krijnhoetmer.nl/irc-logs/whatwg/20091030#l-588 [2] http://www.w3.org/2007/03/HTML-WG-charter#decisions
Received on Monday, 2 November 2009 00:50:55 UTC