evolution bug triaging information.

I wrote this about a year ago, now it’s time to publish this so it becomes easier for any potential successors willing to do this. so before the last person that remembers some ximian bugzilla wisdom finally leaves the project, it is time for a knowledge transfer before all this information would get lost.
I’d like to thank Novell for an interesting time, 7 t-shirts, a suse box, and a few bugs and bucks. ;-)

=======General.=======

• Why Everyone Needs A Bugmaster by Luis.
• Many users are just pissed if their software crashes, only few users spend time on filing a bug report, so be polite. Say thanks. (Just use the nice stock responses if you have enabled Javascript in your browser.) If you have an idea what could be a solution to the reporter’s problem, tell them, and set to NEEDINFO. If you need additional information by the reporter, explain them which additional information you need, and even more important: Tell them how they can get the additional information that you need. If you set a bug report to NEEDINFO, you must tell the reporter to REOPEN it when he adds more information. I have found many bugs where this was not told to the reporter, and so the bug was just forgotten. CC yourself if you like to. Make users happy, not necessarily yourself. ;-)
• If you add comments refering to another existing bug, the text “bug xxxxxx” (where xxxxxx is the number of some bug report) is automatically transformed to a hyperlink. So use “bug 987654” instead of “#987654” or even “987654”!
• Use keywords and get familiar with them. Keywords are extremely important for searching (also for searching for duplicates!).
• Some Evolution-specific keywords would be just useless for other applications then Evolution. Therefore they are on the Status whiteboard. Use it like “evolution[filters]” or “evolution[vfolders]”, please use the “evolution” namespace so this does not interfere with other Gnome applications. Take a look at the complete list of Evolution’s status whiteboard keywords. I have also added the entries “evolution[codecleanup]” and “evolution[nosip]”. You can also use the whiteboard to improve your own workflow by using custom tags, see the Status whiteboard neat tricks.
• If a bug report misses a version number and you can find it out, add it!
• Use the severity. People reporting bugs often use the preset (“normal”) or do not set the severity to “enhancement” though their wish definitely is an enhancement and not a bug.
• If you try to reproduce a bug, also add information about your own version and distribution.
• Crashes with stacktraces should be kept “unconfirmed” until they can be reproduced. If they include symbols and line numbers *and* are from an uptodate version, please set the status to NEW.
• If you like to be kept informed, use the weekly report.
• Take a look at Evolution’s Product Specific Traiging Guidelines. Update them, if necessary.
• When triaging, be aware which period of the Gnome development currently takes place. Take a look at the Gnome timetable. For example, if there’s a UI Freeze, it is not allowed to change the UI. Stable releases are under String Freeze always. If strings really must changed or added, you must inform the gnome-translators mailing list. See e.g. bug 321640.
• There’s a (developer) wiki available with information e.g. about the architecture or compiling from cvs: http://go-evolution.org.
• Searching for duplicates:
  • try synonyms. also think of gerunds, e.g. search both for “delet” and “remov”. It covers both “delete” and “deleting”.
  • crashs and their stacktraces: use the simpledupfinder. Only mark them as duplicates if they fit exactly, if they are quite similar add a comment. If you close a bug as a duplicate because of a stacktrace, explain why you close it. Users/reporters must not take a look into the stacktraces, and sometimes the same crashs happen in different situations so one gets irritated if the bug includes a totally different description then the original one.
• Last, but not least: If necessary, snap at the developers. It’s not the aim to be best friends, but to be productive and to have happy customers. You’re part of the marketing. Deal with it.

=======Common requests/tasks and their links (partially unpleasant, repetitive gruntwork ;-).=======