Sandra Martin O'Donnell, HP
Michael Kaplan, Microsoft/Trigeminal Software
Lynn Ruggles, HP
Cathy Wissink, Microsoft
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.
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.