It's a thorny problem, there are several distinct classes of documentation and each are least worst served by different schemes.
- style guides and other "how to do business" -- something formal but easy to edit like a well sorted wiki section with a designated caretaker to keep it nice - designs that are under discussion -- wiki pages under a section devoted to that activity - designs that are ratified -- something tamper resistant like a pdf (from docbook or ODT sources) - implementation details -- POD, inline docs made by the developer; release manager would review and could reject if missing I've never seen it done well if that helps. -reed _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
