On Wed, Dec 22, 2010 at 4:56 AM, Juancarlo Añez <apal...@gmail.com> 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 _______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : email@example.com Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp