OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]