I would post a general post to all the observations that have been made in this thread.
First of all, I agree that this bugtracker is not the best tool of its kind that there is on the market. I think that its use is simple and straigthforward but the research function should be better, in order to make life easier to everybody. It would be good if it would be more customizable and also, from the admin side, to obtain different groups with different "attributes". However, this is not possible in the bugtracker today, and this is surely a limitation. Categorizing the bug should be easier and more intituive, but it is also true that not all players have the technical knowledge to know if a bug is client or server and at the moment, that hasn't been a huge problem for us, developers. This is basically what Ralleyon has said as well.
However, the main problem, which we would encounter with whatever bugtracker there is around, is how people use it.
That is why I have been putting my time in trying to create a so call "bug tracker process", as acraig stated, that should be a guide on how to use the bugtracker, for each "roles" available, and represent an unequivocable tool for following the life of a bug report.
Still, the problem is in enforcing this "life path" of the bug report. There will be always people that act indipendently and, we will try to contain that.
I would love to get this document ready as soon as possible, but I have a pending release at work, and this has caused me to have really little time for everything (I have to work overtime for the whole week, until absurd hours). However, I will try to do my best to finish it as quickly as possible. This document will try to include also a description on how to use the different fields, with the hope that everybody will notice how the bug report is changed (for example, with the "fixed in version Xxx" thingy) . It is also hard to enforce everybody to write a comment when they modify the bug report... (the bugtracker I use at work actually do that, but we don't have a really customizable tool here :-), not sure about the other proposed).
For Nurahk, I think that people *can* actually edit the summaries. So, that should be no issue, today. If you look in the bug report there is a field called "Summary". I think everybody can edit that but I am not sure, since I am admin of the bugtracker ;-)
For stevenw9, we had the updater for that purpose, but it didn't work fully perfectly so at the moment (as far as I know) we are skipping its usage. However, acraig has replied perfectly on why, in a kind of development as ours, it is hard to have a system like you describe. Vengeance's inventory is not completed (still in development) however it is committed in CVS ;-)
Now, about the *big* polemic.
First of all, if you feel that your role is the one of a bug hunter, in my opinion, you are not a "bug tracker janitor". You find bugs, you report them, you annotate which one are most important, you verify that a fix is actually a fix (and not a new bug), eventually you perform regression tests to see what else is broken and so on.
We have plenty of cases of bug reports closed too hastily, comments that are really not understandable, misplaced and people entering a "conversation" in a bug report not just to confirm the bug, bug to add new bug reports (write a new one then), and so on and so forth. Of course, closing the bugtracker was a temporary solution (even if, not everybody in the team actually was thinking of it as temporary - and it was not me
). I remember many many times in different "hobby oriented" projects where the people got fed up of complaints, of things not working as they should and so, and they just remove the service. Why? Because it is a privilege to have that service and not a right.
You want to cooperate? Then, observe how the *janitor* is working on the bugtracker, ask questions if you have doubts, have a dialogue and not ironic harsh comments every 5 seconds on the operate of the janitor. I have honestly (and I will alway) try to be pedagogic in each bug report that is "misplaced" or whenever a bug should have not be closed I always explain why. In the worse cases, I have tried to speak (with calm, if I could) with the interest person, pointing out *why* and *how* this should be done in a different why. However, somebody doesn't obviously like to get suggestions, since they ignore them :-)
And considering myself the "janitor", for the efforts that I put in the tool and in the process, I feel entitled to try to stear the process toward the right one.
I use the bugtracker every day too, and the latest weeks I found it really time consuming. I like to be the janitor (if you want to call it like that) and I would rather keep the task for myself, because I do have quite good experience with similar systems and I enjoy doing the task. And yes, I have been having really little time to complete my "bug process" and if instead of teaching how to use the bugtracker I would be listened a bit more, I would probably have more chances to conclude the document
The misuse is not just due to the limitations of the system, but rather to *how* the people use it. So we are back on the first words of this long long post.
About new tools. I have been looking at BugZilla and it looks fine. However, it will force us to run the system not where it is today, which is not the most preferred choice we have. Since we don't feel force anyway, to change bug tracker (but rather, the usage of it), maybe it is better to hunt for the "most preferred" choice (which would be compliant with the requests made by acraig).
I could write more, but I have honestly not the right amount of time to bore everybody with this monologue, so I will keep it short now.
Please, do not put me on a stake, just for the sake of doing it, because locking the bugtracker hasn't been my decision (even though I didn't disagree), and surely, it hasn't been my fault.
