Re: XHTML 2.0 and Semantics

At 11:38 AM 2003-01-16, Alex Rousskov wrote:

>On Thu, 16 Jan 2003, Al Gilman wrote:
>
> > What we need to formalize is the notion of the "opt-in panel"
> > comprising those who took the trouble to contribute comments.
> > There are multiple points, minor review phases, where the people who
> > should have a voice are those who took the trouble to exercise the
> > invitation to voice comments in a closely related earlier phase.
> > This could be reflected in access rights, tracking notifications,
> > etc.  The notices or digests of activity should come automatically
> > out of the Bugzilla installation [issue-tracking engine] and be
> > controlled by individual preferences as to immediate notification on
> > individual event vs. weekly or whatever periodic updates.  The user
> > can also profile what issues they wish to track.  But they have to
> > take the time to get on the reporting-administration site and edit
> > the profile.
>
>I agree, though I would not call it a "panel" since W3C, by design,
>does not operate on the basis of consensus with public; W3C operates
>on the basis of consensus within W3C (AFAIK).

a) I did not mean to imply any particular voting protocol, or voting status.
  The 'panel' I referred to is a bag of individuals who have distinguished
themselves by contributing comments and to whom it may be beneficial to the
overall mission satisfaction to afford ancillary services (as individuals),
such as notification of state changes in the processing of comments.

I called them a 'panel' because these people should get asked to verify that
the changes actually made to the document address the issues that they
raised in their comments.  At a point where the general public that hasn't
spoken up in the public comment period don't get so asked.  This bag of
individuals is a quality resource, and we need to recognize this in our
process theories and capitalize on it in our process automation.

>Public participants have
>the right to submit comments and should have the right to see those
>comments addressed. They should not, however, have formal "votes" when
>the decision is being made. Moreover, W3C does not have to make it
>easy for the public to _group_ their voices;  WG-individual contacts
>should be sufficient. This is the key difference between IETF (a free
>opt-in public panel) and W3C (a for-fee opt-in semi-private panel).
>
>Bugzilla is a good interface for the WG-individual communication, and
>will make WG accountability relatively simple. However, just
>installing Bugzilla would make little difference -- there needs to be
>a formal requirement for WGs to address/close pending reports before
>each major milestone. I do not know if W3C is willing to assume such
>an obligation.

Beg pardon?  The formal requirement is already there in many cases, to
notify individual commentors of the disposition of their comments and to ask
them to indicate their acquiescence or opposition with regard to this
disposition.  So far we are missing satisfaction of this requirement too
often, and when we do satisfy it it is not done in a way that actually
delivers the quality assurance value that could be extracted from the process.

What we have found in practice is that this communication has to happen in
at least two waves, when the working group reaches a functional intent as to
the resolution, [when the precise language of the docuement change has been
proposed to or agreed to by the group,] and when the re-drafting resolving all
comments has been complete.  Errors often creep in between the first of
these steps and the completion of the last.

This requires better issue tracking tools to make it efficient enough to
do it right, and it is most logical to treat commentors inside
and outside the W3C much the same in this regard.

Our rate of satisfaction of this formal requirements is, say, 70%.
Less than we would like.  Communication with commentors is an area which
clearly has room to improve.  The only thing that the public don't know
is that it's not just them.  The same holds for internal communication.

Not to get too deeply into internal matters, here, we should acknowledge
that this is a known problem and that it is the intent of the process
crafters to gain the maximum advantage from the knowledge and insights
of all who take the time to read and comment on the documents.

This is why, in a companion mail, I am suggesting we need a more visible and
customer-friendly ombudmanic function so members of the public will more
readily trust that they are being listened to.

Al


>Alex.
>
>--
>                             | HTTP performance - Web Polygraph benchmark
>www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>                             | all of the above - PolyBox appliance

Received on Thursday, 16 January 2003 13:09:40 UTC