Re: Process for proposals

Shelley Powers wrote:
> Sam Ruby wrote:
>> There seems to be an undue fascination with what is, and what is not, 
>> included in Ian's draft at any particular moment in time.
>>
>> First, despite the name of the role that both the WHATWG and the W3C 
>> has given to Ian, my observation is that Ian is first and foremost an 
>> author, not an editor.  Editors supervise, assemble, correct, revise, 
>> and adapt material from a number of sources.  The document that Ian 
>> has been authoring is, instead, essentially an original work.
>>
>> Given that multiple people have participated in the development of 
>> this work (through bug reports, suggestion of use cases, etc.) the 
>> HTML WG has recognized this document as meeting the criteria to be a 
>> Working Draft of this Working Group.  This status is not likely to 
>> change.  This despite the fact that, at various points in times, this 
>> document has contained a number of sections which were later split out.
>>
> I think that "participated" is open to interpretation. Several use cases 
> were given for semantic metadata, but they were re-written by Ian, and 
> then answered by Ian. Well, some of them were re-written by Ian, and 
> interpreted by Ian. He's not addresses all the use cases yet.
> 
> So in effect, Ian has also acted as client rep, requirements gatherer, 
> decision maker, etc. You call him "author", he calls himself "benevolent 
> dictator". I would say his interpretation of his role is much closer to 
> the truth than yours. I just happen to think that "benevolent dictator" 
> is an oxymoron.

OK, so Ian has acted as any or all of the above for a document that he 
produces on his own space, one that the W3C has recognized as Working 
Draft of this Working Group.  All I am saying is that others are 
welcome, and even encouraged, to follow Ian's lead.  Perhaps those that 
do could be a bit more "benevolent" and a bit less of a "dictator", but 
there is no requirement that they do so.

>> If others do likewise, the documents they produce will also be so 
>> recognized -- this is particularly true for any for documents with 
>> little or no overlap with other WG documents, though documents with 
>> overlap may also end up meeting the criteria for FPWD, it's just that 
>> we will be more careful in how we assess consensus on such documents.
>>
> "If others do likewise, the documents they produce will also be so 
> recognized.." I'm sorry, I'm new to this, but this isn't exactly 
> accurate, is it? If another person or group produces a document, and Ian 
> doesn't recognize it, or refuses to include it in the draft, that's it, 
> isn't it?

Ian's document can loosely be described as "those pieces that Ian cares 
to author".  Looking at past history, it is entirely plausible that some 
pieces will be added, some will be spun out, and perhaps even some will 
be dropped entirely.

Others are authoring related documents.  Here are a few recent examples:

   http://www.w3.org/MarkUp/2009/rdfa-for-html-authors
   http://www3.aptest.com/standards/rdfa-html/
   http://philip.html5.org/docs/rdfa/

If we get to the point where one or more of these documents meets the 
criteria to be called a Working Draft of this Working Group, such a 
document will be published as such.  If, by the time we reach Last Call, 
there is consensus that two or more of these documents should be merged, 
then we will be looking for a person to fulfill the role of editors.  If 
this is something that Ian is interested in doing, that would be ideal. 
  Should that not end up being something that he ends up wishing to do, 
we will deal with that eventuality too.

> In addition, isn't this a violation of what you say is the guiding 
> principle behind this effort: commit, first, then review?

Ian is proceeding with a CTR process for the document that he's 
authoring.  Other authors are welcome to employ a similar approach, or 
even explore other methodologies.

> Perhaps you can provide more detail about exactly how other documents 
> become part of this process. Do we raise an issue, and then attach a 
> proposal to that issue? If the proposal is acceptable to the majority of 
> the HTML WG, are you saying then that it will be added to the HTML5 
> draft specification?

The overall structure of the document is uncertain at this time.  Just 
looking at one source of input, namely Ian's draft, there are pieces 
being spun off, and new pieces being added, all the time.

I laid out a series of "if's" above.  I can't predict all of them, but 
looking at the potential worst case: if there are multiple documents, 
AND there is consensus to merge two or more of them, AND this ends up 
not being something that Ian is interested in doing, AND no other 
editors step forward, THEN this Working Group will simply fail.  Ian's 
document will still exist, the WHATWG will still publish it, and many 
people will still find value in it.

At the present time, I'm not interested in exploring those hypothetical 
scenarios further.  I'm confident that there will be a successful 
outcome to this Working Group, otherwise I wouldn't still be participating.

Meanwhile, please produce documents.  Don't feel like you have to wait 
on Ian or anyone.  Or better yet, collaborate on one or more of the 
existing documents.  If any of these gets to the point where there are 
more than three independent contributors actively participating in the 
development of that document, we can explore making such a document a 
product of the Working Group.  Initially, I would proceed with such a 
decision by a process the ASF calls Lazy Consensus[3], which means that 
if any member of the group objects, the matter would come to a formal 
W3C vote.  At the present time, I'm dealing with Maciej's suggestion to 
resolve the one outstanding Formal Objection to the Design Principles 
document in exactly such a manner right now.

>> If no other authors emerge, then there will be no need for a separate 
>> "editor" to assemble, correct, revise, and adapt material from various 
>> sources.  We specifically need people to put forward suggestions for 
>> @profile and @summary.  If no such proposals are produced, such issues 
>> will be summarily closed.
>>
> See above.

Ditto.

>> As to what such a future would look like, here is a rough sketch:
>>
>> 1) The biggest outstanding issue on the document isn't consensus, but 
>> agreement on a suitable license.
>>
>> 2) The content in the document that does not have unresolved overlap 
>> and contradictions with existing specifications will likely be 
>> recognized as having consensus.  This could very well include sections 
>> on microdata and origin.  Those that feel otherwise would be served by 
>> raising issues[1] well before Last Call.
>>
> Noted, and will act. Deadlines on any of this?

Clearly, the sooner the better.  Preferably no later than the summer 
months.  But if issues come later, particularly for issues that couldn't 
have been reasonably predicted earlier, they will be addressed.

>> 3) The issue about what the document itself is named (raised by Roy 
>> Fielding[2]) is also something that needs to be resolved.  This issue 
>> primarily affects the title page and little else.
>>
>> Ian's stated intent is to be ready for Last Call by October.  My 
>> intent is to assess consensus within the working group and to make 
>> every effort to "satisfy significant dependencies with other groups" 
>> (e.g., deal with the accessibility of canvas) prior to Last Call.  At 
>> the present time, I see no reason that all of the above can't be met 
>> by this winter.
>>
>> - Sam Ruby
>>
>> [1] http://www.w3.org/html/wg/tracker/
>> [2] http://lists.w3.org/Archives/Public/public-html/2007Nov/0430.html
> 
> Shelley

- Sam Ruby

[3] http://www.apache.org/foundation/glossary.html#LazyConsensus

Received on Wednesday, 20 May 2009 14:57:37 UTC