[arch-general] Closing bugreports too fast?

[Dennis Herbrich]

On Wed, April 30, 2008 13:41, Gerhard Brauer wrote:

> It's not - more - an issue for me, I've learned my lesson ;-) (That is,
> was Xavier mentioned in his answer). But i know 3 other tasks were the
> user must be pointed: Look directly to #12345, the problem you ask about
> is already fixed (and closed).

I don't see any reason why anybody would actually *search* for bugs that
are announced that way. There's a reason for the Task ID being supplied,
namely to enable users to enter it directly into that dedicated little
search field labeled "Show Task #" fitted snugly into the upper right
corner of the flyspray GUI, which leads upon activation directly to the
task specified, no matter it's status.

However, I'm sorely aware of the problem of not finding closed bugs by
default; It's really annoying to be basically forced to always use the
enhanced search features. However, as long as the ID is announced, that's
simply not an issue.

If people who refer to tasks intend to be nice to their readers, though,
it's surely a good idea to link the bug id. Saves a couple seconds and
prevents typos on the user's side.

Either way, deferring bug closure introduces, by definition, an
inconsistency between facts and reports. Yeah, that's just a fancy way of
saying "Fixed bugs appear as still unfixed". That sucks, because it might
entice another developer or *anyone*, for that matter, to look into an
issue that is in fact already fixed!

To me it does not seem feasible to artificially introduce what could be
described as an "intended lack of communication" to circumvent a perceived
inability of users to use Flyspray optimally.

HELL, NO!!1!eleven

RTFM is key, as with all that is Arch.
Actually, knowingly introducing inconsistencies into any kind of data
storage seems so inherently evil to me that I personally have real trouble
reciting good arguments against it! ;)

> Regards
> Gerhard

$POLITE_CLOSURE,
  Dennis