[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] ODF-Next - grouping issues?
robert_weir@us.ibm.com wrote: > 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. The problem with this approach is that we don't have any idea right now how long the individual proposals may take. So, it is difficult if not impossible to plan when these drafts should be ready. >> >> 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. This is more what I'm thinking of. But we should also agree in advance when the CSDs shall be ready. I further would like to keep the options to also have a public review for CSD01 and CSD02. > > 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. I agree. Michael > > -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 > >> > > > --------------------------------------------------------------------- > 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 > -- Michael Brauer | Oracle Office Development Phone: +49 40 23646 500 Oracle Office GBU ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]