@iamntz: When creating an issue you can select one of the existing labels for these. I don't think you can edit them later on though, that's probably an admin task.
The only problematic thing about this is that these issues won't be closed if the issues aren't resolved and depending on the amount of issues it might become messy. On the other hand, we have labels to group things and we can close non-issues easily.
Expanding on the labels thing, I think we need more than just categories. Most issue trackers have a priority property which we could implement as labels but prefixed with an underscore or a tilde or similar to seperate these from the categories.
Furthermore, that's a damn lot of categories which probably all have their use cases but maybe we can reduce one or another in the future when they aren't used frequently (e.g. Macros).
Seeing a lot of Trac usage I like its idea of closing reasons, such as "invalid" for non-issues, "timeout" for no further information given, "duplicate" for, yeah, duplicates. We could use these as well with another prefix, "__" or "*" or "~" and more. We can agree on the exact prefix later when we consider this to be useful (which I certainly do).
What I'd also like to keep are "enhancement" and "bug" tags (with or without prefix) to separate these two entirely different things. "question" should not be needed since this issue tracker is not about asking questions.
A positive thing I just thought of: By creating and managing milestones we can assign closed issues to released builds which helps orginizing.
As a round up for things requiring a label (prefixes are suggestions):
- Type ("+")
- Priority ("~")
High, Medium/Normal, Low -> e.g. "~high"
- Close reason ("_")
Fixed (does this appy for feature requests?), Invalid, Duplicate, wontfix (only from Jon probably) -> "_fixed"
- Categories, no prefix
As @tito suggested.
Edit: Sorry for using "we" so much but I somehow consider myself really wanting to contribute to this.
Edit2: Since "priority" seems to be somewhat pre-defined and might suggest being set by Jon himself I thought about "severity" which is used by mantis in conjunction with priority. A "severity" property allows pre-filtering issues without suggesting that things will be implemented more likely than others (although that should be the case for crashes etc.). Mantis uses tags like "crash", "block", "major", "minor", "tweak", "trivial", "feature". The latter can be discarded due to the type property.