(here's a can of worms, please forgive any erroneous assumptions I'm making)
As someone new coming to FG, it's pretty tricky to get a handle on what's going on, what's being worked on, what needs fixed and so on. Of course this is an issue for all software projects, and there's different solutions depending on the nature of the team, how many active contributors exist and so on. FG seems to have a few potential tracking 'points' - the Developer Wiki, the SourceForge tracker / bug system, some (mandated) files in CVS (ToDos) and the usual source code 'FIXME' annotations (which something like Doxygen can extract, if formatted suitably). Notably, there's a few questions for someone looking to get involved and some ancillary nice ones: - known broken things in current CVS - current tasks required for a release based upon OSG (or in general, the next planned release) - things that can be improved / fixed / cleaned up using OSG, but can wait (for whatever reason) - things that are being actively worked upon [the nice to have ones] - things that the aircraft / scenery modelling community would like to have in the near / medium / long term - long-standing bugs (and maybe why they're long-standing!) - potential quick tasks / re-factorings which could be undertaken by a new coder to the project - larger scale refactoring tasks From reading the code, the list, and watching CVS commits, plus the odd naiive email, it's possible to get partial answers to all of the above, but they are incomplete answers at best. A few of the questions, BTW, I'd like an actual concrete answer to (especially the 'tasks blocking an OSG release' one) but the main question is about visibility, i.e if there's a place any of the above is recorded by a working consensus (eg, > 60%) of developers. Obviously I have my own preferred solution to the above list (use a tracking system like Bugzilla, Trac or the SF tracker) but I'm heavily biased by familiarity with such systems, and using them in other projects. I'm aware that they might not work for FG (no one is using the SF tracker, possibly because it's a bit of dog), and they definitely don't work unless enough people use them. Equally it's pointless (and harmful) in open-source coding to be dogmatic about work methodologies (which is not the same as not having any, either) Soooo, comments on the above? Have I missed other sources of this sort of information? Am I overstating the need for it, or value of it, in a project such as FG? Are there incremental or experimental improvements to tracking the project that people would like to suggest? I'll say right now that I am pretty sceptical of the 'keep a wiki page up to date' approach to project tracking, though any system is only as good as the time people put into it. ToDo / BUGS files in CVS can work, in my experience. I'd be happy to setup a Bugzilla (eurgh) (or any sane alternative) on my DreamHost, as a slightly more usable alternative to the SF tracker, but if it's purely to indulge my masochistic tendencies, I'll stick with my current approach - many (virtual) yellow post-it notes with scrawl such as 'PROPS_STANDALONE can die' and 'why isn't magvar updated by the SGSubsystemMgr?'. Regards, James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
