Re: [Fresco-devel] issue tracking: Request For Comments

Stefan Seefeld <[email protected]> writes:

> >>* status: new, open, closed
> > reopened ("huh, I thought I fixed this")
> > pending ("I know of this, I'm working on it, but I need some time")
> > (both from debian bts)
> 
> what is 'pending' vs. 'open' ? 'later' vs. 'working on it' ?
> And why is it important to know that a bug had previously been closed ?
> Why isn't it enough (for the status) to know that it is currently open.
> The rest is available in the bug's history...

Pending / Working on it - a developer has noted the existence and
reality of the bug and has put it in his/her proverbial in-box. They
are currently thinking of and/or implementing a solution. A fix is
imminent.

Open - the bug has been accepted into the BTS, but no action has been
taken. Default status after a bug has been submitted. 

Later - a developer has noted the existence and reality of the bug,
but has set it aside. Perhaps they expect that it will be fixed by a
larger effort not directly related to the specific bug. 

Reopened - while not functionally different from simply "opened," it
may be deemed psychologically useful to note that this is another
go-around with the problem. The idea, I suppose, is to discourage
half-hearted fixes and encourage developers to be reticent when
closing a bug. IE - "did I really fix it?"

> >>* priority: immediate, urgent, high, normal, low
> > priority is  imho... "urgent priority" but "minor severity" ?
> 
> huh ?

"The program doesn't crash, and it performs it's duties without error.
However, it emits a message questioning the propriety of my mother.
These are fighting words in some places. Please select a more
culturally neutral insult."

Or something.

[random opinions follow]

Bug trackers are really meant for streamlining and organizing
communication. Strangely, that's something that I think is often
overlooked. I used to work for an ISP with telcom aspirations. They
decided that they wanted to be "taken seriously in the
telecommunications sector." Management decreed that the Thing To Do
was to purchase a workflow management package like the one used by
their competitor, Verizon.

Try not to laugh when I tell you that it typically takes several hours
to provision a single T1 with this thing. ALL of that time is spent
manipulating the work queues. None of it is spent touching the routers
(IE - actually provisioning a T1). The provisioning itself is handled
automatically by a batch cycle that runs a simple little script on the
routers. So, what are their employees actually accomplishing? I have
no idea!

At the same company, I found myself in a position where I had to
handle dozens of requests a day using only an IMAP mailbox to track
the workflow. Chaos! Madness!

Clearly, one needs to tailor the BTS fit to the project. That's a
non-trivial matter, IMHO. It's also important to make it fit the work
habits of the people who are actually going to use it (NOT the other
way around!). Various people have different ideas about work and time
management, so you want your workflow system (in this case, a BTS) to
act as a buffer between different personalities. 

The balance is between detail/control and overhead/complexity, and
yes, it seems to be largely a matter of taste. 

There's the matter of inertia. Once a BTS exists, it becomes harder
and harder to change it as the project grows. If Fresco has millions
of users someday, do you really want them all submitting "wishlist"
bugs? 

Russell