<< snip >> > >At least some introductory document should be available for every > project, even > > - or esp. - in this nascent stage. > >I talked with Jeff Biss about it, and suggested to use doxygen > throughout the > > entire source. That would be a dream for every new member, and > minimal effort > > for the author of the code IMO. (of course the OpenBeBook is still > needed as a > > readable API-description) > >A shining example in this regard is the VM-Preferences-app! > > Yep, but we need some decent output, and doxygen is not too good in > that. Ah well, I'll see if I can get something up as an example for > discussion, but I think it will be pretty difficult to get this going > in a way we all (or most) will agree on. > I think that one thing we could do is just agree on a standard right now, some common way of documenting our code, and then during the next x weeks work on a parser for that commenting system so we can get output how we want it. If we're thinking essentially of an automagically updating OpenBeBook, I don't see a whole lot of problems with coming up with a very simple program to get the output we want. The important thing would be to come up with a standard way of documenting code soon, whatever it is, before we end up 80% completed with no common documenting system. I think that a while back there was some talk on the list about an OBOS documentation group, or something like that - checking the Teams page on the website doesn't show one, and I don't really think that an entire team would be needed to come up with a decent system - I'll volunteer to come up with a document describing syntax, etc if that's something the group decides we need. Matt