| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Groups - DITA TC Meeting Minutes 26 June 2018 uploaded
- From: Tom Magliery<firstname.lastname@example.org>
- To: email@example.com
- Date: Tue, 26 Jun 2018 09:35:32 -0700 (PDT)
Robert: review OASIS docs about normative language and present that at July 10 meeting (two weeks out).
Kris: organize meeting to begin work effort on restructuring topics in the "DITA for Technical Content" spec.
Bill: start an email thread on the TC list to discuss a name for the "DITA for Technical Content" spec.
Minutes of the OASIS DITA TC
Tuesday, 26 June 2018
Recorded by Tom Magliery
link to agenda for this meeting:
Attendance: Robert Anderson, Deb Bissantz, Carsten Brennecke, Bill Burns, Don Day, Stanley Doherty, Kristen Eberlein, Maria Essig, Carlos Evia, Jang Graat, Richard Hamilton, Alan Houser, Scott Hudson, Eliot Kimber, Tom Magliery, Christopher Nitchie, Karthikeyan Rengasamy, Keith Schengili-Roberts, Eric Sirois, Dawn Stevens, Robert Thomas
Regrets: Nancy Harrison, Jang Graat, Deb Bissantz
11 AM ET open
Approve minutes from previous business meeting:
19 June 2018:
https://lists.oasis-open.org/archives/dita/201806/msg00044.html (Tom Magliery, 21 June 2018)
Kris: motion to approve the minutes
08 May 2018:
Eric: Consider e-mail on dita-comment from Stefan Eike and report back to TC
12 June 2018:
Bob: Get DITA for Technical Content repository functional again (COMPLETED)
19 June 2018:
Bob: Investigate problems with the committe note XHTML stylesheets (COMPLETED)
Kris: Request publication by OASIS of DITA 1.3 Errata 02 (COMPLETED)
Scott: Review the code examples for the glossary elements affected by issue #85, and make suggestions for changing one or more of the examples to include sup or sub
Kris: Ensure that the decisions/example/guidance are documented out of the small group spec meetings with/Robert and Carlos
Spec editing report
Robert, Kris, and Carlos met on 21 June 2018
Guidelines and examples for each section of the (reworked) element reference topic
Carlos: Very impressed by the amount of detail involved
Kris: heads-up: trying to get through review of element ref topics that overlap with LwDITA. Will open up DITAweb review for the TC. We are reorganizing all these topics from top to bottom, with special attention to examples.
Subcommittees and Adoption TC
When has the DITA last received a report?
How frequently has the subcommittee met?
What have they achieved and what are goals for the future?
Keith: Chief thing to point out is that in a date tbd in July we plan for a DITA listening session in Broomfield, CO, in Oracle offices. Have interest from about 20-30 people. Might be pushed to August but trying to get people before conference season.
Another thing considering at next meeting is idea of more and better examples of DITA code. We're looking at coming up with a set of examples based off what currently exists in 1.3 spec and expanding upon it to hopefully reflect best practices.
That's about it, has been relatively quiet since summer started.
Bob: Are you familiar with the Thunderbird manual?
Keith: Yes, we may lift some examples from that. We're mostly looking to expand the examples beyond spec to cover some best practices.
Kris: Hope we can count on the Adoption TC being heavily involved in our early review of 2.0 topics.
DITA 1.3 Errata 02
21 June 2018: Request for OASIS to publish was opened
Kris: haven't heard about our request yet, may be related to Robin Cover leaving OASIS, things may be moving a little slow.
Normative statements about navtitle
https://lists.oasis-open.org/archives/dita/201806/msg00046.html (Eberlein, 24 June 2018)
https://lists.oasis-open.org/archives/dita/201806/msg00048.html (Kimber, 25 June 2018)
Kris: This came out of our spec editing meeting last week. If there are things that don't have normative statements we can think about adding normative statements. In this case the spec language used a lowercase "should", we wondered if it should be normative. Do we want a SHOULD or a MUST?
Eliot: I think it should be a SHOULD not a MUST because this is ultimately a function of presentation style, and should be up to the processor. Even if we made it a MUST it would be unenforceable.
Robert: I agree, but something else I think is that the current language and the new language just basically says what the effective value of the navtitle *is*, it doesn't say what you have to do with it. We're not actually mandating presentation. Which I think is how it should be.
Eliot: There's a subtle difference here between that and conref, the spec says "the effective value of a conref is ... whatever". But here we're saying there are three things that are all present, and these are the rules for how we expect you to choose.
Tom: The word "generate" seems to imply presentation, so perhaps we could change that word.
Kris: Fine with changing that word to something better.
Kris: How do people feel about the word "render"?
Bill: Agree with all being said.
Kris: Generally with changes for DITA 2.0, it might be good to have a refresher on what is mandated by OASIS about normative language. Can I ask someone on the TC to take an action item to review that content and give an overview to the TC next week.
Robert: ACTION ITEM to review OASIS docs about normative language and present that at July 10 meeting (two weeks out).
DITA TC proposal process and subcommittees
https://lists.oasis-open.org/archives/dita/201806/msg00047.html (Eberlein, 25 June 2018)
Kris: Sparked by a request from L&T subcommittee who wanted someone to talk about what the TC expects from subcommittees about the OASIS proposal process, i.e. the Stage 1-3 process that we implemented for 1.3 and 2.0 specs. What are the TC's expectations about work products?
Kris: I feel the stage process really applies to things in the main TC, and subcommittees can follow procedures that work for them as long as they come through the TC for publication.
Chris: It's going to depend on how much editorial muscle we need to flex on various subcommittee drafts. E.g. the LwDITA note required some pretty substantial editing and required quite a bit of input.
Kris: That's part of the conundrum of having subcommittees actually developing work. When it comes down to it it has to come through the main TC. We'll naturally be opinionated about the design of work products.
Chris: I wonder if work products with our name on it need a more thorough editing as our final pass, not just thumbs-up/thumbs-down on the way out the door.
Kris: I think you're correct, work products will need more detailed editorial attention. Question is, is there a review/editorial framework that we want to set up in advance?
Tom: The stage 1-3 process doesn't seem like the right thing, though, it's more targeted at spec parts.
Kris: It also doesn't cover the editorial/QA work and there's a LOT of that. E.g. I spent almost 20 hours editing the sort-as related proposals for DITA 1.3.
Kris: two questions here. 1 about technical issues, 2 about editorial and QA. 1. SC advised to get TC input early on as to what they're planning.
Kris: Carlos, any input here from perspective of LwDITA.
Carlos: I think this CN was a unique situation. We got distracted by all the requests that we got from people to provide demos, plugins, samples, etc., and had time away from work on the CN itself. So you got heavily involved with that document which may not be normal for SC work, I expect more autonomy. But I do agree that SC should be sharing with the TC frequently. A good step is the call that we have regularly with Michael, that keeps me aware of the work of the TC.
Tom: Maybe SC should make more frequent reports to the TC when they are actively working on products to keep awareness high between the SC and TC.
Kris: What frequency should reports be?
Carlos: Maybe once per month?
Kris: Perhaps L&T should report less since they meet less.
Tom: How about once per month minimum, but more when the SCs are meeting more often? We needed more frequent input from LwDITA when they were very busy with the committee note.
Kris: I think that's a great plan.
Stan: This might be a chance to meet about our relationship to working products. Someone was working with Madcap Flare, one with GitBook, we're going through these docs from Madcap and Github, talking about how it's superior to DITA, and I was saying that's not quite true etc. There should be some official statement available [from the TC] about how DITA differs from these products. There are maybe other similar work products that we could kick around and discuss.
Kris: We have tended to avoid making statements about particular vendor products.
Robert: Part of this is me reacting to someone saying something bad about DITA. If we refute things, the people who are saying them will just say "Well of course you would say that".
Keith: In terms of reports on the state of the DITA marketplace I think that has to be within the realm of consultants and firms that are operating in that area. I'm leery of the idea of OASIS putting out "official" statements about this product is this or that.
Kris: I'm sympathetic, but this really isn't our purview. Our primary job is to develop the standard.
Keith: My research on behalf of my company often looks at companies with both Flare and DITA implementations, I'm finding that it seems to be rare that one company wholly goes from either one to the other. They exist often in tandem. But that's for a future report, probably not until the fall. That'll probably be a DITA Writer thing, not IXIASOFT.
DITA for Technical Content
GitHub repo now is functional; Bob opened a pull request that Robert merged on 25 June 2018.
Kris: ready for folks to engage in work. First step is interested folks can start thinking about restructuring/reorganizing these topics.
On the agenda next week: talking about appropriate name for this.
This is simply a first pass to take content of topics from 1.3 and move it into appropriate sections whether it's usage info, formatting, processing, examples. Once all these have been reorganized a 2nd pass is to edit this.
Who are present today interested in the hands-on work? I know small group people were Bill, Maria, Nancy, Bob, Chris, Carlos, Scott,
Bob, Bill, Maria, Robert. (Kris: chuckle, you and I by default)
Kris: should we have another small group meeting to get started with the work effort?
Kris: ACTION ITEM to organize meeting to begin work effort on restructuring topics in the "DITA for Technical Content" spec.
Kris: Anyone have any great thoughts on a new name for this yet? Can someone take an action item to kick off an email thread for this?
Bill: ACTION ITEM to start an email thread on the TC list to discuss a name for the "DITA for Technical Content" spec.
Restructure element reference topics using new DITA 2.0 format
Enable steps to nest (Anderson, stage 3)
Bookmap enhancements (Sirois, stage 2)
New diagnostic elements for troubleshooting topic
Committee note about multimedia domain for DITA 1.3 -- On hold until GitHub repo is set up
Kris: We got notice from OASIS that they have set up a new repo. Robert and Eric and I are the admins who can accept pull request.
Kris: How do we want to structure this repo? Initial thought was master branch that contains source for CNs that have been published. Then maybe branches for each CN in progress. Thoughts from others?
Robert: I have nothing else.
Kris: Unlike spec repository I think we'll have more folks authoring and editing content.
Bob: I think this is the simplest solution that will work.
Kris: In general as we have more repositories having some structure common to all of them will be good. Master branch for published content is one good thing. Other subcommittees may have different needs for branches, we can't really mandate it. But this one will probably have way more people actively involved.
Stan: Industry development in last ouple of years, people publishing content on portals are providing Github content in parallel for public comment. Almost a community-based Github feedback mechanism. There might be something we could consider as being trendy and interesting.
Robert: I'm not sure about that, I think the big feature of Github is that anyone can make a pull request. I don't think we would want to provide it in an alternate format. If someone is knowledgeable enough to provide feedback, I'd sorta think they should do it against the DITA source.
Kris: We have an established format for feedback on TC products which is dita-comment.
Stan: Just pointing out that this is a trend, might be something to look at.
Kris: I'm leery of activities that would take more resources away from us.
Robert: If we opened up another avenue for public input we would need to be able to respond to it and we're already struggling with the amount of work that we're doing without that.
Kris: We're already behind on dita-comment.
DITA 2.0 stage three proposals
#85 Add sub and sup to glossentry elements
https://lists.oasis-open.org/archives/dita/201806/msg00024.html (Hudson, 11 June 2018)
Kris: Move that we approve this proposal
Roll call vote:
#73: Removed delayed conref domain
https://www.oasis-open.org/apps/org/workgroup/dita/download.php/63270/Issue73-stage3-delayedConref.html (Houser, 18 June 2018)
Kris: move to approve
Roll call vote:
Kris: 2019 DITA conference was possibly being considered for the RTP area, now I think it's nearly final that the conference hotel will be the downtown Durham Marriott with overflow in boutique hotels in the area. Durham is a pretty nice place, a lot of restaurants, this is right in the downtown center. I'm looking forward to that. Tie-in to the Adoption TC I'll be trying to follow through with my plans to organize an RTP listening session before next year's conference.
12 noon ET close
-- Mr. Tom Magliery
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]