OASIS Open Document Format for Office Applications (OpenDocument) TC

Hello

I've been looking through the current status of issues targeted for
ODF-Next.  These being jira issues with a fix-for-version set as
ODF-Next.

http://tools.oasis-open.org/issues/browse/OFFICE/fixforversion/10019

There are 213 such issues currently, of which 92 have not been
categorized ie. not assigned to a component.  I think the first
priority is to work through these and get them classified.  Do people
agree?  I tried doing this today but there is some problem with my
jira login which I'm still trying to resolve :-(.  I really hope I can
solve it soon.  Of course the 92 only represent those issues which are
currently tagged odf-next.  That number will surely grow as more
issues get relegated into this zone.

Following that we need to determine how best to convert all of this
into an ordered plan of action.  I'd welcome some discussion on how
best to proceed with this.  I'm thinking the best approach would be to
go through category by category and try and summarize themes, related
issues, major upheavals vs minor edits etc.

Regards
Bob

cc'ing the main list, at least initially, and reminding everyone there 
that we're starting up the ODF-Next discussion on the Requirements 
subcommittee list.  Join if you want to participate.

So my big question is what do we want to do in ODF-Next.  Since that is 
too big a question to answer outright, I think that leads to the question, 
how do we determine what ODF-Next will be? 

It seems we can do a bottom-up approach, where we look at deferred feature 
requests and public comments, and build a plan around that.

And another approach is top-down, where we articulate a broad vision and 
then fill in the details, including where appropriate deferred features.

Or you could do a mix of both approaches.

But I think we probably should agree on the general parameters of what 
ODF-Next is.

For example, one set of parameters might be: 

"ODF-Next is an incremental revision of the standard, intended to be 
backwards compatible  and with a target to publish within 18 months,"

Another vision might be:

"ODF-Next is a purification and modularization of the existing 
capabilities of ODF, with the intent to make it a more flexible framework 
for future innovation"

And so on.

I think that is something we need to come to agreement on sooner rather 
than later.  Is "ODF-Next" something small, incremental and backwards 
compatible?  Or is there something bolder we want to do?


-Rob

Bob Jolliffe 

Mmz, what about releasing a ODF 1.2.1 / 1.3 first, focusing on change tracking ?

Best regards

Bart

________________________________________
From: robert_weir@us.ibm.com [robert_weir@us.ibm.com]
Sent: Friday, July 16, 2010 8:42 PM
To: Bob Jolliffe
Cc: office-requirements@lists.oasis-open.org; office@lists.oasis-open.org
Subject: [office] Re: [office-requirements] Current status

cc'ing the main list, at least initially, and reminding everyone there
that we're starting up the ODF-Next discussion on the Requirements
subcommittee list.  Join if you want to participate.

So my big question is what do we want to do in ODF-Next.  Since that is
too big a question to answer outright, I think that leads to the question,
how do we determine what ODF-Next will be?

It seems we can do a bottom-up approach, where we look at deferred feature
requests and public comments, and build a plan around that.

And another approach is top-down, where we articulate a broad vision and
then fill in the details, including where appropriate deferred features.

Or you could do a mix of both approaches.

But I think we probably should agree on the general parameters of what
ODF-Next is.

For example, one set of parameters might be:

"ODF-Next is an incremental revision of the standard, intended to be
backwards compatible  and with a target to publish within 18 months,"

Another vision might be:

"ODF-Next is a purification and modularization of the existing
capabilities of ODF, with the intent to make it a more flexible framework
for future innovation"

And so on.

I think that is something we need to come to agreement on sooner rather
than later.  Is "ODF-Next" something small, incremental and backwards
compatible?  Or is there something bolder we want to do?


-Rob

Bob Jolliffe 

Anything is possible.  In the end the TC decides based on its votes.  I'm 
more interested right now in figuring out how we can converge on a shared 
vision without too much bloodshed.

One approach would be to have another call for proposals period.  We did a 
public one before.  And we collected member submissions before.  But the 
TC membership is different than it was back in 2008, so we should probably 
solicit for proposals again.

So first, thing, have another call for proposals.  Maybe this can be done 
in conjunction with a public review of the ODF-Next paper?  In any case, 
get all of these proposals in JIRA, categorized as ODF-Next.

Then, have some sort of voting procedure.  For example, give each TC 
member 20 "points" which they can allocate across any of the proposals. 
They could give 20 different proposals 1 point each, or 1 proposal 20 
points.  Anything that adds up to 20.  Well, maybe not anything.  Giving 
-1000 votes to one proposal and 1020 to another would not be good!

At the same time, ask for volunteers to own the specification of any 
particular feature.

We then agree to work on the proposals which have the highest number of 
points and which have a volunteer. 

-Rob


Hanssens Bart 

Hi

On 16 July 2010 21:02,  

Hi

On 16 July 2010 21:02,  

Bob Jolliffe 

Rob

> 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.

Not sure if this helps or actually makes things worse, but do we have an idea of which
of the requested features are:

- already implemented in an implementation-specific way 
- relatively easy to implement (depends on code base of course, but if a few
companies would indicate that X is hard to implement but Y is piece of cake...)


Best regards

Bart

Bob Jolliffe 

cc'ing the main list, at least initially, and reminding everyone there 
that we're starting up the ODF-Next discussion on the Requirements 
subcommittee list.  Join if you want to participate.

So my big question is what do we want to do in ODF-Next.  Since that is 
too big a question to answer outright, I think that leads to the question, 
how do we determine what ODF-Next will be? 

It seems we can do a bottom-up approach, where we look at deferred feature 
requests and public comments, and build a plan around that.

And another approach is top-down, where we articulate a broad vision and 
then fill in the details, including where appropriate deferred features.

Or you could do a mix of both approaches.

But I think we probably should agree on the general parameters of what 
ODF-Next is.

For example, one set of parameters might be: 

"ODF-Next is an incremental revision of the standard, intended to be 
backwards compatible  and with a target to publish within 18 months,"

Another vision might be:

"ODF-Next is a purification and modularization of the existing 
capabilities of ODF, with the intent to make it a more flexible framework 
for future innovation"

And so on.

I think that is something we need to come to agreement on sooner rather 
than later.  Is "ODF-Next" something small, incremental and backwards 
compatible?  Or is there something bolder we want to do?


-Rob

Bob Jolliffe