[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-requirements] RE: [office] Re: [office-requirements] Currentstatus
Bob Jolliffe <bobjolliffe@gmail.com> wrote on 07/19/2010 07:48:04 AM: > > So I would suggest that > (i) we complete the current process of categorizing current odf-net > jira issues into thematic areas. > (ii) we have a roadmap discussion where we can identify some > milestones of subsequent odf versions. This might best be done in a > teleconference which could be done under the auspices of odf-next SC. > Will it be 1.3, 2.0 or do we converge to the square root of 1.5: > 1.224744871... :-) > (iii) we start pegging the issues from (i) to the proposed versions of > (ii). This process could well proceed using the mechanism Rob has > suggested. > It is interesting to consider a strategy of simultaneously working on two versions of ODF: A) A backwards-compatible, maintenance of ODF 1.2, doing errata, of course, but also any urgent feature work that can be done in a backwards-compatible way. B)A more substantial perhaps release which would have some larger features added. This approach has been attempted before with other standards and there are some traps to avoid: 1) The visionary release takes so long to create that market forces push more and more new features into the maintenance version and the visionary release can't keep up. 2) The visionary release is too much for vendors to implement, and they don't adopt it, instead sticking at on the maintenance release. This in turn can feed back into #1 above. 3) The visionary release introduces compatibility problems that lead to #2 above. 4) The announcement of a visionary release causes adopters to pause and wait to see what happens before adopting the standard. In other words, it increases the perceived risk of adoption. There may be other such risks. Interesting to look at examples like XML 1.1 that never quite made it. Of course, these are risks, not absolute certainties. There are things we could do to make this work. For example, the visionary release could include a modularization effort that allows us to better formula an ODF/A for archiving, for example, which would be more suitable for long-term document retention than ODF 1.2 or ODF-Next by itself. And if we're careful about only adding features where we have several vendors committed to implementing, then we avoid some of the other risks. In any case, I like your idea of continuing to categorize the ODF-Next issues in JIRA. Is there anything I can do on the admin side to make this easier? For example, are their any "components" that we could add to JIRA that would make classification into thematic areas easier? Or any conventions we should adopt? Do we need to agree on what the themes are? -Rob
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]