Re: [office] ODF-Next - grouping issues?

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 01/14/2011 02:30:38 PM:

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

I was thinking more like this

CSD01: Integrate fixed from any ODF 1.2 Errata generated from ISO review 
of ODF 1.2.  Also any other work that is "ready to go" early.

CSD02: Whatever other features are ready at this point

CSD03: Last call for new features. This CSD is "feature complete" and goes 
out for public review.

CSD04: No new features.  Just address issues raised in review.  It is a 
final editing release.  This is the version we hope will become the 
Committee Specification.

I think the main difference is I'd like to avoid introducing new features 
in the last CSD. 

I'm not strongly opposed to alternative approaches, but I do see clear 
liabilities with introducing last minute features into the final CSD.  I'd 
rather just insert a new CSD at that point, if we find it necessary to add 
a significant new feature.

-Rob


 
> 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 

> > 
> 
>