zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

On Wed, Dec 22, 2010 at 4:56 AM, Juancarlo Añez <apalala@xxxxxxxxx> wrote:
> The usual strategy for dealing with long list of issues is to sort them by
> priority, category, and/or release.

Yes, but when the list keeps growing faster than items are resolved
this strategy breaks down at some point. You will end up with lot of
items in low priority categories that never get looked at again. This
is what I see happening in the bug tracker for zim. I realize my rule
of thumb of ~100 items is quite arbitrary, but it depends on the
number of people working on resolving bugs. Currently there is only a
few people apart from me that submit patches for bugs.

> Marking an issue as Won't Fix is enough information to close it. Deleting
> issues from the issue base destroys valuable information, and makes users
> prone to post the seme or an alike issue.

Sorry for not being clear, but when I close bugs I do it either by
setting the status to "Won't Fix" or marking them as "Incomplete".
"Won't Fix" means the request is clear and understood, but I will not
work on it in the foreseeable future. "Incomplete" means there is
information missing (either details for bug or good design for
feature), or I can not reproduce. Incomplete bugs expire automatically
after a set time.

Of course these will still remain in the system and may turn up when
people search for bugs.

To be honest in some cases I rather have people submit the same bug
again than keep the old one sitting in the list. Usually a new report
adds a different perspective and/or a new solution. Having the old one
sit there gives people a false sense that it is being worked on
already.

Regards,

Jaap