confidentiality in W3C WGs

[Matthew Gertner]

> Right.  Do it the OldeFashionedWay:  Document by paragraph number the
> text, the suggested edit to the text, the rationale for the technical
> change, the submittor. the reason for accepting or rejecting the
> change.  There are some sage standards editors on this
> list (Dr. Goldfarb? Dr. Newcomb?) who can provide a precise format
> for this kind of document.
> 
> It really is that easy.  We can't fix the W3C.  We can't fix the
> press.  We can go our own way.... or we can state in earnest to
> whatever authority can provide support that the need for clearly
> documented public rationale for public utilities outweighs the
> need for confidentiality.
> 
> Editing such documents before publishing them is good practice.
> Publishing blow by blow summaries of meeting debates is bad practice.
> There is plenty of experience in this community to explain those
> practices.

Well, I wonder if the argument for doing it Ye Olde Fashioned Way is
really as strong as all that. I see two reasons to at least consider
that this might not be the case, assuming that the primary motivation
for the current confidentially policy is the one laid out my Lauren
earlier in this thread:

1) The situation in the DOM group was exceptional in that two very
high-profile companies were engaged in a very public legal battle at the
same time as the WG was attempting to consolidate and improve on the
well-known and broadly-used technology of these companies. It would be
safe to say that a situation of this type hardly ever arises. Even the
industry press is unlikely to latch onto a debate over, say, how many
namespaces XHTML should use. I am therefore not sure whether such rare
cases should be given too much weight in setting general policy.

2) The world is changing. Someone made a comment that the press will
continue to distort facts even if these facts are publicly available.
Maybe so, but they can and do do this anyway. Surely a situation where
these facts can at least be confirmed and rebutted by interested parties
would be more desirable than one where no one but W3C members can even
comment, and all they can say is "Please trust us, its not true but we
cant say why or explain the real situation". Even 5 (3?) years ago it
was not possible for the vast majority of people to gain preliminary
access to information about W3C goings-on (or any other standards
activities) through any means other than the media. Now almost everyone
who is at least as interested in these activities as in the
square-footage (acreage?) of Bill Gates new house has access to the Web.
As technologists of one breed or another we should be the first to
recognize that radical changes in the way the world communicates should
affect the way that we address this kind of issue.

I am honestly not expecting the W3C to change their confidentially
policy because me and a couple of other crackpots on this list think
they should, although I do think that complete openness would have huge
benefits far outweighing the disadvantages. Actually, it occurred to me
that there is a more convincing argument for at least keeping the exact
contents of discussions (i.e. who said what) secret: companies
(especially startups eager for publicity) might take extreme viewpoints
to attract attention, distracting everyone from the work at hand.

Be that as it may, this policy needs revision of some sort. Apart from
what appears to be overall agreement that the content of and motivation
behind important decisions should be published more consistently in a
clear and timely manner, it should *never* be necessary for a W3C member
to refuse to discuss any technical detail of work in progress with any
outsider, even if they are not willing to reveal who said what. No one
has stepped forward and even attempted to present an argument as to why
this is necessary, and that it is counterproductive both in the
political and technical sense (not only W3C members have good ideas,
right?) is quite clear.

Matthew

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)