w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2009-08-10 to 2009-08-17.
96 answers have been received.
Jump to results for question:
Do you support publishing this Editor's draft (i.e., without the additional warnings, also a.k.a. Ian's draft) as a Working Draft at this time?
Choice | All responders |
---|---|
Results | |
yes | 56 |
no | 40 |
Responder | Publish draft without warnings? | Comments |
---|---|---|
Sam Sneddon | yes | |
Kornel Lesinski | yes | |
Stephen Stewart | yes | |
Toby Inkster | no | |
Andrew Sidwell | yes | |
Nicolas Le Gall | no | |
Doug Wright | yes | |
Michael Puls II | yes | |
Larry Masinter | no | If the working group is operating on "commit then discuss", then any substance that was committed without discussion (or discussed without resolution) should at least be marked as such in the text. To do otherwise is misleading. |
Martin McEvoy | yes | |
John Drinkwater | no | |
Stephen Axthelm | no | |
Dan Smith | yes | |
Joe Williams | yes | Just the right thing to do. Manu can be free to do whatever else he wants except control the basic keystrokes in the official standard. His effort is fine and posibly productive, but it is a side show that should be used to the advantage of the group's deliverable, but incorporated as a process help to identify problems, not in the official standard. Otherwise there will just be a continuing sequence of unintended changes. |
Sam Ruby | no | What concerns me most is that Ian agreed to add a note for issue 32 and then removed it without explanation, and did not respond to Laura's and my suggestions to add it back in. |
Martin Kliehm | no | |
Matthew Turvey | yes | |
Julian Reschke | no | The draft (a) didn't make sufficient progress on controversial issues (table/@summary), and (b) introduces new controversial stuff (for instance microdata). Publishing it without stating what the status of these sections is would give the wrong impression to the public. |
David Håsäther | yes | |
Benoit Piette | no | |
Theresa O'Connor | yes | As Ian's draft has already gone through FPWD, I think we should always publish new WDs whenever Ian would like to. |
Catherine Roy | no | |
John Kemp | no | I believe that this current draft does not adequately capture the consensus or lack thereof around sections of the document. I also believe that it is important to include that information, and further, that publishing two drafts where one is a superset of the other might be confusing to outsiders. |
John Foliot | no | Given that there is no technical differences between the 2 competing documents at this time, I believe more information over-all is better than less. While we are only talking about a Working Draft here, the reality is that developers are using this as a basis for production class (or near production class) sites today, and providing those content creators with as much info as possible can only be good. |
Chris Wilson | no | This draft does not give adequate information about the state of WG consensus on the individual sections. |
Bruce Lawson | no | |
Henri Sivonen | yes | I think we should just publish a snapshot of the draft Hixie is editing whenever the W3C Process requires a heartbeat WD. |
Jeremy Keith | yes | |
Ian Hickson | yes | |
Tantek Çelik | yes | Inline warnings simply clutter up the draft. There is already an issue tracking system, and I would be ok with a link to the issue tracking system, but I don't think it is required for this working draft. |
Jonas Sicking | yes | |
David Hyatt | yes | |
Adele Peterson | yes | |
Lachlan Hunt | yes | |
Maciej Stachowiak | yes | Ian has been our longtime editor and I believe he has been editing in good faith. It would be poor process to reject his draft based solely on a last-minute objection. |
Alexey Proskuryakov | yes | |
Lee Kowalkowski | yes | I just dislike having content inside attributes in general... |
Adam Roben | yes | |
Gavin Sharp | yes | |
Robert Marshall | yes | |
Shawn Medero | yes | |
David Singer | yes | |
Shelley Powers | no | I'd be willing to see both drafts published, but it doesn't look like this option will pass, so will go with the one that has additional information |
Chaals Nevile | no | I think Ian's current draft is not sufficiently clear as to the real status of agreement in the working group (let alone the wider HTML community), and this creates a misleading impression. Given the importance of HTML and the value of implementation of drafts, I think that is insufficient guidance to the community, and that we would benefit from providing more clarity to people who may read the spec but not follow the endless discussions of the working group, in order that they concentrate their efforts with some understanding of what clearly enjoys wide support, and what is a temporary and speculative section really reflecting where Ian is up to in processing his email backlog more than anything else. |
Channy Yun | yes | |
Cameron McCormack | yes | Given that the only difference between the two drafts is a small amount of informative text, I don't mind which draft is published. |
Karl Dubost | no | |
Alex Robinson | no | |
Leif Halvard Silli | no | Ian recoginizes that there are wide disagreements - as he think LC will be delayed for years by group members who will object to spec parts based on weak, unfounded "opinions". How does it make us advance to LC any earlier if we try to push these "opinons" under the carpet? |
Jason White | no | |
Roy Fielding | no | table @summary should not be warned against. Use of the term URL in a manner that directly contradicts an Internet standard is negligent and childish. HTML5 can rot until that is fixed. |
Ben Adida | no | |
John Vernaleo | yes | |
Masataka Yakura | no | |
Robert O'Callahan | yes | |
Adam Barth | yes | |
Russell Cavell | yes | |
Frank Palinkas | no | |
Alfonso Martínez de Lizarrondo | yes | |
Philip Jägenstedt | yes | |
James Graham | yes | |
Laura Carlson | no | Delineating open issues [1] in the spec will help the public become aware of topics of concern or problems. Pointing out areas of contention while they are under discussion will aid transparency. Public review and comment from outside the Working Group are vitally needed and should be vigorously sought. As Jason points out, warnings and comments for reviewers will help enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate. [1] http://www.w3.org/html/wg/tracker/issues/open |
Joshue O'Connor | no | |
Patrick Lauke | no | |
Hallvord Steen | yes | |
Jude Robinson | no | |
Denis Boudreau | no | |
Richard Schwerdtfeger | no | The draft should flag the areas being looked at for accessibility. We need to flag problem areas like canvas. There should also be a reference to adding ARIA support. The working group is working to accelerate comment processing. The reason for not yet responding is that many are interrelated and we need to have all the working drafts modifications in. |
Jace Voracek | yes | |
Cynthia Shelly | no | I can live with publishing Ian's draft, but prefer Manu's. |
Jens Oliver Meiert | yes | (Don’t feel strongly about either version.) |
Arne Johannessen | yes | This particular draft lacks notes on the stability of individual sections; ideally, these would be added as editorial notes before publishing. However, publishing this draft as-is still is fine for fulfilling the heartbeat requirement as a matter of principle. |
Rob Ennals | yes | I think Ian is doing roughly the right things with his draft. I appreciate the need to debate controversial issues, but I am not convinced that a public draft with warnings is the right way to do this. |
Debi Orton | no | I don't believe accessibility issues have been adequately addressed in the current editor's draft. |
Eric Carlson | yes | |
Vicki Stanton | no | |
Jirka Kosek | no | |
Ben Boyle | yes | |
Laurens Holst | no | |
Per-Erik Brodin | yes | |
Anne van Kesteren | yes | |
Michaeljohn Clement | yes | |
Chris Cressman | yes | |
Scott Lewis | yes | |
Tab Atkins Jr. | yes | |
Manu Sporny | no | This document is a subset of the HTML-warnings document, meaning that publishing this document would be redundant. |
Daniel Schattenkirchner | yes | Yes, I've got no single objection. |
Gregory Rosmaita | no | clearly delineating (with markup, and NOT merely stylistically) open issues [1] in the HTML5 public working draft will help highlight and invite public comment of topics of concern or problems upon which the HTML WG has had difficulty reaching consensus. as rich schwerdtfeger, laura carlson and jason white (and others) have noted, highlighting areas of contention while they are under discussion will aid transparency, and expedite the consolidation of the working draft. public review and comment from outside the HTML WG is essential and should be vigorously sought; in addition, the HTML WG should maintain a resource which documents what parts of HTML5 have been implemented, by whom, and what aspects of HTML5 will developers be implementing next? helping dispell questions as to what is implemented, what the HTML WG has agreed upon, and what is either abstract (no implementations) or controversial (implementations without a standard means of providing long and terse descriptions for CANVAS, to cite but a single example. warnings and comments will help reviewers, as well as enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate, or for which no accessible, interoperable alternate exists. test drivers of the spec need not only an accellerator, but also warning signs, alerts, and a brake -- anything else is a disservice to all of the HTML WG's target audiences. [1] http://www.w3.org/html/wg/tracker/issues/open |
Steve Faulkner | no | |
Ben Millard | yes | |
Sander van Lambalgen | yes | |
Krijn Hoetmer | yes | |
Stéphane Deschamps | no | As has been said in several comments: it's long enough that it can stand comments. Without comments it's not clear as to what has reached potential consensus and what is still not final and needs more discussion. |
Nikunj Mehta | yes | |
Tobias Horvath | no | Warnings would correctly outline the current state of discussion regarding pressing issues that need to be taken into consideration. Comments need to be at hand for easy reference, not far away in an issue tracker. |
Simon Myers | yes |
Do you support publishing this Editor's draft (i.e., with additional warnings, also a.k.a. Manu's draft) as a Working Draft at this time?
In order to provide more useful feedback regarding which warning text should not be considered controversial and thus, should be removed, please follow the suggestions outlined in this email.
Choice | All responders |
---|---|
Results | |
yes | 45 |
no | 51 |
Responder | Publish draft with warnings? | Comments |
---|---|---|
Sam Sneddon | no | |
Kornel Lesinski | no | |
Stephen Stewart | no | |
Toby Inkster | yes | |
Andrew Sidwell | no | |
Nicolas Le Gall | yes | |
Doug Wright | no | I don't see the value in publishing this draft - the warnings don't add anything on a technical level, and simply rehash (some) of the many emails/open bug reports that the Editor's draft already links to and that interested parties should be skim-reading before sending technical feedback. |
Michael Puls II | yes | |
Larry Masinter | yes | If the working group is operating on "commit then discuss", then any substance that was committed without discussion (or discussed without resolution) should at least be marked as such in the text. To do otherwise is misleading. |
Martin McEvoy | no | |
John Drinkwater | yes | REWORD #the-source-element |
Stephen Axthelm | yes | |
Dan Smith | no | |
Joe Williams | no | |
Sam Ruby | yes | While the criteria is a bit unclear, in general I would prefer to err on the side of too much warning than not enough. The feedback I've seen to date seems to mostly be of the nature of "is this warning necessary?" rather than "this warning should have been included". |
Martin Kliehm | yes | |
Matthew Turvey | no | |
Julian Reschke | yes | (will follow up on the mailing list with respect to the precise warning texts) |
David Håsäther | no | |
Benoit Piette | yes | |
Theresa O'Connor | no | |
Catherine Roy | yes | |
John Kemp | yes | I would suggest that for now, it is useful to provide as much information about the ongoing discussion as possible. If there are sections which have warnings, but for which there is no associated tracked issue, I would recommend that either an associated issue is suggested which captures the controversy, or that the warning is dropped (_after_ the draft is published, and has received some review). |
John Foliot | yes | It is my hope that moving forward, warnings or advisories might also note affected W3C Working Groups outside of HTML WG; ideally with some form of indication of communications or requests for feedback. |
Chris Wilson | yes | |
Bruce Lawson | yes | |
Henri Sivonen | no | I think the selection of warnings is too arbitrary to support. I would support porting the WHATWG status marker data into the HTML WG draft in a way that doesn't use scripting (to comply with pubrules). REMOVE #urls This warning is redundant, because the spec already says there's a willful violation. The warning is also misleading, because "challenging" it doesn't change requirements for compat with existing content. REWORD #fetch HTML 5 is now delegating to MIMESNIFF. The section in HTML 5 doesn't seem to need an update if MIMESNIFF is edited. REMOVE #misinterpreted-for-compatibility The warning about the willful violation is redundant, because the spec already says there's a willful violation (again, required for compat as willful violations always are). As far as I can tell, banning encodings that are problematic from the security perspective or that contribute to gratuitous encoding proliferation isn't controversial. REMOVE #implied-strong-reference I haven't seen evidence of this section being controversial. Normative implementation advice is what a sufficiently detailed spec is! REWORD #other-metadata-names I don't agree that the sentence "The IETF, IANA and W3C have proven that they are capable of operating these types of registries" can be presented as a statement of fact using the word "proven" due to past issues with the timely functioning of the IANA MIME type registry (consider video/mp4, image/jp2 and image/svg+xml). REWORD #microdata I think it would be appropriate to note the immature implementation status of microdata. However, I think it's inappropriate to use the microdata section as a promotional soap box for RDFa. The note shouldn't make forward-looking statements about RDFa or promote a present RDFa REC that is inappropriate for text/html. It would be the clearest not to mention RDFa at all and to focus on the implementation status of microdata. REWORD #the-source-element I think a note saying that a baseline codec would be good to have would be appropriate. (Something like the note that was in the spec from December 2007 until recently.) However, I don't think the W3C publication should repeat anyone's speculative patent concerns about other formats. REWORD #alt The past controversy has been about absent alt--not about blank alt. The PFWG has sent a response to the HTML WG, and the response OKs absent alt under certain conditions. The issues raised have been about accessibility--not about "usability". REWORD #the-head-element In practice, microformat consumers ignore @profile, so it's inappropriate to cite microformats as a reason to have it. |
Jeremy Keith | no | |
Ian Hickson | no | Please count this as a YES if "I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts." wins. REMOVE warnings on all sections |
Tantek Çelik | no | |
Jonas Sicking | no | NOTE: I'd prefer to publish both drafts, but the current votes seems to lean towards that not happening. In this case I would prefer to just publish Ians draft, which is why I answered 'No' on this question. However if publishing both drafts is an option then please consider my vote a 'Yes' vote. Original comment: While I support publishing any draft that someone makes a serious effort to produce, I'm not yet convinced that putting warnings in the spec is the best way to track outstanding issues. Nor am I convinced that we need to track controversial issues separately from outstanding issues (which HTMLWG currently tracks in the issue tracker/bugzilla). However since I value other peoples opinions, and concede that I could very well be wrong in what the best way to track outstanding/controversial issues is, I'm all for publishing Manu's draft as well. |
David Hyatt | no | |
Adele Peterson | no | |
Lachlan Hunt | no | My previous comments http://lists.w3.org/Archives/Public/public-html/2009Aug/0447.html I concur with these comments from James Graham http://lists.w3.org/Archives/Public/public-html/2009Aug/0563.html I also concur with Henri's comments about the content of the warnings themselves. |
Maciej Stachowiak | no | I suggest removing the <bb> and garbage collection warnings. I suggest reviewing all warnings to see if they meet the proposed criteria for "controversial issue". I suggest rewording all the issue markers to start with "issue" instead of "warning", and to link to the relevant issues in the issue tracker. Upon further review: I also agree with all of Henri's remove and reword suggestions. |
Alexey Proskuryakov | no | |
Lee Kowalkowski | no | |
Adam Roben | no | |
Gavin Sharp | no | |
Robert Marshall | no | |
Shawn Medero | no | |
David Singer | no | I don't mind the warnings, as they are true, but overall, I think it should be clear that while some parts of a WD may be more stable than others, all parts are 'undecided and open to change' until the group formally declares consensus on a complete draft. I'm concerned about the implication of stability on un-warned sections |
Shelley Powers | yes | Rather than clutter up the draft, the inline warnings give a good idea of issues still to be resolved, without having to dig through a database. |
Chaals Nevile | yes | There are various unhelpful value-judgements (terms like "wilfully ..." in the warnings) that should be removed first. However, clarifying the status of various sections is something I think should be done, and I far prefer to see the annotation of sections that do not enjoy consensus as part of the formal drafts that we produce. I support the comments of others who suggest that these annotations should be based on general stability, not just because some things are "controversial". In a draft that is way too long to sit down and read quickly anyway, a few extra notes that clarify the status of what I am planning to read don't clutter it, but help understand it. |
Channy Yun | no | |
Cameron McCormack | yes | If Manu's draft is published, I would like it to be published only after the split-out spec sections (e.g. Databases) are removed. I have no opinion on whether certain warnings should be removed or reworded, without having looked into it in detail. |
Karl Dubost | yes | |
Alex Robinson | yes | |
Leif Halvard Silli | yes | NOW - at this time - is the time for warnings. Lifting these issues more into the light will make us reach LC faster. It is also in the spirit of the hearthbeat requirement to make clear where we stand right now. |
Jason White | yes | Publishing drafts with editorial notes that call the attention of reviewers to material on which comments are especially sought in order to resolve controversies or address complex issues is good practice. This is particularly so in this case, since the draft specification is relatively long, hence potentially time-consuming to review as a whole. By pointing out specific issues in the draft, members of the public with particular expertise in those areas will have a better opportunity to locate, and comment upon, issues on which members of the working group desire more input. I am also in favour of noting aspects of the draft which are subject to disagreement and therefore likely to change, in order to forestall early implementation of these features that could conflict with subsequent resolutions arrived at by the working group. |
Roy Fielding | yes | Only because the warnings make it better than the last published draft. A proper solution would remove anything controversial that is not supported by existing practice, perhaps moving it to a separate document on proposed extensions. |
Ben Adida | yes | |
John Vernaleo | no | |
Masataka Yakura | yes | I support the idea of showing issues that HTML5 currently has. so yes. However, there are some errors (like "alt that is blank" is not what PFWG claimed) and should be corrected. But I think it's a good start. |
Robert O'Callahan | no | |
Adam Barth | no | |
Russell Cavell | no | |
Frank Palinkas | yes | |
Alfonso Martínez de Lizarrondo | no | Those warnings seems to have been picked randomly. To understand the status of each section of the document I've found much better to use the WHAT WG version. |
Philip Jägenstedt | no | The warning at http://html5.digitalbazaar.com/specs/html5-warnings.html#the-source-element reduces the issue to being just about patents while at the same bringing in non-arguments about "open-source" in relation to submarine patents. It also calls out Apple and Microsoft as potential targets if they shipped "Ogg Vorbis and Theora or Dirac" even though Microsoft has said nothing on the issue. This kind of speculation belongs on the mailing list or issue tracker comments, not in the spec. Ian's original note was better, but nothing at all is fine too. Warnings don't help implementors agree on a codec and authors would be better helped by a link to something like http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support |
James Graham | no | I believe this draft takes a counterproductive approach to addressing the problem it was designed to solve; see http://lists.w3.org/Archives/Public/public-html/2009Aug/0563.html for more details. |
Laura Carlson | yes | Delineating open issues [1] in the spec will help the public become aware of topics of concern or problems. Pointing out areas of contention while they are under discussion will aid transparency. Public review and comment from outside the Working Group are vitally needed and should be vigorously sought. As Jason pointed out, warnings and comments for reviewers will help enable and encourage members of the public to comment upon difficult or controversial issues, while discouraging early implementation of features that are the subject of debate. I agree with Henri to reword the alt warning. The issue is about the spec allowing an <img> element to have no text alternative - not about blank alt. WAI CG has provided advice [2] which has not been acted upon. It is an accessibility issue. It is not a usability issue. Details are in the Wiki. [3] [1] http://www.w3.org/html/wg/tracker/issues/open [2] http://www.w3.org/2009/06/Text-Alternatives-in-HTML5 [3] http://esw.w3.org/topic/HTML/IssueAltAttribute |
Joshue O'Connor | yes | |
Patrick Lauke | yes | |
Hallvord Steen | no | I strongly support the idea of doing this, but not its rushed and random implementation in Manu's draft. Some sort of consensus tracking could be added to the spec review copy so that reviewers could give thumbs up/down for each section and subsection. It would be fairly obvious from a high number of "votes" for a specific section that it has generated passionate disagreements, and this information should be presented along with implementation status details. (As this as described is not really a *vote* for/against the feature, vote rigging might not be a problem). |
Jude Robinson | yes | |
Denis Boudreau | yes | |
Richard Schwerdtfeger | yes | There should also be a note regarding investigation of canvas for accessibility. |
Jace Voracek | no | |
Cynthia Shelly | yes | I prefer this draft, but can live with publishing Ian's. |
Jens Oliver Meiert | yes | (Don’t feel strongly about either version.) |
Arne Johannessen | no | Concurring with Charles McCathieNevile's comments, I generally support incorporating notes on the stability of individual sections (for example, based on existing WHATWG data). However, none of this particular draft's selection and wording of notes appears to me as being ready for publishing at this time. |
Rob Ennals | no | |
Debi Orton | yes | This version provides more information for those web authors who relied on the accessibility techniques associated with WCAG 1.0. Providing this additional information allows more informed comment and may expose some more palatable options for achieving the same ends. |
Eric Carlson | no | |
Vicki Stanton | yes | |
Jirka Kosek | yes | |
Ben Boyle | no | I know there's been some explanation on the list but needs to be clear for those who just come to the draft what's going on. Drafts look the same, this is confusing. |
Laurens Holst | yes | Agreement with all of the reservations in Sporny’s draft, except for #the-source-element. |
Per-Erik Brodin | no | |
Anne van Kesteren | no | We should either be exhaustive with warnings or have it based on some criteria, but not arbitrary. Having said that, the draft already announces it is WIP and I have not seen anything that suggests this is not enough. |
Michaeljohn Clement | no | |
Chris Cressman | no | |
Scott Lewis | no | Criticisms of the set of warnings currently in the draft have convinced me that there should be more discussion in-group and possibly changes to the set of warnings before publication. |
Tab Atkins Jr. | yes | With Manu's new updates, I'm satisfied with the 'warning draft' |
Manu Sporny | yes | |
Daniel Schattenkirchner | no | The warnings in this draft add no real information. If there are issues they have to be discussed, if there are features at risk, maybe mention them in the Differences document that has been published along with the HTML5 draft. |
Gregory Rosmaita | yes | editors drafts should be public, but must be clearly marked as such, and every editor's draft needs he same comments embedded in it as should any public working draft |
Steve Faulkner | yes | |
Ben Millard | no | |
Sander van Lambalgen | no | Lack of consensus and the possibility of change is implied in the working draft status. Although I appreciate the constructive approach to more explicitly informing readers about known areas under heavy discussion, this particular subset seems too hastily thrown together on more or less arbitrary grounds. Additionally these warnings might give the false impression that sections not marked up with a warning are guaranteed to be more stable and/or carry more consensus than might actually be true. |
Krijn Hoetmer | no | |
Stéphane Deschamps | yes | Warnings are vital, from what I've gathered when I tell people of HTML5. So many things change (or are not stable yet) that people want to understand, and they don't necessarily have the time to read the oh-so lengthy discussions on the public-html list. |
Nikunj Mehta | no | |
Tobias Horvath | yes | |
Simon Myers | yes | REMOVE as per Henri Sivonen's comments REWORD as per Henri Sivonen's comments |
Given that these documents differ only in the presence or absence of warnings, how would you like the results of the poll to be interpreted?
Choice | All responders |
---|---|
Results | |
I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | 30 |
I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | 66 |
Responder | What to publish? | Comments |
---|---|---|
Sam Sneddon | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Kornel Lesinski | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Stephen Stewart | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Toby Inkster | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Andrew Sidwell | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Nicolas Le Gall | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Doug Wright | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Whilst I believe the approach of annotating/selectively editing the Editor's draft potentially has merit as a platform for discussion within the WG, I believe that actually publishing multiple versions of the same document as official WDs of the WG is just plain confusing. I would not vote against publishing a reformulation of the additional material as separate WG Note. |
Michael Puls II | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Larry Masinter | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I think neither "majority" nor "most votes" should be used: if there is not "consensus" and there are votes (rather than straw polls), then one-vote-per-independent organization should be retained (one company has 17 members in "good standing"), and the "good standing" role of "invited experts" who are not actually experts or who do not actually participate should be reevaluated. A vote should not determined by those who are listed as working group members out of courtesy or for the rationale that their IPR disclaimer is needed. As far as IPR is concerned, both drafts contain new, unreviewed material that might trigger a patent review; commit-then-discuss should be evaluated against the patent policy to see if some adjustment is needed. |
Martin McEvoy | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
John Drinkwater | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Stephen Axthelm | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Dan Smith | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Joe Williams | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Manu's work can be used but not directly. |
Sam Ruby | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | In this case could live with either document and in the case of competing technical drafts I would support publishing both; but publishing two drafts simultaneously that differ only in informative content seems like it would cause confusion. |
Martin Kliehm | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Matthew Turvey | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Julian Reschke | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing both would create confusion, and also raise the question about which is "the right one". |
David Håsäther | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Benoit Piette | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Theresa O'Connor | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I think each "fork" should go through FPWD (which so far has only happened with formal WG decision-by-vote). Once through FPWD, I think we should always publish new WDs whenever the editor(s) would like to. (I think it wouldn't be a good thing for Manu's draft to also go through FPWD, as it only differs in warnings from Ian's, but nevertheless if we're going to embrace the "anyone can author a spec" idea, we should embrace it fully.) |
Catherine Roy | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
John Kemp | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | As mentioned, I think it might be confusing to publish two drafts where one is a superset of the other. |
John Foliot | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | If there were technical differences between the 2 documents, my answer would likely have been very different. Since I currently see the "Manu's Draft" version as simply an enhanced copy of the work produced by Ian I see no benefit in making both available as Working Drafts. |
Chris Wilson | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Bruce Lawson | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | changed my answer, having seen John Foliot's cleverer response: If there were technical differences between the 2 documents, my answer would likely have been very different. Since I currently see the "Manu's Draft" version as simply an enhanced copy of the work produced by Ian I see no benefit in making both available as Working Drafts. |
Henri Sivonen | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | The purpose of heartbeat WDs is to communicate to the community outside the WG itself, and publishing multiple drafts with only differences in informative statements fails at clear communication. |
Jeremy Keith | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Ian Hickson | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | If "I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts." wins, please count my vote as YES to both drafts. |
Tantek Çelik | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Jonas Sicking | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
David Hyatt | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Adele Peterson | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Lachlan Hunt | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing two separate drafts that are almost identical except for a few editorial comments about the stability of some random "controversial" sections does not solve any real problems, and will only serve to create confusion among the wider community. Even though I do not support the draft with extra warnings, I would rather see that one published by itself than have both needlessly published together. |
Maciej Stachowiak | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Alexey Proskuryakov | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Lee Kowalkowski | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Adam Roben | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Gavin Sharp | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I think publishing multiple drafts would be problematic from a PR perspective. |
Robert Marshall | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Shawn Medero | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
David Singer | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I fear having two variants of one document would be confusing. |
Shelley Powers | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | Two drafts would acknowledge the Editor's work, while providing another document that shows issues of concern. There is no PR problem with this approach--it reflects the current state of the group. On the other hand, I have a difficult time understanding why people who profess support for making information both visible and semantic, would vote for a choice that does neither. |
Chaals Nevile | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing two drafts seems likely to lead to confusion. However I agree with Larry that a serious attempt to reach consensus makes more sense than going through with something that receives a large minority of dissent. I recognise that the decision on how to proceed is up to the chairs, rather than a poll of all comers actually being binding. Please note that Opera Software, with many participants in the group, is not expressing a formal opinion at this time, but rather each participant is free to vote as they see fit, in what we understand to be the spirit of this poll. Should a suggestion such as Larry's be accepted, we would of course submit a single formal vote clarifying that it is such. |
Channy Yun | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Cameron McCormack | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | While I am happy for the WG to publish multiple documents, I don't think selecting between drafts to publish as the main HTML 5 spec at a given point in time is the best way to proceed. I wonder if David Hyatt should really be listed as editor on whichever documents end up being published, though, given that he has not edited either. |
Karl Dubost | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Alex Robinson | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Leif Halvard Silli | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | Now is the time to, eventually, display disagreement. |
Jason White | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Roy Fielding | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Ben Adida | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | I would prefer that we pick a consistent long-term approach: if we are CTR, then everyone gets to CTR. |
John Vernaleo | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | For what it's worth, I don't feel as strongly about my answer to this question than the other two and can see good reasons for either way. |
Masataka Yakura | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Robert O'Callahan | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Adam Barth | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing two very similar editor's drafts would be pretty confusing. If we end up doing that, we should explain what the differences are and why we're choosing to publish both. |
Russell Cavell | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Frank Palinkas | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Alfonso Martínez de Lizarrondo | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Philip Jägenstedt | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing multiple drafts would be harmful. Instead of having polls like this we should spend our time discussing the specific issues, possibly resulting in the inclusion/removal of notes or warnings in Ian's draft, but preferably actual solutions. |
James Graham | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Laura Carlson | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Joshue O'Connor | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Patrick Lauke | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Hallvord Steen | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Jude Robinson | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Denis Boudreau | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Richard Schwerdtfeger | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | These choices seem redundant. |
Jace Voracek | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Although I believe that publishing these approved drafts would be acceptable for those that have a preference, I conclude that taking a vote of which individual draft to publish will lead to the best outcome. |
Cynthia Shelly | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Jens Oliver Meiert | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Arne Johannessen | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Rob Ennals | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publishing multiple drafts will be confusing. |
Debi Orton | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | Based on what I have read in the workgroup's listserv, I fully expect the draft with less accessibility support to receive the majority of votes. In that case, I would like the explanatory draft to be available also, so that we could point authors to that version for explanations of changes. |
Eric Carlson | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Vicki Stanton | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Jirka Kosek | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Publication of multiple drafts will confuse spec readers from outside of HTML WG. |
Ben Boyle | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I would prefer there be one draft for clarity, however I am not opposed to publishing multiple drafts to see if that achieves anything (other than confusion), which it might. Think the differences need to be highlighted in a clear and obvious way for this to be effective. |
Laurens Holst | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Per-Erik Brodin | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Anne van Kesteren | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | In general I'm ok with publishing all Editor's Draft that have majority approval, but they have to offer some normative difference in my opinion. |
Michaeljohn Clement | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Chris Cressman | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Scott Lewis | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Tab Atkins Jr. | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Manu Sporny | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Daniel Schattenkirchner | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | The original draft is sufficient. |
Gregory Rosmaita | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Steve Faulkner | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Ben Millard | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | Being able to fork the development of HTML5 so that alternative approaches can be worked on and reviewed has always been part of the project, as I understand it. Competition and collaboration can co-exist within a project and improve it. |
Sander van Lambalgen | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Krijn Hoetmer | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | |
Stéphane Deschamps | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | I expect it's a matter of democracy. But I really don't see the point of publishing a draft at this point without comments and warnings. |
Nikunj Mehta | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. | Our vote is focused on the continued progress of HTML5. We are supportive of Manu's intention to clarify to the general audience a full measure of where the working group stands. Given the relative short life to date of Manu's draft and the rather daunting task of adding adequate and appropriate warnings in the existing draft, we feel it is best to advance Ian's draft at this time and revisit this topic at the next heartbeat. |
Tobias Horvath | I would prefer to publish all Editor's Drafts that have majority approval as Working Drafts. | |
Simon Myers | I prefer to publish only the one Editor's Draft receiving the most votes as a Working Draft. |
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
w3c/wbs-design
or
by mail to sysreq
.