It is good to see ODF 1.2 Part 1 is now out for public review, according to the OASIS Public Announce Lists. The review is 60 days, ending 26 March 2010. There is a web form.
How do you make useful comments on a draft standard?
- For a start, be specific. Don't abuse the ODF TC's time by failing to include specifics like page or section numbers, and if possible suggest the actual improvement you think would be better.
- Understand the scope. Every standard has a scope and a reason for existing: comments that stray too far away from them may seem pretty much a waste of everyone's time. In particular, because there is an OASIS effort already under way to make the next generation of ODF (ODF NG), you would expect that comments that don't relate to the current feature set of ODF 1.2 would be shipped on to that effort. (Which is not to say that such comments are necessarily not useful. And sometimes, but rarely, new features do get added as a result of a review.)
- Be systematic. You don't need to be an expert in areas that you are not interested in, but these processes work because you know something and you check for that, and I know something else and I check for that. For example, if you are an expert in spreadsheets, review the spreadsheet sections.
- Be self-interested, but not partisan. Your requirements matter, and no-one can tell you that your requirements are bogus. So make sure the standard works for you. And the corollary of that is that if someone else has different requirements, don't try to shout them down. And if you don't intend to use ODF, don't get in its way. For example, if you are blind, review the standard for its accessibility.
- Be co-operative. Reviewing a draft is not a political process but a technical one. So there is little reason for people to duplicate each other's work. Instead, it can be useful to concentrate on areas that you may expect may get lighter review: for example, probably there would be little need to run the standard through a spell-checker.
- Be as precise as necessary, but not too precise. Lax phrasing of a standard can cause interoperability problems; however, there sometimes needs to be a little give or underspecification, especially where implementations of a draft feature are not mature. (For example, this comes up in schemas, where most schemas are written so that elements are only either required or optional: whereas in real life they may be part of some feature set or profile, or possibly deprecated, or possibly ignorable.)
- Be respectful. This is the one I have difficulty with, when it is people I know: I tend to use more sardonic language trusting that the recipients will appreciate plain speaking. But it is a miserable mode of communication for talking with strangers. Standard groups rarely have pathological self-justifiers who take every technical comment as a threat or insult, but very often committees will have discussed the very issue you have raised already.
- Be persistent. Just because a committee decides against something for this version, it does not mean that the idea will necessarily be rejected next time. You may have to make your case for a certain feature or approach over time. For example, you may think there are large gaps in internationalization for East Asian documents (as OOXML has too).
- Don't fight the same battle after it is lost. If the committee rejects a decision this time, don't go back to the same issue in the next week. Wait till next version.
ODF 1.0 took about 2.5 years from start to finish. ODF 1.1 took about 1.5 years. ODF 1.2 looks like taking about 3.5 years, if I count correctly. So I would not count on any new features becoming part of ODF (1.3 or 2.0 or whatever) until late 2012 at the minimum, unless they come up with some way to make the process less coupled and more agile.