If I were to nominate an area that I thought would be the most
productive in helping build the team, I'd be suggesting that the
developer documentation is sadly lagging behind the rest of the
development.
I have to agree with what Conrad says here. I've done quite a bit of
delving into the code by now, trying to fix bugs, and because of the
lack of documentation, both within the code and without, I'm still as
ignorant of how Gnucash actually knits together as a whole as when I
started.
I agree, too. Last fall, some (small) effort was spent on documenting the core engine function for the 'doxygen' doc generation tool. You can see the results of this work e.g. in src/engine/Transaction.h, or when you invoke 'make doc'.
However, this effort never came to a point where really the 'big picture' was being documented. But of course something like 'the big picture' is essential for newcomers to not be too frightened by the code base. If somebody could step up to work on this, it would mean putting together the texts from src/doc/design, from 'make doc', and from various other places :-) , e.g. src/report/report-system/doc/report-html.txt for writing a new report, or src/gnc-module/doc/design.txt for writing a new gnucash module.
If somebody (like you, Kevin or Nigel) would volunteer to collect and write documents like that, I would happily help at reviewing/ proof-reading these.
And about a possible testing process: During my heavy-coding phase for the HBCI module (like, September through December last year), I would've loved to hear from a larger group of users and testers, and I would've happily joined any sort of formal process to further streamline testing and bug fixing. However, now since I have stopped the active coding, and many other coders seem to have reduced their commitment as well, I would agree (as mentioned above) with the previously mentioned statement: The current no. 1 challenge for the gnucash project is not so much finding a better testing/release process, but rather finding a better "how to encourage and support new developers" process... Better source code documentation is almost surely a necessary condition for that. I don't know whether it's sufficient as well... :-)
Christian
PS: As for the text format of developer documentation, AFAIK 'doxygen' can be used for big text documents just as good as for auto-generated source code, so maybe this might be a good tool to use even for the non-autogenerated parts of developer documentation.
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
