Here you can find vital information about what to fill in the IssueTracker if you are submitting a new issue, just reading or modifying it.
Please remember: each piece of information is important for testing and fixing an issue. But make sure it is at the right position.
Choose the appropriate link to enter a new issue -> Issue Tracker.
Choose the appropriate application, language, project or code module.
Selected the appropriate options or input information for each field before using the Submit issue button to enter your issue.
The information you provide here significantly determines the effectiveness of your issue reports and the response to them. Descriptions for each of these fields follow to help you optimize your issue reports.
Important note:The target is set by the appropriate developer or a member of the QA Team. Setting the target depends upon the impact of the fix, the time needed to do the fixing and the priority of the issue.
Found in Version:The release in which you identified this issue or found the defect.
Component/Subcomponent:Identify area within the project that this issue is associated with. Only one selection is permitted.
Platform
This corresponds to your hardware platform when you are reporting a defect. For example, these options might include:
All (happens on all platform; cross-platform issue)
Macintosh
PC
Sun
HP
Note: Selecting the option "All" does not select issues assigned against all platforms. It merely selects issues that occur on all platforms.
Operating System:This is the operating system against which the issue is being reported. For example, these options might include:
All (happens on all operating systems, making this a cross-platform issue)
Windows 95
Mac System 8.0
Linux
Note that the operating system implies the platform, but not always. For example, Linux can run on PC, Macintosh, and others.
Issue Priorities
Intention
The "Priority" field in IssueZilla describes the severity of a problem, for the user base of OpenOffice.org as a whole. If you like, it's a measure of the summed-up annoyance a problem causes. Understood this way, "Priority" is one measure which helps people to plan their work - without additional constraints, a developer would fix a problem the earlier the higher its "Priority" is. Note, however, there usually are other constraints and side conditions, which also affect task planning. Such constraints are explicitly not to be described by an issue's "Priority" value.
Guidelines
When priorizing an issue, ask yourself the following questions, to judge the severity:
How much does the problem hinder the user's work?
How many users would be affected by the problem?
How often would users be hit by the problem?
How easy is it to work around the problem?
Thinking about those questions should give you a good first estimation on the problems severity for the whole user community (remember that this is what is reflected in the "Priority").
Definitions
P5:
P5 marks problems which describe wrong behavior of the application, but rarely affect anybody noticeably.
Issues with this priority are not relevant for a release.
Fixing them would be nice-to-have.
Example:
In a seldom-used dialog, a control with an offset of a few pixels
P4:
P4 describes problems which are non-critical or rarely occuring.
Issues with this priority are desired, but not required, to be fixed before the next major release.
Not fixing issues with this priority has a less negative impact than not shipping in time.
Examples:
Incorrect behavior that doesn't affect functionality
Spelling errors (“Typos”) in rarely seen places
Bugs that are easy to workaround
Minor performance problems, e.g. a dialog which initially needs 1 second to open, each time you just started the application
P3:
P3 marks non-trivial problems which probably affect a noticeable number of users.
Issues with this priority must be fixed before the target release.
Not fixing them for the target release must be justified by a superordinate rule.
Examples:
Spelling errors in obvious places e.g. an application's main menu
Menu entries or standard keyboard shortcuts (e.g. Ctrl-S) do not work
The application crashes in very special circumstances;
e.g. when you need to customize 129 icons into the same toolbar to make the application crash
Responsiveness of a commonly used UI (e.g. the File/Open dialog) is noticeably and consistently bad;
e.g. it takes 2 seconds to open every time you invoke it
Functionality which is not available, but a workaround exists;
e.g. you cannot apply formattings to your text via the toolbar, but only using the menu
The user interface for a common functionality is confusing.
Noticeable performance regression of a functionality, compared with a previous build / version / release
P2:
P2 marks severe problems which affect a significant number of customers
Issues with this priority must be fixed before the target release (see Target milestone), which usually is the next major release, and should be dealt with as soon as possible.
Not fixing them for the target release is not acceptable.
Examples:
An essential product feature - e.g. Printing - does not work at all, and no workaround exists
User data is corrupted in an easy-to-encounter way;
e.g. saving a document corrupts the resulting file and renders it unusable
Crashs or freezes during normal operations of the application
A critical usability problem;
e.g. a user interface which renders the underlying functionality incomprehensible for the majority of users
Severe performance problems in often-used/basic functionality;
e.g.
every application startup takes 5 minutes
saving/loading of usual small-sized document takes several minutes
Huge memory leaks in common or easy-to-reach functionality;
e.g. a mail merge operation which leaks 1 MB per merged document
UI responsiveness of a non-essential feature is extremely poor, rendering the feature unusable;
e.g. a File/Open dialog which needs 5 minutest to open
Counter-Examples
Functionality is working improperly, but UNDO restores the previous state
P1:
P1 marks extremely severe problems.
Issues with this priority must be fixed immediately, and the fix must be included in the next available build of the application.
Not fixing those issues is simply impossible.
Examples:
Reproducible, unavoidable crash or freeze in functionality indispensible for the whole product;
e.g. crash upon loading arbitrary documents
Build problems
Incorrect text or graphics with legal implications
Security issue in a released version
Counter-Examples
Nearly everything not listed above. There's rarely anything which really qualifies as P1 issue!
Defect: is a problem with an existing feature that is either not developed to spec or does not work as designed. These are often referred to as "bugs."
Enhancement: is an improvement to an existing feature.
Feature: is an addition to the software to add a piece of functionality that does not yet exist.
Task: is an activity to be done on behalf or in support of a feature or enhancement. Tasks do not typically require direct changes to the code base.
Patch: is a special kind of issue, a section of code to be applied or attached to existing software, often to fix a defect.
If you do not have the permission 'Project Issue Tracking - Change', any issues you enter will have the initial state of "new" or "unconfirmed." Marking an issue unconfirmed means that it is not yet determined whether it is true or valid. Read more about "state" in the "About issues"- page.
Enter the username of the one individual who is in charge of resolving the issue. If this field is left blank, the issue by default is assigned to the component/sub component owner. Every time this field changes, the status changes to NEW to make it visible in the assignee's list of issues.
CC:
Add usernames of other individuals who need notification when this issue changes status or when there is other activity on this issue. Delimit multiple usernames by single spaces only -- no commas or semi-colons are necessary.
Note: Assign cc addresses sparingly. Project participants whose interest or involvement in this issue is peripheral should be encouraged to use the Issue Tracker to check and track issues rather than to rely on automatic email notification.
URL
How to use this field depends on the issue type:
For defects, URL should lead to a fairly stable system where the the problem is obvious or can be easily reproduced.
For enhancements, URL should provide details pertaining to the improvement, such as mockups.
For features, URL should link to any web-based form of material explaining the improvement such as mockups or design specs.
For tasks, URL is optional and may include linking to the associated feature or enhancement.
Summary
A terse, specific statement to describe this issue. This should a few unique, self-explanatory words to identify this issue easily in reports and short lists. Limiting your entry to the width of the field is best for the columnar display of query results.
Description
Provide a full description of the issue including any pertinent history or activity around this issue. Because this field is additive, it serves as the knowledge base and means of communicating through this issue's life cycle. Other project participants view and add comments or information using this field.
Submit enters this issue into the project's issue database.
Reset returns all field values to their default or blank settings.
Remember values as bookmark template lets you save your input settings to save keystrokes when entering multiple issues for the same project component.
For more information about entering issues into the Issue Tracker, see also Issue writing guidelines.
Existing issues may be accessed in two different ways:
Entering a specific issue number in the "Find" field located on the Issues page displays the "Issue View" page.
Querying for issues either by clicking the "Query database" button in the Project Issues page displays an "Issue List" page of your results. (See Issue Tracker Query.)
The Issue View page is similar to the Enter issue page and contains many of the same fields, but there are several important additions:
Target Milestone
If your project has designated milestones, this field can be used to associated issues with those milestones, such as version releases. A milestone plan enumerates when different features are expected to be completed. If an issue has a target date or version release, this means the work on this issue must be completed by that date. This field should only be set or changed by the person responsible for the issue.
Add/Remove CC:
You can add additional email addresses to this issue to alert other project members when activity occurs on this issue. If you are adding multiple addresses, delimit these with single spaces; do not use commas or semi-colons. You can also remove one or more email address listed by selecting it and checking the "Remove selected Cc's" box below.
QA Contact
This field should contain an email address or alias for the person(s) responsible for quality control of this issue.
URL
If this field is populated, clicking the field label links directly to the designated URL.
Status whiteboard
The purpose of this generic field can be user-defined and project-specific. This field is used for writing short, one-line notes about the issue.
Attachments
Adding attachment to an issue can be very useful. For defects, appending test cases, screen shots and/or editor logs to the issue can help pinpoint the problem to help the developer reproduce it.
For features, enhancements, and tasks, you can attach screen shots, mockups, and other files to provide supplemental information to illustrate the issue.
You can also used this field to attach a patch related to the issue when appropriate. Read more about contributing patches.
Dependencies
When an issue can't be addressed until one or more other issues are resolved, these are dependencies. Each issue can have other issues it depends upon , as well as issues that depend upon it, that is, other issues that this issue "blocks" while being unresolved.
Vote for this issue
The Issue Tracker's "voting" feature allows project members to have a certain number of votes in their project to use toward issues. Project owners set the number of votes allowed per issue, as well as the number of votes allowed per member. Some projects/components may not allow any, which means you can't vote on those issues at all. Your vote indicates which issues you believe are the most important to be addressed.
You may vote for the same bug more than once, however, you have a limited number of total votes allocated to you. You can either vote once for many issues, or use multiple votes for a fewer issues that you think are particularly critical.
If an issue has received votes, the total number appears next to "Votes for this issue", or "0" if no votes have been logged. Clicking on this number displays the Show Votes page. If there are votes, names and their associated number of votes are listed.
To view a list of issues that have received votes, use the Issue Tracker Query page, and enter the numeral "1" in the "At least ___ votes" field. This returns issues in your query results with at least one vote.
To vote for an issue:
Open the issue (by clicking the issue from a list or report).
Click on the "Vote for this issue" link just above the "Additional Comments" field. (If no such link appears, then voting may not be allowed for this issue's project/component.)
Indicate the number of votes you want to log for this issue. This page also displays how many votes you've given to other bugs, allowing you may reallocate your votes as necessary.
You receive automatic email notification anytime changes occur on issues you have voted for.
You may review your votes at any time by clicking the "Change your password or preferences" on the Issues page or at the bottom of the query page.
If one or more drop boxes appear identifying project-defined groups to be included in or excluded from viewing an issue, this indicates that the project/component owner has created groups within the project. You should contact this person to determine how to use these fields.
Leave as NEW
If you are viewing an issue with the status NEW but it is not assigned to you, leave this default as checked. When the issue is assigned to you, you should accept it by changing its status to "Started."
Resolve issue
Once an issue is resolved, this is where to designate the type of resolution. Changing an issue to "Resolved" means that as far as the assignee is concerned, this issue is completed.
Note: Changing an issue's status to FIXED signals all other project members that any source file changes associated with this issue have been checked into the CVS repository.
Reassign
The person responsible for the issue can be changed here by entering a new email address, or reassigned to the component/sub component owner.
View Issue Activity
This link displays a snapshot page of changes made to an issue.
Format For Printing
This links redisplays the Issue View in a format for printing out.
Format as XML
This links displays the issue as XML.
Submit
This button saves any modifications made to this issue. Caution! When viewing an issue, the "Enter" key works like the Commit button. Any modifications you may have made (accidentally or otherwise) are saved and the issue's assignee and cc list receive email notification of activity on this issue.
To exit out of viewing this issue without making any changes, use the links at the top of this page to view other issues, or the Back button in your browser. Even when you have changed fields, as long as you do not use the Submit button or the "Enter" key, the issue remains unchanged in the database.
Reset
Returns all fields to their previously submitted values.
