Re: CfC: Request transition of HTML5 to Candidate Recommendation

On Nov 25, 2012, at 8:38 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 11/25/2012 10:07 PM, Roy T. Fielding wrote:
>> On Nov 25, 2012, at 5:36 PM, Sam Ruby wrote:
>> 
>>> On 11/25/2012 06:18 PM, Roy T. Fielding wrote:
>>>> Instead, the specification takes on a bizarre "Us vs The Man"
>>>> attitude
>>> 
>>> The specification has been developed in the open over a long period of time.  The current editors were chosen as they were felt to be people that could respond reasonably to requests for change.
>> 
>> AFAIK, the current editors have not edited that section.
>> They are free to respond reasonably to the requests I just made.
>> 
>>>> If the WG decides to advance the HTML5 specification to CR
>>>> without fixing these errors and inconsistencies, then please
>>>> consider this a formal objection.
>>> 
>>> Typically, the way this process starts is with one or more bug reports:
>>> 
>>> http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#basic
>>> 
>>> Some of the issues you describe appear to be editorial in nature. Presumably those could be addressed during CR?
>>> 
>>> Others appear to be more substantive.  Ideally, the reporting of such would propose changes[1] that (if adopted) would remove the need for a Formal Objection.
>> 
>> We already have
>> 
>> http://www.w3.org/html/wg/tracker/issues/56
>> http://www.w3.org/html/wg/tracker/issues/81
>> 
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=7687
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=8207
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=8264
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=8906
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=9035
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=11380
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12543
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13721
>> 
>> http://lists.w3.org/Archives/Public/public-html/2011Mar/0585.html
> 
> For completeness, I will add:
> 
> http://lists.w3.org/Archives/Public/public-html/2011Mar/0404.html
> 
>> I proposed changes that would remove the need for a formal
>> objection.  While the bug reporting system is useful and has been
>> used to file similar issues in the past, which were later closed
>> without action by the editor, I don't believe that bugzilla entries
>> are necessary for an objection to advancing to CR.  The CfC is
>> subject to the official W3C process and I believe that my email
>> is sufficient for that process, including enough technical detail
>> for the editors to resolve the objection if so desired.  I don't
>> have the time or energy right now to add any more, at least not
>> until some of the existing ones are addressed.  CR is supposed
>> to imply that such known issues have been resolved.
>> 
>> I believe the editors are fully capable of understanding my
>> objection without more process.  If necessary, I can help in the
>> production of a git patch next month if the discussion warrants it.
> 
> From my perspective, the status in March of 2011 -- after literally years of discussion -- was that we were waiting for somebody to turn your proposed text to a change proposal; and that you believed that the issue should remain open until there was a proposal that satisfied the issue.
> 
> The status as of late November 2012 is that we still don't have a proposal.
> 
> This is not a matter of people not being capable of understanding your objection.  This is a matter of nobody putting forward a proposal that satisfies your objection.

It is the responsibility of the editors to do so if you wish the formal objection to be resolved. This notion that the reporter of errors in the spec needs to produce an exact diff is something you created that is not part of the W3C process. The message I wrote is sufficient to make the changes.

> Others are welcome to chime in, but given what I see, my recommendation is that we don't hold up 5.0 CR waiting for something that has yet to happen.

I did not ask anyone to wait. You did. The purpose of a CR is to present a specification that is technically complete. Your focus should be on producing such a spec, not grasping for reasons why I have to do the work for five intelligent editors.

> Should something better comes in during CR and we decide to adopt it, then we have already built in a plan for another Last Call[1].  Should the proposal come in after CR, the improvements can be folded into 5.1.

As I said, I object to advancing to CR without resolving the issue. The current spec does not qualify for advancement.  If you want to call the spec ready for CR, then have the editors resolve the objection or prepare your case for why the Director should disregard it.

If I happen to find the time to prepare a set of patches to the git source, I will, but I have other specs for which I am the responsible editor and none of them allow the editors to sit idle while waiting for complete diffs of every suggestion.

....Roy

Received on Monday, 26 November 2012 07:14:13 UTC