[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Procedure question
A worthy question, Paul. The prioritization pass of April/May got the list of most-asked-for 1.1 issues on the docket, as it were. The proposal pass gives the rest of the TC a chance to assess the feasibility, benefits, and cost of each proposal. Each proposal should be developed well enough to understand its feasibility and effort for more complete design. The understanding was that not all the issues would necessarily make it into the final 1.1 lineup if the assessment recommends against inclusion at this time (too much projected design effort, the design or processing is too complicated, not backwards-compatible, and so forth). Proposals that pass this current process are implictly in the 1.1 plan. I realize now that in our TC meetings, we might be trying to develop too deeply at this early stage. As a TC, we need to act managerially--read the bottom line and give each proposal a thumbs up or thumbs down. Use the list to firm up the proposal prior to its assessment, but after it is approved, do the deeper design during the activities projected in the "time required" section of the template. Perhaps we are front -loading some of this discussion ahead of the go/no-go assessment. Anyway... After this stage, our process is less well specified, so I suggest this roadmap: Each passed proposal can go on immediately to design phase per the projected plan. Those proposals we characterized as "low hanging fruit" will be relatively trivial to finish up. I'm more concerned about those proposals that projected *days* of additional work. Complexity is usually indicative of reliability, so I'd ask each leader to track actual effort against the projected effort so that the TC has a rough sense of the reliability of the design that comes back. The outcome of the design phase should be a piece of spec-like documentation that can go into the revised DITA map for 1.1 along with any commensurate DTD/Schema fragments. The editors might need to recommend a template for the teams to follow, and also be planning on where the worked proposals will fit into the 1.0 base. Each team (of 1 or more) will need to come back to the TC with this document for blessing, but that process should be a shoo-in unless there is a need for intervention or consultation on a design point. The first 1.1 Committee Draft will be complete when all the leaves with no fatal issues have been added into the 1.1 DITA map and we have given it at least one internal review. Again, this is how I visualize it working out. I expect some refinements along the way, but I'm starting to see long-term function in the form we've been following. Regards, -- Don Day Chair, OASIS DITA Technical Committee IBM Lead DITA Architect Email: dond@us.ibm.com 11501 Burnet Rd. MS9033E015, Austin TX 78758 Phone: +1 512-838-8550 T/L: +1 512-838-xxxx "Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?" --T.S. Eliot "Paul Prescod" <paul.prescod@bla stradius.com> To <dita@lists.oasis-open.org> 08/02/2005 01:48 cc PM Subject [dita] Procedure question Let’s say that we vote in favour of one of these issue proposals at our meeting. Are we voting in favour of detailed design that will also be separately approved? Or are we voting in favour of actually merging the feature into the DITA 1.1 specification (which will then have a straight up or down vote itself). It isn’t clear to me whether these documents are supposed to be detailed proposals that address all technical details or whether they are just the first pass. Paul Prescod
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]