On Mon, Feb 2, 2009 at 8:55 AM, Rodolfo S. Carvalho <[email protected]> wrote: > Hi folks! > > On Mon, Feb 2, 2009 at 7:15 AM, Adriano Marques <[email protected]> wrote: >> Hi Bart! >> >> On Mon, Feb 2, 2009 at 9:12 AM, Bartosz SKOWRON <[email protected]> wrote: >>> What kind of documentation? Manual pages? HTML pages? txt? >> >> That's what I'm proposing to discuss about. What to document, and how. >> > > I think we could start documenting classes and functions of our own > subprojects. I think it's not that hard to do, and it could be a > kickstart. I'd like to suggest you to use ReST with Sphinx, which is > the python official tools for generating documentation. After that, it > could be nice to make help files for Umit at all. We need to think in > both sides: the final user side, and the developer side (once Umit is > a free software project, we need concern about produce code docs to > guide new developers).
There must be something wrong going on. I don't understand how we can mark documentation at this point more important than improving the current UI, for the Scheduler for example, than adding more documentation. UMIT is not a library that is used by several other programs or a programming language, I hope we still know that, so focusing on developer documentation right now is even more wrong. Right now we could start by getting to know what thing Francesco found hard to use, or what part of code, and try to make the interface better or the code clearer. This shallow talk about picking a class and functions and start document is too counter-productive for me to accept it, sorry, at least bring some more concrete. -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
