On Mon, Oct 3, 2011 at 8:11 PM, Luis Falcon <[email protected]>wrote:
> > > 2011/10/2 Telesight <[email protected]> > >> Because there was not a real manual for administrators, I have started a >> Tryton 2.0 Administration manual. >> >> Hopefully it can help beginners with Tryton to understand the system and >> use Tryton as a support for their organization processes. >> >> I have setup the manual as a Google doc, not the best way for editing an >> document, but at the moment the easiest way to cooperate with others. >> >> Maybe in many ways this manual version is far from perfect, but at least >> it is a start ... >> There is still a lot of work to do, but if people like to contribute we >> can speed up a little bit! >> >> Well, let me know what you think of it ... >> >> Tryton 2.0 Administration manual version 0.1: >> >> https://docs.google.com/document/d/1L4ddmKDkEgkBoqhMoovkypXxexW3i6NG7XshsrZJvZk/edit?hl=nl >> >> Anthony >> > > Excellent Anthony. Thanks ! > > I wish you could port this to a wiki so the community can also work on it. > > >> > > >> >> >> -- >> [email protected] mailing list >> > > > > -- > Luis Falcón > GNU Health > health.gnu.org > > -- > [email protected] mailing list > This looks really good. Expanding on Luis Falcón's line of thought, what if this document was just created from RST files via sphinx and placed in another package such as trytondoc. Then changes could be tracked and releases could be made and updated for each major release. Maybe a developer's guide, administrator's guide and user's guide could all be placed there? Just a thought. Then the documentation could be improved without worrying about commits to the code repositories. Furthermore, I think it would be possible to have a rough documentation extension mechanism inspired by view/model extension tryton already does with code. This way custom modules built on top of Tryton could append their documentation, explaining changes made and maybe also remove part of the existing documentation that wouldn't make sense. So each module could then include a developer section, administrator section and user section. The problem with a single guide is that administration might change drastically depending on how the modules manipulate the existing code base. For example accounting and product management: Fields could be added. Another example might be sales: flows could be altered or replaced. Just some thoughts. -Ian -- [email protected] mailing list
