Handling Tickets (bugs/enhancements)

Filing tickets

  1. You can add set other fields, but don't change the Owner. That way the committee sees the incoming tickets (those marked as Owner: somebody).
  2. If you really have to fix a bug right away, file it and send a notice to cldr-dev explaining what you are doing and why. Otherwise, file the bug, wait for the next Wednesday meeting for discussion and approval.
  3. The latest ticket workflow should be listed at CldrWorkflow on the trac server, and is pictured below.
  4. http://unicode.org/cldr/trac/wiki/CldrWorkflow


  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.


  1. Assignees periodically review and take care of their tickets.
    1. Go to http://unicode.org/cldr/trac/report/61 for My Tickets
  2. design: You must go back to the committee with the completed design before checking anything in. For example, if the ticket doesn't describe an exact DTD structure, then add the proposed structure to the ticket in a comment, and send an email to the committee asking whether anyone objects. 
  3. assess: Tickets marked "assess" need to be evaluated for priority (or whether to do them at all). Send your suggested disposition to the cldr group by email.
  4. 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.
  5. 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.
  6. 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

DTD Changes

  • If you are making any DTD changes, please follow the instructions on Updating DTDs.


  • Add unit tests for changes you make, then
  • Make sure to run the tests in Running Tests!

Skipping test failures

If there is a test failure that is due to a bug that cannot be fixed right now (eg it requires a data change, but it is past the data freeze), then use the logKnownIssue() method to disable the test. See http://site.icu-project.org/setup/eclipse/time for details, and look in the CLDR test code for some examples of usage.

Survey Tool in Production Phase!

  1. Before you make a commit, add a line to the Issues spreadsheet below (Spreadsheet View), 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.
Once the statuses are all READY, anyone can push to production:
  1. Make sure the statuses are all PUSHED or READY and that the "Last Built Rev" isn't later than any items on the list
    1. If there are any untested commits, double check the timeline and make sure something isn't slipping in!
  2. Check http://unicode.org/cldr/trac/timeline?changeset=on&build=on&daysback=8 to verify that no changes "slipped in"
  3. Add a line PUSHING
  4. Push to production
  5. If there were noticeable changes, put them in http://cldr.unicode.org/index/survey-tool#TOC-Latest-Updates (move the old items up to Tool Updates).
  6. If it was a Known Bug, remove from https://sites.google.com/site/cldr/index/survey-tool/known-bugs.
  7. Change status of all READY and PUSHING items to PUSHED.
  8. You can delete some older items that are no longer relevant.
  9. If the spreadsheet data seems stale, switch to the BuildsCheckins tab, and increment the 'to update' cell. [ If anyone knows a better way to structure the spreadsheet, please feel free.. -srl]


  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.


If you accidentally check something in with the wrong ticket number...

  1. Add a comment to the ticket you checked in against describing the misticketed commits.
  2. Navigate to the wiki page http://unicode.org/cldr/trac/wiki/MisTicketed
  3. Click "Edit This Page" (logging in first if needed)
  4. Add your new line immediately after the first line in the page. (other example lines shown for context)

    (In the example below, revision 6658 was checked in under ticket 6636, but should have been under 4453.)

                         ||r6658||ticket:6636||ticket:4453||This is a comment||

    ||r6973||||ticket:4594||already fixed, just needs cache update||
  5. Click "Submit Changes"
  6. Send an email to the cldr-dev list with notification that you have changed the Misticketed page.


  1. On "Available Reports", click on My Reviews
  2. For each of your tickets to review, open it and do the following:
  3. First read the description and comments/replies in the original ticket, since they may contain changes or additions, and also sometimes alert you to changes not captured by the diff tool.
  4. In the top right, under View Tickets, you'll see "Review <x> commits." Click on that to see the changed files. (Often best to to see side-by-side, with right-click > open in new window.)
    1. In the Changes column, click on each of the items (eg, edit) in each of the cells, and make sure that the implementation matches the description.
    2. For data tickets, the goal is to verify that the data in the ticket matches what is entered in.
    3. For spec tickets, it is often easier to go to the Modifications section of the latest proposed spec update, search for the modifications entry with the ticket number for the change that you are reviewing, and then click in that entry’s link to the relevant portion of the spec. The modifications in that section will be shown in yellow, and that is what you need to review.
  5. Once you are done, go back to the original ticket (you can click on it at the top), and hit "Modify Ticket" near the bottom.
    1. If the implementation looks good:
      • click "REVIEWER: Close as fixed", then 
      • click "Submit changes"
    2. If any problems are found
      • add a comment to original ticket describing the problems you found
      • click "back to owner"
      • click "Submit changes"
      • if time is short (near the end of the release), send an email to the owner also.
    3. Hit "Submit changes"
  6. If any issues come up or the topic needs general review, send a message to the cldr@unicode.org list.


  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.

Subpages (1): Design Proposals