There are four kinds of defect comments, based on how we treat them:
1) Comments received during public review periods -- for these, we are
obligated under OASIS rules to process the comments, and note our
resolutions on our mailing list, before the draft can be approved. Where
the comment is reporting a defect in the standard we will typically make
the change in the draft and send it for further review. No need for
errata, no need for rationale. We just change the text directly, since it
is still a draft. Since the text is still a draft, we are free, if we
wish, to fix other defects uncovered while fixing the reported ones.
2) Comments received the public on an approved ODF standard -- for these
we have no obligations under OASIS rules. However, the TC has agreed to
process and log all public comments in a spreadsheet, and to process them.
Our options for any defect are: a) Include a fix in one or more errata
documents, b) Fix only in ODF 1.2, c) Refer to the ODF-Next Requirements
SC, or d) Do nothing. Since ODF 1.0 has been widely translated I would
like to avoid making widespread changes to the text. However, technical
errors can and should be addressed via errata.
3) Comments received via TC members. Similar to #2. If it is an
editorial error, then I'd recommend fixing it in ODF 1.2 only. If it is a
technical defect, then raise it to the list as an item for an errata
document. We probably need some mechanism for tracking these, to ensure
they don't get lost. We could use the same mechanism as #2 to track them?
Or maybe we can have a wiki page for member-submitted defect reports?
Whatever we do, we need a tight loop between the reported of the defect
and Patrick.
4) Formal defect reports from JTC1/SC34. This is really the turd on our
plate right now. It is striding two different processes and really
doesn't follow the rules correctly for either one of them. The best thing
we can do is to get it off our plate ASAP. This means an ODF 1.0 approved
errata document that addresses the SC34 defect report, and only items in
that defect report. (The JTC1 process assumes that their corrigenda
documents contain only fixes to defects that JTC1 reported). We'll have
an opportunity to issue additional ODF 1.0 errata documents to address
additional comments in the future, so nothing is lost. However, we
committed to responding to the SC34 defect report, and we're already quite
late on that. So I'd ask for the TC to help us get through this process.
I'm hoping that #4 is a one-time thing, and we can treat any future
occurrences the same as #2. As it is, I have some discomfort in that we
are addressing the JTC1 defect report, out of turn, even though they are
almost entirely trivial editorial comments, while we have stepped over (in
chronological order) other public comments, some of which indicate more
credible defects and ambiguities. This is not fair to the submittors, is
not good PR for the TC and leads to a poorer errata report than if we had
triaged all of the comments. But since we committed to delivering #4, and
Murata-san is expecting it and indeed widely complaining about it, let's
finish the job and get it off our plate. But we should commit ourselves
to taking a broader view of errata for the next ODF 1.0 errata document.
Regards,
-Rob
"Dennis E. Hamilton"