From: Jesper Skov (jskov@zoftcorp.dk)
Date: Fri May 02 2003 - 09:50:11 EDT
On Thu, 2003-05-01 at 20:05, ericzen wrote:
> I was talking with a usr/reader just a moment ago about your bug graph.
>
> The gist of it was that it's nice to have a graph, but that the year-view is a) compressive and b) misleads at how much work is being done (nothing past unverified).
>
Both true. But I don't plan on making changes to the scripts. Feel free
to hack them yourself if you want.
> Personally, I like having the graph available (as I've mentioned since I first approached you about taking over).
>
> Right now, I intend to include a more condensed weekly table to show the current progress; however, I was wonder if, preferably in the post-2.0-era (when your not dedicated to bug squashing), if you could address either or ither of the problems.
>
> Just a thought I'm passing on. The email sent (at least, the source of the discussion) is this bit:
>
> > I've also tried to read JSs bug-graphs. If I do understand it?!
> > - then the pile of new bugs is raising and the fixed ones is
> > "continous". Meaning bugzilla is growing. Do you have the same
> > picture of it (thinking of the AWN text-statistics). You do
> > probably remember the AWNs better than I do!
>
> Which is the bit I brought up with someone else as I was literally reading it.
>
Maybe the graph deserves an explanation: If you decide to include the
graph, you may want to add (part of) this description of what the graph
is intended to show - because it actually does show what I intended it
to.
You have to understand it was not meant as a tool to gauge AbiWord
development progress, but rather to highlight the fact that users are
not good (enough) at helping us help them. This is an important point!
Anyway, here goes. Rant in []:
o Unconfirmed Bugs:
Tells us how well we keep up with confirming problems reported in
bugs. Bugs in this state can be "processed" by everybody - its
level is an indirect (and probably imprecise) indication of how
good users (and dedicated non-hacking helpers) are at helping the
developers find and confirm bugs.
[The trend looks to be unchanged - we're usually on top of this
and users have an incentive to help, which is why it's under
control.
Still, there is ~100 bugs which are unconfirmed. In other words
~100 (potential) bugs which will generally be ignored by the
developers. Which is sad. We'd like the users to help here -
with the amount of users (evidently) aware of BugZilla, it should
be possible to get this one down to <10.]
o Resolved/unverified Bugs:
Tells us how well we keep up with verifying fixes from the
developers. Again, bugs in this state can be processed by
everybody - most interestingly the reporters. It shows us
how good reporters (and other users/helpers) are at following
up on the developers' work.
[The trend is clearly that our users are not concerned with
Bugs reported in BugZilla, after they have been fixed. Which is sad
because it means they do not realize that the cost of leaving the
verifying process to the developers means both that
(a) it gets to be a bulk operation when the bugs get old enough
(see the sharp drop at the start of April which is when I went
on the rampage the last time).
(b) the reporter-to-verifier ratio is large, so which would take
each reporter 10 minutes to do, ends up taking many hours for
the developers. Hours that could have been spent fixing bugs.]
o New/Assigned Bugs (i.e. confirmed Bugs)
Tells us how many "officially recognized" bugs we have, which are
still pending a fix.
Obviously, only developers can do something about these.
[The trend *was* a slow increase, because the number of users
reporting problems grow quicker than the number of bugs the
developers are able to fix.
Things do look amazingly good after December last year though.
So the developers are clearly processing more bugs. Which is
cool.]
> I'll go with whatever you decide; as it really is your project, not mine.
You can have it :)
This archive was generated by hypermail 2.1.4 : Fri May 02 2003 - 10:02:19 EDT