Adrian Bunk <
bunk@debian.org> writes:
I remember being pretty pissed when in a different open source project
some abuser asked me every 6-12 months whether I can still reproduce the problem with the latest upstream version, each time I spent several
hours for confirming it, but this abuser never bothered to follow up on
that after I did the work that was requested from me.
Somewhere along the line, the free software world, particularly around
larger projects, seems to have become convinced that bug triage is a good
way to become involved in a project as a volunteer (maybe! true in some circumstances!), and separately has defined bug triage as closing old bugs (sort of! true if they no longer apply!). Neither of these are entirely unreasonable, or put another way both of these are true in specific
situations. But they interact very poorly: people who don't know the
project or the community very well are taught to tackle "bug triage" as
their first project without good instructions, and naturally gravitate
towards closing as many bugs as possible because this seems useful.
(And, of course, as pointed out earlier in the thread, a lot of projects
have now automated this and just autoclose all of their bugs, which is certainly a choice. I personally have given up reporting bugs against
anything in the Kubernetes ecosystem since it's pointless; I'm just
talking to an autoclose bot, and it's an unsatisfying conversation.)
That said, I also agree with something Ian has said in the past about
bugs: the function of bugs for volunteer free software projects is
primarily as an aid to development and secondarily as type of user-facing documentation (here are things known to not work and possibly some workarounds). If they don't serve either of those purposes, and
particularly if they get in the way of improving the software rather than provide a guide for how the software should be improved, they're not worth keeping around solely because a user did encounter that problem at some
point.
So in short I agree with Holger: it really depends. It's rude to ask
someone to do a bunch of work when you have no intention of following
through on that work, which happens a lot when new volunteers do bug
triage without the skills required to follow up on the responses to that triage. But also if you're never going to work on a bug and you don't
think it serves any documentation purpose, it's okay to close it as
wontfix and arguably better communication to the bug reporter than leaving
it open and creating the illusion that you might fix it some day.
There are a lot of really low-quality bugs out there. Not as many in
Debian because our users tend to be a bit more sophisticated, but if
you've ever watched a reasonably widely-used package in Launchpad for a
while, you'll see an endless series of bugs that are clearly some
unrelated system problem, a corrupt installation, or just the user
completely not understanding what they're doing. The more prominent the package and the larger the unsophisticated user base, the more aggressive
you have to be about closing bugs if you want the open bug list to be a
useful artifact for guiding development.
A bug is a communication channel between the user, the maintainer, and
other users. Like most other forms of communication, it's neither
inherently good nor inherently bad. It doesn't make sense to keep all
bugs any more than it makes sense to respond to every email message. It's
a nuanced social judgment.
Or one can just use an autoclose bot, I guess, which is basically the equivalent of one of those email autoreplies that says "this mailbox is unattended and no one will ever read your email." :) And, to be honest,
if that's the reality of the situation, maybe better to know than not!
--
Russ Allbery (
rra@debian.org) <
https://www.eyrie.org/~eagle/>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)