- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 18 Jan 2010 17:42:33 -0600
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Shelley Powers <shelley.just@gmail.com>, Maciej Stachowiak <mjs@apple.com>, HTMLWG WG <public-html@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>
On Mon, Jan 18, 2010 at 5:27 PM, Sam Ruby <rubys@intertwingly.net> wrote: > Tab Atkins Jr. wrote: >> I disagree. It is implied that there is a material difference between >> a single change proposal being written, and a change proposal plus a >> zero-edits counter proposal; the former is implied to be more likely >> to be accepted, despite the fact that the zero-edits counter proposal >> is typically nothing more than a collection/distillation of arguments >> that have already occurred on the mailing list. > > If it truly is that easy, what is the issue? I never said it was easy. It typically involves a non-trivial amount of work. >> Thus, a really bad change proposal obligates me to write a counter >> proposal just to reduce the chances of it being accepted by default. > > That would only happen if both the chairs were asleep at the wheel *AND* > absolutely nobody in the working group were to comment on the Call for > Consensus. In other words: ain't going to happen. So then there's no reason to write a zero-edits counter proposal, since we can just object when the Call for Consensus is made? It's been implied by Maciej that it's somehow better to write a zero-edits counter proposal. >> Before the change proposal is written, however, I have no idea of its >> quality. Before it is written there is also the distinct possibility >> that *no* change proposal will emerge at all, and the issue will be >> closed without prejudice. It doesn't make sense for me to expend >> effort distilling the mailing list arguments in either of these >> circumstances. > > This is only an issue if there are features in the document for which > determining the rationale is not obvious. I can't tell if it's obvious or not, however, since it's you chairs that make the decision. I have no idea what you consider obvious. >> The entire point of the Process is to reduce the power of a single >> person to DoS the group, by requiring a non-trivial amount of effort >> from people who raise issues before the working group has to respond >> in kind. Changing this so that the working group has to spend effort >> automatically when an issue is raised completely kills the reasoning >> behind the process in the first place, and will make the group as a >> whole *very* vulnerable to DoSing. > > That is *a* point, not *the entire point*. > > There is a point to requiring rationale in the first place for every change > made to the document, retroactively if necessary. > > There is also a point to requiring those that would like something different > to actually document what they would like. > > I definitely subscribe to the latter (see [1]), but that doesn't mean that I > don't think that the former is important too. In particular, saying that a > DoS attack is a theoretical possibility is not an excuse for features to be > present in HTML5 without literally *ANYBODY* in the group willing to provide > the rationale for that feature. Typically rationale *is* provided via mailing list discussion. You just discounted mailing-list discussion as a valid place to point for rationale, however. I am *not* willing to expend the effort to separately defend every single portion of HTML, and I don't think it's reasonable to expect anyone to, or even for the group as a whole to do so. That's the definition of DoS. >> I still hate the current Process, but it sucks less than some >> alternatives. > > It is not clear to me what you disagree with here. Sorry, that wasn't germane to the discussion at hand. ~TJ
Received on Monday, 18 January 2010 23:43:25 UTC