[PLUG] Bug-tracking software.

Rogan Creswick creswick at gmail.com
Tue May 15 17:31:07 UTC 2007


On 5/15/07, alan <alan at clueserver.org> wrote:
> On Tue, 15 May 2007, Aaron Burt wrote:
> > On Mon, May 14, 2007 at 10:12:43PM -0700, Ronald Chmara wrote:
> >> Something I've found helpful is to not introduce new *software* to a
> >> team, but instead introduce new *process*.
> >
> > +1.  It's all about tha process.
>
> Sometimes the process gets overdone.

The last company I worked for had nothing but process for reporting
bugs.  To give a bit of context, I was working in a cube less than 15'
from the data entry people who used the application I was writing,
when they found a bug, this is what happened:

 * They would email my manager, saying something to the effect "it's broke".
 * My manager would come over, walk past me (saying nothing) look at
the problem.
 * Manager would then email them a link to a Word template on a samba
share to fill out a bug report.
  * The data entry person would (hopefully) *not* munge the only copy
of the bug report template while creating a new bug report.
   * Data entry would then email this report to another data entry
person (who was assigned to manage the "database" of bugs)
   * This person would try to reproduce the bug, add a boolean value
to the report, and stick the report on a fileserver with some random
name that didn't conflict with any of the other bug reports on the
samba share.  To keep track of the bug, it was also given a row in a
spreadsheet on the same samba share (which no one else was allowed to
open because of the lack of any locking mechanism.)

 Once all this was done, the process of assigning the bug could begin:

  * at the next weekly bug meeting the managers would decide which
department was responsible for the bug (it could be either
development, or, well, development.)
  * The dev manager (my manager) would then email the bug report to
the selected dev, and we would finally get a chance to see what all
the complaining was about. (at this point, the actual bug would have
been encountered 1-2 weeks past, if not much, much longer.)
  * Once the bug was fixed, the process worked in reverse, with the
exception of actually verifying that it was fixed.  (Yes, no one
actually *ran* the software to see if the bug was repaired, but at
least 3 people had to "Ok" the bug report before it would be closed.)

I didn't work there long enough to find out how long this process
took, but I was assigned a bug on my third day there, which was
submitted by someone who had quit over 6 months previously, and when I
left 4 months after fixing that bug (I had to insert a "<" in a
predicate), it was still open.

--Rogan

>
> Where I work they started to use Bugzilla.  They are using it not only to
> report bugs, but as a project tracking and request system.
>
> They have so ritualized the process as to make it difficult to get
> anything done.  You have to caluculate due dates, even if you have not
> researched the problem.  They have meeting upon meeting analysing the open
> bugs.  (They figure that if you have more meetings it will get done
> faster.)  It has gotten to the point where you just don't want to enter a
> bug because of all the emotional baggage that has been attached to the
> process.
>
> >> The biggest *process* problem I run into is when the CXO can enter
> >> bugs like "website broken" or "something isn't working right", but
> >> that's more of a process issue.
> >
> > That's what a trouble-ticket (job-tracking, whatever) system is for.
> > It's been very carefully explained to me that RT is NOT a bug-tracker.
>
> The hard part of any bug tracking or trouble ticket system is getting
> people to make clear descriptions of the problem.
>
> "Its broken" is not a description.  "That thingy over on the internet does
> not work" is also not useful.  Getting users to write detailed and
> informative descriptions of the problem is a challenge.  Even harder is
> making an impression on them that it is their responsibility to be clear.
> They seem to think that it is somehow the IS department's job to somehow
> determine the true problem from a cryptic and next to unreadable message.
>
> And it is not just trouble tickets.  I have a co-worker who writes process
> specs where it is next to imposible to figure out what tables or fields
> she is talking about due to the terse and cryptic method of writing.
> (Half the time she uses the name of the field from the legacy system and
> sometimes it is the current system and sometime it is an aproximation of a
> field name.  And it is usually using COBOL syntax to add to the fun.)
>
> And don't get me started on "Spreadsheet Worship"...
>
> --
> "ANSI C says access to the padding fields of a struct is undefined.
> ANSI C also says that struct assignment is a memcpy. Therefore struct
> assignment in ANSI C is a violation of ANSI C..."
>                                    - Alan Cox
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list