Re: suggested process for adding new features to HTML 5.1

Hi Silvia,

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

yes, but I am happy to keep the current level of formality if it works for
people. My email was intened as a discussion starter as how the current
process works was unlcear to me.

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

as above if the current process works for people I am OK with it.

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

yes, I have requested as such here
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20309, it may well be that a
less formal approach works without recourse to a more formal procedure with
assoicated overhead.

a side note: it would be useful if html.next bugs appeared on the
html-public-admin mailing list and a html5.1component added to html.next

>I can see this working with branches in GitHub. However, it needs somebody
to be the champion of the extension specification.
>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?)?


I would suggest that if someone objects to the addition of a feature to
HTML5.1 they need to provide a rationale and be prepared to provide an
alternative proposal. The aim should be to encourage the development and
review of new features within the WG.

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?

No, I was jotting down ideas of a possible process, if this already occurs
and works for people,then it is fine as is.

In general what I am seeking is parity for additions to HTML5.1 regardless
of origin, if the current informal process delivers that with minimal
process overhead then we should continue as we have been.


best regards
SteveF



On 10 December 2012 06:45, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote:

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