13253 2011-07-14 16:19:41 +0000 Sometimes Change Proposals request a grab bag of changes that are loosely related, but separable in principle 2011-07-15 17:11:21 +0000 1 1 1 Unclassified HTML WG working group Decision Policy unspecified PC All NEW P2 normal --- 1 mjs dave.null eoconnor mike mjs Paul.Cotton rubys public-html-bugzilla oldest_to_newest 51032 0 mjs 2011-07-14 16:19:41 +0000 Sometimes Change Proposals request a grab bag of changes that are loosely related, but separable in principle. This creates a few problems: a) At times, the Chairs have to refactor an issue into multiple separate surveys. This tends to be confusing to the WG. b) Sometimes the Chairs may find that one part of a proposal drew the weakest objections but not another part, leading to split decisions. Split decisions can lead to confusion about applying the decision and undue controversy. c) Evaluating and countering more complex Change Proposals is more challenging for Working Group members. 51033 1 mjs 2011-07-14 16:23:03 +0000 Proposed resolution: 1) When a Change Proposal covers multiple separable changes, during review the Chairs suggest (but do not necessarily mandate) splitting the Change Proposal into one per change and splitting the issue in a corresponding way. D) If a Change Proposal author is unwilling to split, and feels the changes are all-or-nothing, then the Chairs treat it that way. If *any* part of a compound Change Proposal (where a split was recommended) is found to draw stronger objections than the alternative, the whole Change Proposal is rejected. We do that instead of issuing a split decision. E) If two compound Change Proposals, where in each case the Chairs recommended a split, are up against each other, and one part of one draws weaker objections, and another part of the other draw weaker objections, they both fail. If these are the only Change Proposals, the issue is closed without prejudice. 51118 2 eoconnor 2011-07-15 17:11:21 +0000 I think the prevailing (and only) Change Proposal for ISSUE-150 code-point-verbosity illustrates this issue. In it, Julian proposed two types of changes to the spec: * One dealt with how individual code points should be referred to in the spec. On this point, he received support from several implementors (Anne, Aryeh, and Henri) in the original bug. * The other type of change was to have the spec define ad-hoc character classes, a point on which Henri objected. The changes, while thematically related, are logically separable and could indeed be applied to the spec independently of one another.