Re: Re: Digest of QA/Developer Lead Discussion

From: Alan Dechert <adechert_at_earthlink_dot_net>
Date: Sat Aug 09 2003 - 20:16:30 CDT

----- Original Message -----
From: "Matt Shomphe" <mshomphe_at_comcast_dot_net> wrote:
>
> But if this meeting has stuff relevant to me, I have to be able to
> understand it. I cannot understand the text of a chat without a
> significant investment of time & effort, much more than someone
> coming up with a summary of the meeting.
>
Okay. But it also takes a lot of time and effort to produce a summary.

.....
>
> But if we're just pasting chat transcripts (and believe me, if they are
> required, that's the ONLY thing that will be sent out), ...
>
I see your point here, but if Anand thinks the summary is important, then I
encourage him to keep writing them.

> *I'm* going to be forced to read it. I need to be on the
> up & up wrt everything.
>
To a large extent, we will have a summary of the bug meetings since what you
and Anand decide will be reflected in the database. This is where I am most
interested in seeing your published comments, opinions, conclusions, etc.

We want all the issues tracked in the bug database.

>
> >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."
>
>
> Okay, maybe I'm missing something, but I'm not seeing how this is
> relevant. It's not that our discussions are secret; they are not subject
> to NDAs, etc. The discussion here is what is the most appropriate way of
> transmitting information to the group.
>
Okay.

> The summary that comes out of the meeting is implicitly agreed
> to by the participants of the meeting -- otherwise corrections
> would fly around as soon as it was published. ...
>
That's fine, especially if the meeting has only two participants. My
experience in bug meetings tells me that successful bug meetings typically
work best with several developers and several testers participating.
Besides the QA Lead, you usually want the person(s) that posted the issue(s)
in case questions arise about what is meant. And, besides the Lead
Developer, it helps if the developer to whom an issue is assigned is there
so the assignee understands the issue.

> Using chats as a medium would be an abysmal failure.
>
But, again, we're not really using chat as a medium for conveying what was
decided at the meeting. The decisions will be reflected in the bug
("Issues") database.

I see the transcript as a way to see that important points were not
overlooked. I've seen important issues brushed aside in bug meetings that
had disasterous consequences. Suppose you were at a bug meeting for the
dBASE DOS 5.0 product at Borland in 1994 where someone said, "maybe we
should include SET EPOCH like Clipper has." Do you know how costly this and
other such brush-asides were for Borland? Oh, it was just another "feature
request." The SET EPOCH "feature" was included in Visual dBASE 5.6 but not
until late 1998 -- not long before the dBASE product was sold off for next
to nothing. Borland got a well-deserved reputation for shipping buggy
software and paid the price.

.....

>
> Everyone can attend these meetings, and all the output from these meetings
> will be available for public consumption. There is no secrecy.
>
Again, I'm concerned about what might be overlooked. I might be able to
look at the transcript and say, "what about this?" whereas, if I only get
the summary, I might never see what was ignored.

> This is my argument:
> (1) Chat transcripts are not a viable way of conveying information. The
> signal to noise ratio is terrible.
>
Fine, but that's not why I want the transcripts. The decisions coming out
of the bug meetings should be reflected in the database.

> (2) If we require chat transcripts and *only* chat transcripts, they will
> be the only thing people send out. I know I would do it if it was
> considered to be sufficient.
>
I will leave it to you and Anand as to whether or not you produce a summary.
The real results of the meeting -- all the comments, assignments, decisions,
etc should show up in the database.

> (3) I still fail to see the benefit of sending out
> transcripts. "Open-ness" is preserved without sending out
> transcripts.
>
Again, I am interested in seeing what might have been missed. I won't be
able to attend all the meetings. Most people here won't be able to attend
all the meetings. The transcripts can serve as a reference in case someone
wants to know, "how did that happen?"

> Meetings are open to anyone. ....
>
Make sure you announce the time/place so that others will know.

> The results are open to everyone.
>
> If this is what you require, I'll do it, but I'm not convinced that we
need
> this...
>
If you guys are concerned about having your chats show up on google or
something like that, we can work around that. We could start by just
sending the transcripts to me, Arthur, Adrianne, etc.

--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:06 2003

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