Meeting minutes 2019 03 14

Attendance: Radu Coravu, George Bina, Jarno Elovirta, John Pashley, Kris Eberlein, Lief Erickson, Robert Anderson, Roger Sheen, Paul Gregory, Frank Wegmann

Item 1: Any updates about prior releases?

3.3 is out. Hotfix branch open for 3.3.1, currently includes a couple of long-standing minor fixes.

Item 2: DITA-OT 3.4 Development status and updates

DITA-OT 3.4 project page: https://github.com/orgs/dita-ot/projects/12

New feature: DITA-OT project configuration: https://github.com/dita-ot/dita-ot/pull/3243

• Will likely be implemented over several pull requests -- incremental addition of features on this existing base
• Instead of having Java properties file to define input / output / arguments, you have a custom format for configuring a deliverable.
• Allows us to more easily / correctly resolve paths
• Becomes easy to support different formats for that (json / yaml / xml); vendors can then let you edit those files and/or use them internally as a way to define transformation scenarios / deliverables / etc
• Plan is to let you define multiple inputs, multiple deliverables in one configuration file
• For example, could run dita command saying "Build deliverable X" -- or could run full project such as "build html / pdf / website"
• Projects could refer to each other, build project that refers to others, or for example, set up all of your common filter rules from one project and reuse that
• Current format is a bit inconsistent but working on that (currently at MVP level)
• Part of Jarno's overall goal for 3.4 of features that are aimed at developer productivity
• Lots of discussion from George about idea of projects, deliverables, and build context. George's goal: a project is useful not only for publishing, but also to exchange information between tools - validation, editing, translation, etc. George will send more info to Jarno.
• Suggesting a wrapper element around (map and filters) -- when setting this up you might not know what output you will eventually need, but you would know what maps and filters are in play.
• Some concern about how far to go with this: if we try to do too much it may not come out right
• Roger points out: only thing harder than naming something like this is renaming later
• Jarno brings up idea of versioning (of format), which could help handle that
• Current thought is that if other items are found that we don't recognize, ignore them (don't use what we don't recognize)
• Right now everything in one pull request but will need to make new more specific ones for more updates
• Not sure how heavily to document or to push this. Is this the recommended "new way of going"? Roger suggests that we should certainly document it (noting that properties files don't work in several ways now, such as relative paths)
• Suggest making new project, handle this as something like an Epic, with all related issues tracked in the project

Another feature Jarno has been considering is support for multiple root files. For example, "Input a.ditamap and keys.ditamap and scheme.ditamap". Could let you build a bunch of deliverables at once. Could let you build content + a map with common key definitions + a map with a common subject scheme.

• Could let you build one topic + pass in keys / scheme
• Could let you build maps and pass in scheme on its own
• George points out it's not necessarily "Support 3 inputs" where someone might expect 3 outputs ... it's really an implied wrapper around three specified maps, so a single input but it covers 3 maps. Like with filters, if you specify 3 DITAVAL files, you're still giving one set of conditions, just implied that they are all pulled together.
• Jarno: initial naive idea was if you have 3 input maps, you create that wrapper. But not sure, if you have 3 input bookmaps, where do you pull the book title? How do you merge maps that don't merge well together? More generally, if you have inputs that don't merge nicely, how to handle?
• Might be a case of "don't do that" -- if you have a map that specifies a start-to-finish PDF deliverable, don't try to use more than one of those as a single input / don't try to put that map in the middle of others when building PDF
• This has something in common with chunking, how would you handle that with an implied map that wraps several inputs

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

Last call: discussed moving project website hosting for dita-ot.org from GitHub Pages to Netlify. Close to moving that over. Robert & Roger plan to coordinate DNS changes next week.

After we enabled the Stale bot after DITA-OT Day, we saw some issues: issues got the "if nothing happened" warning, people commented, and that didn't reset the clock. Roger filed a comment in the stale bot, it's a known issue that owners of stale bot haven't been able to reproduce but other projects have also seen it. Not much we can do apart from re-open. We should try to watch for notifications and make sure others are not closed in error; if closed in error the only remedy is to reopen.

Do we still need the XmX parameter? Probably not: https://github.com/dita-ot/dita-ot/issues/2415#issuecomment-457476607

Lief is planning to use DITA-OT web site for masters project. One outcome from last year's survey is that search experience is less than ideal. Kris suggested maybe building a taxonomy, but that could go several directions. Could improve search if we get Algolia to make use of it. Could be indexing in PDF. We may notice Lief doing various things to the docs over coming months (with Roger's guidance) -- usual approach of pull requests and issues.

[end of meeting, out of time]