confidentiality in W3C WGs

[Lisa Rein]

It has been my experience that both:

1) They put it in the spec if they think of it.
2) Someone in the group will tell you if you ask them (private email is
sometimes better than mailing list email -- you can't tell me (any of
you) that you don't maybe leave out details sometimes when you post to a
public mailing list -- you're inviting a public discussion that you
might not always have the time to have to monitor adinfinitum (or until
the damn thread dies down) -- whereas with an individual you can answer
their question and if they have another, they can ask that too!

3)I guess my biggest problem with all these complaints about the process
is that I, personally, have NEVER had a problem finding out the
technical nature of anything occurring in a W3C spec. Period. (except
those things where the working group themselves hadn't gotten around to
blessing the "thing" itself yet -- in which case whoever I've written
will say -- we don't know if that's going to stay that way -- and that's
it)

I will admit that sometimes the explanation of the rationale goes "over
my head" as it were, in which case I will usually spend a few emails
trying to understand it, in which case, consistenty, whomever I have
contacted has always been willing to help me figure it out.

Now, sometimes I don't agree with the rationale, but I don't argue about
it.  If I wanted to argue about it THAT's when you go to the public
discussion list and take it from there (and not THIS public discussion
list, please!  This isn't the "my beefs with every W3C spec" list, is
it?  Sometimes I wonder!)

lisa



Ronald Bourret wrote:
> 
> Reynolds, Gregg wrote:
> 
> > Here is the best you will ever get without an open process:  the reason
> > proposition X passed is that it got the most votes.  I'm not making a
> joke:
> > that IS the reason XHTML got three name spaces, and its the only reason.
> > Why doesn't matter.
> 
> Why does often matter. Here's two reasons:
> 
> * Why helps explain what. As a simple example of this, consider the design
> goals at the start of each W3C spec.  These certainly aren't required by
> the rules written in the spec, which are undoubtedly clear, concise, and
> unambiguous ;), but they go a long way towards setting up the context in
> which the reader understands the spec.
> 
> * Why helps adoption. If there's a hard technical trade-off to be made in a
> spec, the result is not going to make everybody happy. Explaining why helps
> people understand why the decision was made as it was and gives them a
> stake in that position. Telling them what only leaves them confused,
> annoyed, and ready to jump ship for something better. Dictatorships and
> democracies both work, but democracies get a lot more genuine support.
> 
> Why doesn't have to be directly in the spec, but it needs to be somewhere
> more than in just a few people's heads.
> 
> -- Ron Bourret
> 
> 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)

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)