Chris Wilson wrote:
James Graham wrote:
It seems to me that several aspects of this procedure have not been followed:
Speaking for myself as chair, as I was chairing the call yesterday, and
although I think Mike and I are in sync on this I want to offer him the
opportunity to give a different take:
The Charter says: "However, if a decision is necessary for timely progress, but
after due consideration of different opinions, consensus is not achieved, the Chair
should put a question (allowing for remote, asynchronous participation using, for
example, email and/or web-based survey techniques) and record a decision and any
objections, and consider the matter resolved, at least until new information becomes
available."
On this topic, there has been much asynchronous participation already. I
explicitly listed this as a topic for discussion for the telecon, to invite
those who might not be able to participate to offer their input or ask for the
matter to handled in some other way in order to incorporate their input.
(There were, BTW, no explicit regrets for this telecon.)
It was not at all clear to me that "for discussion" meant "for making a
spec decision" in this case when it has not in the case for other items
listed as "for discussion" in that or previous telecons.
I also elicited different points of view at length during the issue
discussion on the telecon. There was, in effect, no significant dissent
represented on IRC or the telecon, and I considered consensus to be achieved -
thereby requiring no further question to be put to the group.
As Ben has pointed out this is not reflected in the minutes.
The chairs are NOT bound to put each and every issue to a vote or poll, when we feel
consensus (= "general agreement", not unanimity) has been achieved.
How do you decide whether consensus has been achieved? In this case
there were, roughly speaking, two opinions on the issue (although, I
note, the telecon had far more participants with one opinion than the
other). I have not seen significant evidence that people who started
with one opinion have migrated to the other nor that some common ground
in the middle has been reached. Given the relatively small number of
participants in the discussion compared to the size of the group, it's
not clear to me what the majority opinion is, especially given that many
people with opinions may be staying out of the discussion if somebody
else is adequately representing their viewpoint.
And, of course, after putting such a question to the group, it would still be
Mike and my responsibility to declare a decision anyway.
Indeed, my reading of the charter is that as long as you /ask/ the
group, you can /decide/ anything you please.
As a member of the WG, of course, you can claim that the chairs are
inappropriately declaring consensus, and ask for an explicit poll, or of course
escalate to the Staff Contact, the Group Lead, etc. I would ask, of course,
that you start by approaching the Chairs and ask for a discussion (email, to
the group even, is of course just fine) of why a particular decision might be
considered consensus even when there is dissent, and I think you'll find that
Mike and I are happy to oblige. But we do want to make progress, and I don't
think any of us want to be blocked by lack of unanimity.
Indeed, if unanimity is a necessary requirement there will never be any
progress, and clearly progress is necessary otherwise we will have
failed. I certainly don't want to block progress, nor do I intend to
spend my time escalating issues through the W3C hierarchy. However, as I
say below, I think circumventing the ordinary feedback loop in order to
make quick decisions should be reserved for issues where the benefits of
a quick decision outweigh the costs. I have no idea why this was
considered to be such an issue.
James, you also said:
There is no need for a decision to be made for timely progress.
That could be said of pretty much any part of the specification. We must
somehow boil this ocean anyway, so I'd consider that we need to start
somewhere. If there is a reason that setting this section aside would be a
good idea (e.g. new information is expected, industry is changing, etc.) then
I'd be willing to entertain that.
Nevertheless, for better or worse the charter puts the burden of proof
on those wishing for a formal decision to be made to demonstrate that
the decision is needed for progress. Is there a documented reason that
this particular decision was so important that it should circumvent the
usual proposal-draft-feedback-redraft cycle? We have recently seen the
positive impact of the usual feedback cycle with the beginings of of
convergence on the @alt issue; I think that, in that case, making a
premature decision based on "consensus" achieved amongst a group of ~10
people at a telecon would have been significantly less effective in
finding a solution that the group as a whole agreed represented progress
over the previous state of the spec than we achieved by iterating the
draft, thus allowing for asynchronous consideration of the merits of
each proposal.
A good example of a case where there was a need for a decision for
timely progress was the recent forms survey; clearly HTML 5 requires
forms support, and the longer that the forms work is left out of the
spec, the less opportunity there is for valuable peer review.
If you are concerned that "boiling the ocean" may take a long time, I
would suggest the right approach is not to pick the areas most likely to
recondense, either through dissent within the group or by implementors
doing something different so we have to change anyway in CR. This
question, which is both controversial and about a largely unimplemented
(except insofar as extant AT /supports/ @headers pointing to <td>, which
is rather different from whether it should be /conforming/) section of
the spec seems to suffer from both of those problems.
It is not clear that all the different opinions were adequately considered.
That is always a concern of mine, of course.
For example, I can see no evidence to suggest consideration of my point that
marking up the example table with <th> for all the cells which the UA should
treat as headers, and modifying the automatic association algorithm to cope, is
easier for authors to understand and more likely to be done by authors not
specifically interested in accessibility [2]. Therefore, taking this alternative
approach will do more to improve overall accessibility of the web than simple to
spec, hard to author, solutions like @headers pointing to <td> (this is related
to our "Priority of Constituencies" design principle [3]).
Actually, we did discuss this explicitly. See the minutes
(http://www.w3.org/2008/08/28-html-wg-minutes.html) and search for "Hierarchical
headers".
I saw that but I'm not sure what consideration was given to my point
that the extra complexity of the language model implied by allowing <td>
cells to act as headers has accessibility risks. Accessibility is, of
course, one of our design principles. At risk of repeating myself, I'll
outline the argument for not allowing <td> to act as a header cell again:
Case a)
All header cells are always <th>
1) A normal author who has a limited interest in accessibility wants to
mark up a HTML table.
2) He reads in a HTML tutorial that everything that should be treated as
a header for one of the other cells must be marked up as <th>
3) He marks up his table using this relatively simple principle and,
without any additional effort has produced an reasonably accessible
table (except in the rare case where the table is extremely complex and
@headers is required)
Case b)
Headers cells are either <th> or <td>
1) A normal author who has a limited interest in accessibility wants to
mark up a HTML table.
2) He reads in a HTML tutorial that everything that should be treated as
a header for one of the other cells must be marked up as <th> unless it
can also be thought of as also being data in which case it must be
marked as <td>
3) He marks up the table using this principle but has now produced a
table which is likely inaccessible as a UA has no chance of
understanding which of the <td> cells were supposed to be headers and
which were supposed to be data. Having little interest in accessibility
the author does not know about complex mechanisms like @headers, or does
not care enough to painstakingly add all the extra markup to his table
that use of @headers implies.
I see mixed <th>/<td> headers as a design that works for people who's
primary interest is in accessibility; it is largely people in that field
who have been arguing in favour of changing the spec. However such
people do not represent the majority of authors and are presumably not
responsible for the majority of content that people using AT want to
visit. Therefore we should not optimize our design according to the
principle that everyone will act like an accessibility expert, but
rather to the principle that accessibility experts are the exception
rather than the norm. I think, although I would be interested in seeing
data to prove or disprove it, that the mixed <th>/<td> design for
headers does more harm than good here.
A telecon does not allow for asynchronous participation.
No, but a telecon and a mailing alias, plus an escalation path, do. If you
feel this issue hasn't been given due process, then let's discuss how to ensure
that you believe your feedback is being listened to, even if it is not followed
directly.
The charter says
"If a decision is necessary [...] the Chair should should put a question
(allowing for remote, asynchronous participation using, for example,
email and/or web-based survey techniques) and record a decision"
At what point was the question put by the Chair? I don't recall that
happening but I may well have missed something; I have been unusually
busy recently. I'm also not sure which emails were considered part of
the "remote asynchronous participation"for this question. I know some
emails were discussed at the telecon but it's hard to ensure that a
specific point is considered without being present. This seems likely to
diminish the influence of the "remote asynchronous" participants
compared to those who are present, making the final decision of the
chairs less likely to reflect the full spectrum of considerations
brought forward.
In general I would suggest that one way to ensure that people (not just
me) feel like their feedback is being listened to is not to make
decisions at telecons that they cannot attend. It seems clear to me that
the intent of the charter is not that any topic discussed on the mailing
list is fair game for a synchronous decision at a telecon or F2F, but
rather that decisions are only made in asynchronous media (although I
accept that you disagree), and I would expect that making decisions at
telecons will often cause people to escalate the issue afterwards.
Therefore this seems like an inefficient way of deciding things,
particularly things that require detailed consideration of a range of
technical arguments. Also, since synchronous meetings necessarily
require expediency, it seems less likely that good technical decisions
will consistently be made this way. It also seems like the decisions
will have obvious biases toward the opinions of people able to attend as
part of their work and against people who have unrelated employment or
classes to attend. Therefore, regardless of the interpretation of the
text of the charter, I think it would be better to avoid this kind of
decision making process.
