On 10 Dec 2004, at 09:28, Danny Angus wrote:
If you were starting all over today, what things would you have done differently? What are the blind alleys?
<snip>
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.
+1
danny's covered all the fundamentals well but here are a few random personal recommendations:
unit test everything. encourage a healthy culture where developers contributing code patches and users reporting bugs contribute unit test code.
let everyone know exactly how much you value documentation patches. documentation is of equal value to code and don't be afraid to make people committers who have only contributed documentation.
remember the rule of three: it takes three committers to form a quorum. the natural process by which committers are replenished seems to break down when the number of committers falls too low. action may be needed if the number of active committers on an active project falls too low.
beware too many organizational layers. flat is best. having a single sub-project with many releasables artifacts sharing the same community space (mailing lists, committer lists, voting eligability and so on) has proved more successful (see jakarta commons) than a complex web of sub-sub-sub-projects. factor along community lines: groups working on different releasables being unhappy about sharing the same community space is a good sign that they are two separate projects. (most modern email clients have good filtering support so provided conventions are adopted, several different code bases can be easily support on a single mailing list. for those unwilling or unable to set up filters, using a news reader and www.gmane.org works well.)
mentor new committers and projects either formally or informally. this is the best way to ensure continuity of culture.
devise a way for sub-projects to be monitored and potential issues picked up before they blow up. (this is an area where jakarta has had problems in the past and IMHO we don't have good answers for this one.)
take legal issues seriously and make sure a few trusted people have the means to act first and discuss later. these actions should be provision pending a properly constituted decision.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
