"...used throughout the industry" is known as argumentum ad populum -- and besides it isn't even a very accurate assertion. Perhaps Mr. Z is referring to the use of Confluence within the ASF, and "available support" is of course a decent argument for sticking with wiki-only documentation as long as the ASF provides superlative infrastructure & support. Otherwise it <i>will</i> become a sticky wiki wicket that offers only greater long-term restrictions than something like single-sourced DITA or Docbook (even with adequate wiki support the writing as it were appears to be on the proverbial wall regarding technical communication trends).
There is such a thing as change management. Indeed, if there were no such thing, bureaucracy would grind all potential change to a permanent halt. Change for change's sake is a business management pitfall, obviously, so it comes down to a decision about whether the project has enough resources to spare for investigating DITA (which is gaining popularity among tech writers more than any similar typing architecture or proprietary wiki engine). "Change because there's something new to try" is a management no-no. "Don't change because everyone is used to the old way" is a management no-no. I am ignorant about this project's current resources or ultimate aspirations. I'm guessing that open source human resources are scarce, which typically means (at least in the software game) that documentation gets tartarooed toward "oh, anyone can whip up some documentation during the final days before release" oblivion. Fair enough, and contributors are being generous with improvements to the documentation as it exists right now, so if resources are less than available for appropriate change management commitment then the existing wiki is the way to go for the next few years. As a tech writer, though, one with experience stretching back to the 80s, I am confident asserting that after "the next few years" a proprietary wiki engine, when compared with single-sourced XML markup that can target multiple output formats, will come to be seen as more of an anchor than a lifeline. Perhaps a few years out is a reasonable dart-toss goal for a documentation change management sub-project. Aside: my "two cents" OFBiz wish list has CMIS integration at the top (minor sub-project with a large potential end user payoff), as well as something like <a href="https://coreos.com/"; target="_blank">CoreOS</a> integration right beneath that (major sub-project with a ginormous potential end user & dev-ops payoff). I try, of course, to be one of those "take what I can and be thankful" users because my typical open source contributions amount to cybergum-flapping opinions. On 14-11-28 06:51 PM, Mike Z wrote: > I think that recently the docs have made a great leap forward thanks to the > good folks here on the mailing list. The more comfortable people are with > the wiki the more it will be used. Confluence is a standard wiki used > throughout the industry and I think it would be a mistake to change things > just as it is gaining steam. > > Sent from my BlackBerry® PlayBook™ > www.blackberry.com > > ------------------------------ > *From:* "Sharan-F" <sharan.f...@gmail.com> > *To:* "user@ofbiz.apache.org" <user@ofbiz.apache.org> > *Sent:* November 28, 2014 6:02 AM > *Subject:* Re: Notes from Apachecon EU Budapest Meeting > > Hi Todd > > Thanks for explaining this and giving the links. > > I'd like to investigate this as I'm keen to understand if we need to discuss > changing our approach to in application documentation. > > Thanks > Sharan > > > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Notes-from-Apachecon-EU-Budapest-Meeting-tp4658991p4659098.html > Sent from the OFBiz - User mailing list archive at Nabble.com. >
