Re: [HTMLWG] Decision: Adopt "Plan 2014" with modifications and make some specific related decisions

On 10/17/2012 06:53 AM, Henri Sivonen wrote:
> On Tue, Oct 16, 2012 at 12:17 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>> The specific disposition of the objections provided by Henri are as follows:
>>
>>> I object to taking an Extension Specification to FPWD simply when a WG
>>> participant offers a draft.
>>
>> Plan does not require that, nor is that our intent.
>>
>>> I object to promoting Web Intents, HTML+RDFa or Encrypted Media Extensions
>>> [under the HTML5 brand]
>>
>> Plan does not require that, any future efforts along these lines would
>> require separate WG approval.
>
> I have noted the lack of “nor is that our intent” in the response to
> the second item.

These points aren't parallel.  In the prior bullet, we have prior 
experience, and we have never done nor even considered what you were 
objecting to.  We have always done Calls for Consensuses or surveys 
prior to decisions like the one you were objecting to.

As to this point, we have no idea what the future will hold.  We can't 
currently categorically rule out what you are objecting to, but we can 
point out that you will have an opportunity to participate should that 
be something that somebody actually proposes.

>>> I object to deciding to publish such Extension Specifications in a way that
>>> portrays them as being on equal footing with for example the canvas API and
>>> fails to conspicuously portray them as dissenting opinions.
> ...
>> The W3C Process explicitly states that Working Drafts do not
>> necessarily represent Working Group consensus on their contents.
>
> That’s unlikely to be clear outside the group of people who have
> studied the Process document. It seems odd to use confusion within the
> W3C (https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c18) as a
> reason to engage in a promotional campaign aimed at the general public
> and then cite the details of the W3C Process as a reason not to
> clarify to the general public something that they seem to be confused
> about.
>
>> Therefore,
>> we do not believe we can add this type of requirement and remain consistent
>> with the W3C Process.
>
> This “therefore” does not seem to follow from the sentences preceding
> it or from precedent. The most recent /TR/ publication of HTML5
> includes a bunch of indications of non-consensus in its Status of this
> Document section and having the CR-time filter does not seem to have
> any logical “therefore” precluding legends in the Status of this
> Document section. Can you, please, elaborate on how exactly this
> “therefore” follows from the considerations presented before it?

You have a tendency to use emotive words with significant negative 
connotation like 'promotional campaign' to describe what the normal 
evolution of a specification is: somebody proposes a feature; there is a 
call for implementations; sometimes that results in implementations, 
sometimes that results in changes, and sometimes the feature is not 
implemented.

Based on your other posts, you seem to want the W3C HTML WG to not 
participate directly in this process.  I guess that's your right to hold 
this opinion, but as long as there are people who do want the HTML WG to 
participate directly in this process -- and indeed 'promote' the changes 
that they feel are warranted -- we will continue to see if there are 
ways that we can help enable rather than discourage those activities.

Meanwhile, we will continue to apply W3C processes for managing dissent:

http://www.w3.org/2005/10/Process-20051014/policies#managing-dissent

And the decision policy:

http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#basic

In particular, we wish to set the expectation that the primary way to 
participate is through bug reports.

>>> I object to this if the resulting [a11y TF] Extension Specifications are
>>> portrayed as deliverables of the HTML WG.
>>
>> While the plan does require that, the proposed states "both Working Groups
>> must approve transitions such as First Public Working Draft or Last Call."
>> Therefore, if HTML WG members wish to object to a specific Extension
>> Specification being an HTML WG deliverable, they will have the opportunity
>> to do so.
>
> I wasn’t seeking an opportunity to object. I was seeking a truthful
> labeling of provenance.

And we point out that you will have an opportunity to object if/when 
such documents are proposed.

>>> I object to treating the inclusion of the hgroup name in the parsing
>>> algorithm as being at risk
>>
>> The original plan and CfC aren't sufficiently clear on this point.
>> Clarified.
>>
>>> I also object to treating the UA stylesheet rule hgroup { display: block; }
>>> as being at risk
>>
>> The original plan and CfC aren't sufficiently clear on this point.
>> Clarified.
>
> Thank you.
>
>>> I object to the plan of being silent on what the master branch is.
>>
>> While the plan is indeed silent on this matter, the proposed charter change
>> replaces "actively pursue convergence" with "consider proposals".
>> Clarified.
>
> I don't see the “clarification” clarifying the matter on the level of
> detail I was seeking. Part of this might be attributable to me using
> “master branch” to mean the main source of changesets (*right now* de
> facto the WHATWG SVN repo) whereas you seem to be using it to mean the
> particular branch currently labeled “master branch” on GitHub which,
> to my surprise, is not an svn-git mirror of the WHATWG SVN repo but a
> branch onto which the editorial team has already cherry picked
> changesets from the svn-git mirror.
>
> I should have formulated my objection as “I object to the Plan lacking
> clear detail on the expected relationship with the deliverables of the
> WHATWG.”
>
> I would expect the Chairs to have an intention with regards to how
> they have instructed or intend to instruct the editorial team to
> behave when cherry picking changesets from the WHATWG repository into
> the HTML WG GitHub master branch and when to introduce changesets that
> don't originate from the WHATWG repository. I expect this intention to
> exist, because it would be very surprising if such an intention hadn't
> surfaced in the discussions the Chairs have had with the CEO or when
> recruiting the editorial team.
>
> Could the Chairs, please, state how they have instructed the editorial
> team for the HTML 5.0 cycle and how they plan to instruct the
> editorial team for the HTML 5.1, 5.2, etc. cycles?
>
> In particular, could the Chairs, please, indicate what the difference
> between their intentions and the following straw statement is?
>
> “Release branches for Recommendation Track documents for HTML 5.0,
> 5.1, 5.2, etc. will be cut from the master branch maintained at
> https://github.com/w3c/html/commits/master . The editorial team shall
> cherry pick onto the master branch changesets from the WHATWG spec
> repository that don't contradict Working Group Decisions and that
> don't introduce features that were not present in the March 29, 2012
> Working Draft of HTML5 unless a Working Group Decision exists for the
> adoption of a feature that was not present in the March 29, 2012
> Working Draft. The editorial team will also similarly cherry pick
> change sets from the repositories of other Community Groups from which
> the Working Group has Decided to adopt a feature for the
> Recommendation Track. The editorial team will introduce change sets of
> its own that don't exist in the upstream Community Group repositories
> only for editorial purposes or to implement Working Group Decisions.
> The HTML WG will focus on getting release branches to REC and won't
> position itself as a venue for developing new features.”

The editorial team is already fixing bugs that aren't addressed in what 
you refer to as "upstream" repositories.  And while this team has an 
opportunity to cherry pick change sets from various sources, they have 
no obligation or expectation to do so.

Their obligation is to address bugs reported against the HTML set of 
specifications.  At times they may assist that process by opening bugs 
and initiating discussions on features that may appear elsewhere.

That merely covers obligations and expectations.  It give the HTML5 
editorial team wide latitude without constraining the HTML WG.  But I 
will note that we picked the editorial team based on what value these 
individuals will bring to the table.

I encourage you to look at results.  Within the HTML5 editorial team, 
Silvia has volunteered to track the WHATWG specification.  That is not 
something she was asked to do, but something she volunteered to do.  I 
encourage you to read her posts on the subject:

http://lists.w3.org/Archives/Public/public-html/2012Oct/0089.html
http://lists.w3.org/Archives/Public/public-html/2012Oct/0085.html
http://lists.w3.org/Archives/Public/public-html/2012Oct/0023.html
http://lists.w3.org/Archives/Public/public-html/2012Oct/0019.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0512.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0503.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0379.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0351.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0349.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0230.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0224.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0222.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0221.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0206.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0205.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0200.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0091.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0089.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0077.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0076.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0072.html
http://lists.w3.org/Archives/Public/public-html/2012Sep/0070.html

Neither W3C management nor the HTML co-chairs have ever discouraged this 
work.  In fact, I will go further and state that I personally invested 
considerable effort into facilitating this by not only seeding the HTML 
git repository with every single commit dating back to 2006:

https://github.com/w3c/html/commits/b3b9bbc9fca6553b70cba5f33c56e2b45f3f4ec1

But also with actively keeping the feature/whatwg branch current:

https://github.com/w3c/html/commits/feature/whatwg
http://html5.org/tools/web-apps-tracker

- Sam Ruby

Received on Wednesday, 17 October 2012 12:09:17 UTC