I am really happy to see we are discussing on the documentation of this excellent project.:-)
I am also a newbie in FlightGear. I just downloaded all files and made a first successful loadbuild in cygwin. I really want to look into the codes to find out what I can do for this project since I saw there are many new(or old?) goals... I think a HLD(High Level Design) documentation will be great for me. Though I know the codes are changed quickly, the S/W architecture from a high level point of view is not changed frequently. Is that correct? If S/W architects of this project(Curt, Jim, Erik, David, Jon...) can give a brief outline of the main point of the HLD, and then some volunteers update each section they are familiar with(or are investigating on), that will be great to a newbie like me. I can be such volunteer and update such document while I am looking into codes. Of course, the update to this document should be reviewed and approved by these architects. So for these really busy guys, what they need to do is just review the doc, comment, and approve for submission. It's very difficult for us to catch up with the paces of these architects who contribute a lot to this project. If we have good documentations, more fans of FlightGear can do some(big or small) work for it and make it better and better... Thanks. -----Original Message----- From: Curtis L. Olson [mailto:[EMAIL PROTECTED] Sent: 2003年6月11日 19:56 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] next volunteer Hi Richard, Thanks for your comments. You make some very good points. Documenation is something that is hard work, but that we should all strive to do a better job with it. Being an open-source project, one of our big challenges is we don't have any full time "employees" who we can dedicate <cough>force</cough> to do documentation. We are all volunteers so people mostly do what they need the worst, or what they want to do, or what they are most interested in doing, or what is most fun. Recently I touched up the simgear documentation in several areas, and added an overview with links to the subcomponents. SimGear is big part of FlightGear, but this is low level bottom up stuff and not the top down stuff you are referring to. Even so, documentation is still something I personally am too lazy with, need to work harder, on and devote more time to. Keeping the existing documentation up to date can also be a struggle :-( (as David mentioned.) If you haven't taken a look at our "installation and getting started guide" (available in the docs section of the web site) please have a read through that. It addresses many items on your list given below. Unfortunately, for personal reasons, Michael B. (it's chief architect) has been unable to continue updating this document. Hopefully Martin S.? and others can keep going with it and keep it from getting too out of date. (It's written in Latex by the way) :-) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org Richard A Downing FBCS writes: > This is my point about documentation. I think David's passing shot > about an O'Reilly book should be taken seriously. When I was in > management I would always tell my programmers: ' No program exists > without full documentation!' - if it's true for commercial software, > it's doubly true for volunteer-supported Open Source. FlightGear > with SimGear and TerraGear, JSBsim, YaSim etc, is more complex than > many expensive software packages with whole companies of support > workers behind them. > > I've only just discovered FlightGear, and I'm enthusiastic to the > extent that I'm trying to build a better scenery model for my part > of the UK, but as Tim says, this is an uphill struggle. Even with > David's excellent Scenery Tutorial. Without all Curt's work and his > and other's papers from the website and in the distribution files > nothing would have been possible, please don't think I'm in any way > critical - it's just that I see an opportunity... > > In my 35 years in the IT industry I've probably read and written > more software manuals than many people have had hot dinners, and I'd > volunteer to author/edit, but at the moment I don't have the > knowledge to do that for FlightGear. The way to attack it is to use > the Elephant-eating principle (one bite at a time). My list is > probably biased to my needs: > > 1) What you can do with FG. > 2) How to get FG, build and install it on your platform. > 3) Learning to fly GA with FG - VFR. > (oops, now we need good local scenery for somewhere!) > 4) Learning to fly GA with FG - IFR. > (and now we need the weather too) > 5) Ground studies for Simulator Pilots (reference the common books) > 6) Building Scenery for FG. > 7) Making Aircraft Models for FG > (a) The Visual Model > (b) The Flight Dynamics Model in JSBsim. > (c) The Flight Dynamics Model in YAsim. > 8) Internal Construction of FG. > 9) Building a new Flight Dynamics Module for FG. > 10) 'Hacking' on FG and > (a) List of 'Things yet to do...' > (b) Repository of documented good ideas. > (c) Hints not yet well documented, but worth knowing... > > <Emphasis> When <\emphasis> I have built some good scenery, with key > structures, for the SE UK, I plan to get into (6) above. I think I > could write a UK version of (5) and maybe (2) now, but it'd be > pushing the envelope! > > Since XML seems to come naturally to people around here, why not set > up a FlightGear-The-Book projectin a cvs repository? Then people > can get html, pdf and whatever else formats. Or you could use > LaTeX. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
