First thought is this: A bug's likelyhood of ever being fixed decays with time, starting when I first read it. If I have to read it a second time, the bug has already become more complex, since something prevented me from just fixing it the first time. If more information has to be added to the bug, that makes it yet more complex. If there is an argument in the bug about whether it is a bug, or how to fix it, just revisiting the bug at a later date can become more expensive than it's worth. Much of what is involved in filing good and effective bug reports are obvious corollaries of this. It also follows that it's best to either fix, or at least plan how to fix a bug immediatly upon reading it.
Second thought is about "wontfix". A bug submitter and the developer responsible for the bug see this state in very different ways, but the name hides what it really means, which is that there is a meta-bug affecting either the bug submitter, the developer, or both. Once you realize this, wontfix bugs, from either side, become a bit personally insulting. They also quickly decay to uselessness (see first thought), and then just lurk there wasting the developer's time in various ways. Bug tracking systems should not provide a "wontfix" state; if they want to track meta-bugs they should provide a way to reassign such a bug to some other party who can actually resolve such a meta-bug.
There are bug tracking systems for software and for packages. Debian BTS is the latter, in most cases.
I have a lot of WONTFIX bugs in cvs which I’d like to close, but anal-ist reporters tell me to only close them if “the bug has been resolved” (meaning if they are pleased). These things are misunderstandings of the reporters, difference in opinion about the topic at hand, and (most) development of new features or changes of existing behaviour that the packager, as opposed to upstream, just cannot do (or cannot reason).
So I’d like to keep my WONTFIX, please. (Otherwise, I’d be closing them all and ignoring the reporters’ cries which, I guess, some code of conduct would forbid me eventually.)
PS: I don't use markdown, and what’s otl? The “plain old text” option is missing here…
Many of the wontfix bugs I know of would indeed fit into different categories:
However, for some of these cases I do think a more general tag should exist, which says "despite the possible closure of this bug, treat it as an open bug for the purposes of showing it when searching the bug lists, so that people don't file duplicates". Something similar to the "affects" mechanism, but for open or closed bugs in the same package rather than open bugs in a different package. This tag should also generate a separate category, which the maintainer can more easily ignore.
Josh, I like your idea of having a submitter and a maintainer view of bugs which only interest one party, such as your third class of wontfix bugs. (And the second class, with the option to show them in a maintainer view too, when the maintainer is in a state to actively look at the upstream bugs in his package.)
There’s also, still, “not a bug” (invalid, closed?) and “difference in opinion”…