Re: Clarification of process for raising html5 accessibility related issues

Apologies for top-posting, but here we go.

I recommend the following tactical steps regarding the
issues that Gregory added to the Tracker and Mike removed:

- the issues will be reviewed by PFWG; and to the extent confirmed
by that review, will be raised by PFWG with the HTML WG.

- Mike, Chris, Michael and I will work out the details of how
they get worked into the HTML WG Tracker, agendas or whatever
works for HTML WG, just so long as HTML WG addresses the substance
of the issues.

This is IMHO an application of two standing principles:

1. "The Chair runs the Group" -- as memorably summarized by
the Advisory Board.  The leadership of the HTML WG has to have
the ability to control workflow and to tailor their work process
to the needs and nature of the individual group.

2. PFWG as a source of a second opinion when someone who think that
they have an accessibility issue with a W3C technical report
is not satisfied with the way their issue is handled by the
pertinent Working Group.  This may not work and other channels
of recourse are available, but this should be tried first.

Al

On 13 Jun 2008, at 11:26 PM, Laura Carlson wrote:

>
> The following is a related message from Jason White relayed here with
> Jason's permission:
>
> On 6/13/08, Jason White <jason@jasonjgw.net> wrote:
>
>> On Fri, Jun 13, 2008 at 11:28:16AM +0200, Robert J Burns wrote:
>>> I'm all in favor of us clearing up the process surrounding the  
>>> WG, but
>>> I don't want to endorse Mike Smith's unreasonable position regarding
>>> the issue tracker. The issues Gregory added on my behalf are  
>>> perfectly
>>> within established norms for adding issues to the issue tracker. If
>>> their are substantive objections to those issues, then the  
>>> discussion
>>> should focus on the substantive objections (i.e., what problems  
>>> would
>>> solving these issues cause for users, what confusion could solving
>>> these issues cause for authors, what difficulties would implementors
>>> face in implementing solutions to these issues, etc.).
>>
>> I agree this is where the priorities should lie. It is more  
>> important to fix
>> the HTML working group's issue tracking practices than to discuss,  
>> on this
>> list, ways of working around their inadequacies.
>>
>> While it is possible for a working group not to track all issues  
>> raised
>> during
>> the early stages of the development of a spec, this practice needs  
>> to be put
>> in place in later stages of the W3C process so that the group can  
>> formally
>> respond to all issues raised in comments submitted. However, with  
>> a large
>> and
>> complex specification such as HTML 5, I would be concerned that  
>> unless
>> issues
>> are tracked carefully from an early stage, there is a very real  
>> risk that
>> important problems could easily be lost. After all, the purpose of  
>> an issue
>> tracker is to ensure that this doesn't happen and that decisions are
>> documented sufficiently; and as the number of issues grows, this  
>> becomes
>> increasingly necessary.
>>
>> If issue tracking isn't carried out properly from the start, then  
>> problems
>> which are discussed but, for one reason or another, not addressed,  
>> are
>> likely
>> to emerge again later in the process, where dealing with them can  
>> be much
>> more
>> painful. No reasonable working group participant wants a large  
>> number of
>> difficult issues to arise at Last Call or later that could have  
>> been more
>> adequately dealt with earlier. Last Call, Candidate Recommendation  
>> and
>> Proposed Recommendation are challenging enough as it is, without a  
>> host of
>> issues that have previously been raised but then overlooked or
>> disregarded.
>>
>> Also, having significant, dissatisfied constituencies among those  
>> who will
>> implement or otherwise use a spec, is just asking for formal  
>> objections or
>> negative votes as the W3C process proceeds; so this, too, is  
>> precisely a
>> situation which it is rational for working group participants who are
>> committed to the success of the process to ensure is avoided.
>>
>> Of course, HTML is a large spec, and tracking the issues  
>> adequately is a
>> correspondingly difficult job. However, the working group is also  
>> a large
>> one,
>> which should make it possible to divide up the problem among  
>> participants so
>> as to reduce the over-all burden.
>
> -- 
> Laura L. Carlson
>

Received on Saturday, 14 June 2008 14:03:22 UTC