Hello Tom!
It is most unfortunate that the mountain of defects is so big that we
have defects, several years old. I am still hoping that we eventually
will be able to solve most of them so that this will not be an issue.
What I want to achieve by this is to be very explicit as to what issues
we do not touch during the beta period.
I agree that the per-issue notice method has several drawbacks but have
not been able to find an alternative.
For the 0.22 release I have an attempt with having the list of known
defects shown with the release. If you all think that that is a good
enough way to publish the known defects list (and possibly also the list
of unaddressed enhancements/features etc) and that it is explicit enough
we can make do without the per-issue notice.
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 16 juli 2006 18:50
> To: [email protected]
> Subject: [argouml-dev] Reducing noise in bug reporting system
>
> I made this request privately before, apparently without success, so
I'm
> repeating it publically in hopes that others on the team will support
it.
>
> I'd like our procedures modified to eliminate any updates to the bug
> database that don't add value. In particular, I'd like to see the
"this
> wasn't fixed in release 0.xx" updates stopped.
>
> There are two primary reasons for this:
>
> 1. The noise that they add to the database make it impossible run
useful
> queries like "show me the bugs that haven't been updated in the last
year"
> or "show me the bugs that were updated the longest time ago."
>
> 2. These updates are basically taunting our bug report reporters.
They
> hear
> little or no human feedback on their bug reports, but then every 6-18
> months
> we send them automated email saying "Just wanted to let you that we
> ignored
> your problem AGAIN." This leads to bugs like issue 664 which has been
> open
> for 4 1/2 years, has never been acknowledged or updated by a human,
but
> has
> had *6* automated updates posted to it. That particular issue was
raised
> by
> a former developer, but there are equivalent situations for external
users
> as well.
>
> If we were to make a goal of, for example, acknowledging bug reports
> within
> 60 days and providing users with updates at least once every two
years,
> there'd be no way we could use our tools to support that goal (see
#1).
> (BTW, I'd like to set the bar much higher, but we currently don't even
> meet
> this loose standard.)
>
> Finding known problems in a given release can be done with a simple
query
> and doesn't require modifying the database at all. On the other hand,
> given
> our current practices, there's no way to find bugs that we've ignored
for
> long periods of time other than brute force manual browsing individual
> open
> bug reports.
>
> It's too late for this release, but I'd like this to be the last
release
> that this is done for.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
