[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/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 > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]