[Flightgear-devel] Project tracking

[James T. <zak...@ma...>]

(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