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] ODF-Next - grouping issues?

Patrick Durusau <patrick@durusau.net> wrote on 01/13/2011 07:43:30 PM:
> Greetings!
> I took a few minutes today to scroll down the list of ODF-Next issues
> and must say it is an impressive list!
> Given the train schedule that seems to be under popular discussion -
> approx. 6 months, let me suggest a means of making a cut at the issues
> that will be resolved for the next version of ODF:

I'd start with one additional suggestion.  If a member has something that 
they want to see in ODF-Next that is not already in JIRA, then please go 
ahead and enter it now.  No need for a complete technical proposal at this 
point, but write up enough so that other TC members know what you are 
talking about.

I'd also recommend that members who have an interest in a particular 
issue, to declare that now by assigning the issue to themselves.

> At the start of each month, generate a list of issues that have
> completed proposals for incorporation. 

Developing a "complete proposal", ready for integration into the draft, 
for a substantial feature, can be a large investment of time.  I would not 
want to do all that work and then have a TC member object to the feature 
overall, not just the details.  So I think we need some way for a member 
to give a brief outline of a proposal, and get a sense of whether further 
efforts in this area will be well received or not. 

Note specifically that I am concerned with any approach where we all, in 
an uncoordinated way, simply add features of interest to our 
implementations, without regard for interoperability, redundancy, easy of 
implementation, wider applicability, backwards compatibility, etc.  Since 
I would likely oppose feature proposals that had liabilities like these, I 
think it behooves us to have some way to understand these types of 
objections early, before members have invested a lot of time in a 
proposal.  In many cases, discussing these concerns early can lead to a 
better solution overall, with less effort.

> Some of those, after the first month, will have been incorporated in the
> next draft so that will be a measure of our progress.
> The issues that have not been incorporated, due to lack of agreement on
> the proposals or other changes needed in the proposals, become the first
> priority for the TC in the following month.
> Issues that don't have proposals are just that, issues that don't have
> proposals. 
> Nothing prevents any TC member or even a member of the public from
> contributing a proposal but the existence of a proposal should be the
> starting point for further TC action. 

I generally like the idea, but I think we may need a two-stage approval 
process:  1) agreeing that we want to address a particular functional 
area, and 2) agreeing to a specific specification proposal that addresses 
that functional area.

> I think such a process would keep us focused on issues that have a
> substantial likelihood of appearing in the next version and make it
> clear to anyone who cares about an issue, that caring isn't enough. A
> "fully formulated proposal" is required for the issue to progress.
> BTW, "fully formulated proposal" means all the required text/edits have
> been specified along, optionally, whatever arguments you wish to make.
> (It helps if you specify needed formatting.)
> In other words, saying: "you need a better table model," as a proposal
> gets a shrug and we move onto the next issue. I happen to think that is
> true but such a "proposal" could not be usefully evaluated by the TC. 

In my model, I'd give the example as:

1) I propose, "we need a better table model, specifically Japanese 'kite' 
diagonally split table headers, similar to that described in the W3C 

That proposal then gets discussed and aa vote up or down.

2) If the feature proposal is approved, then a member needs to develop the 
"full formulated proposal", with all the edit changes, etc.  That then 
gets voted up or down.

We probably want to set deadlines for each of these actions to be 
completed by.  Maybe the goal is for CSD02 to be feature complete, and go 
out for public review, and CSD 04 is only corrective?


> Hope everyone is having a great day!
> Patrick
> PS: Don't forget to vote on CD07!
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> 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
> Newcomb Number: 1
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

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