Protect the community: Difference between revisions
m (link fix) |
DonStewart (talk | contribs) |
||
Line 13: | Line 13: | ||
* [http://www.codinghorror.com/blog/archives/000706.html The community around a product is more important than the product itself] | * [http://www.codinghorror.com/blog/archives/000706.html The community around a product is more important than the product itself] | ||
* [http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a_.html How to Build a User Community] | * [http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a_.html How to Build a User Community] | ||
* [http://praxagora.com/andyo/professional/mailing_list_follow_up/ How to Help Mailing Lists Help Readers] | |||
== More notes == | == More notes == |
Revision as of 07:29, 17 July 2007
This page collects resources from the open source world on maintaining and building healthy communities around your open source project.
Resources
- Protecting projects from poisonous people
- Notes on this talk
- More notes on this talk
- Mailing list community care
- Avoid bikesheds (related to Wadler's Law of Language Design)
- Reaching consensus in open source
- Reaching consensus
- The community around a product is more important than the product itself
- How to Build a User Community
- How to Help Mailing Lists Help Readers
More notes
- Build a community, not just a mailing list.
- Be very conscious of tone.
- Followup with constructivly with criticisms on blogs (ie "Thanks for you criticism, how can we do this better?").
- Be careful of trolls, and just ignore them. Possibly ban them.
- Spam can't be an afterthought. Don't think oh, we won't get spammed. Google groups does a good job.
- Listen to the community. Everyone has good and bad ideas.
- Don't pay too much attention to vocal minority. But be willing to take big risks when the community asks for them.
- Have to be willing to ask for help and delegating things.