1.
Communities Over Code
How to Build a Successful Project
Joe Brockmeier (@jzb)
PRESENTED BY:
Manager, Community Team (OSAS)
This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.

2.
About Me (Briefly)
· Red Hat since August 2013
· Apache Member, CloudStack PMC, Incubator
PMC
· Former openSUSE Community Manager
· Technology Journalist ~1999-2008, 2010-2012
· Likes books, Vim, cats, music, beer, and polar
bears – not necessarily in that order.

3.
What We'll Cover
· Why “Community Over Code”?
· Defining Success
· Governance and Community
· Infrastructure
· Marketing
· How Can We Help?

4.
Don't Forget:
@devconf_cz
Hashtag:
#devconfcz
Me: @jzb

5.
What is
“Community Over Code”?

6.
Community Over Code
· How You Do Things is as Important as What
You Do
· A Healthy Community Can Roll with Changes
· People Come and Go – No One is Irreplaceable
or Permanent
· “But they're a great contributor” – doesn't
matter
· “We'll do it right later” – maybe there won't be
a later...

7.
Core Principles
· Communication & Openness (“If it didn't
happen on the mailing list...”)
· Mentorship
· Earned Rights (“Leave Your Hat at the Door”)
· Quality > Speed
· All Contributions Matter
· Users Matter

8.
Defining Success

9.
What Does Success Look Like?
· Define Project Goals
· What are you building, for whom, and why?
· Measurable
· Can you track your success? Can you trace it back
to causes?
· Communicate the Goals Often, to Everybody
· It's easy to lose sight of the big picture.
· You can be successful accidentally, but don't
count on it!

10.
Governance &
Community

11.
Governance
· One Size Can't Fit All
· Have Clear Guidelines on How Things Are
Done
· How does a user become a contributor?
· How does a contributor become a core
contributor / earn rights?
· Golden Rule
· Diversity
· Skills and people

12.
Governance Suggestions
· Everything happens on the mailing list*
· 72 hours for feedback
· Use “lazy consensus” to make decisions*
· Exceptions: Legal, missing stakeholder, security,
etc.
· Leave your Hat at the door
· Company / titles shouldn't matter
· Make decisions stick
· Document, document, document

13.
Infrastructure

14.
Care & Feeding for
Community
· Mailing Lists
· Forums ?
· Bug Tracker
· Documentation / Wiki
· Code Repositories
· Trello / Kanban, etc.?
· Continuous Integration (CI) & Testing Infra
· Translation tools

15.
Face to Face
· Nothing beats in-person bonding.
· We still don't have beer over TCP/IP!
· You can't depend on in-person collaboration
all the time – but try to make it happen
sometimes!
· Find time for learning, doing, and socializing.
· Carry as much as possible back to the rest of
the community.

16.
Marketing
& Promotion

17.
Audience & Goals
· What are your goals?
· Fuzzy goals == unfocused
· Who are you trying to reach?
· Personas / profiles of users
· What do they want?
· Craft a story / message around how your project
fits their needs. May need to “fix” the project!
· Feedback loop
· Talk to users, use their ideas!

18.
Project Voice and Messaging
· Tailor Website to users
· Have talking points / messaging for the project
that explains it to new folks
· Explain benefits, not features or low-level
technology
· Show me how to be successful, quickly

19.
Blogging and Social Media
· Take the time to write about what you're
doing.
· Video / screencasts are also good – but remember
the old-timers.
· Find contributors to help run social media,
blogs, etc.
· Provide social media guidelines!
· Advanced: Editorial calendar, SEO, scheduled
tweets, target influencers

20.
Releases!
· Start planning release announcements early
· Ideally, before the first alpha
· Identify publications that might be interested
· Identify partner projects that might help
promote your project
· Go big, but don't just focus on releases!

21.
Summary
· Community is a process, not an end state
· You will never, ever, ever be “done”
· Successful communities change
· Single-company projects < Diverse projects
· If you build it, you still have to promote it
· If you're not growing, you're dying
· Golden Rule

22.
Questions?
example@fedoraproject.org
CONTACT:
License statement goes here. Creative Commons licenses are good.