On 07/16/2007 01:10 PM, Stuart Buchanan made a number of excellent points: > A far better approach is to look at how we can make our processes > more efficient so that the management (of which you are the CEO) can > make better use of their time. I think what is required is more > delegation. > > Martin Spott mentioned on the list problems with getting the web-site > updated promptly, presumably because you are the sole maintainer of > the site, and have too much on your plate. I don't feel that the > web-site is something that has to be maintained by the CEO - it could > easily be delegated. > > Similarly, John Denker recently commented on the huge proportion of > checkins made by Melchior Franz. Melchior does a quite incredible job > ensure that the data tree in particular is kept in good order, and > committing huge numbers of contributions. However, I'm sure his life > would be much easier if more aircraft maintainers have commit > permissions. The ocassional bug might fall through, but most > maintainers have enough pride in their work to fix bugs, and Melchior > would still have commit permissions... > > The Manual is a prime example of where delegation has worked > extremely well. Martin and I both have commit permissions and have > made significant changes without any need to bother anyone. > > Therefore, I think it would be a good idea for you to look at what > can be delegated from your workload onto other people and suggest > appropriate roles to the list. > > Of course, good delegation is one of the signs of good management :)
I was going to write something similar, but Stuart beat me to it, and did a better job than I would have. Let me add a couple of minor points: 1) I changed the subject line. "Chaos" means different things to different people, but in any case it is too strong a word. -- There are always "issues". -- There is always room for improvement. -- Right now the development process is not broken, and is nowhere near chaos, but everyone agrees there is room for improvement. -- The recent trend has been in the wrong direction, which makes it especially timely to examine the issues. 2) As a specific constructive suggestion, it seems to me that upgrading from CVS to git would make things go smoother. This project outgrew CVS a long time ago. Git is available for unix and for windows. A lot of the people involved already know how to use git. 3) Among the eleventeen reasons for using git is that it allows fine-grain delegation. For each model aircraft, the principal developer could be delegated control of that aircraft (without affecting the control of anything else). 4) Code review is an area that needs attention. There are two sides to this coin, and both sides are in need of improvement: a) There are some meritorious contributions that never got incorporated due to lack of proper review ... and b) There is some suboptimal code that has been incorporated due to lack of proper review. On 07/16/2007 02:24 PM, Curtis Olson wrote: >> I don't disagree with anything [Stuart] said, but delegation is a lot harder >> than it looks. I need to find (a) someone qualified to do the work and (b) >> someone who can do it consistantly and isn't going to get overwhelmed after >> the first month and drop out of the picture. I've had several past >> delegation efforts derailed because things just didn't work out. I don't understand that. If you *add* a competent delegate, and after a few months he gets overwhelmed, you're no worse off then where you started. >> For the record, 20 different people have commit access to various portions >> of the FlightGear repository. That's true but misleading, as previously discussed. Practically all of the work is done by a muuuch smaller number. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11481.html >> Addressing the specific case of the web site. The web site is in cvs. I'm >> not the only one that is authorized to make changes. However, I am the >> only >> one that can upload those changes to the actual server. Unfortunately, >> giving access to this last step of uploading content would involve personal >> passwords and the ability to affect my paypal account and a few other >> things >> that I'm somewhat nervous about handing off. There are lots of ways of solving that problem. We agree that shared passwords are a bad idea. Always bad. Very bad. OTOH, most security should be certificate-based, not password-based. Uploading to the web site could easily be controlled by a short list of SSH public-key certificates, one certificate per delegate, with no sharing of passwords nor sharing of private keys. >> Deligation is one of the main tasks of a paid manager with paid employees. >> Deligation is needed to get the overall job done as efficiently as >> possible. In a project this size, delegation is needed to get any reasonable amount of work done. >> But in a context where a volunteer manager is dealing with >> volunteer developers, none of whom can devote 40-80 hours a week to the >> project, delegation becomes much harder. Actually, you can't even really >> call it delegation. Sure you can. This is not a new issue. There are tons of all-volunteer open software projects. There are also boy scouts, girl scouts, garden clubs, bowling leagues, sewing clubs, and even .... flying clubs, all with officers who volunteer their time. Statistics show that such organizations are a significant part of the economy (if you measure things properly). The flying club president delegates a huge amount of work to the vice president, the treasurer, the chief flight instructor, the safety officer, the maintenance officer, multiple crew chiefs, multiple assistant crew chiefs, the recruiting officer, and who-knows-what else. If you don't want to call this delegation, pick another word ... but most people just call it delegation. If a large club ever gets into a situation where one or two guys are doing all the work, those guys are going to get burned out, and then quit. At that point the very survival of the club is in jeopardy. Therefore it is crucial for clubs to appoint officers who know how to delegate wisely. >> Right now we depend on a precious few people who really know the code >> backwards and forwards and just "get" the project so to speak. However, >> there is so much work todo, that there is a very real danger that these >> people will burn out and dissappear. Exactly! That's a core problem that needs to be addressed. Also: If the code is so obscurely written and poorly documented that new well-qualified people cannot get up to speed in a reasonable time, we need better code ... not better delegates. >> What do you think would happen if I started picking >> names and assigning tasks and deadlines and demanding weekly reports?!? >> Instead I have to resort to trickery, mind games, and reverse logic to >> convince people who are already very busy that they should take on >> additional tasks Of the top-ten things that need doing, I don't see that any of them would benefit from deadlines or weekly reports. >> It appears that we have hit or are near to hitting some sort of "ceiling" in >> the open-source world. Is there a way to break through to the next level? That's mostly the right question to be asking. But I don't think things are really so dire. I don't think we are near any sort of ceiling; I think we can improve things quite a bit via simple, evolutionary changes, without the need for breaking through anything. In addition to the items enumerated above, here are some specific suggestions: 5) It would help to encourage people on occasion to improve the decorum on this list. Time-honored rules apply -- It is OK to critique the code. It is not OK to launch ad-hominem attacks against the person who wrote the code. -- Suggestions should be specific and constructive. Non-specific non-constructive remarks like "this whole thing is garbage" are unhelpful. -- et cetera. 6) The documentation is in great need of improvement. Improving the documentation would make things better in a hurry. More than a dozen specific constructive suggestions can be found here: http://www.av8n.com/computer/htm/documenting.htm ------------------------------------------------------------------------- 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
