YUILibrary - Open source JavaScript and CSS for building richly interactive software.
Fork YUI on GitHub

YUI 2.x

Reporting Defects and Making Enhancement Requests for YUI Components

Discovering, isolating, and documenting errors is one of the most valuable things you can do for a software project. Suggesting compelling additions to the API or feature set is also a benefit to the overall growth and usefulness of the project. YUI welcomes this kind of support from everyone in the community.

If you wish to file a defect report or an enhancement request, we ask that you first review the guidelines below. Once you've read the guidelines, proceed to the component's project page to review existing tickets or submit a new request.

Defect Reports

Defect reports are useful documents when they are accurate, unique, specific, and complete. To ensure that your defect reports meet these criteria, please take the following measures in preparing your bug submission:

  1. Verify that the defect has not already been filed: If a defect report already exists do not file a duplicate ticket. Instead, add any additional information or code samples you might have that are relevant to the issue to the existing ticket and add yourself to the ticket's cc list if you would like to be notified of future ticket updates.
  2. Seek the simplest use case in which the defect can be reproduced: Bug reports should include as little code as possible while still illustrating the unexpected behavior. Taking the time to simplify the reproduction steps will also help confirm if the issue is specific to the YUI component or is being caused by other code in the implementation.
  3. Test the defect in as many browsers as you can: Test your bug in as many A-Grade browsers as you can and include your findings in your report.
  4. File a defect report filling out all applicable fields: Use the YUILibrary.com ticket database on the component's project page to file your defect report. Note: you must be a registered user on YUILibrary.com to file a ticket. If you are not already registered, please sign up for an account. When you have an account, simply log into YUILibrary.com, select New Ticket from the Project Page, then complete each of the fields listed below:
    • Summary: A short but specific description of the issue (e.g., "TreeView Control 2.6.0 expand() method fails in Opera 9.01").
    • Description: Provide as much detail here as you can about the issue and the implementation details that trigger the bug. If the issue describes functionality that had been working in a prior release, please include the version number of the last release in which the function had been working properly.
    • Type: Defect reports should be set to type defect.
    • Component: Specify the component to which the report applies (ie Event).
    • Observed in Version: The version of the YUI component in which the defect appears. Refer to the README file for the component you are using to determine the version number.
    • Browsers: Please indicate which browser(s), the browser version(s), and the OS(es) on you can readily reproduce the defect using the selections in this field.
    • Attach File: Use the Attach File button to upload a file containing the minimum set of code that can be run to reproduce the problem.
    • Test Information: If there are a discrete set of user actions that are to be performed while running the sample code provided, list them here. This field can also be used to specify a small code snippet that can be used to reproduce the problem. However, If your code snippet is larger than a couple of lines, please add it to the ticket as an attachment.
    • Severity: Specify the severity of the issue based on the criteria listed in the table below. Please do not exaggerate the severity setting in your ticket in an attempt to expedite a resolution. Incorrect settings will be revised to a more appropriate level during the triage review if necessary.
Severity
Description
S1 (critical)
Critical issue that results in a serious failure that has no workaround and needs to be addressed immediately. Fix will likely be shipped immediately as a patch as soon as the issue is resolved.
S2 (high)
Serious defects that have a workaround that can be used until a fix is available. Fix will be shipped soon after resolution as part of a patch or interim release.
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.

Please be sure to accurately describe the defect and include sample code so that the defect can be reproduced and debugged quickly. 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 receive no response for additional information will automatically be closed after 9 days of inactivity.

Enhancement Requests

Enhancement requests are an important means for the YUI community to propose additions to the library components as well as influence the task prioritization for future releases. Follow these guidelines in filing enhancement requests for YUI components:

  1. Check to see if the enhancement request has already been filed: If a report already exists do not file a duplicate ticket. Instead, add any additional information or use cases you might have that are relevant to the request to the existing ticket and add yourself to the ticket's cc list if you would like to be notified of future ticket updates.
  2. Decide if this is something that belongs in the core library: Ask yourself the following question: Is this enhancement so important that it's worth adding weight and complexity to the core package? If the answer is no, probably the enhancement belongs in an implementation or extension rather than as part of YUI itself. Creating an implementation/extension and sharing it with the community via the forums, your blog, or the YUI Gallery for implementations making use of YUI 3, might be the best solution in that case.
  3. Describe the enhancement fully: Focus on creating a simple, powerful, elegant enhancement and include core use cases.
  4. File an enhancement request filling out all applicable fields: Use the YUILibrary.com ticket database on the component's project page to file your defect report. Note: you must be a registered user on YUILibrary.com to file a ticket. If you are not already registered, please sign up for an account. When you have an account, simply log into YUILibrary.com, select New Ticket from the Project Page, then complete each of the fields listed below:
    • Summary: A short but specific description of the request (e.g., "Add built-in XHR sourcing of content for Panel Control")
    • Description: Enter a detailed description of the enhancement, including some potential use cases, as text within this field or as a document attachment to the ticket. You should also summarize, as clearly as possible, why you feel this feature belongs in the core library and describe why you feel it would be of interest and useful to a broad cross-section of developers.
    • Type: Enhancement requests should be set to type enhancement.
    • Component: Select the name of the component to which your enhancement request applies. In the case where your request is a proposal for a new component to be added to the library, leave this field with the default setting of None.
    • Attach File: Use the Attach File button to include any assets that might be of use in evaluating your request - visual mockups, working prototypes, etc. Such assets are strictly optional; a feature request can be complete without them.

My Ticket is Entered, What Happens Next?

The YUI development team works hard to ensure that all complete defect reports and enhancement requests are addressed appropriately. All incoming tickets are triaged on receipt resulting in one of three actions being taken:

  • the ticket is sent back to the submitter with an inquiry when more information is needed
  • the issue is resolved with details added as a comment to the bug describing the action taken
  • the ticket is added to the queue to be completed in an up coming patch or release

Issues that are confirmed to be critical are given a Priority setting of 1 or 2 and are released as soon as a fix is available by means of an interim release or patch. All other tickets are prioritized in relative to other items already in the development queue. You can view the Target Release and Priority settings in a ticket you are interested in to get a sense as to how soon a resolution will be available. The setting will be one of the following:

Target Release
Description
release number
All tickets that have been accepted to a specific target release are tracked for completion in that release. The tickets are addressed in priority order with changes blocking other issues taking precedence.
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 the release. However, these items are considered of 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 and will be scheduled into a development cycle at a later date.

The following table provides additional background behind the priority designations:

Priority
Description
P1 (critical)
Critical items resulting in serious failures that have no workaround and need to be addressed immediately. Category should be used rarely and all P1 tickets must include complete instructions to reproduce the failure as well as sample pages or code. Fix will likely be shipped immediately as a patch as soon as the issue is resolved.
P2 (high)
Serious defects that have a workaround that can be used until a fix is available. P2 tickets must include complete instructions to reproduce the failure as well as sample pages or code. Fix will be shipped soon after resolution as part of a patch release or interim update.
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 changes (ie dialog text changes, API doc errors).

When a code change is checked in that resolves an issue, the status of the ticket changes from accepted to checkedin. At that point, the update is available on Github for checkout. The ticket subsequently transitions to the closed state when the release is officially posted for download. Tickets corresponding to issues with the site content are closed as soon as they are checked in and enter the queue for the next site update as site updates happen on a more frequent basis.

The following diagram provides a visual summary of the YUI ticket handling process:
http://yuilibrary.com/projects/yuilibrary/download/Process/ReviewingATicket/ticketFlow.png