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

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.

>> 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?

>> 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.

>> 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.”

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Wednesday, 17 October 2012 10:54:03 UTC