D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

Re: [LUG] bug triage

 

On Wed, 29 Aug 2007 15:38:19 +0100
Julian Hall <lists@xxxxxxxxxxxx> wrote:

> Neil Williams wrote:
> > More likely (and more worrying), 60% of the work is wrong rather than
> > simply missing.
> >
> > Incorrect knowledge is more of a problem than a lack of knowledge.
> > Someone who doesn't know is more open to the correct answer than
> > someone who believes the wrong answer is true. Seeing as the pupil is
> > never told WHICH 60% of their answers were wrong, it is likely that at
> > least 25% of their "knowledge" is simply WRONG.
> A very good point.  In one module we had an online test and I scored 
> 11/12.  Not too shabby, except nowhere was I told which one was deemed 
> to be wrong.  With that sort of approach only two states give a 
> definitive answer 0% and 100%.  At least with those you know you got no 
> questions right, or every question right.
> 
> One of our lecturers had it right - he gave us online tests as well, but 
> not only did he tell us which we had wrong, he also gave the correct 
> answers.  Being told which is wrong is only half the battle... knowing 
> how to correct it is the other half.

Bringing that back on-topic:

Getting the bug report is only the start of the problem.

The next issue is having enough knowledge to understand the bug report
and decide if it describes a real problem, whether there is a real
problem behind the report but not actually described or whether the
reporter has just not done things properly. i.e. is this a WONTFIX, an
RTFM, a WTF or an OMG? 

The final task is fixing the bug.

Someone who has not been told which 60% of their "knowledge" is bunk
will do one of a few things:

1. Patronise the reporter by accusing them of submitting an RTFM bug
when it isn't.

2. Miss the real issue and fix a side-issue that only masks the real
problem.

3. Spend weeks 'fixing' a non-bug because s/he believed the bug report
and causing a string of new bugs because the 'fix' breaks other
functions.

4. Not ask for moreinfo when it is desperately needed - by the time
someone else joins the hunt, the reporter has moved on to other things
and the info required is not available.

5. Ignore critical bugs that will blow up in their face very, very soon
but which are badly described in the report (often because English is
not the first language of the reporter).

Now, I'm going to be a little controversial here:
<devilsadvocate>
For the above reasons, a *humble* self-taught programmer may make a
better team worker than a *over confident* graduate.
</devilsadvocate>

Basically another way of saying that you are better off with those who
know that they don't know and can ask those who do know than someone
who knows they know what they don't actually know and doesn't ask for
help because they know it already, except they don't know it at all.
;-)

(Reminds me of a certain US politician . . . )

If you know what I know and I know that you don't know what I know who
is the liar?

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

Attachment: pgpZLqpwleC8L.pgp
Description: PGP signature

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html