Re: suggested process for adding new features to HTML 5.1

Hi Steve,

I assume your email is mostly about formalizing some of the process that we
have followed in recent weeks already.


On Sun, Dec 9, 2012 at 9:47 PM, Steve Faulkner <faulkner.steve@gmail.com>wrote:

> Hi all,
>
> on recent threads [1], the subject of how and what new features (in this
> case I am referring to the addition of attributes or elements) get added to
> HTML5.1, has arisen.
>
> The current situation appears to be:
>
>
>    - New features originating from the WHATWG spec can be added without a
>    CFC from the working group
>
> This is not entirely true.

I send an email every week explaining what patches I am staging for merging
into the HTML5.1 (and what editorial fixes I'm staging for the HTML5) spec.
While this is not currently an explicit CFC, It comes with a request for
objections to merging those patches. Thus, every week, the WG is being
asked to raise concerns about the merging of patches from the WHATWG. I
only go ahead where there are no concerns and address concerns the week
after.

We can possibly make this weekly email a more formal email, which is
followed up by a chair asking for formal CFC. Would that be sufficient to
meet your request?



>
>    - There is no clear path for features originating from other groups or
>    from within the HTML WG to be added to HTML 5.1.
>
>
I believe this is not true. The HTML WG has a decision process that has
been worked out well, see
http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#basic .

The way for features to get into the spec is through email discussions on
the list and through bugs.

Maybe your concern is that we need to add the addition of HTML5 extension
specifications as another means of introducing new features into HTML5.1? I
would support this - unless the extension specification is meant to be a
separate spec altogether for modularity reasons.


>
> I suggest that for any new feature (addition of an attribute or element)
> or major change in a current feature (removal or redefining of its
> semantics/function) regardless of origin, that A CFC occur.
> If a CFC passes without objection (objections are processed as per WG
> process by the chairs), the addition may upon request be merged into HTML
> 5.1. If there are objections (upheld by the chairs) the feature may be
> pursued as an extension spec subject to the usual WG process for extension
> specs.
>

I can see this working with branches in GitHub. However, it needs somebody
to be the champion of the extension specification.

I am flagging this because it is easy to stop a WHATWG feature from being
introduced into the HTML WG when none of the proponents of that feature are
actually active in the HTML WG. In this case, there will also be nobody
championing the extension spec. Is it expected in this situation that the
editors take over the duty to create, write rationale, and progress the
extension specification? Or will we just pull the objectionable feature
into a separate GitHub branch and wait until a browser vendor implements it
(having read the spec ... at the WHATWG?)?



> In the case where there are multiple overlapping new feature proposals
> (example srcset and picture) that they be developed as extension specs
> until consensus emerges on one of the proposals, which then may be added to
> HTML 5.1
>

This has indeed been the course of action already in the past. Are you
asking for this process to be formalized?


In the case where an extension spec is developed that competes with a
> feature currently in HTML 5.1 and is published as a FPWD, the feature in
> HTML 5.1 is pulled out of the spec and may be developed as an extension spec
>


> In the case where there is a feature developed as an extension spec that
> has reached FPWD and with no competing proposals, upon request, the
> feature  be merged into HTML5.1
>

As for other features originating from the WHATWG, the editor of a merged
> extension spec can continue to develop the feature via the spec and changes
> are pulled into HTML 5.1 subject to usual WG oversight.
>

I'm basically ok with these.

he initiation of a new merge should probably follow a CFC on the mailing
list (similar to what is proposed for the WHATWG changes) and a bug in
which the author of the extension spec and an HTML editor sort out the
merge. Preferably the merge is just a patch on the HTML spec source file.

Regards,
Silvia.

[1]
> http://lists.w3.org/Archives/Public/public-html-admin/2012Dec/thread.html
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
>
>
>