Your View to the Health of Your Development
Many organizations and teams began using Bugzilla when they were small, bugs were manageable and life wasn’t too chaotic. But, the mere fact that a bug tracking tool was necessary for them was an indication that they were on the right track; growing and expanding. As projects grew and bugs mounted, it was difficult to consider a move to another system. Familiarity with Bugzilla, simplicity in its use within the overall process, and the need to focus elsewhere allowed bug counts to grow not just into the hundreds, but many times into the thousands of bugs in a Bugzilla database. By this time, a management tool was needed to help in prioritizing bugs – even just visualizing them. And that, is where the Bugs Dashboard comes in.
The Bugs Dashboard connects to a Bugzilla database and provides you with multiple views into the issues therein as well as tools to visualize and manipulate those issues. Individual tools focused on presenting some piece of information or functionality are referred to as “portlets” or “widgets”. You may construct many dashboards consisting of any of these widgets you chose to employ for the purpose of that dashboard. You may have one that looks solely at a particular product (or one for each product). You may have one that compares two products side-by-side. Every portal is configurable to your definition with many examples included in the Bugs Dashboard. You may also add widgets that do specific things for your organization or team by simply creating a new class and configuring the Bugs Dashboard to work with it.
Issues by Priority Within Product
An Enterprise utilizing Bugzilla will often have many products in their repository. It’s important not to lose track of the big picture while working on individual projects, balancing priorities and juggling responsibilities. The Bugs Dashboard provides an at-a-glance view of the state of health for each of your projects. We hate nasty surprises as much as you do!
You may see a thermometer on the Dashboard for Priority 1’s that reports a large number and become concerned. The thermometers, as explained below, are an aggregate of all issues within that Priority. Before you become overly concerned, use the Issues by Priority Within Product (Priorities frame) to find those issues assigned to the product you’re interested in.
A balanced workload is important, not just for the health of the individual members of your development team, but for the health of the projects. The Bugs Dashboard helps you manage the workloads of individuals by providing a view into their assigned responsibilities within the repository.
The numbers at-a-glance for individuals, however, must be tempered with knowledge for the project. For example, someone may be able to dust off a large number of small nuisances in short order while another individual requires time to work through a complex issue. The numbers themselves are not fool-proof, but they are an excellent starting point for identifying potential problems.
The numbers can help you avoid bottlenecks and balance the work amongst the development team members. Perhaps most importantly, the visibility the Bugs Dashboard brings about can generate communication and discussion which can lead to improvements in all areas of development.
There are five thermometers on the dashboard; a total of all open issues and the first four individual categories. Because not all categories may be reported (.e.g Priority 5 and lower), you may not be able to sum the four individual categories to equal the total thermometer. The total open issues is a general statement about the health of your development. However, there are two schools of thought: a lower number could represent a lack of quality testing procedures whereas the other school says too large a number represents a poor quality of development.
Each situation is different and you must determine which statement applies to your situation. If you have a very complex system, a large number of open issues early in the cycle may very well be acceptable. As the release date approaches, you probably want to focus on the Priority 1 Thermometer more so than the others as you drive for a quality release.
Your Priorities – You Can Have It Your Way
You may look across all the bugs of a product (or products) and set your priorities accordingly.
When someone opens a new issue, they’re allowed to define a priority. If the issue is opened by a Quality Assurance Engineer, it may well carry an initial priority that would be different if you opened it. When you “Set Priorities”, you’re telling the development team what you want them to focus on. This allows you to focus resources on issues that provide the greatest benefit to your expectations.
One thought is that you ask everyone who opens a new issue to classify it using a very low classification or you establish a classification that is “to be prioritized”. If you elect to use this strategy, we strongly recommend that you provide a mechanism for everyone to notify of expectations – those issues that require your immediate attention. You don’t want to wait a week, if that’s your normal schedule, to prioritize a critical issue. For this reason, we do not recommend this strategy.
Changing a Priority
To adjust the priority of an issue, click anywhere on the issue where you see the cursor change to four arrows.
Hold the mouse down and drag the issue into the priority box of the priority you wish to set it to. Note: if the priority you wish to set the issue to is higher or lower than is visible on the screen (requiring scrolling), use the mouse wheel to scroll while holding down on the issue.After you release your mouse and the issue appears in the list of priorities you want it moved to, you must enter a comment and submit your change. This can be done for every change or once after you’ve set all your priorities. The determining factor of when you submit should be what you want as the comment on the issue(s) you’re submitting. For example, there’s only one classification for “Priority 1”. If you have a dozen priority one’s – all of which are critical, which should the development team focus on first? You may use the comments to communicate your desires to the development team.
Your Severities – How Badly Does It Affect You?
As mentioned above, there’s only one category of “Priority 1” no matter how many issues are in that category. Once you have many issues categorized as priority ones, you’re faced with the dilemma of how to address them. The Bugs Dashboard helps you through this by allowing you to see the big picture as you work to put order to each of your priorities.
The “Set Severities” page assists with the proper classification of each issue. By looking at the big picture, you can quickly work through the questions that surround each issue. Once this is completed, you may return to your priorities and work on those top level priorities with the most severe impact.
Changing a Severity
You do the same thing for Severities as you did for “Changing a Priority” above. Recall that when you have set a severity, you need to determine whether a single comment works for all severities (e.g. “Severity set by Project Stakeholders on 28 Feb 2007”) or individual comments are necessary. This is the same as it was for commenting on a priority.
Keep Issues from Causing You to Age Too Quickly!
As you work through your issues over time, you may find issues of a lower priority sliding further and further out. The Bugs Dashboard works hard to keep these from falling “out of sight, out of mind.”
You define the initial age at which you wish to report in the preferences (property files). By default, the process looks for issues 30-days and older. However, you may wish to look at those between the 7-day period on the dashboard and the 30-days of the aging page (or focus only on those more than 90 days out). The Bugs Dashboard provides you with the ability to specify the number of days to being the aging process from.
Your Dashboard – Your Way!
The Developer edition allows you to create one dashboard with any number of widgets. The Enterprise edition allows you to create any number of dashboards which are then added to your menu bar with your style and your definition of portlets. This allows an enterprise to track multiple projects separately (e.g. use different dashboards with widgets selecting specifics for that project). The project details (i.e. dashboard) can be projected on a wall for all to follow or individual project managers can follow the details that are pertinent to them with greater ease.
Create Your Own Widgets And Add Them To A Dashboard
You may have need for information from your Bugzilla repository which is not currently offered through the Bugs Dashboard. For example, tracking milestones or hours, projecting releases, or forecasting may be desirable, but unique to your situation. Now, you can create your own server-side objects which return a string of HTML and then plug it into the Dashboard as your own portlet. You can even provide your own style sheet!
When You Just Have to Have More
When properly configured with the URL to your issue tracking system, the Bugs Dashboard allows you to drill down into each issue. You may however, be required to login when you drill down as the Bugs Dashboard has no means of exchanging logins with the issue tracking system. We recommend a read-only account for customers and stakeholders to have visibility into issues as this can help them set the proper priority and severity for an issue without accidentally modifying the issue itself.