One of the things I’ve learned in recent times is that good customer service means good communication. You need to actually use tools like Bugzilla to keep up to date with what people are asking for, and you need to file status updates at least once a day to hot-button issues so that people know where they stand. Sometimes there’s extra process to whine about, but on the whole using tools like Bugzilla correctly is “For The Win” (as the kids say). I am mostly refering to work uses of Bugzilla, but the following is generic advice.
I discovered some time ago that Bugzilla has a great feature called “whining” (it’s under the “Administration” options, and if your site has disabled it because they did not think about you wanting to use that “admin” feature for yourself, be sure to whine at your admin about it). With this feature, I can setup what are essentially Bugzilla cron jobs that will run at certain times of the day. Combined with various advanced queries, it’s possible to do some fun things to keep on top of where things stand with open issues. For example, each morning, I get the following emails from Bugzilla:
*). New bugs reported. Includes both bugs for me, as well as e.g. all kernel bugs and other core subsystem reports.
*). Currently assigned bugs. This is split out into work and community.
*). Bugs for a specific project I am involved with.
*). Bugs that are set NEEDINFO to me.
*). Bugs on which I was added to the CC in the past 36 hours.
*). Bugs for which new comments were added in the past 36 hours.
Then, every 4 hours throughout the day, I get an email that shows any new comments that have been added to bugs for which I am responsible, or for which I am set as a “watcher” (most core work subsystems at this point – kernel, dracut, LVM, etc. just to make sure I am aware of everything that changes). All you need to do to implement this is to create some Bugzilla searches and then define what wil run and when using the “whining” feature. You can use the boolean logic feature of bugzilla to add in the necessary bits to catch things like “I got added to CC” (which is not explicit), or that NEEDINFO or other custom flag extensions were changed recently.
I find that it now takes relatively little effort to open a new browser window with tabs for each bug and check on it when it changes state. If some action is needed, I note it down, whereas if some action is not required then I will try to make a note of this fact in the bug. The idea is that the bug conveys all information about what is required right now, or what is not required right now, so I know I am not the blocking factor. Eventually, I plan to have bug state changes automatically create a TODO item in my todo-management software to note that I need to take action. In the meantime, I hope that others will play with these features to help optimize their own workflows.
Jon.
I’d love to see the whining output turned into a bugzilla user dashboard to monitor what’s things of interest to them.