Contents

1. 1 Assigners
2. 2 Assignees
3. 3 Reviewers
4. 4 Releasers
5. 5 Start of Release

Assigners

1. When a bug* is filed, it goes into the incoming folder.
2. The chair or vice-chair assesses the bugs weekly. Straightforward ones are just assigned. Others are moved into the discuss folder for discussion at the meeting.
3. Assigning a person and a release number:
   1. in the confirm folder: the assignee is to verify the fix and/or flesh out the implementation (eg the precise XML), then move back to discuss for authorization to do the bug in the release.
   2. outside of the confirm folder: the assignee is to do the bug in the release.
4. Assigning a person but no release, means it is for a future release, to be prioritized later (see below).
5. Assigning to the future folder means it is for future discussion (at the start of the next release).
6. During the meeting, any discuss items are assessed and assigned.
7. Bugs that we will not do are put in the returned folder, with a note explaining why not.
8. If a bug has multiple owners, the Notes must describe who is doing what. Otherwise it needs to be split into multiple bugs.

Assignees

1. One place to start: http://www.unicode.org/cldr/bugs-private/locale-bugs-private
   
2. Assignees periodically review and take care of their bugs. Click on the "Assignee" link, then your name, then "assign [view by target]".
3. Bugs in the confirm folder are not to be fixed: they are to be evaluated and returned to the discuss folder for approval.
4. If the bug is a duplicate, any extra information is copied to the other bug, an xref is set in both, and the bug is returned.
5. If the bug requires separate phases, such as a change to the spec, then a separate bug is filed, with xrefs set in both.
6. If part of a bug cannot be completed in the release, the part that can't is split into a separate bug, a note is added the original, and both have xrefs
7. If during the course of doing the bug, the person runs up against a problem, then the bug is moved back to the discuss folder for discussion at the next meeting. Examples:
   1. The description doesn't work
   2. Another mechanism looks better
   3. It looks like it can't be done in time for the release
8. All changes checked into CVS for the bug use the format "cldrbug XXX: <description>", where XXX is the bug number.
9. Once the bug is fixed, it is assigned a reviewer.
10. The assignee sends a message to the reviewer if the review should be done soon.

Reviewers

1. The reviewer uses the review page to look at bugs to review. Click on the "Reviewer" link, then your name, then "assign [view by target]".
   1. If the reviewer doesn't have internal access to jitterbug, then he/she asks someone to send the list.
2. Open each bug for review.
3. Clicking on "CVS diffs" brings up a diff page, where the changes for the bug are shown.
4. The reviewer needs to look at the Notes and Replies, 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 bugs, the goal is to verify that the data in the bug report matches what is entered in.
6. If any issues come up or the topic needs review, the bug is moved to the discuss folder.
7. If the implementation looks good, the bug is moved to the fixed folder.
   1. If the reviewer doesn't have internal access to jitterbug, then he/she sends a message to the bug assignee to do that.

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 bugs in the fixed folder are moved to closed.

Start of Release

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

 * bug means either a defect that needs to be fixed, or a feature request to be implemented.