I'm not quite convinced that the pseudo-code would be the best way to go - in my experience, programmers know for the most part exactly how a program needs to be written, structure-wise, in order for it to do what they want. The thing that usually keeps them from putting working code on the field is the lack of time to get rid of all the little bugs in the functions. On the other hand, I agree that providing code that is functional right out of the box would not be beneficial at all to programmers who are trying to develop their skills.
What I suggest, then, is that the FPG provide two things: Firstly, an easy way to get direct support from knowledgeable programmers. Secondly, a collection of code libraries, not at all implemented in the default code, which can be used for such things as position tracking, navigation, and driver control. I would liken these libraries to any other shared library in the open-source world - take the Windows APIs, for example. The Windows functions are provided to you for free, are relatively free of bugs (ok, maybe Windows is a bad example here
), and no-one likes to fiddle around in assembly with software interrupts (except me, of course
), but you still need to have a pretty extensive knowledge of how the APIs work and a good amount of programming know-how to be able to implement them properly.
To sum up, while just providing 100% functional robot code would be bad, providing pseudo-code wouldn't help much either since the debugging time problem would still be there, so in my opinion providing unimplemented but completely tested libraries would be the most effective compromise.
As for the meeting issue, maybe a Wednesday night meeting in Atlanta wouldn't be the best idea, considering many people won't be there (I'll either be at the de-crating itself or still on the bus from Montreal). It might be easier to schedule an IM session sometime.