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 <[EMAIL PROTECTED]> 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
