Meeting minutes 2016 03 31

Attendance: George, Robert, Shane, Stefan, Kerry, Jarno, Roger,

Item 1: Any updates about prior releases?

2.2.3 has been posted. 2.2.4 hotfix branch created; expect 2.2.4 out in about two weeks.

Developing an official patch policy: Discussion about time boxing for hotfix releases

Came about because we had a patch branch in github for a while that went unreleased. When you set a limit, then those will come out, you won't end up with a branch that's open forever waiting for more issues.

Robert describes - historically on his team in IBM - have gone back and forth. For a while - view was "too many patches = perception of bad code", led to policy of patches every 5 or 6 months. Result: angry users who didn't get fixes very fast. Other extreme: hotfixes or patches for everything. Result: angry users who didn't like so many tiny fixes. Robert's thought: today, people are more used to frequent updates. Also, our release notes clearly show fixes - if you are unaffected, no need to follow every patch.

Discussion: from the time the first fix is created for any release, put out a fix version within 2 to 3 weeks max, depending on urgency of what's in there.

Item 2: DITA-OT 2.3 status and updates

Jarno has been adding some features. Biggest thing: right now have new Travis jobs, we create a build for every push to develop and upload that binary to Amazon web services (Jarno's account). Essentially, we have an always-latest build available. It's there for anybody who wants to try out the latest but doesn't want or doesn't know how to download code and build. That latest-build is also used for doc builds on Travis. Future: Travis will build and upload the final package to github as well. Tag release > do the merges > triggers Travis to build and upload. Only manual step then is updating web site, release notes, etc. Could be possible to automate the doc bit as well.

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

Since last call: Kris did a bunch of work early in month revising plugin topics, now merged. Docs now built via Travis CI process (yay). That's currently deployed to dev branch of website - it's there but not visible. Once we are sure this is all working as intended, the daily docs updates can go directly to web. Thoughts on whether this is a good idea? Robert: likes it. Jarno: we don't have official review cycle, and review should take place in the pull request. Could end up with incomplete info being uploaded, but if so then we should just stop doing that. Think we should give it a go.

Next steps: trying to catch up on migration info in the user guide. Jarno pointed out he had begun several versions ago to list deprecated items in source code; Roger has been looking for that and collecting. Updated 2.1 migration topic with that a couple days ago, to list deprecated targets and their replacements. Will continue with 2.2.

Item 4: DITA-OT Day 2016

November 13 in Munich. George created a great flyer to give out next week at DITA North America.

Soon we'll need to figure out the call for proposals (date, subject, etc). Also need to come up with main session ideas. May want to start out sort of like last year - main sessions are from major participants, call-for-proposals will be for shorter sessions. But if we have a great session idea from outside team, don't want to rule out a long session.

Jarno: think our idea is to focus on HTML5 / EPUB. Don't want to repeat discussions of PDF2 / XSL-FO / CSS that we've had at both previous conferences. Think there will also be interest in lightweight DITA work within DITA-OT.

Other topics

Who on the call will be at DITA North America next week?

Discussion about subdomains or shortcut links, such as http://issues.dita-ot.org as a redirect to the issues tracker. Good idea, bad idea, helpful, unhelpful? No expectation of masking, just a simple URL that could be easily remembered / shared and would redirect to github. Robert and Roger discussed "issues" (redirect to the issues tracker), "code" (redirect to code repository), "wiki" (redirect to this wiki). Discussion started with "devbuild" or similar as a redirect to the Amazon cloud page that currently has the development build. Jarno mentions - the one people would probably look for and appreciate is "support", but with current team and resources we don't have a dedicated support channel - it would probably have to direct to the dita-ot-users group.

Nobody seems opposed, and some will find this helpful, so will go with the current domains. Already posted:

• http://wiki.dita-ot.org as a forward to this project wiki (handy way to find meeting minutes if needed)
• http://issues.dita-ot.org forwards to issue tracker
• http://code.dita-ot.org forwards to the github code repository
• Robert also set up a shortcut after the first DITA-OT day to Jarno's PDF Generator, after people asked about it and Robert couldn't remember the exact URL. It's at http://pdfgenerator.dita-ot.org but should be clear this isn't an official part of the project, Roger isn't documenting, etc. Also, Jarno has a new URL for his project that is already easier to remember, http://dita-generator.elovirta.com/

Item 6: Backlog discussion

Jarno has one - discussion about 2244 and how it was handled. How to set user expectations, etc. Lots of things in this issue to discuss / learn from. Main thing is noting that we are not great at / we could use help with quickly responding to issues. Nobody, including those of us on the call, enjoys having issues sit open without attention. The good news: have a good fix for 2244, it's already in 2.3 develop branch, planning to port it back to 2.2.4 hotfix.

If anybody else can review the release management pull request apart from Jarno, please do - Jarno has not had time to read it all and would like to ship it in 2.3 - https://github.com/dita-ot/dita-ot/pull/2248

Stefan is thinking about an HTML5 bootstrap based webhelp plugin. Thinking about how to do it because a new plugin might copy a lot of code, which doesn't make a lot of sense. Also doesn't make sense to fork it because want something similar. Need bootstrap formatting of several elements. Question: would it be possible to extract bootstrap processing from the HTML5 plugin and externalize them so that they are reusable in other plugins?

Jarno: stuff we have for the website is closely tied to our website. WRT HTML + Bootstrap, Jarno has an HTML5 WebHelp plugin that he's been working on, not released yet, some of the JS it uses is already in use at website (dynamic TOC, topic finder).