On Dec 11, 2013, at 10:22 AM, David T. <sunfis...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
