Contents

convene weekly HTML WG issue-tracking
telcon

<smedero> oedipus, I'm not
convinced the names are right...

<smedero> but who knows

<smedero> Steve_Faulkner
joined before I did... so he should be in the first slot,
right?

<oedipus> GJR has 2 agenda
requests: 1) ternary state of tracker (formal request of chairs
made) and 2) a week's extension for my proposal to the forms
task force list as i have had severe infrastructural problems
(including an entire day without electricity)

MikeSmith: as far as Chris
Wilson's +1 message, I don't find that particularly
useful
... in general, "+1" messages to the list are rarely, if ever,
useful in discussions on the list

<oedipus> shepazu: ignoring
plus one messages discourages participation - sometimes there's
nothing left to add to a well articulated post

shepazu: can I slightly disagree
with that?

<Lachy> if there's nothing
left to add, then there's little point in posting anything at
all.

<oedipus> is following up on
issues the responsibility of the issue tracking team?

<Laura> A +1 adds an
additional voice of support to a concept or proposal.

<Lachy> the problem with
+1's, which we had trouble with back when the group started, is
that it floods people's inboxes with mostly useless messages
and takes up valuable time from reading potentially more
important messages

<shepazu> discouraging "+1"
can suppress minority opinion by alienating list members who
might have nothing more to say but who do agree with the
poster... it's a good way to make sure that only the most vocal
are represented in the considerations

<Zakim> oedipus, you wanted
to say that we need a statement on behalf of the chairs as to
what the three states mean

<shepazu> Lachy, agreement by
a large number of people *is* something to add

<Lachy> and it seems to imply
that the opinion of the person who sent the +1 actually carries
weight, when it may well not carry any at all, except in rare
cases

<Lachy> shepazu, no, it's
not, because it's the quality of the argument, not the quantity
of support

<Lachy> that matters

<shepazu> ... unless you are
keen on suppressing other opinions from finding a voice

<oedipus> GJR thinks issue
raising and tracking needs to be addressed by the chairs so
that we can progress towards something resembling stability and
consensus

<shepazu> Lachy, sometimes,
but not always... many decisions are simply a matter of what
the most people want, and have no deep technical merits to
either side

MikeSmith: I am not inclined to
require that we obligate ourselves to take action on every
RAISED issue in any way different than what we have already
been doing.

<Steve_f> 'quality of
argument' is a qualitative statement, showing support for an
argument reinforces the argument

<oedipus> especially "same
level of response that I give any e-mail sent to the WHATWG

<oedipus> list; that is,
given full consideration and given an explicit response.

<oedipus> why not the same
consideration to issues raised in the HTML WG?

<oedipus> and on
public-html?

MikeSmith: We will be using
bugzilla as a means for allowing anybody to raise issues
against that spec and to be able to track them.

<shepazu> also, it doesn't
take long to process a message that says only "+1"

<oedipus> SF: issue - summary
attribute been raised twice - how do i get it on issue
tracker?

<oedipus> MikeS: appropriate
for bugzilla

<oedipus> LC: already in
tracker

<oedipus> MikeS: really? what
is issue number?

<oedipus> LC: issue 32 - was
closed by hixie

<Lachy> +1's should be
reserved only for issues where a vote matters, and in which
case it should be done with a survey, not a bunch of +1
mails

<oedipus> MikeS: other issue
is that hixie was told to do what he is doing - when issue in
issue tracker and editor done responding to it as editor, he
was told to close it out and that's what he's been doing; don't
have state in tracker that marks "resolved by editort" --
bugzilla provides far more granularity

<oedipus> MikeS: editor could
mark an issue as resolved to his satisfaction in bugzilla

<oedipus> MikeS: discuss on
telecons; number of issues in my estimation don't merit enough
attention to be discussed on weekly calls - especially 42
through 50; summary does need resolution, but night and day to
GJR's issues

<oedipus> GJR notes to
shepazu that that was his original request until he realized
that RAISED served the same function

<smedero> Ian closed it
because he needed wanted more information....

<oedipus> MikeS: limitation
of tracker - resolution needs chairs intervention - reopened
issue 32 and will remain open until have a resolution that
allows it to be closed; not resolved now -- needs more
discussion

<oedipus> SF: in situation
where have issue considered resolved by editor and chairs, but
not by members of WG, how are those issues tracked?

Steve_f: in a situation that is
considered resolved by the editor and by the chairs, what is
the recourse?

<shepazu> oedipus, not
quite... raising an issue means that it is in the system to
make sure it's considered, while "pending review" can mean that
work has been done on it

<oedipus> SF: are some
substantial issues that editor considers resolved, but WG
members do not - what is resolution path?

<oedipus> shepazu, i was
trying to work within the framework of the available
tools...

<Lachy> I don't see the value
in reopening the summary attribute issue until there are more
substantial arguments, that aren't simply rehashing the same
arguments from before

<Lachy> I don't think people
saying they object to the issue being closed, which is
basically all there has been, qualifies as such a reason

<oedipus> SF: marked as
closed, reopened, then closed again, then reopened again - not
going to be resolved in near future -- WG working on it from
different angles, but if doesn't get resolved through
conversation/discussion has to be resolved via a vote

<oedipus> MikeS: alt issue
closed is same problem with summary

<oedipus> SF: substantive
issue not resolved should stay as open issue on tracker

<oedipus> MikeS: will happen
going forward - issues will not be closed without my (mikeS)
say so

<oedipus> MikeS: should
review all closed issues - if any anyone feels closed
prematurely, bring up and reopen, as did with summary
attribute

<oedipus> MikeS: hixie
already said that that is his stance -- if that is "correct"
interpretation of his role is a seperate issue

<oedipus> MikeS: Laura,
received question about priority of response (WHAT WG over HTML
WG) - need to make clearer what are the priority issues and
bring them to hixie; complicated by discussion about the issues
42-50 which i don't think merit any special attention than any
other issues no matter their origin; those issues were not
agreed to as priority

<oedipus> MikeS: gives me
more leverage to get hixie to reprioritize issues

<oedipus> MikeS: agree we
need to have more of a coordinated consensus about which issues
we want to make priorities; cannot insist that every issue
raised on public-html more important than those raised anywhere
else

?

<oedipus> GJR how can you say
it is not an issue by fiat when those attending calls keep
raising them

<oedipus> GJR: what is
"review process"? how can we raise issues if no "review
process" defined

<oedipus> MikeS: equally
confused by fact that GJR and RobB don't understand difference
between an important issue and parochial issues

<oedipus> GJR notes that a
blind man's poison is another man's food

<oedipus> MikeS: alt required
a show stopper for Last Call; issues 42-50 don't rise to that
level

<oedipus> MikeS: same level
as other issues floated on list - if everyone in community who
wanted to make their own issue a special priority, there would
be no way for us to track issues with real priority; tracker
needs to be a place where we are looking only at high priority
issues

<oedipus> MikeS: need to
formulate a way to define issues that rise to issue tracker
level

<oedipus> MikeS: another
class of issues: issues raised by other working groups;
example: issue added on behalf of Al Gilman (chair of PF);
issues that affect relationships with other WGs or other
specifications, need to be resolved at highest priority; need
to resolve issue now or during last call -- that's the kind of
issue that should go on tracker

<oedipus> DS: only flaw is
that criteria hasn't been made clear to group; need to declare
how things are given issue status - as important as "principles
of operation" - group decides on system to manage issues and
actions - should be codified someplace

<oedipus> GJR: looking for
clarification from chairs

<oedipus> GJR: original
comments on MS in role as staff contact, not as chair or
whatever

HTML Authoring Guide

MikeS: checked in changes -
current version in CVS reflects latest changes, right?

<Lachy> I'm going to try and
get something worth publishing as an FPWD within the next
couple of weeks

<Lachy> yes, I checked in the
most recent changes about 30 minutes ago

LH: brief summary of changes -
added syntax change descriptions, differences between HTML and
XHTML - will add major elements to section after that and hope
to have draft ready for publication in a week or 2

MikeS: want to stick to 3 month
heartbeat req; next version of spec in September 2008; would
like something publishable at least a month before next
heartbeat release
... 10 September 2008
... another useful thing would be to give a heads up on
public-html list and give a summary of what you've changed

MikeS: due date today - chrisW
moved due date to today's date
... 150 days from 22 january - so 22 june 2008 is due date for
patent review
... any patent disclosures with regards the draft published on
22 january are due 22 june - this applies to anyone and
everyone
... don't know current situation with all patent stakeholders;
apple been doing review - as well as MS

DS: issue will be obsolete after
22 june 2008

MikeS: right
... need chrisW to update
... downside of tracker - doesn't give audit trail
... test cases don't apply to open source discussion; from w3c
team side, have not received/seen any change in w3c license
policy
... w3c documents cannot be modified and published in modified
form; applies to rec-track documents, but don't distinguish
between normative rec-track documents and notes (which are
non-normative); more important to ensure don't have conflicting
versions of standards being published
... my own opinion - don't know what info DanC has that might
affect this

<smedero> MikeSmith: From
Dom@W3 about Action changelog - "Note that actions created from
IRC do not carry that information, since it isn't possible (or
at least practical) to define who asked to create the action
based on the IRC commands."

MikeS: forms working group
(action 56)

GJR: needs more time to propose
to task force - hopefully by end of day/tomorrow

<MikeSmith> action-56?

<trackbot> ACTION-56 -- Chris
Wilson to wilson to follow up with Forms WG to make sure they
understand this plan of action by 5/1/2008 -- due 2008-06-12 --
OPEN

MikeS: volume of change makes
hard for most people to keep up to date; trying to keep a
running record and recycling info to the WG; need to publish a
message weekly that says "these are the changes that have been
made this week" so that have more eyes on changes and don't
sneak up on people

MikeS: going to make
accessibility related changes a highlight; all WG members
should review changes to spec to keep up to date on current
status, so that those with special interests and expertise
(especially accessiblity) are in the loop
... will also be working on a better way to recycle to group
regular updates on changes
... biggest set of issues left -- next week, instead of
approaching in serial manner, start with "big issues"
... couple of raised issues related to HTTP which we haven't
taken up and do need to take up - julian has expertise

MikeS: reopen issue 41 - an issue
for discussion with TAG - example of what should be kept open
on tracker
... don't know what can do about "decentralized accessiblity"
-- issue for TAG and a lot of others (WAI, Ubiquitous Web,
etc.)
... any others people want opened?

MikeS: not sure what issue
precisely is - ARIA has dependency on XHTML - extension of Role
Attribute Module - Role module references CURIEs
normatively
... CURIEs put forward by XHTML2 WG - not sure if TAG has made
a finding

GJR: TAG concerned about CURIES -
multiplicity of ways of defining short URIs a worry, but no
declarative finding; XHTML2 WG continues to work on CURIEs
draft

<MikeSmith> oedipus: TAG has
issued a finding that they have some reasons to be uneasy with
the current CURIE spec ... XHTML2 WG is working on addressing
the concerns

<MikeSmith> oedipus: this has
been a problem with PF as far as ARIA ...

GJR: PF taking CURIE agnostic
view -

DS: don't think HTML WG should be
considering

<MikeSmith> ... our PF policy
has been to use @role as outlined, and we worry about CURIEs
when a decision comes down about CURIEs

MikeS: long-term concern, but
nothing about ARIA in HTML5 spec, so no attempt to address
CURIEs; haven't incorporated ARIA attributes into spec, so not
of immediate concern, but will be an issue if CURIEs end up
being endorsed by TAG; as far as way that spec is currently
defined, CURIE syntax might be in conflict with conformance
criteria already in HTML5 spec - specifically
microformats
... RDFa integration also a question - use case for CURIEs from
RDFa task force - if have RDFa integrated into HTML5 will have
CURIE issue