Meeting Notes: 01-06-2-13

=================================
   MEETING NOTES (01-06-2013)
       DITA Tech Comm SC
=================================

A. DITA 1.3 Specification Take-aways
- - - - - - - - - - - - - - - - - - - - - - - 
We chatted a bit about our experiences during the December end-game for the SC feature proposals.

1. Tom
   - The process in general worked.
   - No process can be predicted 100%; impossible to
     freeze all the variables.
   - That said, it was not entirely clear what all the 
     Stage-3 deliverables consisted of. 

2. Bob 
   - Doing feature proposals with cross-feature 
     dependencies is not fun,
   - There was quite a bit of last-minute discovery 
     involved with doing any medium- or heavy-weight 
     feature.
   - Once the requirements/dependencies around the IBM 
     troubleshooting specialization got ironed out, 
     things moved along more swimmingly.

3. Stan
   - Regardless of what SC members anticipate as the 
     complete set of architectural issues/dependencies, 
     there is almost always another set that becomes 
     visible only when an SC proposal gets up to 
     technical folks on the TC.
   - Feels that the feature approval pipeline has three 
     stages more frequently than two stages:
     > SC submission
     > TC technical architects' review
     > TC general review

B. Brainstorming for 2014 Activities
- - - - - - - - - - - - - - - - - - - - - - - 
What might we consider by way of SC activities in 2014?
1. SC visitors
   Stan suggested that it might be useful to for the SC 
   to host a series of "visiting DITAheads." The goals 
   are:
   - Get feedback from different types of organizations 
     using Tech Comm features about what they are 
     encountering
   - Potentially recruit new SC members / participants
   - Gather feedback on future Tech Comm features or 
     requirements
   - Gather feedback on how Tech Comm practitioners are
     using our spec materials
2. Technical "solutions development"
   Jennifer suggested that we take a hard look at some 
   of the more challenging implementation issues that 
   our Tech Comm constituents face routinely. 
   - Example: Figuring how to manage keydef libraries 
     across large doc sets WITHOUT creating conflicts 
     can be very tricky.
   - Example: Resolving conflicts at a meta-product 
     level when reuse libraries that were designed to 
     work at the product levels bubble up to the cross-
     product level.

3. Yahoo User Group issues
   Bob reminded us that issues with the Tech Comm 
   feature often pop up on the Yahoo user group 
   discussion list.
   - Example: <choicetable> versus <substep> logic when
     you want to route readers based on their choices 
     in a <steps> procedure. Given that software logic
     can be inherently convoluted, being able to route
     readers within cononical DITA tasks <steps> is 
     important. 
   - Example: Getting back to Yahoo users with 
     information about the historical logic of our 
     feature decisions would help.
   Jennifer noted that most companies develop 
   "standard" workarounds for some of these design 
   gaps, e.g. using <ol>s and <ul>s within 
   <choicetable> elements works. Collecting these would 
   be useful.
  
4. Lightweight DITA
   Bob recommended that the SC get more involved with 
   the post-1.3 effort known as Lightweight DITA. 
   Michael Priestley had just posted a ZIP archive 
   containing his latest working DTDs and spec 
   information on December 19. 
   https://www.oasis-open.org/apps/org/workgroup/dita/documents.php
   Providing ongoing feedback with this effort needs to 
   be a priority for the SC and its constituents.

Next Meeting: Monday, January 20