https://twitter.com/michalmigurski/status/421033907757121536 ("Wanted: IDEO-style method cards (http://www.ideo.com/work/method-cards) for community management and open source stewardship." "When you’re spinning your wheels, pick a card for an action that will help get your community unstuck.") also for ideas - http://opensource-events.com/ http://open-advice.org/ http://producingoss.com/en/producingoss.html (ask) New participant experience HOW: Ask new members what their introduction to the project was like, what they stumbled on. WHY: Reveal hidden stumbling blocks that experienced members have mentally worked around but are still causing problems. OSM - as a new contributor, I was really confused that new changes took a long time to show up on the map; telling experienced users this caused at least a better note about it to be put into the main editor. (learn) Motivations HOW: What are the deeper motivations of people working on the project? Sense of personal accomplishment, sense of service, learning new things? Some ideas from a cynical game mechanics perspective (but still useful): http://techcrunch.com/2010/08/25/scvngr-game-mechanics/ WHY: See if the project is reinforcing those or breaking them. OpenHatch - for me, I think I contribute to learn how nonprofit social change organizations work, learn what is effective and what isn’t; add new skills and practice old ones. knowing this helps other contributors figure out tasks for me, like helping with a fundraising campaign. (look) Boundaries/barriers HOW: What are the markers of a participant? Is there any ceremony / commitment about it? What keeps people in, and what keeps people out? What is the ladder of increasing commitment to the project? WHY: Figuring out how to help people go up that ladder, figuring out how to help discourage people who are unhelpful to the project. Even very open projects have some kind of barrier, but usually it's implicit. Cydia - there is a huge first step on the ladder - from knowing-nothing to knowing enough to be willing to jailbreak, and then from there, people tend to stay in the community if they also have friends in the community and become a local expert. they might do that by becoming part of a forum. so - we make forums more obvious and easier to join. (ask) Letters HOW: Ask people to tell you why they like and care about your project. WHY: Boosting morale. Often you just get bug reports and complaints, and the happy people are quiet since they're happy. Giving them an invitation to say nice things can be wonderful. Delicious - we asked for letters in exchange for sending out stickers, and it was a hugely positive experience reminding us that a lot of people cared a lot about delicious. (look) Google results HOW: Google your project. what do you see? WHY: It's so easy to forget about this basic entry point into your project. You find out who is speaking about it for you. Cydia - Sadly, lots of scams and spam blogs come up when searching for jailbreaking topics, adding to the difficulty of joining the community. (try) In person meetings HOW: Get contributors/users to talk to each other in real life, even just with local coffeeshop meetups of a few people. WHY: The different context + real life socializing patterns generate ideas and connections. And people who snipe at each other online often find they are OK with each other after sharing a beer. OpenHatch - at an in-person sprint, I knew I could get some focused attention from other contributors, and I knew my verbal suggestions weren't being logged for potential future embarrassment, so I felt comfortable with suggesting bigger ideas like a homepage redesign. (try) Measure things HOW: measure anything that can be measured - how many days before a filed bug gets a response? before an email to the project gets responded to? how long do people spend on the site? WHY: measuring changes your perspective on things! OpenHatch - even the idea of considering keeping a public chart of how long it takes us to respond to emails (being held accountable for it) helps the email-answering team remember to respond to emails promptly. Wikipedia - measuring impact of automated "your new contribution was rejected" messages produced ideas for improving them - https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2011-08-01/Research_interview (look) Feedback HOW: Study in detail what kinds of responses people get from actions they take (filing a bug, saying something, contributing a change). WHY: looking for incorrect assumptions about the messages people are getting. making the implicit explicit. Wikipedia - adding ‘your change was saved’ feedback made a difference - https://www.mediawiki.org/wiki/Post-edit_feedback (learn) Fix the Wikipedia article HOW: Look at the Wikipedia article for your project (if it has one), and see what's missing or flawed about it. Make suggestions on the talk page. Or if it doesn't have an article, write a draft of one. WHY: The Wikipedia article represents some of what the public thinks about or finds important about the project, which can be interesting to look at. And it's written in a specific genre/format; spending some time in that very straightforward genre can be interesting. LocalWiki - When I was curious about LocalWiki, I spent some time improving its Wikipedia article as a structured form of studying the project and learning what various media sources have said about it (because of Wikipedia's focus on citing secondary sources).