Contents

1. 1 Filing tickets
2. 2 Assigners
3. 3 Assignees
4. 4 SmokeTest
5. 5 Checkin
6. 6 Reviewers
7. 7 Releasers
8. 8 Start of Release

Filing tickets

Assigners

1. The committee assesses the tickets weekly.
1. Straightforward ones are just assigned and prioritized and given a milestone.
2. Questionable ones are assigned, but left with priority=assess. The assignee will report back before doing anything.
3. More complicated ones are moved into the design folder for later discussion at the meeting.
4. Don't fix a bug until it's been approved.
2. If a ticket has multiple owners, the Notes must describe who is doing what. Otherwise it needs to be split into multiple tickets.

Assignees

1. Assignees periodically review and take care of their tickets.
   1. Go to http://unicode.org/cldr/trac/report/14 for My Tickets
2. assess: Tickets marked "assess" need to be evaluated. Send your suggested disposition to the cldr group by email.
3. duplicate: If the ticket is a duplicate, any extra information is copied to the other ticket, an xref is set in both, and the ticket is returned.
4. splitting:
   1. If the ticket requires separate phases, such as a change to the spec, then a separate ticket is filed, with xrefs set in both.
   2. If part of a ticket cannot be completed in the release:
   1. Set the milestone to the release number
   2. Add a comment indicating what part of the ticket was done, and what part wasn't.
   3. Set a reviewer.
   4. Create a new ticket for the remaining work, with an xref to the old bug.
5. problems:
   1. If the ticket can't be done due to lack of time, or is being downgraded in priority from major or above to below major, send an email to the cldr group.
   2. If during the course of doing the ticket, the person runs up against a problem, then send a message to the cldr group. Examples:
• The description doesn't work
• Another mechanism looks better

SmokeTest

(while ST is live)

1. Before you make a commit, add a line to the Issues spreadsheet below, with status OPEN, bug number, short desc.
• Don't do this if there is a status=PUSHING
2. When you're ready for checking, add the commit number to your line, send a message to a designee (cc cldr-dev) and change the status to CHECK, add testing description (what to check, links if possible).
3. Designee changes status to READY, or communicates problems back to you.

Checkin

1. All changes checked into SVN for the ticket use the format "cldrbug XXX: <description>", where XXX is the ticket number.
2. Don't mark the bug as fixed! Instead,
3. Once the ticket is done, assign a reviewer. 
• Send a message to the reviewer if the review should be done soon.

Reviewers

1. On "Available Reports", click on My Reviews. Open each of your tickets.
2. In the top right, under View Tickets, you'll see "Review <x> commits."
3. Click on "Review" to see the changed files. Follow the instructions at the bottom.
4. The reviewer needs to look at the Notes and Replies in the original ticket, since they may contain changes or additions, and also sometimes alert the reviewer to changes not captured by the diff tool.
5. The reviewer looks through the diff to make sure that the implementation matches the description. If any problems are found, the reviewer contacts the assignee, and they work together until the problems are resolved.
   1. For data tickets, the goal is to verify that the data in the ticket matches what is entered in.
6. If any issues come up or the topic needs review, send a message to the cldr@unicode.org list.
7. If the implementation looks good, resolve as "fixed".
8. Change PUSHING to PUSHED

Releasers

1. All reviewers should be done well before the end of the release, so that any problems can be taken care of.
2. At release time, all the tickets with status "fixed" are changed to "closed".

Start of Release

1. The future folder tickets are moved to the discuss folder
2. Unscheduled tickets (with no release number) are re-evaluated.