Installing the optional modules

The Bugzilla Guide describes the optional modules necessary for the web service. These include SOAP::Lite and TEST::Taint. To install these, you will need to execute the following command. If you have a single Bugzilla instance and are not using these outside of Bugzilla, do the following from the Bugzilla directory (assumes perl is in your PATH):

perl install-module.pl Test::Taint SOAP::Lite

Testing the web service

To test the web service, go to the /lib directory under your Bugzilla installation (note that if your @INC path includes the above modules you don’t have to do this, but we have found it works well for us). From there invoke the bz_webservice_demo.pl script pointing it to your instance. As an example, this is how we test each installation of a new version of Bugzilla prior to installing Bugs Dashboard:

../contrib/bz_webservice_demo.pl --uri http://server.wmpnj.net:88/bugzilla42o/xmlrpc.cgi

The above should return you the current timezone for Bugzilla. From our instance, the returned value is:

 Connecting to a Bugzilla of version 4.2.
 Bugzilla's timezone is +0000.

At this point, your web service is configured correctly!

Verifying the ability to login

You can test the capability of your web service a bit more to validate that Bugs Dashboard will be capable of logging users into the application by issuing the following command using the proper username and password (again, we do this from our lib directory):

../contrib/bz_webservice_demo.pl --uri http://server.wmpnj.net:88/bugzilla42o/xmlrpc.cgi --login bugzilla3@bugsdashboard.com --password bugzilla

This should return the following for a valid username and password:

 Connecting to a Bugzilla of version 4.2.
 Bugzilla's timezone is +0000.
 Login successful.

The Bugs Dashboard Configuration

During the time of installation, you were asked to designate the URI of your Bugzilla implementation in the wizard. The URI is exactly what you have been using in your tests above. In our case, the URI is:

http://server.wmpnj.net:88/bugzilla42o/xmlrpc.cgi

Note that this points to the Bugzilla installation, not to the Bugs Dashboard installation. Your tests and the Bugs Dashboard configuration should all point to your Bugzilla implementation.

Restrict Reporting By Classification, Product, Component and/or Milestone

v3.5 will introduce a new capability allowing you to restrict widgets and reports to all products in a Classification, a single product and all it’s components, a single component or the component of a specific product, and/or a specific milestone.

Dashboards can now be restricted by more than just a single product.

This capability can be set to an entire dashboard when the dashboard is created or manipulated after the dashboard is loaded via the Restrict Dashboard widget.

Restricting the dashboard after it’s loaded can be accomplished with the proper widget.

Because there can be several round trips to the server to get the proper lists of products, components and milestones, we’ve also introduced a message to inform you when the lists are properly populated and redrawn. Although the length of time is only seconds for the entire process, we still felt it was important to give you the visual feedback for when the process was complete.

A new message will inform you when the process is complete.

New Features Added To The Scorecard Widget

The Scorecard widget will now report both your threshold and the number of issues which caused a status (e.g. red, yellow, green) to be reported.

New properties to the Scorecard widget will provide additional visual clues to the status of projects.

Additionally, we are working on the ability to drilldown on each status so that you can see who exactly has too much workload, or which bugs are of a particular severity, etc.

New Widgets

We are also working on adding new functionality with v3.5.

Triage Widget

The existing “Triage” widget will be renamed and a new widget will list all unconfirmed bugs and allow you to:

• Change the priority using a drop down of all priorities
• Change the severity using a drop down of all severities
• Change the status (e.g. unconfirmed to confirmed or resolved)
• Change the resolution (e.g. closing a bug as a duplicate)
• Change the assignee

The purpose is to allow teams to very quickly move through many new bugs, accepting or rejecting, etc.

Activity Stream

We are working on a widget which will allow you to see all activity recorded for a product, version, bug, etc. This will provide a quick view into the log for a bug or group of bugs.


We’ve just released v3.4.5 with many changes, but we’re already hard at work on v3.5. Check back regularly or subscribe to our RSS feed for updates on a specific release date.

Using your thresholds for Key Performance Indicators, the Scorecard Widget measures performance using data from Bugzilla.

The Scorecard Widget introduces an ability to edit the features of a widget.

The Scorecard Widget is the first to use an edit button to allow editing of a single widget's preferences right from within the dashboard.

With the inline edit feature, you are not required to step outside of Bugs Dashboard to edit the preferences of a widget. For its initial release, we have selected a few KPI and provided an ability to set thresholds for each. We are excited to hear what others wish to see as KPI that can be effectively measured from their Bugzilla database! If you have ideas for what you would like to see added to the Scorecard Wdiget, please contact support.

The principle behind each KPI is simple; a KPI is green (e.g. good-to-go, within limits, glance-and-forget, etc.) unless it crosses a threshold. You determine the threshold for each of two other states; yellow and red. Your yellow threshold will be lower than your red threshold and so we set it first, working up the chain in order of importance. When we actually measure the performance from the Bugzilla database, we will begin by examining your red threshold first. If crossed, we report as red. If the threshold is not crossed, we move on to examine your yellow threshold, measure and report appropriately. Only if we are below your yellow threshold will we report a green condition.

The preferences of the ScoreCard Widget are easily edited from within the Dashboard.

We would love to hear from others both what they wish to measure and what are considered reasonable thresholds. Each team will have different thresholds based on size, capabilities, deadlines, etc. If you care to share, e-mail support. We’ll post the results from time-to-time.

Checking for      PostgreSQL (v8.00.0000) ok: found v09.00.0400
Adding new table bz_schema ...
Initializing the new Schema storage...
Table already exists: bz_schema at Bugzilla/DB/Schema.pm line 1904,  line 522.

If you run into this, do not do what I did and bang your head against the keyboard for hours. Give thanks instead to Neven Klacar who chased this down already (see his posthere for an explanation on how he chased this down).

The answer is to change one line in postgresql.conf, which in our case was found at /var/lib/pgsql/9.0/data. Do a quick search on “hex” and it should jump right to the line you need to change. Change

#bytea_output = 'hex'                   # hex, escape

to

bytea_output = 'escape'                 # hex, escape

Then, restart the postgres service and rerun checksetup.pl.

To attempt an automatic install of every required and optional module
with one command, do:
  /usr/bin/perl install-module.pl --all
Attempt to reload DateTime.pm aborted.
Compilation failed in require at Bugzilla/Util.pm line 53,  line 522.
BEGIN failed--compilation aborted at Bugzilla/Util.pm line 53,  line 522.
Compilation failed in require at Bugzilla/Error.pm line 33,  line 522.
BEGIN failed--compilation aborted at Bugzilla/Error.pm line 33,  line 522.
Compilation failed in require at Bugzilla/Install/Filesystem.pm line 31,  line 522.
BEGIN failed--compilation aborted at Bugzilla/Install/Filesystem.pm line 31,  line 522.
Compilation failed in require at Bugzilla/Config.pm line 38,  line 522.
BEGIN failed--compilation aborted at Bugzilla/Config.pm line 38,  line 522.
Compilation failed in require at Bugzilla.pm line 38,  line 522.
BEGIN failed--compilation aborted at Bugzilla.pm line 38,  line 522.
Compilation failed in require at ./checksetup.pl line 102,  line 522.

You may find online references to resolving this by installing List::MoreUtils. That may solve your problem, but not necessarily. In setting up the various demonstration sites on BugsDashboard, we found that there were several different packages that could lead to this error. To simplify the debugging process, use the following at a command line from within the bugzilla directory (same level you ran checksetup.pl):

perl -I. -Ilib -e 'use DateTime';

In several cases, we received the following the above command:

[root@redhat-web bugzilla-4.1.2]# perl -I. -Ilib -e 'use DateTime';
Can't locate Math/Round.pm in @INC (@INC contains: . lib/x86_64-linux-thread-multi lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/local/lib64/perl5/DateTime.pm line 13.
BEGIN failed--compilation aborted at /usr/local/lib64/perl5/DateTime.pm line 13.
Compilation failed in require at -e line 1.
BEGIN failed--compilation aborted at -e line 1.

Note the line “Can’t locate Math/Round”. This indicates that we need to install Math::Round.

To install the missing package, we entered the following:

perl install-module.pl Math::Round

and reran the checksetup.pl with success.

Have fun with version 4 and above!

The Scorecard widget is intended to provide the 50,000 foot view of all projects. It’s color coded according to the parameters you define so it’s reflective of the overall health of your development efforts.

Using the Scorecard widget, you will define KPI’s that suit your organization’s situation as shown in the image below. Each KPI has three levels of indicator; red, yellow or green. Using the parameters you provide, Bugs Dashboard begins with the most critical situation, red. If the KPI does not meet the critical threshold, it is evaluated for the warning situation, yellow (see the second image below). If that is not met, the assumption is that you are meeting the KPI and green is displayed although you can set parameters for green as well. If the parameters for green are set and the threshold is not met, the display is a light gray for “unknown”.

The thresholds for Key Performance Indicators can be set so that you receive a 50,000 foot view of your development efforts.

The first version of the Scorecard widget will be at the very highest level – covering all projects within the Bugzilla instance (unless excluded by the global preferences). A future version will allow you to break out KPI’s by project if you so desire.

KPI's are shown according to the threshold they've met giving you a quick read on the health of your development efforts.

We are working to add additional KPI’s to the widget and value your input. A forum has been set up here to allow you to suggest and comment on KPI’s that are of value to your organization and which you’d like to see included in the Scorecard widget.


<?php
echo "<h1>Hello from the PHP test page</h1>"
?>


Then, create a widget entry that points to your php page, such as the following:

portlet41.title=PHP Widget
portlet41.package=com.wmpnj.bugz.widgets.PhpWidget
portlet41.method=getText
portlet41.stylesheet=phpwidget.css
portlet41.javascript=plainajax.js
portlet41.desc=Allows Ajax calls to PHP.
portlet41.call=
portlet41.restrictTo=
portlet41.parameters=’http://bugsdashboard.com/phpTest.php’

You can reuse the above widget as many times as you wish by changing the title and url in the “parameters” property (the dwr.xml file will need to be updated with your new widget title (if configuring manually, use of the admin tool will do this for you).

The result of the above is the following in your dashboard.

You can use the above to test your configuration, then change the url to your own.

ScrumWorks Pro has the ability to interface with Bugzilla, which makes it perfect for working with the Bugs Dashboard as well. One issue that a Scrum team faces is dealing with the unplanned, unexpected events which arise during a sprint. For example, if a bug is found in a previously released product update, the time required to address it affects the velocity of the team. This impact is difficult to predict and varies from sprint to sprint. In many Scrums, this is an invisible impact as it is not recorded against the product backlog. ScrumWorks Pro helps to make the issue visible within the sprint by importing the issue from Bugzilla. It helps to keep the team focused on issues and allows the team to determine the necessary trade-offs if the impact becomes too great. This can aid in planning and review meetings where you break down the tasks required for the sprint.

My Goal For Integration As A ScrumMaster

I use a custom field in Bugzilla which allows me to correlate issues noted in Bugzilla with sprints in ScrumWorks Pro and a portlet in the Bugs Dashboard. What I am looking for is the impact issues raised in Bugzilla have on the current and imminent sprint. By keying the portlet on a custom field, I can easily track the estimated impact of a Bugzilla issue as shown below.

The portlet shows me what the estimated work required is, how many days remain in the sprint to accomplish what is required and the urgency (priority and severity) of the work. I can easily use this information to communicate with the Product Owner, stake holders, customers, senior management, etc. using the other features of the Bugs Dashboard, e.g. Set Priorities.After importing the Bugzilla items into ScrumWorks Pro, I can use the custom field to associated the Bugzilla item with the proper sprint (through drag-and-drop) as show below. Now, I have the information necessary to conduct a planning meeting with the team using the importance of the Product Owner to provide the necessary context to go with the issue.

I actually conduct several planning meetings during each sprint. The initial planning meeting is long enough for us to get the necessary details for the expectations of the sprint and the initial, immediate goals. I then hold other planning meetings as issues, such as unplanned tasks arising from bugs, come to light.Integrating Bugzilla, ScrumWorks Pro, and Bugs Dashboard allows me to manage the tasks expected in each sprint. You may ask how the Bugs Dashboard plays into this – where is the link?

The Importance of Bugs Dashboard To The Process

When issues arise during a sprint, they impact a team in many ways. They may affect morale if they appear to indicate a poor quality product. They may affect team dynamics if it is perceived that the bugs come principally from one person’s contributions. They almost always increase the pressure on the team through an increased sense of urgency to meet the previously stated goals of the sprint (which may already include other Bugzilla entries) and the new “pop-ups”.

The Bugs Dashboard aids in classifying the issues as a matter of the product owner’s point-of-view vice the report. For example, someone may feel that a relatively obscure bug is preventing them from using the system because it affects something they have an emotional attachment to. I say obscure because few users utilize that same function and thus there is not a great many users requesting the “fix”. The team’s desire to address that three weeks from now, in the next sprint, could be viewed negatively by the end-user. By allowing the Product Owner to specify the importance, I have the ability for the user to express their view, the team to express theirs, and the choice to be the Product Owner’s. With the Bugs Dashboard and ScrumWorks Pro, I can give the Product Owner the information necessary to make the tough choices. Perhaps something must be given up in the current sprint to meet the emergent need. Perhaps the emergent need can wait or perhaps additional resources must be authorized to deal with the need. Bugs Dashboard provides the right information and the right tools for these decisions to be made with minimal pain.

How-To Integrate Bugzilla, ScrumWorks Pro and Bugs Dashboard

Physically, it is simple to integrate the three products: just follow our “How-To” guide. The reason I direct you to a separate page is because there are over 20 screen shots to guide you step-by-step at that page.

Mentally, it may not be as easy to integrate the three. That is because you have to “herd the cats”. The bug reporter has a say in how a bug is interpreted and may need to be consulted further, but handled gingerly while separating the emotional ties to the issue. The team may need to be consulted to ascertain the expected impact of addressing the issue – an interruption to their current work knowing you will be asking them to perform the new work. The Product Owner may need to be consulted to provide the give-and-take on expectations for the sprint – and giving up expectations is never an easy thing.

My Approach

There are several approaches to how to handle interruptions of this nature. The one I favor is to create a separate product backlog item in each sprint for “unexpected events” from the very start. Initially, this is a low budget item – perhaps 4 hours in a 4 week sprint. As the sprints build, this number usually increases due to more functionality that must be maintained, a large installed base, larger code repository, etc.

Unexpected events can include bugs which arise and are deemed urgent enough to be addressed in this sprint. It can also include technical debt which must be paid back through refactoring, increased demand for documentation, loss of work due to sickness, etc. The cool thing is that the team can fill any unused time with additional tasks from the uncommitted backlog should they get the opportunity. Only the team can add items to a sprint after it has started.

Must Haves

Each of us has a style and we all have our individual preferences. For me, and I may be biased – I admit it, the best approach I have to managing the complexities of a project in a simple fashion is to use Bugzilla, ScrumWorks Pro and Bugs Dashboard. these are all “must haves” for my toolbox!

bugzilla

Prerequisites

Prerequisites

• Tomcat has been successfully installed (see Installing Tomcat 6 on Ubuntu at the How-to Geek)
• MySQL (see the Ubuntu Guide) or PostgreSQL (see the Ubuntu Guide and supriyadisw dot net) have been successfully installed
• Bugzilla has been successfully installed in one of the above databases and can be reached via a JDBC connection from the Tomcat server

Steps

1. Download the latest Developer or Enterprise version of Bugs Dashboard and either a) save it to disk or b) open it with the Archive Manager and then Extract the contents. We chose to save the zip file to the desktop.
2. If you did not use the Archive Manager in step 1, navigate to the downloaded file, right-mouse click on the file and select Extract Here.
   
3. Extracting the file locally will result in a new directory named “bugs”.
   
4. Open the bugs directory. Inside, you will find the README (read it, please!), the documentation (under the docs directory), the license, and the bugs.war file.
   
5. Right mouse cick on the bug.war file and choose Extract Here.
   
6. This will create another ‘bugs’ directory and this is the directory you will deploy.
   
7. Open the bugs directory. In it are the css, images, javascript and WEB-INF directories. Much of the modification which you must do to configure the Bugs Dashboard will be done in the WEB-INF directory.
   
8. Follow the steps at the Quick Start post or the How-to Configure pages to configure your copy of the Bugs Dashboard.
9. When your configuration is complete, move the second bugs directory (the one we stated you would deploy above) with the WEB-INF directory in it to the Tomcat webapps directory. In our case, this was under /opt/apache-tomcat-6.0.16/webapps.
10. In our testing, we found that it was not necessary to bounce the Tomcat server for the Bugs Dashboard to deploy. Open a browser and navigate to your local installation (this might be http://localhost or your domain name, in our case, it was http://localhost:8080/bugs/portal) and open the portal page (it will open to the first portal in the portals_en_US.properties file). If, for any reason, the page does not come right up, review the troubleshooting tips in the Quick Start guide.
11. Should you need to change your configuration, it may be necessary to stop and restart (i.e. bounce) Tomcat. You can do this by opening a terminal window, switching to root (sudo -s) and navigating to the Tomcat bin directory. Execute the shutdown script (./shutdown.sh), make any necessary changes, and then execute the startup script (./startup.sh).