ICU tickets follow a definite path through their life, from initially being opened, through implementation or fixes, to closing and release of the changes in an updated version of ICU.

Ticket Types

1. Defects: These are opened to report some problem with ICU - incorrect results from the code itself, errors in documentation, errors in the project website or on-line tools, etc. 
   
   A good defect report should include enough information to allow the problem to be reproduced, including
   
   • the version of ICU
   • the Operating system type and version
   • the compiler version
   • for Java code, the JDK version
   • a code snippet that exhibits the problem, preferably small and self-contained

1. Features: These are opened to request the addition of new functions or features to ICU.
   
   Note: Feature requests used to have "RFE:" (Request for Enhancement) in their description because our former ticket database did not have any other mechanism to distinguish between defects and features. While many ICU Feature tickets still retain this, it is obsolete usage, replaced by the Ticket Type field.
   
   
2. Tasks: These represent work items to be done in support of the ICU project that aren't directly visible to users of the library.

Submission

Tickets may be submitted by anyone, at any time. Before submitting a defect, it is good practice to check whether the problem has already been submitted to Trac database.

Initial Evaluation

A members of the ICU development team will monitor incoming tickets and make an initial evaluation. Some tickets may be resolved as duplicates of other tickets, or as invalid (submitter misunderstood expected behavior) at this stage. Remaining tickets will be assigned an owner.

Scheduling

As part of the planning cycle of an ICU release, a set of open tickets will be marked for inclusion by setting the "Milestone" field to the release number and planned mile stone number.

Prioritization is primarily based on the requirements of the companies providing the developers to the project.

Additional contributions to the project are welcome, so long as they are consistent with the overall objectives and design of ICU. But do talk to the ICU development team first, via the project mail lists.

Coding

At the time actual work begins, the developer should accept the ticket, and set the Milestone field to reflect the development milestone that is expected to have the fix or feature (if it is not set already).

For non-trivial commits (If in doubt, it's non-trivial), it's best to do feature work on a branch. See "Merging-and-Branching" for some tips on branch work. Here are some examples of why you would do work on a branch:

• You expect contention:  It's a large involved change, over a period of time, and other developers may commit code that conflicts with yours.
• You are looking for review and/or testing during the development process:  Others can pick up the branch and try it, or view the commits. 
• You expect test breakage during the development process.  Commits to the trunk should not break tests.  Work on a branch until the tests are clean.

All commits of code back to subversion must include the associated ticket number with the commit message. This information will be used by reviewers to identify the complete list of changes associated with a particular ticket.

svn commit messages have the form
ticket:1234: a short message describing the changes being checked in

Fixed by Other Changes

If a ticket - defect or feature - is handled by changes associated with a different ticket, a brief explanation of the situation should be added to each ticket involved, and all of the tickets should be proceed through the normal process to the review step. We do not want to lose track of the fact that a reported problem was fixed simply because it was one of a group of related problems that were fixed by a single set of code changes.

Testing

For defects, before making any fixes to the implementation code, a test should be written that fails because of the problem. The problem should then be fixed, the fix being checked by the just-written test.

C and Java

Most ICU services exist in both C and Java. Any defect reported against one side should be checked (the test ported) to the other, and if it exists, it must there as well. This must be done before moving to the review step.

Review

Once the developer believes the defect to be fixed, he/she will assign a reviewer for the changes. The developer does not marked as fixed at this step. The reviewer is normally another ICU developer with some familiarity with the area of the code involved.

The reviewer will look over the changes. If all appears to be OK, the defect will be resolved as "fixed" in the database. If there are questions, the reviewer will directly contact the developer to resolve them.

Ticket Components