How the FlightGear project works: Difference between revisions

Rule #2: Volunteers may or may not be inexperienced -- it has to be evaluated and management is different for the two cases. Allow a lot of time for inexperienced developers.

Rule #3: Let the volunteers learn something. You can tell them the right way to do something, and they may or may not listen. They are volunteers; let them do what they want even if it means redoing the work at a later time (example -- I had an undergrad student code an early telescope trajectory algorithm -- he wanted to numerically integrate rates because it was a whole lot simpler to derive; I explained that numerical stability would be much better with analytic positions. He coded rates, it was unstable, and he redid it as positions later. This was an extremely valuable lesson). Keep in mind that sometimes the volunteers are right...be prepared to learn something from them (the same student insisted on making a simulated sky, over my objections that it was unnecessary for the task at hand and time consuming -- and it turned out to be the single most valuable feature we have).

Rule #3A: Volunteers may want to exceed their abilities. Let them unless it's far beyond their abilities and you can't tolerate a delay (if you're in that zone, reconsider whether a volunteer effort is really appropriate). They may need a lot of help, or their work may need to be redone, or they may not finish the work. This is part of the cost of a volunteer effort.

Rule #4: BE GENTLE. These are volunteers. They won't do work you want/need if it's painful. Coax as needed, but nicely. Steer, don't push.

Rule #5: Though management is necessarily loose with volunteers, it cannot be completely absent. There has to be a coherent vision coordinating the effort, or it will be unfocused and will not serve the needs at hand.