Greetings! Just a few lines (hopefully) to address some of Chet's questions but probably not all. One of the primary defects of the current TC process (and yes, I was there when many parts of it were written and/or approved) is that review is *back loaded* both in the present process as well as Jacques proposal. That is a TC may work for months or years and quite naturally doesn't put forth what it thinks is a highly defective bit of work, only to find that others disagree. The impression, of the TC, is that its progress is suddenly being delayed, by problems it did not spot. That's not a criticism of the TCs, it's quite human and understandable. However, it doesn't result in high quality work because there is an artificial window for public comments and as I noted, it is loaded on the back end, when a TC is *least* likely to make improvements. Just bad design and as I said, I was part and parcel of it. Consider a slightly expanded continuous public review model: 1) Unlike the present model, there is no "approved" working draft which triggers the 3 formats for posting. TCs issue working drafts as they wish, with the suggestion/limit that it be no more often than once a week. 2) I would not use Github to incorporate edits or diff between version but as a repository for each new "draft" against which issues could be filed. 3) The use of Github would enable the tracking of issues against every issued draft and rolling those up for summaries of all the issues addressed. 4) All comments, including those of the TC Admin are posted as issues in Github and answers to the TC Admin comments must be accepted by the TC Admin before a last call public review draft issues. 5) The last call public review is in the 3 standard formats, has correct naming, etc. and obeys other quality rules. We can re-write the approved machinery to apply only to the last call public review drafts. Instead of being pulled up short once there is momentum towards a Committee Specification and often an OASIS Standard, the TC has both the time and opportunity to incorporate (or not) feedback as part of the authoring process. In sum, continuous public review presents new (and old) TCs with what looks like and indeed is an "agile" process, not one that is falsely labeled as "agile," but is in fact the replication of a back end loaded review process that offers little opportunity for reviewers and even less for a TC to make material improvements before seeking approval of their work. I am a creature of the present process but almost a decade of little use of comments has convinced me that serious changes to it are necessary. It is just a happy coincidence that we are trying to attract people for whom public and incremental revision are values (thinking of the agile community). Hope everyone is having a great day! Patrick -- Patrick Durusau
patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog):
http://tm.durusau.net Homepage:
http://www.durusau.net Twitter: patrickDurusau Attachment: signature.asc Description: OpenPGP digital signature