On 7/17/07, Tim Moore <[EMAIL PROTECTED]> wrote:
I agree with the observations and suggestions that John made. I also
agree that the development process isn't really broken, but there is
frustration with the slow pace of releases. FlightGear is not a huge
project, but it is pretty big and faces some interesting challenges.
Because realism is the stated goal, the problem domain often requires
specific knowledge of aeronautical engineering and physics, not to
mention flying experience, as well as coding skills. It's not too common
to find these traits in one person. Also, the "data" assets of
FlightGear are huge and have many contributors who don't consider
themselves developers, even though more and more development work is
happening in the data tree due to the powerful scripting support FG has.
Then there is the scenery, apparently off in its own mysterious world...
Curt, if there was a company willing to pay you or one of its own
employees to be the FG "manager," I suspect that you'd already be able
to identify it. The key here, as John suggested, is not to delegate your
responsibilities to one person but to a group of people. Many free
software projects do well with a "core" of developers that manages a
wider circle of developers who make contributions in specific areas of
the project. The core sets the direction (as much as that is possible)
of the project and decides technical and non-technical issues. Projects
use many methods to reach a consensus, ranging from straight-up voting
to reliance on a benevolent dictator to resolve disputes.
I've always felt that the FlightGear project has enjoyed a healthy core set
of developers. In the past, core developers have typically earned their way
in through demonstrating a history of well conceived contributions to the
project and through that showing they have a good understanding of the
project and also [important] showing they can work effectively with the
existing team. New core members are added through an informal consensus of
existing core developers.
However, we've experienced some significant attrition recently in our core
group. I want to tread delicately here, but we've also experienced several
flaming threads recently that were primarly driven by one or two strong
personalities. (This thread may even be an off shoot of one of those.) This
has magnified the issues and set everyone on edge.
Perhaps the core issue here is (or should be) how do we fill the voids in
our core development group? Does our conservative and safe "earn your way
in" approach perhaps needs to be replaced with something more agressive and
risky so we can build our core set back up to healthier numbers. How do
other projects select core developers?
If someone contributes patches that no one in the core or wider circle
of developers feels competent to review, then it's not too much to ask
for references to the subject matter so that everyone can become better
educated. Perhaps the contributor is a good candidate to become a
developer for some section of the code base.
Some projects with which I've been involved use a system of time-boxed
releases. For example, every 2 months a branch is made from the main
source tree and becomes a release, ready or not. Automatic testing helps
with this strategy -- of course it helps in general. One could write
automatic tests for FlightGear using the scripting and scenario support.
I hate to roll too many discussions into a single message, but ...
This might be something worth considering. In the past we have tried to get
all our ducks in a row first, then get binaries lined up, get the whole
windows setup thing ironed out (that's 95% of our user base so it's
important to do) and finally push it all out. It's a large amount of
effort, easily consuming a 40-60 hour work week. It has always become
deathly quiet when I've floated the idea of someone else taking over release
duties. :-) I have gotten good help though when I've asked for it.
Given your load and frustrations, Curt, I urge you to think about a core
who can share what you do. I bet you already have in mind the
membership of that group.
Here again, this is as much a political process as it is a technical process
so I want to tread lightly here. I'm comfortable with the existing "active"
core members. I'm sad that we seem to have lost a couple of our really key
contributors in the last year or two. This has left a noticable void.
There are maybe 2 or 3 people that I would be happy to add to the core group
but I've sensed hesitation from others so I haven't pushed.
Is it time to put out a call for new core developer nominations? Does
anyone want to take over release duties and commit to rolling out releases
on a reasonably fixed time table?
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
