Meeting minutes 2016 07 07

Attendance: George Bina, Radu Coravu, Robert Anderson, Bob Johnson, Bill Gamboa, Leif Erickson, Bill Burns, Roger Sheen, Shane Taylor, Jarno Elovirta

Item 1: Any updates about prior releases?

2.3.1 released since our last call. Milestone 2.3.2 branch is open at github but no set date yet. [Note upcoming developer absences.] There are some items that should be fixed.

Item 2: DITA-OT 2.3 status and updates

Jarno has been working on a configuration option that lets you hash file names in the temp directory - places everything in the same directory, avoids issues with directories, with the uplevels calculation, etc - simplifies a lot of processing. Original names stored in .job.xml so that you can still write out files based on original names, if desired.

This leads to a more general processing change to process all maps first - finish processing maps before processing topics. This makes more sense than the current system that fetches both at the same time; that's how it's "Always Been Done" and thus tough to change, but many more recent DITA apps, based on experience over the last decade, take the map-first approach.

Item 3: Doc updates and plans, update on documentation call

Idea: make "Who we are / come participate" topics more prominent, maybe in main TOC? Currently not visible from docs, might be wise to make that as prominent as possible (usual problem that users often do not realize how small the team is, or that we'd like to encourage others).

Related: Robert posted a blog about DITA versus DITA-OT. Came out of confusion in user community between who owns DITA-OT (in sessions led by OASIS members, DITA users incorrectly thought that the OASIS TC had some operational control over DITA-OT). Thinking about how to address this perception problem led to the previous suggestion.

Adding those links seems easy, good to have multiple entry points to the content. Next step is to clean up that content further.

Related: Roger also considering some changes to the nav bar on top. Limited real estate, but may want to clean it up.

Leif: as a user who had trouble with the distinction between DITA / DITA-OT / Wrapping application, think it would be nice to have something in the log that highlights the problem. Either up at the top where your options show up, or at the end, which is the last thing you see. Kris: maybe both places. Robert: would need to be really short, I've had years of people telling me not to put things in the log due to clutter.

Jarno: don't like this idea, the log tells you about the process - here is what we did, here is any debug information - but if you look at any other tool, the log will not print something about the tool itself, especially something like "this tool is not related to the spec". Sort of like having a browser that every time you open, pops up "this is a browser, but unrelated to HTML spec".

Shane suggests: "Built using the DITA Open Toolkit Version 2.3.2. DITA Open Toolkit is an open source project. See http://www.dita-ot.org".

Robert: I think I like that first line - it doesn't seem out of the ordinary for processing logs I've seen, either at the start or end of the logs: "Built using XXX version YYY".

Jarno: my experience, normal users don't really read the logs. If they see something failing, they look. Nobody is interested in what was processed correctly; they want to look when it fails, and when it fails, they want the log as short as possible.

Bill Gamboa (Astoria): we do produce the logs when content is generated. I've learned how to read them, but only do so when something fails. As a user, log is only important when something fails. For understanding more about DITA-OT, I would just go to the site and look around.

Discussion comes back around - if the premise here is that we want to help educate the using community on DITA vs DITA-OT vs wrapping application, log probably is not a useful place to do so. Those reading the logs are already deep enough to know what "DITA-OT" is, it's unlikely to meet the original goal for more than a handful of people at any point. Should focus on other ideas / venues / outreach.

Item 4: DITA-OT Day 2016

November 13 in Munich. Need to start submitting topics, working on agenda:

• Robert still interested in localization topic
• Roger: considering something with more detail about how we automate the docs, toolkit. Since I've talked about that in the past at DITA-OT day it may not be useful - but might propose that for DITA Europe instead. Could also do lightning talk on "what's new in docs".
• Kris: Remember that for most of us, content from previous years is something we remember. For a lot of others who attend, they probably don't remember. Be less worried about overlap with previous years. Roger: depending on other sessions, available time, could scale that up.
• Robert: Jarno has suggested to me short talks about "what has happened in the guts since last time" and/or "what we could do next". Roger: I think that's very useful for this forum - that's exactly what some people are coming to hear, "What have we done and what is next". If not in this forum, where else? Bill: I think if there were a published roadmap, that would be really helpful. Robert: think this is less a roadmap, more of a jetpack blue-sky discussion - "Here is what we think we might like to do next". Lots of discussion about the term "roadmap" - not quite right because our roads tend to change.
• George: we should also set a deadline for call-for-proposals. DITA Europe call ends at start of August so Robert suggests lining up with that. George will set August 1 as the deadline, and we can start publicizing. Can extend if needed. Have 3 proposals in there so far. George and Radu each submitted one, so did Stefan. Robert and Roger will submit theirs using the form.

Item 5: Other topics

Question from Leif about long term support - is there, or will there be, a version that you can depend on for long term support? Robert: unfortunate short answer is no, given the size of our dev team and lack of any paid support team. Support is on a volunteer basis, and focus is always on the most recent stable release:

• Active feature development is on the next major release
• Active maintenance is for the latest major release
• Latest-minus-one could be patched, but only for major issues, and chances are this would only be shortly after the latest major release
• Latest-minus-two is unlikely to be patched, but (it's open source after all) anybody that has a fix could recompiled by anyone

This plan is laid out in Robert's DITA-OT presentation at DITA North America, available here, for some reason without the avatar that makes the author clear: http://www.slideshare.net/RobertAnderson151

Item 6: Backlog discussion

Time to go through pull requests, issues tracker, determine how to handle open issues.