ACPI Ticket Processing Guide

This guide is written for reporters, developers and ACPI project management.

Reporters

Entering New Tickets

When a new ticket is created, the milestone will default to the milestone corresponding to next scheduled ACPI version release. As of 2/9/2009, this is ACPI version 3.15.

The version will default to the current ACPI version. As of 2/9/2009, this is ACPI version 3.14. If you are reporting an issue for some other ACPI release, please override the default with the correct version.

The default values are defined by the ACPI project manager.

A well written ticket will contain sufficient information so that the developer can respond to the ticket without the need to request additional data. http://svn.netlabs.org/acpi/wiki/WikiStart#SubmittingTickets and ​http://ecomstation.ru/projects/acpitools/?action=logs will help you understand how to make this happen.

Responding to Tickets assigned to the Feedback Milestone

If your ticket has been moved to the Feedback Pending milestone, the developers need you to supply additional data or take some action. It is your responsibility to do this and respond the the ticket. When you respond to the ticket, it is also your responsibility to reassign the ticket to the current milestone. This will ensure that the developers are aware that you have responded.

If you forget to reassign the ticket, there may be a delay until the developers realizes you have responded. Developers must give priority to tickets assigned the the current milestone and may or may not notice your response if you neglect to reassign the ticket to the current milestone.

If you have questions of any kind about the status of your ticket, add a note to the ticket. This note will be seen by ACPI project management.

Developers

Handling New Tickets

Developers should review and respond to new tickets within 1 or 2 working days. As always, sooner is better.

When the ticket is reviewed, developers should change the ticket status to assigned.

Developers should correct the milestone and version fields, as needed.

If the reporter has neglected to supply the appropriate logs, the developers should point the reporter to http://svn.netlabs.org/acpi/wiki/WikiStart#SubmittingTickets and ​http://ecomstation.ru/projects/acpitools/?action=logs and move the ticket to the [http://svn.netlabs.org/acpi/milestone/Feedback%20pending Feedback Pending milestone].

If the developers need additional information from the reporter, add a note the the ticket and move the ticket to the [http://svn.netlabs.org/acpi/milestone/Feedback%20pending Feedback Pending milestone].

Displaying Tickets Requiring Developers Attention

To display the list of the tickets that need attention, click on the http://svn.netlabs.org/acpi/roadmap roadmap link, click on the current milestone and click on the open ticket count link.

It is recommended that developers bookmark the resulting Custom Query. This will provide one-click access to this ticket list.

In general, developers should ignore tickets not displayed on this list.

Using the Feedback Pending Milestone

The purpose of the [http://svn.netlabs.org/acpi/milestone/Feedback%20pending Feedback Pending milestone] is that tickets that are awaiting a response from the reporter out of the developers current work list.

In general, once a ticket is moved to Feedback Pending milestone, the developers should ignore the ticket until the reporter to supplies the requested information and reassigns the ticket to the current milestone.

When to Close Tickets

Tickets will only be be closed as resolved when the reported issue is fully resolved.

A ticket is considered resolved only when the reporter states that the issue no longer exists.

When the resolution requires no code changes, the ticket may be marked closed when the reporter indicates that the issue has been resolved.

When the resolution requires source code changes, the code changes must be submitted to the Subversion repository as soon as possible after the reporter indicates the issues is resolved. In general, the changes should be submitted within one or two business days. This allows times for source code and comments to be cleaned up, if needed.

After the changeset is submitted, a comment must be added to the ticket indicating the Subversion change set number along with a description of the nature of the code change and how it resolved the reported issue.

When the resolution requires source code changes, instruct the reporter to test the next milestone version when it is released and move the ticket to the Feedback Pending milestone.

The above means that the test results for interim builds will never cause a ticket to be closed. Only the test results for a milestone release version will cause a ticket to be closed.

If a ticket will not or can not be resolved by the next milestone release, leave the ticket open. If the developers wish to take this ticket off the list of tickets requiring developer attention for the current milestone, move the ticket to a future milestone.

Management

Maintaining Tickets After a New Release

When a new version is released and the milestone corresponding to the new version is be marked complete, there will usually still be open tickets assigned to the milestone. The ACPI project manager will move these open tickets to the next milestone.

Handling Stale Tickets

Over time, stale tickets may accumulate in the Feedback Pending milestone. The ACPI project manager will monitor this milestone and determine how to dispose of these tickets.