Richard, Hi.
> I was wondering; what are the lessons learned? Everything you see is a lesson learned, what you see in practice is our best, but still admittedly flawed, practice. > If you were starting all over today, what things would you have > done differently? What are the blind alleys? I'm not sure that there is much, some practices have evolved and others have been abandoned or withered away, management structures are changing, but I suspect they always change for any project OS or commercial which has some life about it. I've set up commercial projects for former employees based upon "the Apache Way" and they do tend to work, it is all about empowering people to make the decisions which they are best placed to make, but at the same time ensuring peer review and oversight to ensure consistency and quality. The important thing to remember is that you're working with volunteers, hell we're all volunteers, and if you suceed they'll all be way smarter, and busier, than you are. So you have to keep the bar to contribution low. It must be easy for anyone who has the knowledge you need to contribute it. Keep the need for knowledge as close to the focus of you project as you can, don't make people have to learn how to use new technology just to participate. Don't have a requirement which makes people spend money or sign contracts in order to become a first class citizen. Value each and every contributor highly, judge people only on their merit. Keep it simple. Keep it public. Have one official communication channel for decision making, we use well publicised mailinglists for a reason, and stick to it, keep traffic on the lists so that everone can see whats going on now and what went on in the past. Encourage anyone to contribute, create a welcoming culture but let people earn your trust, don't form a clique. Don't form a clique. Don't patronise or underestimate people just because they can't use the tool or don't have english as their native tounge. Always try to get consensus. Have a clear and acceptable policy for expelling people and then try your damnedest not to ever invoke it. Make sure your product is in demand and of high quality. > Also, I have been researching and designing the build > process for these various projects. I've looked into > using Maven, in particular. It looks like you guys are > using Ant to drive your build process ~ are the > reasons based on history or did maven not provide the > flexibility you wanted? Do you like the way you are > generating your websites right now? Actually it is a decison made by the people who are going to use it, don't constrain people by imposing unnecessary boundaries. Opinion is mixed about how we generate the sites its not perfect (having several different processes each with its own strengths and weaknesses) but it works enough to get the job done. If you look around you'll see that as well as Maven and Ant there are a range of choices made by sub-projects and other Apache projects about how to manage this that or the other part of the lifecycle. Not all projects use the same version labelling, though most use a variation on a theme, not everyone uses the same wiki or bug tracking tool, though there are Apache systems available, it a matter of taste. As long as you are clear about what you are doing and what the benefit is, can justify it, and it doesn't raise legal or security issues there's no real reason why you shouldn't do it. There is an infrastructure which provides mailing lists, wiki, version control, web servers etc. But there are few hard and fast rules about what you *must* do or how you *must* do it. Those that there are are there largely for security and legal reasons, everything else is decided on its merits often from bitter experience. Jakarta is a meritocracy, I believe that that is why it works. But I think the real lesson for you is, don't ask *us*, have a look at what we do but ask your own community to make these choices. d. *************************************************************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
