Post-mortem on Unicode 4.0 UTC review

February, 2003

Sandra Martin O'Donnell, HP
Michael Kaplan, Microsoft/Trigeminal Software
Lynn Ruggles, HP
Cathy Wissink, Microsoft


Prior to the November, 2003 UTC meeting, several consortium members provided feedback on the draft chapters for The Unicode Standard, V4.0. The reaction to that feedback during the November meeting uncovered what we believe are some significant problems in the review process. In this paper, we propose some changes to improve the ability of members to have their comments considered, and to lessen the load on Editorial Committee (EC) members as they try to deal with the volume of feedback

The Issues

In early October, 2002, draft versions of Chapters 1-4 of Unicode V4.0 were announced on unicore, and members were asked to provide review comments prior to the November, 2002 UTC meeting.  Comments received before then would be reviewed at the UTC itself.

HP and Microsoft both submitted extensive comments, and we expected to discuss these during the UTC. Our comments ran the gamut from significant technical issues to small editorial corrections. We expected to spend the most time in committee on the technical issues, and that minor editorial
corrections would be remanded to the EC.

However, as the discussions began during the meeting, we were quite surprised to be told that it was "too late" to make any substantive technical changes, and that there was no process for learning how  "editorial" changes would be dealt with. We believe this is not acceptable.

We do understand that there are core conformance issues that need to be addressed long-term in order to rectify some of our concerns. In addition, we now recognize that some review comments represented technical problems that required UTC action, which meant they could not be addressed before the end of the review.

We also understand that the EC consists of volunteers and that the job of putting together a book like TUS is enormous. Small changes accepted for one part of the text can ripple through the book in unpredictable ways, and finding and updating text appropriately is extremely time-consuming.
However, much time gathering and compiling feedback within our respective companies could have been saved had there been a clear feedback process with a set of criteria in place. In the absence of that process and criteria, member companies were asked for feedback, and we submitted it within the requested timeframe. We therefore felt it was logical to assume our comments would be dealt with, and logical to assume there would be some way to find out how our comments had been handled. Unfortunately, that didn't happen.


In order to improve the review process, we propose the following:
  • Lengthen the review cycle to include enough time for members' technical comments to be received, considered, and (potentially) incorporated.
  • Create clear definitions of what constitutes an editorial comment vs. a comment that requires UTC action.
  •  Choose among several options to allow reviewers to determine how, or if, editorial comments have been incorporated into the text.

  • Details of each follow.

    1.  Lengthen the review cycle to include enough time for members' technical comments to be received, considered, and (potentially) incorporated. This means draft chapters must be available earlier in a V*.0 development cycle, or that smaller sections of particularly crucial chapters must be available earlier. The most substantive debates tend to be around the conformance clauses and definitions (both Ch. 3), the Unicode design principles (Ch. 2), so we recommend that drafts of these sections be among the first released for general review.

    We are not sure how much time the EC needs to incorporate changes that would result from an earlier review. The November, 2002 UTC was four months before the planned completion (March, 2003) of the
    V4.0 text, and the drafts were available in early October, 2002. Since that obviously was not long enough, we recommend that drafts of crucial sections be available at least seven months before expected completion, but we are open to input from the EC on how long it thinks would be appropriate.

    If the review cycle realistically reflects the time and effort needed to produce a new version of the book, we will avoid having to ignore input because we have promised to complete our next version by a previously announced date. For V4.0, meeting the date seems to have had the highest priority.

    While lengthening the review cycle would make it possible for members' input to be debated and incorporated, it also should help the EC avoid part of the last-minute crunch that is a feature of nearly all development cycles.

    2.  Create clear definitions of what constitutes an editorial comment vs. a comment that requires UTC action. That is still not clear (and it does need a conformance model in place, which is in progress), but having at least a general idea of these two distinctions would have saved us a lot of pain in at the November UTC.

    3.  Choose among several options to allow reviewers to determine how, or if, editorial comments have been incorporated into the text. During the November UTC, the only option identified for learning of the fate of such comments was to join the EC. Many of us cannot make the time committment necessary to join that committee, and it seems incorrect to us that Consortium members can only find out about such changes if they join this very time-consuming committee.

    Other standards groups and consortia produce documents that describe how or if comments have been accepted. These "Disposition of Comments" documents (DoC) are valuable resources. We recommend that something similar be available for TUS drafts as well. To minimize the impact on the EC, we recommend that such documents only be produced for formal member comments submitted as L2 documents. This is as opposed to random comments that individuals make on either the unicore or unicode mailing lists. While EC members may choose to respond formally to such comments, that is not required.

    Another possibility is to create a group of reviewers that volunteers to review text from the EC before it goes out to the UTC for final review. Volunteers would need to satisfy a minimum set of criteria (UTC involvement, industry expert, etc.), but these people would agree to give feedback to the EC as they got text and within a specified timeframe. This would have the advantage of having people who aren't so close to the text review it for understandability issues, and also flag potential problems that might
    need a UTC decision.

    Still another possibility is for the Consortium to hire additional staff to process member comments, produce DoC's, and incorporate agreed-upon changes into the text. The standard's growth has strained the capabilities of its mostly-volunteer membership to keep up with the current workload.

    While these recommendations are meant to help improve the process and aid chronically-busy EC members, we recognize that the EC may have different ideas about what would help. Therefore, we invite their suggestions on what member representatives can do to help with this task. As members, we want to help, even if we are unable to commit to joining the EC.


    We appreciate the work the EC does in producing the text of The Unicode Standard. This is an extremely complex task, and one that becomes more complex as Unicode's character repertoire and the spectrum of information in the book grows. However, the standard's growth makes it increasingly important that member companies continue reviewing the evolving text -- and that our voices can be heard.