[[PageOutline]]

= 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 1/26/2009, this
is ACPI version 3.15.

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

These default values are defined by the ACPI project manager.

When submitting a ticket, reporters should override these values if needed.

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.
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 developer needs you to take some action.
It is your responsibility to do this and respond the the ticket.
When you respond to the ticket, try to remember to reassign the ticket to the current milestone.
This will help ensure that the developer is aware of your response.

If you 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
developer 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 developer needed 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 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.

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 developer should 
ignore the ticket until the reporter to supplies the requested information.

=== 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 occurs.

When an ticket is resolved by code changes, the code changes must be 
submitted to the Subversion repository before the ticket is closed.

When an ticket is resolved by code changes, a comment must be added to the 
ticket indicating the Subversion change set number.

When an ticket is resolved by code changes, a comment must be added to the 
ticket indicating the nature of the code change and how it resolved the 
reported issue.

When an ticket is resolved by code changes, instruct the reporter to test
the new version when it is released and move the ticket to the Feedback
Pending milestone.

The above means that the test results for an interim build will never cause a ticket to be closed.  Only the test results for a released version will cause a ticket to be closed.

If a ticket will not or can 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.

== 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.