Re: Re: Digest of QA/Developer Lead Discussion

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Sat Aug 09 2003 - 17:08:39 CDT

>
> Alan, although I understand wanting to know the details of the dialogue,
> copying & pasting makes the message kind of incoherent. I'm fairly
> scattered in meetings, so random stuff can be interjected. I would rather
> have a digest/summary of the meeting than the actual text. ...
>
Fine. Then produce a digest or summary. I want the text too, however.

> When you sent your dialogue with Anand, I couldn't really make heads
> or tails of it. ...
>
But you didn't have to either. If someone picked up something relevant in
the discussion, that's fine. If readers don't get anything out of it,
that's okay too. Most people on this list haven't really studied all the
messages posted here. It's not necessary that they study and understand
everything.

> It's like listening to the tape of a meeting, but with "smileys"
> interjected. In addition, someone reading the text might misinterpret
> something, or something that looked resolved earlier in the text is
changed
> later on.
>
Fine. Nobody is forced to read it.

> I would suggest a digest/summary. Some kind of notes for the whole
> meeting. If there are disputes, we can always go back to the original
text.
>
That's fine, so long as the text is cut and pasted and posted somewhere.

Let me be very clear on this point: I have a lot of experience in bug
meetings. One time I missed a bug meeting during one of the projects I
worked on at Intel (R&D lab Hillsboro Oregon) and one of the catastrophic
bugs I posted got classified as a "feature request." No lie. I would have
enjoyed hearing just how that happened and who said what at the meeting,
but, obviously, such discussions regarding commercial products at a place
like Intel are highly sensitive. There is no way any such meeting would
ever be recorded, and the bug databases themselves are highly
confidential -- subject to non-disclosure non-compete agreements etc.

I got it fixed eventually, but if I had been at the meeting it would never
have been classified as a "feature request."

My desire to monitor bug meetings in this project was reinforced by the fact
that of the first four bugs I posted here, two of them became "feature
requests." They were not feature requests. They were requirements.

This project is very different from the process by which proprietary
software gets developed. Let me quote a few things from the Doug Jones
letter draft here:

http://home.earthlink.net/~adechert/ucvs-proposal.rtf

     No discussion of best practices is possible if the practices
     themselves are not open to examination and discussion!
     The area where this poses the greatest challenge is in the
     operation of the voting system itself. All of the electronic
     voting technologies in current use in the United States rest
     on the use of proprietary software that is not subject to
     public disclosure!

.......... and ...

     In short, what we need is an open-source transparent
     voting system, where not only the source code but also
     the design documents, threat analysis and security models
     are available for discussion. This system should be run
     through the entire voting system certification process, and
     all documents produced during certification should also
     be open to public inspection.

These ideas are at the very core of the larger project. I want to extend
this "open" idea to all aspects of the construction of the demo too.

Alan Dechert
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Aug 31 23:17:05 2003

This archive was generated by hypermail 2.1.8 : Sun Aug 31 2003 - 23:17:17 CDT