ACPI Ticket Processing Guide

This guide is written for both developers and reporters.

New Tickets

When a new ticket is added, the milestone will default to the milestone corresponding to next scheduled ACPI version release. As of 7/15/2008, this is ACPI version 3.11.

The version will default to current ACPI version (i.e. 3.10).

These default values are defined by the ACPI project manager.

When submitting a ticket, reporters should override these values if needed. Developers should correct these values as needed when responding to the ticket.

A well written ticket will contain sufficient information so that the developer can respond to the ticket without the need to request additional data. Reporters should attempt to make this happen.

Responding to Tickets

Developers should respond to a ticket within 1 or 2 working days. As always, sooner is better.

If the reporter has neglected to supply the appropriate logs, the developer will point the reporter to http://svn.netlabs.org/acpi/wiki/WikiStart#SubmittingTickets and ​http://ecomstation.ru/projects/acpitools/?action=logs.

Displaying Tickets Requiring Developer Attention

To display the list of the tickets that need attention, click on the 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.

The developers may choose to ignore tickets not displayed on this list.

If a reporter believes a ticket has been incorrectly assigned, add a note to the ticket explaining why. This note will be seen by ACPI project management.

Using the Feedback Milestone

If the reporter fails to supply requested data in a reasonable period of time, reassign the ticket to the [http://svn.netlabs.org/acpi/milestone/Feedback%20pending Feedback Pending milestone].

A reasonable period of time is probably 5 working days. This helps avoid cluttering up the list of tickets requiring developer attention with tickets where the developer is waiting for the reporter. It also generates ticket e-mail to the reporter reminding the reporter that we are waiting for them.

In general, once a ticket is moved to Feedback Pending milestone, it will be ignored by the developers.

Responding to Tickets assigned to the Feedback Milestone

If you are a reporter responding to a ticket assigned to the Feedback milestone, try to remember to reassign the ticket to the current milestone. This will help ensure that the developer is aware of the response.

When to Close Tickets

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

A ticket is considered resolved when the reporter states that the issue no

longer occurs.

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

When an ticket issue is corrected by code changes, it will be helpful the ticket should be updated to show the Subversion changeset number. To be useful, this means that subversion commits should be done soon after the change is implemented.

If a ticket will not be resolved by the new version release, leave the ticket open. If desired, move the ticket to a future milestone. This will take the ticket off the list of tickets requiring developer attention for the current milestone.

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 for the milestone. Any remaining open tickets will automatically be moved to the next milestone.

Handling Stale Tickets

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