Documentation

[John Ralls]

On Dec 11, 2013, at 10:22 AM, David T. <sunfish62 at yahoo.com> wrote:

> John—
> 
> I’ll note that the GnuCash website Writing Documentation page, and it still includes all the information that scared David C. away (me too, I’ll add). Moreover, the directions there are all svn-based. Is there a clear and simple outline of the git process for documentation that us non-programmers can daily follow? To date, I have avoided the DocBook cycle in favor of placing my corrections into comments on Bugzilla and relied on others to migrate my edits into the actual documentation. If there really were a simple method for editing, that functions more like a word processor rather than a programming platform, it might broaden the documentation team.

For version control, see http://wiki.gnucash.org/wiki/Git

There are a variety of GUI front ends to git for all platforms; TortoiseGit is the one I use on Windows.

If the OO exporter doesn’t do it, as Martin Mainka just reported, then the Wiki is our best hope.

BTW *don’t* bury proposed changes in comments. Make a formatted file of some portable flavor—RTF, OpenOffice, HTML, markdown—and attach it to the bug, marked as a patch. That enables bugzilla features that make it easier to find, provide feedback, and indicate whether it’s been committed.

Oooh, thinking about markdown got me thinking about markdown->DocBook, and Google promptly pointed me to http://johnmacfarlane.net/pandoc/ , so there’s another possible workflow, either with markdown or the wiki.

In fact, it also suggests another workflow for the next dev-cycle: Put the document sources in Markdown and use Pandoc to generate the releases. Or drop gnucash-docs in favor of the wiki and again, use Pandoc to generate documents.

Who’s got time to play with this?

Regards,
John Ralls