Using the issue-tracking system

We're currently experimenting with using the issue-tracking system here as the only tracking system. We used to use Bugzilla internally, and would enter bugs into the system as they were notified to us on our old Yahoo! Group. But that meant that formsPlayer users would never get to see the progress of a bug, or have any idea which of the bugs in the list were being worked on at any one time. (Or indeed, what bugs were outstanding.) So we decided to take the approach that unless there was a good reason for logging a bug in our internal Bugzilla system, we would always use the public system.

But that does have its problems, since we need people to use the tracking system in a fairly specific way.

Entering bugs

If you think you have found a bug in formsPlayer, please first search the bug list to see if someone has already raised the same problem, and then add your comments to the existing bug report. If you find nothing similar then go ahead and add a new issue. Each of the main samples also has its own project page and its own bug tracking area, so if you see a problem with a sample, please post to the specific area.

Assuming that you now definitely have a bug, the best way to use a bug-tracking system is start specific and work out. For example, imagine a bug entitled Submission errors when using HTTPS appear to no longer trigger xforms-submit-error. There is a strong possibility that this bug concerns all submissions, not just those that use HTTPS. And it's also possible that the bug is to do with the incorrect registering of event handlers (i.e., not specifically submission errors), or even that toggle is no longer working correctly (perhaps the handler for a submission error uses toggle and the person who entered the bug is not seeing a case change). These scenarios are unlikely, but it doesn't matter, since as a developer works on the bug, they can refine the title of the bug as necessary, should they find that the issue is not related to submission.

So the job of anyone entering a bug is mainly to give as much information as possible to help reproduce the error.

Reopening bugs, or creating new ones

Now, just say that by the time the bug is fixed, the title has been repeatedly changed (in line with whatever theory the developer was working on at the time) until it ends up being called Toggle fails on Wednesdays; in other words, it turns out that the bug was nothing to do with how it first appeared (submission errors not firing when using HTTPS). And then let's say that the day after this bug is fixed and close, the person who entered the bug discovers in some other form that they are workin on...that once again xforms-submit-error is not firing when using HTTPS!

Is this the same issue as before? Well, obviously it can't be, since the previous issue was "Toggle fails on Wednesdays. It may have started life as an HTTPS-related issue, but that turned out to be wrong, and it needs to be treated as if it always was an issue to do with toggle failing on a particular day of the week.

So it means a new issue has to be entered, and we then start from scratch.

Summary

So, to summarise...please enter lots of small issues, focusing on just one problem, and having clear descriptions. There is no need to try to second-guess what the underlying problem is--we'll leave that to the guys with the debugging tools. If we don't do it this way there is no way for developers to get a handle on what's going on, and no way to refer to bugs in an unambiguous way. And the open issues list becomes meaningless.