OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] A few thoughts on ODF change tracking

Patrick Durusau <patrick@durusau.net> wrote on 09/21/2010 04:19:20 PM:
> > It is a non-goal for me to make everyone happy.  It is clear that for 
> > every person who will say, "Why did you approve ODF 1.2 without X?" 
> > is another person already asking, "Why is taking you so long to 
> > ODF 1.2 so we can have Y?"
> > 
> > 
> True, but "we don't have to please everyone" isn't a mantra that is
> going to win many friends. 
> Maybe what we do in practice but better to appear gracious and
> interested in feature requests. 

I certainly am appreciative of feature requests, especially ones like the 
change tracking proposal that came with substantial detail.  But I'm even 
more appreciative of feature requests that arrived before the agreed upon 
deadline for new features in ODF 1.2, a date that was over a year ago.

Note that it is not that I am not interested in new proposals.  It is only 
that I am not interested in new proposals for this release, since new 
proposals at this point can only be considered if we delay the approval 
and publication of the enhancements and improvements we have already made 
to ODF, items that also have their own constituencies clamoring for them. 
So new proposals at this point, naturally end up being deferred to the 
next release. 

If you, or anyone else, has a counter-proposal, I'm all ears.

As for not pleasing everyone, the OASIS rules are quite clear.  The 
highest level of approval we need is to get the Committee Specification 
approved.  That requires 2/3 approval with no more than 25% disapproving. 
Higher approval is better, but adding new features doesn't automatically 
increase your numbers.  For example, I'm likely to automatically vote 
against any proposal to add new features at this late stage that do not 
already have two or more interoperable implementations from TC members. So 
I think it is clear that you cannot make everyone happy. 

> And having a future schedule when features will appear would not be a
> bad thing. 

All JIRA issues have a "due date" field that JIRA editors can set.  So 
anyone is welcome to adopt a feature in ODF-Next, assign it to themselves 
and set the due date.

I'm hoping we set more of a regular schedule for the next release and the 
exactly features that go into that release will depend on TC member's 
interests and priorities.  Taking ownership of an issue and committing to 
a due date are ways of expressing interest and priority.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]