Filing a Bug in YUILibrary.com
Step 1:
Before filing a new ticket, be sure to review the open tickets already filed for a component. If a ticket already exists that covers the issue you are about to file, please do not create a duplicate. Instead, add any additional information you might have that is relevant to the reproduction or resolution of the issue to the existing ticket and click the Cc checkbox to be notified of future updates.
Step 2:
If there is no existing ticket that describes the defect or enhancement request you would like to add to the database, create a new ticket providing as much detail as possible in the fields provided.
Summary
Each ticket should contain a brief summary that succinctly describes the defect or request being reported.
Description
The description field provides ample space to include a detailed summary of the defect or request. Please do not include large code snippets in the description field. If your code snippet is larger than a couple of lines, please add it to the ticket as an attachment.
Defect Reports
When reporting a bug encountered with a YUI component, please include all steps that are required to reproduce the problem. Sample code should also be included as an attachment to the bug or as a link to a publicly available page where the code can be stepped through for debugging.
Enhancement Requests
Enhancement requests should include a detailed description of the addition being requested as well as information on intended use cases.
Component
Select the library component that the defect was found in or to which the enhancement request relates. If the ticket is a proposal for a new component to be added to the library or is not covered by the selections in the menu, select General.
Type
The following table describes the types of tickets that can be submitted to the database in YUILibrary.com:
| Defect |
Describes a bug encountered in the software or an error found in the library documentation. |
|---|---|
| Enhancement |
Proposal for modifications to existing code or new component to be added to the library. |
| Task |
A task is a non code related item that needs to be completed for the corresponding release. Examples:design reviews, code reviews, new browser validation, etc.) |
| Patch |
A means for external developers to indicate a code submission for bug fix or enhancement proposal |
Observed In Version
When reporting a defect, it is critical for the developers to know the version number of the software in which the error occurs. Please select the YUI release from this popup to designate the version number of the library you are using. If you are a developer using one of the more recent checkins submitted to Git that is not yet included in a YUI release, specify "development master" in the Observed Version field and include the SHA1 commit id in the description field of the bug so that we can use the correct sources when reproducing the issue.
Severity
When creating a ticket, the submitter can use the Severity field to specify the impact of the defect being reported. Please be sure to accurately describe an issue and include sample code or a link to a publicly available page so that the defect can be reproduced and debugged quickly. Defects that are incorrectly classified in order to try to expedite a resolution will be switched to a more appropriate setting upon initial review. Any issue that does not contain enough information to reproduce the problem will be returned to the submitter with a request for more detail. Further action on the ticket will be suspended until the requested details are received. Bugs that received no response for additional information will automatically be closed after 9 days of inactivity.
| S1 (critical) |
Functional or procedure failure of the complete system. Major loss of revenue. No work around exists. |
|---|---|
| S2 (high) |
Functional or procedural failure, but an acceptable work around exists. |
| S3 (normal) |
The defect causes no system failure, but the system produces incorrect, incomplete, or inconsistent results. |
| S4 (low) |
The defect does not result in failure or significant impairment of usability, and there are one or more easy work arounds. |
| S5 (trivial) |
Defect is cosmetic. |
Target Release
The Target Release field is used by the YUI team for ticket categorization purposes. When a ticket is filed, this field is initially blank until the ticket is reviewed by the component owner. Once the bug is reviewed it will be assigned a target release timeframe as follows:
| numbered release |
All bugs targeted for a planned release with a designated version number. |
|---|---|
| .NEXT |
These are important items that do not fit in the current release for reasons such as not enough time left in release or the scope of change is too large or risky for release. However, these items are considered if high importance and should take priority in evaluation when building the task list for the next release. |
| FUTURE |
These defects and enhancement requests are reviewed and appropriate to include in the corresponding component but are either much lower in priority than others in the queue or require significant architectural changes for completion. |
Location
The YUI Library is composed of many pieces. There are API Docs, Examples, Tests, and Documentation on the web site that are provided to the development community along with the core library code as part of the each release. This field is used by the development team to designate which component of the overall release is affected in the resolution of the ticket.
| Library Code |
Change location is in core library code or plugin |
|---|---|
| API Docs |
Update is needed in API doc content |
| Example |
New example or modification to existing example |
| Unit Test |
New test or modification to existing test |
| Documentation |
Change to landing page, cheat sheet, etc. |
Priority
All tickets submitted are reviewed by the development team in order to verify that the content is valid as well as specify the target release in which the issue will be addressed. The evaluation of the defect or request, and the Severity specified by the submitter are taken into consideration when setting the fix priority for each ticket. Detailed descriptions of the Priority settings are as follows:
| P1 (critical) |
Critical items resulting in serious failures that have no workaround and need to be addressed immediately. This category should be used rarely and all P1 tickets must include complete repro instructions and sample pages or code. Fix will likely be shipped immediately as a patch as soon as the issue is resolved. |
|---|---|
| P2 (high) |
Severe defects that have a workaround that can be used until a fix is available. P2 tickets must include complete repro instructions and sample pages or code. Fix will be shipped soon after resolution as part of a patch release. |
| P3 (normal) |
Normal priority tickets. The expectation is that all P3 tickets will be complete for the designated release. |
| P4 (low) |
Nice-to-have items. These items will not block a release and will be deferred to NEXT if not complete within the release timeframe. |
| P5 (trivial) |
Very simple, low risk, non code related changes. |
Relates To
In your scan of the ticket database prior to reporting an issue, you may find an entry you feel may be related to the issue at hand but is not an exact duplicate. If so, you can note this relationship in the ticket by adding the ticket number in the Relates To field. Note: ticket numbers that are in the same project database can be entered as a link by preceding the ticket number with the # symbol.
Cc
The Cc field cannot be set when creating a ticket. The original submitter does not have to add themselves to the cc list to receive updates for a ticket. The original submitter of a ticket will automatically receive emails each time the bug is updated. However, if there is an existing ticket filed for an issue that is also affecting your development and you would like to track the progress on its resolution, simply view the bug and check the Cc box to be added to email distribution for updates.
Blocks
This field is used by the YUI development team to identify dependencies described in other tickets that must be completed before progress on that specific ticket can proceed.
Browsers
The Browsers field contains a checkbox corresponding to each Browser supported by the current YUI release as documented in the GBS. When a new ticket is created, this field is set to N/A by default to designate that no browser information had been added by the submitter. If the issue is general to all browsers, please check All. When the issue reported only affects a specific subset of the browsers listed, please check all that apply. If you encounter the issue with a browser not included in the list provided, simply check Other and provide the name of the browser, its version, and the OS on which you were running in the Test Information field.
URL
This field can be used to hold a URL to a publicly available web page that can demonstrate the core concept corresponding to an enhancement request or can be used to reproduce a defect.
Test Information
Submitters can use the Test Information field to specify discrete steps necessary to reproduce the defect being described in the ticket. If a problem can be reproduced using a very small code snippet, the code can be pasted into this field. However, a fully executable file included as an attachment to the bug is preferred.
Assign To
The Assign To field is used by the YUI team for task allocation purposes and will contain the name of the developer that will be working on the issue described in the ticket.
Tags
The Tags field has been added to support the specification of a custom keyword to bugs to that they can be accessed later as a group via a custom query.