W3C home > Mailing lists > Public > public-html@w3.org > October 2012

Re: A11y TF Amendment [was: {agenda} HTML WG telecon 2012-10-04]

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 10 Oct 2012 02:15:42 -0700
Cc: public-html@w3.org
Message-id: <D31FE2EC-ED74-4686-A0C9-1579530411D6@apple.com>
To: Smylers <Smylers@stripey.com>

On Oct 10, 2012, at 2:02 AM, Smylers <Smylers@stripey.com> wrote:

> Sam Ruby writes:
>>  Any such specifications will be considered jointly produced by the
>>  HTML Working Group and PFWG, for purposes of W3C Publication. This
>>  means that, as with any w3c joint task force deliverable, both
>>  Working Groups must approve transitions such as First Public Working
>>  Draft or Last Call.
> (I'm interpreting the sentence with the "must" in it to mean "an
> extension specification can only go through a transition if the working
> groups approve it", rather than "The working groups MUST approve
> extension specifications; they have no choice in the matter". If I'm
> wrong in that, please let me know.)

Yes, that's the intent.

> So if the HTML Working Group judges an extension specification to be
> unacceptable, it can decide not to permit its transition. It can't
> insist on any particular modifications to the content to make it
> acceptable.

The HTML WG could of course pass reasons for denial (along with suggested remedies) back to the TF.

>>  Members of either Working Group who have technical comments or
>>  objections on Task Force publications are expected to raise them in
>>  the context of the Task Force.
> What's the effect of "expected" there in practice? If somebody makes a
> technical objection in an unexpected place, such as in the HTML Working
> Group, what are the consequences of that objection being made there,
> compared to if the same objection were made in the expected place?
> Will such objections be ignored? If a technical objection is made when
> the Accessibility Task Force has presented an extension specification to
> the Working Group for a transition, would that be taken into account at
> that stage as a possible reason for not approving the decision, or would
> the objection be set aside for not having been made in the expected
> place?
> Also, what does "in the context of the Task Force" mean? Does it
> specifically mean by being a member of the task force (which has
> participation requirements of minimum hours per month)? Or would e-mail
> to the task force's mailing list count? If the latter, would it be
> sufficient to send mail there after the task force has presented an
> extension specification for a transition?

The way I expect this to work is that if someone makes an objection at the transition stage, they'll be asked to make that objection to the Task Force, e.g. by email or via a bugzilla bug against the relevant specification.

If somebody has made a particular objection to the Task Force already, and the Task Force failed to make a public, substantive response (as required by the W3C Process and outlined at <http://www.w3.org/2005/10/Process-20051014/policies.html#formal-address>) then that would likely be seen as a strong objection to transition, particularly for later transitions such as CR or PR.

> My concern is that if the task force produces an extension specification
> which happens to have consequences outside the realm of that task
> force's specialization, that all members of the HTML Working Group are
> able to provide technical feedback, including objections, which are
> properly taken into account, and without it being necessary for members
> wanting to make such objections to join the task force (with the
> participation requirements that entails).

If a specification is out of scope for the Task Force or goes significantly beyond the scope, that would be a valid reason to object to transitions and would likely lead to renegotiation of where such a document should be hosted. That being said, making comments on Task Force deliverables should not require joining the Task Force.

Does this sufficiently answer your questions?

Received on Wednesday, 10 October 2012 09:16:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:28 UTC