We want to open up development for everyone who wants to help us create better conversion filters. There is a free subversion repository which is available at http://svn.comsultia.com/docbook2odf/.
At fist join the community by IRC channel #docbook2odf (or #docbook) at irc.freenode.org. We would like to invite you and everyone interested in contributing to our mailing list. All development and user feedback should be discussed here as all information can be searched and anyone can reply to questions asked. Please register at: https://lists.sourceforge.net/lists/listinfo/docbook2odf-devel
Try to understand our code, maybe write some docs and some small examples. It is very important for any hacking in docbook2odf to understand DocBook, ODF and XSLT. After that, search for a part you are willing to code stuff for and let us know.
Inspiration: For example a param.xsl, pagesetup.xsl and templates xml.
Task is to implement all DocBook tags to OpenDocument over XSLT, with special emphasis on quality of XSLT on output and way of implementation in filters (comments and style of coding). It is also very important to make tags configurable in their interpretations (for example - "role" with some tags) and their free reinterpretations with CI (corporate identity) overlay.
Full list of current tasks can be found in roadmap.
The most difficult problem is: how simplify the way of getting the final project to end-users.
We believe the most ideal way to get the project to end-users is to create ebuilds for Gentoo and put these on the web for download and later to become a part of portage.
I'm considering to split the packages to 2 packages:
As for version counting I would like name the ebuilds by svn revisions. eg. docbook2odf-0.[rev_num].ebuild
The install process itself currently consists only in copying the style sheets and perl scripts to the host system. There is no compilation involved but that could change in the future.
This should be a minimal set of documents used to validate and identify problems with generating ODF. Such documents could for example contain all possible tags. These should be stored in the test/ directory which should contain files such as test001.docbook.
The test result should report the failed test document if an error occurred.
Similarly to test documents we would like to provide some examples which could present the features such as creating presentations etc.
Please submit feature requests using this feedback page.