This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
All members of the HTML WG should submit proposals, counter proposals, and alternative proposals following procedures defined in the Decision Process. This includes the HTML5 editor, or the editor of any other specification in the HTML WG. Once the editor of a document has made a decision related to the bug, he or she should not continue editing the document in relation to that bug, once the item in question has gone to the Issues database, and is in the formal change proposal process. The editor is, at that point, no different than any other member of the working group. If no other member of the working group can edit the publicly exposed working drafts, to demonstrate their recommendations, neither should the editor, even though he or she has write access to the document. It is a simple matter to send suggested text in an email to the group.
An editor making a change to the spec while a Change Proposal is under consideration and without consulting the proposal's author or participating in HTMLWG discussion has been controversial [1]. A point that doesn't seem to be well understood is that an editor's edits to the spec are all provisional not final decisions. Without a specific Working Group decision nothing is official. However, as Shelley has pointed out in this bug and in previous discussions [2] and as John recently addressed on public-html [3], a question of equity exists. It may be helpful and collegial if editors would propose edits to the working group while Change Proposals are officially under discussion. Then after consensus or a decision is reached, the change could be written into the spec (or not if the will of the group was a zero edit). Please consider clarifying the decision policy. Thanks. [1] http://lists.w3.org/Archives/Public/public-html/2010Feb/thread.html#msg108 [2] http://lists.w3.org/Archives/Public/www-archive/2010Jan/0066.html [3] http://lists.w3.org/Archives/Public/public-html/2010Feb/0137.html
Tenative personal opinion: I think changes to a draft while Change Proposals are under consideration can be a constructive step, even if they do not fully satisfy everyone. Let's say a Change Proposal cites two problems with the spec in its rationale and the editor fixes one in the draft. Now there are fewer points of disagreement left to settle. On the other hand, sometimes preflighting suggested changes may help avoid bad expectations.
Maciej wrote: > Tenative personal opinion: I think changes to a draft while Change > Proposals are under consideration can be a constructive step, even if > they do not fully satisfy everyone. Let's say a Change Proposal cites > two problems with the spec in its rationale and the editor fixes one > in the draft. Now there are fewer points of disagreement left to > settle. On the other hand, sometimes preflighting suggested changes > may help avoid bad expectations. Such changes could possibly be if constructive if a history of discord and perception of a power inequity didn't exist in the working group. Real or not, working group members seem to feel disenfranchised by the current process [1] [2] [3] on this point [4]. [1] http://lists.w3.org/Archives/Public/public-html/2010Feb/0108.html [2] http://lists.w3.org/Archives/Public/www-archive/2010Jan/0066.html [3] http://lists.w3.org/Archives/Public/public-html/2010Feb/0137.html [4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8892#c1
I'll postulate that the reaction to the changes is addressing a symptom, but not the underlying problem. My observation is when an edit is made in an area related to a Change Proposal that is under active discussion, but that change itself is not accompanied by an email describing the intent and thinking behind the change (was it a baby step? is it thought to address the entire issue? why was this particular approach instead of the one proposed by the change proposal?), then people are left to discover the change, and many tend to react to the change based on their worst possible fears of what might happen. My suggestion is that instead of focusing on the timing of the edits, we should focus on the lack of communication. We should also make it clear that such changes to editor's drafts are provisional, and do not, in them selves, constitute Working Group Decisions.
(In reply to comment #4) > I'll postulate that the reaction to the changes is addressing a symptom, but > not the underlying problem. My observation is when an edit is made in an area > related to a Change Proposal that is under active discussion, but that change > itself is not accompanied by an email describing the intent and thinking behind > the change (was it a baby step? is it thought to address the entire issue? > why was this particular approach instead of the one proposed by the change > proposal?), then people are left to discover the change, and many tend to react > to the change based on their worst possible fears of what might happen. > > My suggestion is that instead of focusing on the timing of the edits, we should > focus on the lack of communication. > > We should also make it clear that such changes to editor's drafts are > provisional, and do not, in them selves, constitute Working Group Decisions. > I agree that communication is a problem, but I don't see the lack of communication being addressed, so all one can do is try to formalize the process. I think it acceptable to ask that the editor propose his changes to the group, first. We cannot have a discussion within the HTML5 document, we can in the email list.
Sam wrote: > I'll postulate that the reaction to the changes is addressing a > symptom, but not the underlying problem. I agree that clear definition of terms and communication is a problem, Sam. But beneath those has been a fundamental disagreement in the concept of and approach to consensus. In July 2008 the HTML5 editor wrote: <quote> The HTML5 work isn't using the traditional W3C approach, and will never use a consensus approach so long as I am editor. Consensus simply isn't a good way to get technically solid specifications, and is in any case basically impossible to achieve in a group with hundreds of participants such as this one. </quote> http://lists.w3.org/Archives/Public/public-html/2008Jul/0354.html <quote> I have no intention of developing HTML5 based on consensus, and will continue to base decisions on the weight of technical arguments without regard to the number of people who hold opinions and without attempting to wait for everyone to agree on a topic before moving forward. I certainly won't put the W3C process above bringing the Web forward to the best of my ability, whatever that may be. I have been very clear about this since well before I was appointed co-editor in the W3C HTMLWG. </quote> http://lists.w3.org/Archives/Public/public-html/2008Jul/0359.html Has the editor's position on and approach to consensus changed? An editor trying to reach consensus would indeed be a positive achievement and help allay worst possible fears. How can that be addressed in a policy?
As the folks in the WhatWG IRC were kind enough to point out[1], the danger to making counter-proposal edits directly to the HTML5 specification is that people don't necessarily know what that document is, and they may think it represents a consensus view at _any_ point in time. Sure, the same people can come back in a week and the section is changed, but very few people outside of this group will check back to see if the section they view on one day, is different on another. We also need to work on equal footing in this team, and that includes all using the same means to discuss a change. Email is this formal means, which we have all agreed on. No, to prevent confusion, as well as prevent what may be perceived as an act of antagonism, when a section is under active debate--with formal change proposal(s), and an assigned issue--it should be locked out of change. We don't have to use technology to attempt to do so, it should come about by explicit directive of the co-chairs. [1] http://www.precentral.net/html5-editors-draft-hits-w3c-flash-doesnt-break-sweat
Strawman resolution: Editors may make changes that impact existing proposals, but that the editor is expected to identify on the mailing list any changes that may affect submitted Change Proposals. If there is an issue but no pending Change Proposal, then the editor is encouraged but not required to identify changes that may affect the issue. In the case of some issues, it may be difficult to even identify what changes would affect it without seeing a Change Proposal.
Addressed here: http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.8&r2=1.9&f=h