Re: Re: Digest of QA/Developer Lead Discussion

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Sat Aug 09 2003 - 18:29:02 CDT

Thank you very much, Anand, for your thoughtful reply.
>
> This meeting was supposed to be just between Matt and Me.
>
Okay.

> Because of timezone differences and other reasons, it may not
> be practical to expect every developer to attend the meetings. ...
>
Kindly re-read my comments on this subject. I explicitly stated that you
are NOT expected to adjust your time to suit others.

You are welcome to have off-line discussions with Matt or any other project
participants. However, if you schedule a meeting where important decisions
are to be made affecting the direction of the project, you need to do two
things:

1) Announce the time and place of the meeting to the group (let's say give
us at least 8 hours notice)

2) Provide the complete text of the meeting.

It is absolutely required that the QA Lead and Lead Developer follow this
protocol on this project.

Posting the dialog publicly may be something negotiable. I know this level
of openness is foreign to most software developers and testers, so I can
understand some reluctance. However, the dialog must be made available at
least to the team management (i.e., Arthur, Alan, Adrianne, Doug, and
David).

If we just get the summary, we may miss something important. That is, if
someone might make an important point that does not get into the summary. I
want to have a chance to review the dialog in case any such things get
buried.

> What matters is whether decisions are taken and if the list is
> notified of the process of taking those decisions.
>
Well, yes that matters. But it also matters to me (and others) just how the
decision was taken. Decisions can always be changed but sometimes it's
easier to catch mistakes if we see right away what was said.

> The digest means what it says in the subject line. It was
> a meeting between QA and Developer leads, so it was
> just that and not intended for other participants.
>
As I said, you are welcome to have off-line discussions. But if you are
having a meeting where important decisions are being made, you need to
follow protocol.

> Of course we also need meetings that require participation of
> everyone.
>
I doubt that will ever happen. We already have 20 members on this list. It
grew by 4 in the last 24 hours, BTW. I doubt we will ever have a meeting
where everyone will participate in chat. In a sense, we are having a
meeting right now but async. Chat is a little different.

> But right now what is more important is to decide when to
> schedule those kind of meetings. The QA and Dev leads
> can make those decisions in their meetings. ....
>
No problem. Just post the time/place for the next one so others can join if
they are so inclined and have the time.

> What we had today was a meeting which would give rise
> to more meetings, so naturally such a meeting was limited
> in its members.
>
Fine. For the next meeting, announce the meeting.

> Maybe I got this wrong. If you mean that the meeting announcement
> should be made to the list and a time specified, so that other members
> are aware of them, it is an idea I back.
>
Good. No problem.

> But then, if we dont find anyone joining in after a specified time,
> what are we supposed to do, cancel the meeting without making
> any decisions or re-announce the new schedule ?
>
Please re-read what I have written on this topic. Again, I explicitly
stated that you should NOT adjust the time to suit others.

> I still favor the procedure of the QA and Developer leads
> meeting separately to make some decisions without going
> through elaborate protocols. ...
>
It is not an elaborate protocol. Again, I repeat the protocol in case you
over looked it.

1) Announce the time and place of the meeting to the group (let's say give
us at least 8 hours notice)

2) Provide the complete text of the meeting.

> The other meetings could be scheduled following these
> protocols.
>
Fine. But the meetings where you and Matt get together and go through the
issues -- making assignments etc. must follow the protocol I have
described. It is absolutely required that the QA Lead and Lead Developer
follow this protocol on this project.

> I recall that in the initial phases of the project, you had
> mentioned that you wanted me(Dev lead) and Matt(QA lead) to
> have meetings on a regular basis. If I am not wrong, this is
> exactly what we are doing here.
>
Yes. Exactly. At that time, I had the protocol in mind for this but
neglected to mention it. If there was some confusion about this as a
result, that is my fault. However, I hope it is now clear

The meetings between the QA Lead and the Lead Developer are an important
part of the engine that will make the project run. I know a great deal
about the dynamics here. I've seen these meetings work really well in
projects I've worked on before (including 9 commercial products at Borland
and Intel). I've seen it work not so well. All these cases were at R&D
centers working on site. I'm trying to translate this experience to working
on software development in cyberspace.

> >
> > 2) I would like to have the entire dialog copied to the list. We want
to
> > see who is saying what, exactly. This takes no time at all -- just cut
> > and
> > paste and send. No editing.
>
> I have reservations about this. People might talk about other things
> than just the EVM project in chats. ....
>
Keep in mind that I am not talking about simple chat sessions. I am talking
about bug meetings.

> Copying and pasting would probably disclose some information
> which the chat participants would not like to divulge to a wider
> audience, ....
>
We can think a little more about this. Here are a couple of thoughts about
that.

1) Do you ever post to Usenet? I think you do. Then you know that your
comments are public. You use some discretion knowing that. I don't see how
this should be a problem for project participants. Most of us participate
in public discussions regularly.

2) I see two levels of the "wider audience." Other team members, and the
public at large. I see no circumstance where anything said at one of these
meetings should be kept secret from other team members. I can see some
justification for having reservations about it being totally public. But
I'm inclined to go back to what I said in the previous paragraph and
elsewhere in this message.

> elite they may be as the participants
> in this esteemed list.
>
It's not a matter of being "elite." Some of us have very substantial
investments in the project. You are new to the project and have little idea
of its history. I spent more than 1,000 hours on this project in 2001. I
did not spend much in 2002, but thanks to David Dill I got sucked back into
it big time this year. I have been saying I have "over 1,500 hours"
invested but I've been saying that for months. Basically, I stopped
counting at 1,500. Figuring that I normally bill my time at $100/hr., I
have $150,000 to $200,000 worth of my time invested. But that's nothing
compared to all that's at stake here. For starters, look at the sums now
being wasted on crummy voting technology right now.

> I have no problems with creating a digest, and I am ready to spend
> that time online. I can cite another four technical reasons at least why
> the chat dilaog should not be copied. Here are some of these.
>
> 1. People use Chat acronyms while chatting and this might
> be difficult to make sense of when reading a mail, since it
> is out of the context of a chat.
>
Again, it doesn't matter if the dialog is not comprehensible to many others.
If it's not easily comprehensible, then it goes without saying the few
people will read it.

> 2. The chat usernames people use may not be exactly puritanical
> or agreeing with Queen's English. Others of the list might
> have reservations reading such dialogs. Forgive me, but this
> is a list of varied cultures and religions, some chat names could
> sound blasphemous to some people out of the context of the
> chat.
>
Again, it doesn't matter if the dialog is not comprehensible to many others.
If it's not easily comprehensible, then it goes without saying the few
people will read it. As for chat names, if someone is concerned about how
their chat name might be misinterpreted, they can easily change it.

> 3. If the chat is a technical one, there might be code pasted
> into the chat area. Is it necessary to post this into the list?
> It might be XML or python or some other language, but not
> conversational English.
>
That may or may not be of interest. In fact, it might be of interest.

> 4. When people interact, it is natural to ask personal questions
> in an effort to get to know the face on the other side. Copying
> chat into the dialog reveals these questions (and their answers)
> to a wide audience. ....
>
Such revelations can be very important to the success or failure of a
project.

> Tomorrow google might cache this information
> on their servers when crawling this list on the internet.
>
Again, do you ever post to Usenet? I think you do. Then you know that your
comments are public. You use some discretion knowing that. I don't see how
this should be a problem for project participants. Most of us participate
in public discussions regularly.

> 5. Chats can be broken in between due
> to failure of servers or computer crashes. In such a case it is
> impossible to get the lost chat data since the archiving (enabled
> in some chat software) might not have cached the messages
> during the failure. There is no way to copy such chats and
> send it to the list but it is possible to create a digest as long
> as you remember what you had discussed.
>
It's possible that chat dialog could become unavailable for copying. If
that happens, then we have to rely on the digest. Frankly, I would expect
this to be rare. It takes about 5 seconds to cut and paste the text into an
email and send it along.

I will insist on following the protocol I've described for bug meetings
between the QA Lead and Lead Developer. The only thing I consider
debateable is whether or not the dialog should be released to the general
public.

I repeat here what I wrote in response to Matt earlier:

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