Xen <l...@xenhideout.nl> writes:

> I would simply suggest that in principle you keep bugs open until it no
> longer exists. But that you introduce a different open state other than
> closed that will communicate "has been looked at, is not capable of
> being solved right now". This could be "pending" or "held" or
> "kept". Because "closed" indeed communicates "not-a-bug" or
> "works-for-me" or "invalid" or "fixed" and not "frozen".

I recommend reviewing the literature around how to manage development
backlogs.  There is quite a bit of thought in this area, and this approach
is widely considered at best useless (the holding area just becomes
another way of spelling "closed" because it accumulates so much stuff that
it becomes unsearchable and no one looks at it) and at worst actively
harmful.

I get that no one wants to hear "no one is going to look at this bug in
any reasonable time frame."  It's not a pleasant thing to hear.  But it's
vastly superior to just not hearing anything.  You're making a mistake
that lots of people make with bug tracking systems: in a desire to be
non-confrontational and to never deliver bad news or provoke hard
conversations about prioritization, you're erring on the side of not
communicating at all or communicating in weak and ambiguous ways.  This
can create unrealistic expectations on the part of the bug submitter,
which are later dashed.  This is just bad all around, and it leads to a
lack of trust in the long run.

If no one is ever going to look at the bug again, just close it.  It feels
more confrontational, but it's far more honest, and it doesn't create
unrealistic expectations.  (Obviously, try to do this politely and
constructively!)

-- 
Russ Allbery (r...@debian.org)               <http://www.eyrie.org/~eagle/>

Reply via email to