DITA Technical Committee Meeting Minutes: 21 December 2010

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

 

DITA Technical Committee Meeting Minutes: 21  December 2010
 
Chaired by Don Day <donday@bga.com>
Minutes recorded by Bruce Nevin <bnevin@cisco.com>
 
The DITA Technical Committee met on Tuesday, 21  December 2010 at 08:00am PT for 55 minutes.

8:00-8:05 Roll call
  o  Regrets: David Helfinstine, Seth Park
  o  Quorum was established.

STANDING BUSINESS:

Approve minutes from previous business meeting:
  o  http://lists.oasis-open.org/archives/dita/201012/msg00085.html (Kimber)
  o  Don moved to accept, Kris seconded, passed by acclamation.

Subcommittee/liaison reports: Resume in January

  o  OASIS DITA for Enterprise Business Documents Subcommittee (resume here on 11 January 2011)

ACTION: Bruce: Tell Michael Boses; verify date of next meeting and remind Michael to put Don on the invitation.

Subsequent reports will be anticipated:
  o  OASIS DITA Technical Communication Subcommittee
  o  OASIS DITA Pharmaceutical Content Subcommittee
  o  OASIS DITA for Programmers Subcommittee (pending formation)
Needs to get started. Robert will start pushing for this in January.
  o  OASIS DITA Machine Industry Subcommittee (Jang Graat)

Action Items:

  o  Review open items: http://www.oasis-open.org/apps/org/workgroup/dita/members/action_items.php
Actions assigned to Gershon need to be reassigned, or at least identify the scope of effort.

BUSINESS:

We note Mary's farewell email message with holiday greetings, and hope for the best with future resolution of her role and duties.

1.	Continuing ITEM: Perceptions of DITA complexity
  o  http://lists.oasis-open.org/archives/dita/201012/msg00070.html (latest post on thread, Priestley)
  o  Continue discussion as necessary, but can move to email and wiki page long term      

Question the word "perception"--it could be taken to imply actually misperception or illusion. Eliot: DITA is as uncomplex as the requirements demand, and we haven't put any features in that weren't justified.  

How can we refer less technical users to more user-friendly documentation? Kris: In 2011 there will be a lot more of such non-normative documentation. Su-Laine: there is concern on the technical side about a perceived trend in DITA (the architecture) to greater complexity. We might raise the threshhold for adding features in the future. Should domain-specific packages & specializations be done by subcommittees and not be part of the spec? We need to evaluate which features are being used to meet their requirements and which not. If something is not used or is only used by a very few we might even deprecate it. Kris: we need to focus on the process by which we develop new features. Robert: yes, make it more difficult to get things in, and make each proposal better specified. Eliot: yes, good to move more semantically specific items out of the TC purview. Anybody can add new vocabulary at any time, in the nature of the architecture. Learning and Training, Machine Industry, did not need to come out of the TC.

Stan: even if we add no features for 5 years, we currently have a perception of complexity. What about the work on the DITA maturity model? Levels of complexity mapped to maturity curve, cross-referenced to the spec. Caveat: It's not a roadmap for advancement (with implied judgement), but rather a more static framework for assessing where you are, and scoping whether to make an additional investment for greater capabilities. Need to coordinate effort with Adoption TC.

Don: Do we need to revisit our charter?

Keith Schengli-Roberts: Shiela (?) developed a survey of what tags are being used by whom. Need to get feedback from users. Thilo: that survey is not so much about elements as [topic types?]. Su-Laine: proposed more detailed survey. Doug: most elements are very rarely used. Don: Tools vendors might be able to pull out stats about how often elements are parsed. Also, we might define prototypical constraint profiles, Michael's suggestion. Doug: In a given enterprise, you only need a few people to understand DITA well, authors need only limited knowledge. Can work from examples. Not many people understand how bullets are stored in Word files, nor do we need to. Don: Not just elements, attributes tend to raise concerns for people who haven't worked with properties before. 

ACTION: Don and Kris: discuss how to prioritize approach to 1.3, and how to structure actions and work items.

Dick Hamilton: If there are things that you think should be done, let him know, they are producing many of the non-normative books. Kris: Tony Self is publishing a DITA style guide; Nora Bellamy and others are producing a book on good writing practices with DITA.

ACTION: All: Contact Dick Hamilton with ideas about what should be done to help with comprehension, adoption, and use of DITA.

2.	Continuing ITEM: Review of packaging survey (Buchholz and Hackos action)

  o  http://lists.oasis-open.org/archives/dita/201011/msg00013.html (Buchholz update)
  o  JoAnn's links, and subsequent discussion:
  o  http://lists.oasis-open.org/archives/dita/201012/msg00083.html

Intent of survey needs clarification. JoAnn: where are people learning about DITA, and what are they trying to learn? Rather than who they are, as in the current set of questions. Kris: This item originated with Gershon, and may have had a very different intention. We need to be very clear about what we want.

Su-Laine: We assumed that people wanted smaller and more focused subsets to download. But what people want is very rarely getting smaller pieces. What are people actually complaining about, what is their goal using the documentation, what is their problem. Robert: we started with the assumption that people were complaining about the doc being too big.  Su-Laine: problem is finding things. JoAnn: people are looking for a tutorial, and this is less of a tutorial than it started out to be.  Su-Laine: are the complaints from people who should understand it or from those who will never understand it? Kris: Complaints are about DITA being too complex, not about the spec being too complex. JoAnn: how about a doc on how to read the spec. Don: at least the lang ref could be augmented by a usage-oriented best practice guide.  [missed names]: We could push in audience indicators, or commentary. SuLaine: We tell people not to specialize if what they want is already there. How do they find out that it's already there? Nobody complains about wikipedia being too complex, because you can find things in wikipedia.

Robert: We need to identify the problem clearly. JoAnn: we put energy into revising questions. They are mostly who are you questions. The second part is about the spec. Robert: the survey wasn't intended to address complexity questions. Do we want to add that in? Don: Wiki page on this question now under Working Documents, action from last week: http://wiki.oasis-open.org/dita/DITA_Perceptions.

Kris: how long do we want to continue talking about this? One other approach for one problem area: If the problem is that the spec is hard to read and hard to use, how do we improve usability and access to what you want in the 1.3 spec?
Robert: identify different definitions of complexity that we (think we) have heard, then decide what we can do, then what we will do.

JoAnn: we could use the survey simply to gather some data as a basis for asking further questions. Robert: agree, keep the user complexity question separate from the user community survey.

ACTION: All: add a section to the wiki page about complexity and brainstorm your perceptions of the problem and potential solutions.

6.	Happy holidays, team. The chairs want to thank everyone for a great 2010, and are looking forward to an exciting next year! See you on January 11.

9:00 Adjourn