This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
At times, tracker issues arise that have no material impact on either authoring or implementation conformance. At times these are changes that the W3C Process would class as "minor" rather than "substantive". The Process has much lower requirements for changes or issues that are not substantive. Non-substantive changes need only diffs, not summary text, as documentation when requesting transition. Non-substantive changes do not require a return to Working Draft. And the W3C Process allows simple voting to be used on non-substantive matters. Treating Change Proposals that call for a non-substantive change the same as any other a great deal of the group's and the chairs' time and energy. It also discourages participation from people who do not feel as strongly, even though such changes are often simply matters of taste, and do not have a material effect on the specification.
Proposed resolution: If the Chairs judge that all possible Change Proposals for an Issue would lead to non-substantive changes, as defined by the Process, then instead of asking for full Change Proposals, they may ask for simple rationale statements and then hold a preference poll. This would turn such decisions into a popularity contest, but that seems reasonable and appropriate for changes that are matters of taste.
(In reply to comment #1) > Proposed resolution: > > If the Chairs judge that all possible Change Proposals for an Issue would lead > to non-substantive changes, as defined by the Process, then instead of asking > for full Change Proposals, they may ask for simple rationale statements and > then hold a preference poll. > > This would turn such decisions into a popularity contest, but that seems > reasonable and appropriate for changes that are matters of taste. Based on the recent feedback on issues 150 and bug 11124[1], I do not support changing the process to be more lightweight for text that is "minor". In this case we have a concrete proposal where there is an assertion that some specific text verges on being opaque to nearly everybody with the possible exception of implementers. The only defense that has ever been given for this is Ian's "I like it the way it is", and now Ted's "I don't recall any other implementors stating a strong opinion". Having a lightweight process leading to a preference poll in this context would indeed amount to a popularity contest, which would both increase drama and be inconsistent with selecting the proposal that draws the least objections. Additionally, I will note that the current process already requires substantial effort on the part of those that wish to advocate changes such as these. Looking at the current queue and looking forward, I don't see evidence of this requiring "undue" time and energy. [1] http://lists.w3.org/Archives/Public/public-html/2011Jul/0215.html
(In reply to comment #2) > Having a lightweight process leading to a preference poll in this > context would indeed amount to a popularity contest, which would both > increase drama and be inconsistent with selecting the proposal that > draws the least objections. In general I don't like preference polls, but it's precisely cases like ISSUE-150 where they would be most useful to *reduce* drama. Anne was right when he said "'Amicable Resolution' seems to more likely indicate 'Lack of Participation' than a resolution everyone can live with." I can confidently say that I would not have replied as I did to the chairs' decision on ISSUE-150 had that decision taken the form "80% of poll respondents prefer this CP to what's currently in the spec" and not "no one could be bothered to reply to the CfC, so please make this change."
(In reply to comment #3) > (In reply to comment #2) > > Having a lightweight process leading to a preference poll in this > > context would indeed amount to a popularity contest, which would both > > increase drama and be inconsistent with selecting the proposal that > > draws the least objections. > > In general I don't like preference polls, but it's precisely cases like > ISSUE-150 where they would be most useful to *reduce* drama. Anne was > right when he said "'Amicable Resolution' seems to more likely indicate > 'Lack of Participation' than a resolution everyone can live with." > > I can confidently say that I would not have replied as I did to the > chairs' decision on ISSUE-150 had that decision taken the form "80% of > poll respondents prefer this CP to what's currently in the spec" and not > "no one could be bothered to reply to the CfC, so please make this > change." My perception of the outcome on issue 150: an objection was raised on the text in the spec and not a single person stepped forward saying that they could not live with the proposed replacement. And this was not completely due to lack of participation: the comments on the bug itself shows a number of implementers having reviewed the text. Having a preference poll on this particular matter would have opened up the question of the relative priority of constituencies[1], and that would have resulted in increased drama. [1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
On a practical note, wouldn't we end up with license problems here? The document used to generate the HTML5 specification uses a different license than the W3C document license. If the editor is forced to take changes to the document then either A) Those changes must be available under the same license as the document used to generate the HTML5 specification. B) The specification would have to be forked. Would we be fine with requiring A from people supplying diffs? Despite the fact that this license is not the W3C document license?
Hmm.. or I might have misunderstood the proposal here based on comment 0. We're already in the situation where diffs are accepted I guess?
(In reply to comment #5) > On a practical note, wouldn't we end up with license problems here? The > document used to generate the HTML5 specification uses a different license than > the W3C document license. > > If the editor is forced to take changes to the document then either > > A) Those changes must be available under the same license as the document used > to > generate the HTML5 specification. > B) The specification would have to be forked. > > Would we be fine with requiring A from people supplying diffs? Despite the fact > that this license is not the W3C document license? I think this concern is unrelated to the topic at hand. This is not about licensing issues with provided text, and such licensing issues can presumably come up whether the text is "minor" or "substantive". This issue is specifically about using a streamlined process for matters that the W3C Process would consider "minor" changes.
(In reply to comment #4) > My perception of the outcome on issue 150: an objection was raised on the text > in the spec and not a single person stepped forward saying that they could not > live with the proposed replacement. Of course everyone could live with the proposed replacement. Everyone could live with the current text too. That's precisely *why* the issue is unimportant and shouldn't require cumbersome process -- the outcome makes little difference to anyone in the end anyway. The reason no one responds to these things is that we know that if we object, we're going to be asked to write a Change Proposal, which is a nuisance even if you make it short. You have to get the right format, have the chairs critique it if you left out something or other, whatever. So we all sit there waiting for someone else to write the Change Proposal because we don't care enough. Then no one does, so the CfC passes. The name "call for consensus" is misleading, because the boilerplate used in the HTMLWG for CfCs does *not* actually represent an attempt to ascertain consensus. It says """ At this time the WG Chairs would like to solicit alternate Change Proposals (possibly with "zero edits" as the Proposal Details), in case anyone would like to advocate the status quo or a different change than the specific one in the existing Change Proposal. If no counter-proposals or alternate proposals are received by July 1st, 2011, we will proceed to evaluate the change proposal that we have received to date for ISSUE-150. """ That pretty clearly says "if you're not willing to write a CP, don't bother responding". But then if no one can be bothered to write a CP, the chairs call it "consensus". If you're going to use that term, you should make it explicit in the CfC that people should object even if they don't intend to write change proposals. Otherwise call it a "call for alternate change proposals". > And this was not completely due to lack of > participation: the comments on the bug itself shows a number of implementers > having reviewed the text. Yes, because writing bug comments is easier than writing even a simple CP.
(In reply to comment #8) > > The reason no one responds to these things is that we know that if we object, > we're going to be asked to write a Change Proposal, which is a nuisance even if > you make it short. You have to get the right format, have the chairs critique > it if you left out something or other, whatever. So we all sit there waiting > for someone else to write the Change Proposal because we don't care enough. > Then no one does, so the CfC passes. "no one" is clearly an overstatement. We've processed plenty of counter proposals within this working group. The definition of what should go in a change proposal is pretty straightforward: http://dev.w3.org/html5/decision-policy/decision-policy.html#change-proposal In the case of a zero edit change proposal, the key section is rationale. > The name "call for consensus" is misleading, because the boilerplate used in > the HTMLWG for CfCs does *not* actually represent an attempt to ascertain > consensus. It says The W3C definition of consensus varies from common English usage of the term: http://www.w3.org/2005/10/Process-20051014/policies#Consensus I encourage you to also read the definition of Formal Objections: http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews It is entirely consistent that the chairs of this working group will not give serious consideration to objections to replacing text unless those objections are accompanied by rationale.
(In reply to comment #0) > At times, tracker issues arise that have no material impact on either authoring > or implementation conformance. At times these are changes that the W3C Process > would class as "minor" rather than "substantive". > > The Process has much lower requirements for changes or issues that are not > substantive. Non-substantive changes need only diffs, not summary text, as > documentation when requesting transition. Non-substantive changes do not > require a return to Working Draft. And the W3C Process allows simple voting to > be used on non-substantive matters. > > Treating Change Proposals that call for a non-substantive change the same as > any other a great deal of the group's and the chairs' time and energy. It also > discourages participation from people who do not feel as strongly, even though > such changes are often simply matters of taste, and do not have a material > effect on the specification. Hi Maciej, you wrote: "At times, tracker issues arise that have no material impact on either authoring or implementation conformance. " Even though issues may not have any material impact on FORMAL authoring conformance they can still be of major importance as the spec is used as the canonical source by many authors/developers/writers/journalists/educators etc. So I ask that this be taken into in any decisions regarding the importance or worthyness of any particular change proposal that does not involve conforance changes.
Mike has commented on public-html: http://lists.w3.org/Archives/Public/public-html/2012Jan/0133.html In that post, he cited Maciej's proposed resolution, but not my comments that immediately followed where I argued against a preference poll. We have an editor who, given the opportunity, will take it to "editorialize" about how much he doesn't believe in the W3C, and will defend putting in examples that, if followed, will allegedly produce inaccessible web pages, and will provide no other rationale for controversial changes than "I like it the way it is". Leaving "editorial" decisions to such an editor and providing no recourse to the Working Group will simply result in Formal Objections. Leaving the process as it is may or may not reduce the number of Formal Objections. But it will ensure that if we get Formal Objections that we have captured all of the necessary information to document why the decision was made as it was. Meanwhile, we have some evidence that asking for a Change Proposal has led to many issues being closed without prejudice, and others to be adopted by amicable consent.
Recently issued decision on a matter that have no impact on conformance requirements. http://lists.w3.org/Archives/Public/public-html/2012Feb/0065.html Any resolution is provided for this issue needs to take into account matters such as this one.