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?


Rob,

I don't think anything in my suggestion is inconsistent with having an
early discussion of concerns or objections. 

I do think we may have a different understanding of the CSD stages.

When you say:


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

Whether intended or not, I hear CSD02 as being the limiting factor on
CSD04.

Yes?

>From my perspective, the following would be permissible (although not
required):

CSD01 - Proposal for integrated styles accepted and integrated

CSD02 - Proposal for Japanese table model accepted and integrated

CSD03 - Proposal for change tracking accepted and integrated

CSD04 - Corrections/changes to proposals from CSD01-03 plus whatever new
features are accepted and incorporated in CSD04, which then proceeds to
become an OASIS standard.

Such that any feature, assuming it was accepted and then
specified/accepted, would never be more than 6 months away from
incorporation into an ODF CSD. 

Is that your understanding? 

Hope you are at the start of a great weekend!

Patrick


On Fri, 2011-01-14 at 12:03 -0500, robert_weir@us.ibm.com wrote:
> 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 
> Note....
> 
> 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?
> 
> -Rob
> 
> > 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 
> > 
> 
> 
> ---------------------------------------------------------------------
> 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]