(I missed the very beginning)
Lower the barriers to entry
Document your coding styles and conventions
Explain something more than twice ? your docs need fixing.
Log bugs for everything, no matter how small
Hosted dev en. We have 70 people on our dreamhacks.
People don't have to spend time installing, it's been done for them. show up and start working.
Clearly defined channels for coding help. IRC channels, mailing lists, contacts for projects or areas of code
Put your project through the "typo test".
Fix a typo. What do you have to do to fix it? How lng will it take a new contributor to figure out how to submit this typo patch and see the change committed and in place?

Set clear expectations:
- document, document, document.
- uphold a code of conduct or diversity statements.
http://dreamwidth.org/legal/diversity- give people goals to work towards
- create a culture where teaching is expected
- foster a sese of social reward for collaboration, not competition.
At first, Mark spent maybe 5 hours a week coding, he spent way more time teaching, getting other people going. Now that's changed and his time is freed up to code.
Denise: this shows the importance of your project culture. what is expected, what's okay and what's not okay. it's important for us to put out a social environment where collaboration is rewarded. check your ego at the door. people need a sense of approval for helping other people.
So many people liked Dreamwidth's diversity statement that it's top result on searches. It's creative commons licensed so please go ahead and use it if you like.
- Explicitly state we're interested in all sorts of contributors. Level of experience, background, stage of life, we want you, we make that clear and we want you to have the tools to contribute.
Giving people goals. Everyone wants to see things get done. (I remember this being very inspiring/exciting with the bugs that blocked launch.)
Quote from a developer "I wrote a patch! it's live on DW now!"
Keep it moving: people have short attention spans. really!
- work in steps and iterate: break tasks down.
- Manage your review queue: don't let patches rot, even if this means you get less coding time.
- Shut down bikeshed arguments quickly.
- Be as available as you possibly can
(I agree with breaking down tasks and bugs into tiny steps!)
Contributors moving through the review queue will eventually start reviewing other people's patches.
Bikeshedding. People can argue about what color to paint the bikeshed for months and years while they wouldn't necessarily argue about something more important.
Empower your community to make decisions, don't micromanage. Down the road if it turns out to be wrong or you don't like it people can change it.
Being available. We are all busy, it's hard, hard to find time to respond to bug mail every couple of days. People like to know they're being listened to. Otherwise why spend my time on it? we want to know we're being heard and feel like we matter.
"I like that everybody cooperates and it's really supportive, ... if you've had a crappy day you won't be laughed at."
Teambuilding is not a dirty word.
- everyond is allowed to make mistakes
- bug tickets are not flaws: they are chances to improve your product
- keep process open: no mysterious inner circles
- code ownership is dangerous!
- don't value big patches over little ones, place equal values on feature development, cleanup, refactoring, documentation, training
Keeping the process open. People can be senior or experienced contributors, great. but everyone should know what the decision making process is, how they can get somethnig changed, how to get a feature added. Community discussion for feature discussions then add to bug list.
Why code ownership is dangerous. we need people to understand the complicated stuff in depth. they must be stewards and not territorial. not driving people away because they like full control or they enjoy power.
About valuing patches. Yay, 3000 line patches with unit tests, documentation, code comments, and it's just what you wanted. Hurray! But little touches are very important. little interface enhancements, clarifications. They have a disproportionatly huge effect on your project! Don't ignore the little contributions, cleanup, refactoring, the less glorious parts of open source development. they also help contributors get invested in the project. scratching someone's little itch, they deal with people's particular accessiblility issues. thus your software over time becomes more accessible.
favorite moment. one moment in irc, someone submitted a much-wanted bug, there was cheering, someone said they get paid at work but no cheering squad.
THE single solitary individual exclusive lone uttermost thing to do!
RESPECT
People thrive on being in the loop
Never reject a patch without explaining
Never reject only for style reasons
Fire toxic people and moderate social channels
Never say no without a reason and an alternative
Keep asking yourself: "Is this answer bullshit?"
Denise: I learned Perl like 6, 9, months ago. with no CS background. Mark takes my patches and does a code review and fixes my quotemarks.
Toxic people. people you mention and people go "Oh, yah. THEM." you need to have a little bit of control over those people. we are social creatures. If we don't provide a social outlet on our project, they'll make one anyway.
Denise says hi to the peopel on IRC. They all say Hi!!!!!!!!!
People have really good bullshit detectors. So if you have a project culture of always being honest with people, your community will respect you because they know you're not lying when you tell them no and why you're saying no.
"I think i've found a new home. kinda cool."
three things you can start doing right now to improve the environment and process of project right now.
Freshman orientation. Appoint a welceomer and laud newcomers' first contributions. this is different from a community manager. Sophie who sets up the Dreamhack dev envs. Patient, question-answering. It's a lot of work but once you have a thriving community they will start doing it for each other. Empower this person to do stuff and fix things and answer questions and make decisions.
Ping? Pong! Stop timing out on communication when people need responses from you. IRC, bugzilla, even a short note. i got your mail, i will think about it, i'll get back to you. Get back to people within an hour or two even if you don't have a complete answer.
Problem Child. Have words with "that person" and let them know their behavior is not okay. Let them know their behavior is driving people away. the problem children and toxic people are allowed sometimes to take over the methods of communication. you as the leader can sit down with that code of conduct and ask them to tone down what they're doing just a little. If you do that, first of all it shows to the rest of your community that you are treating them with respect. Second it shows to your problem child that you are expecting them to be an element of respect in all the communications because we're all working together.
Questions are coming!
Q: what if you are there because you love the tech and not the community or people? they just want to code. what can we do to change people's idea about that?
Mark: it's a mental realignment, if your priority is make tech, okay, that's your goal. if your goal like us is to build contributor community, you have to deal with them as people. initial sacrifice of my time but personally i think it's worth it.
Denise: you don't need 100% universal buy in from your contributor base. we have people who just hack and work on the insanely complicated stuff. you need a balance of people people and tech people. let people know they dont have to be touchy feeling all the time, they just at the very least should avoid pissing people off. that's a good start.
Q: i love hearing about communities. but your slides were contradictory, they say do this do that, avoid hierarchy, but shut down the bikeshedding and kick out problem child. how do you deal with that contradiction.
Denise: every ship needs one captain. projects need a leader to make decisions and make sure things are moving along. our point with avoiding hierarchy is that you as the project leader are available to people and fostering the community, promoting people in the community up to contributors.
Mark: we want to avoid a closed community.
