20,741
edits
How the FlightGear project works: Difference between revisions
Jump to navigation
Jump to search
m
How the FlightGear project works (view source)
Revision as of 17:52, 8 February 2012
, 8 February 2012→You need development guidelines: http://www.flightgear.org/forums/viewtopic.php?f=3&t=11646&start=75#p121664
m (→You need development guidelines: http://www.flightgear.org/forums/viewtopic.php?f=3&t=11646&start=75#p121664) |
|||
| Line 85: | Line 85: | ||
The problem is that the reason that these things do not exist already have to do with how things are in practice - and you're not discussing that. The consequence of developers paying more attention to what users want, rather than what they are interested in, and not being free to ignore suggestions is that I potentially am asked to work on something I personally dislike because enough users want it. Nobody has said it to my face that this is what you want - but you don't need to, I can work out the consequences myself. Your whole case collapses because it doesn't talk about how to do things in practice: Who gets to decide what a relevant suggestion for the benefit of the project is and what a petty suggestion for the benefit of a single user is? Who gets to determine the guidelines and how - and what happens with people who don't want to follow? What happens if a developer doesn't want to code a feature even if 500 users signed a petition? What happens to a developer who belittles a conribution, and who enforces that and how? Once you start thinking these questions through, the moral high ground of the theoretical principles becomes a mud field of messiness and compromises. | The problem is that the reason that these things do not exist already have to do with how things are in practice - and you're not discussing that. The consequence of developers paying more attention to what users want, rather than what they are interested in, and not being free to ignore suggestions is that I potentially am asked to work on something I personally dislike because enough users want it. Nobody has said it to my face that this is what you want - but you don't need to, I can work out the consequences myself. Your whole case collapses because it doesn't talk about how to do things in practice: Who gets to decide what a relevant suggestion for the benefit of the project is and what a petty suggestion for the benefit of a single user is? Who gets to determine the guidelines and how - and what happens with people who don't want to follow? What happens if a developer doesn't want to code a feature even if 500 users signed a petition? What happens to a developer who belittles a conribution, and who enforces that and how? Once you start thinking these questions through, the moral high ground of the theoretical principles becomes a mud field of messiness and compromises. | ||
= Telling volunteers what to do = | |||
Rule #1: You can't tell volunteers to do anything. You can ask, but you have to motivate it if you want good and timely work, or any work at all. | |||
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. | |||
Whether this is open source or not is irrelevant. It's a volunteer effort; there are many of those that don't have to do with software. Think Habitat for Humanity, for instance. | |||
= Some comments on elitism = | = Some comments on elitism = | ||