Got Issues?

Last updated 2002-06-03

Why "Issues" And Not "Bugs"?

Not all 'issues' are DEFECTS, which are more commonly known as "bugs." Some issues will be FEATURE Requests or ENHANCEMENT Requests, PATCH submissions, or even TASKS. For this reason, we feel the term "issue" is a more appropriate one than "bug". People often say 'bug' when they should really be referring to an issue. Enter the tasks you're planning to work on as enhancement requests and will help you track them and allow others to see what you plan to work on. If people can see your flight plan, they can avoid duplicating your work and can possibly help out or offer feedback

What Is IssueZilla?

IssueZilla, a proprietary tool, is based on Mozilla's open-source Bugzilla, but has been generalized by CollabNet to handle all kinds of issues, not just code-based issues. On OpenOffice.org, the supported issue-types now include: DEFECT, ENHANCEMENT, FEATURE, TASK and PATCH. We can add issue types in the future as necessary, and these can be reported against specific components of a project, for example 'documentation', 'code', 'ui', 'definition'. OpenOffice.org's projects are 'api', 'chart', 'database access', 'drawing', 'formula editor', 'presentation', 'spreadsheet', 'word processor' and 'xml' to name just a few. Take a look at the projects/products list to see all of them.

Reported issues will be assigned to an appropriate issue owner.

What do you have an issue with?

Do you want to report an issue with a milestone build or with a copy of OpenOffice.org that you compiled yourself? IssueZilla is the place to submit issue reports for software distributed by OpenOffice.org. This page gives an overview of how IssueZilla works. Read the issue writing guidelines as well, for tips on how to write useful issue reports.

Anatomy Of An Issue

Issues are composed of many fields. Some of them are described here.

Project

OpenOffice.org is composed of different projects. Carefully read the project descriptions if you're unsure of which project to attribute your issue to (visit the projects themselves for fuller descriptions). The project you choose determines which person IssueZilla assigns the issue to.

Status Whiteboard

The Status Whiteboard is used for writing short notes about the issue.

Keywords

This field is used to store various keywords.

Special 'helpwanted' keyword and TASK issue-type

Developers can post helpwanted notices, and IssueZilla can help match-make other developers and apprentices who wish to help out with a TASK. Developers should Write helpwanted in the Keywords field of an issues, perhaps changing the issue-type of the defect or enhancement to 'TASK'. Others searching for things to do will find it and even accept the issue or TASK. People interested in getting involved can search IssueZilla for issues and ENHANCEMENTs marked helpwanted. Maybe one of them will have the expertise and resources to help you with your problem.

Developers can use the TASK issue-type for project-work they'd like to delegate. For instance, if your code has a issue on some platform which you don't have access to, or with some language you don't know, try adding this keyword. A developer can of course change an uncompleted TASK back to DEFECT, ENHANCEMENT or FEATURE (whatever the issue was before it became a TASK again). This could happen, for instance, when the initial issue owner decides nobody is willing to help out with a task.

Or, as with any developer, you're probably swamped with issues. Some of these issues will be lower priority than others. Try marking issues that you realize you won't be able to any time soon as helpwanted. Someone else with different priorities may see this and help you out.

When marking issues helpwanted, be sure to add a comment carefully explaining what work needs to be done, and how to do it, if you know. The better you can explain the problem and its solution, the more likely it is that someone can provide a useful solution.

Dependency

If an issue can't be fixed until another issue is fixed, that's a dependency. For any issue, you can list the issues it depends on and issues that depend on it. IssueZilla can display a dependency graphs which shows which the issues it depends on and are dependent dependent on it.

Attachment

Adding an attachment to an issue can be very useful. Test cases and screen shots can help pinpoint the issue and help the developer reproduce it.

Special patch-file 'Attachment' and PATCH issue-type

If you've already fixed a defect or done an enhancement, you should report an issue of type PATCH, and attach the patch-file to the issue. This is the preferred way to keep track of patches since it makes it easier for others to find and test. To make a patch, you need to generate a diff file containing the differences between the file with your changes and the original file in the repository. To generate a patch file enumerating changes for all files in the current directory try:

cvs diff -u > mypatch.diff

To apply a patch, go to the proper directory and do:

patch < issuepatch.diff

Life Cycle Of An Issue

What happens to an issue when it is first reported depends on who reported it. New IssueZilla accounts by default create issues which are UNCONFIRMED. Currently, on IssueZilla, the quality assurance is done by a list of users subscribed to a "virtual user" issues@<project>.openoffice.org.

You then use your regular IssueZilla account to login, then view, then further "workflow" the issue.

With default settings for your account you will be notified of any change made to the issue. Please do not reply via email to notification messages. The proper way to comment is to login and use the web based frontend. By sending mail to issues-subscribe@<project>.openoffice.org, you can be notified of all changes in bugs of this project.

If you are a registered OpenOffice.org user, you can create UNCONFIRMED issues. When an issue is confirmed and becomes NEW, the developer will probably look at the issue and either accept it or give it to someone else. If the issue remains new and inactive for more than a week, IssueZilla nags the issue's owner with email until action is taken. Whenever an issue is reassigned or has its component changed, its status is set back to NEW. The NEW status means that the issue is newly added to a particular developer's plate, not that the issue is newly reported. Think of "NEW" as an important e-mail you need to answer, except, you answer in IssueZilla, and you can use the tool to better track its progress than e-mail.

Those to whom additional permissions have been given have the ability to change all the fields of an issue (by default, you can only change a few). Whenever you change a field in an issue its a good idea to add additional comments to explain what you are doing and why. Make a note whenever you do things like change the component, reassign the issue, create an attachment, add a dependency or add someone to the CC list. Whenever someone makes a change to the issue or adds a comment, they are added to the CC list and the owner, reporter and the CC list are sent an email showing the changes to the issue report.

When a issue is fixed it's marked RESOLVED and given one of the following resolutions.

FIXED

A fix for this issue has been checked into the tree and tested by the person marking it FIXED.

INVALID

The problem described is not a issue, or not a issue in OpenOffice.org.

WONTFIX

The problem described is a issue which will never be fixed.

LATER

The problem described is a issue which will not be fixed in this version of the product.

REMIND

The problem described is a issue which will probably not be fixed in this version of the product, but might still be.

DUPLICATE

The problem is a duplicate of an existing issue. Marking a issue duplicate requires the issue number of the duplicating issue and will add a comment with the issue number into the description field of the issue it is a duplicate of.

WORKSFORME

All attempts at reproducing this issue were futile. If more information appears later, please re-assign the issue, for now, file it.

MOVED

The issue was specific to a particular OpenOffice.org-based distribution and didn't affect OpenOffice.org code. One such scenario are defects reported against Sun's product version of OpenOffice.org. The issue was moved to the bug database of the distributor of the affected OpenOffice.org derivative.

QA looks at resolved issues and to make sure the appropriate action has been taken. If they agreee, the issue is marked VERIFIED. Issues remain in this state until the product ships, at which time the issue is marked CLOSED. issues may come back to life by becoming REOPENED.

Be careful when changing the status of someone else's issues. Instead of making the change yourself, its usually best to make a note of your proposed change as a comment and to let the issue's owner review this and make the change themselves. For instance, if you think one issue is a duplicate of another, make a note of it in the Additional Comments section.

If you make a lot of useful comments to someone's issues they may come to trust your judgement and ask you to go ahead and make the changes yourself, but unless they do, its best to be cautious and only make comments.