Strong foundation and core principles, environment that promotes checks and balances, and human interactions with empathy, acknowledgement and inclusion.

1. GROWING DEVELOPER
COMMUNITY ONE PULL
REQUEST AT AT TIME
Strong foundation and core principles, environment that
promotes checks and balances, and human interactions
with empathy, acknowledgement and inclusion.
Alex Bulankou,
Engineering Manager,
Facebook Seattle

2. Intro
◦ Alex Bulankou, Engineering Manager, Facebook, Seattle
◦ My experience
◦ Facebook, Video Metrics
◦ internal services that calculate metrics from player signals, Multiple other
teams contributing definitions for input events, business logic, dependencies
and consumers
◦ FB environment: influencing without formal authority: through design, code
review and rollout
◦ Microsoft, Application Insights
◦ 10 SDKs on GitHub
◦ Repos in 10 languages supported by a team of 5

3. Plant Metaphor: What it Takes to
Grow One
Soil: substance,
foundation,
structure
Water: human
interactions
Sunlight: Environment

4. SOIL =
STRUCTURE,
FOUNDATION
Foundation, core principles and unifying theme is the soil
of the project, the structure that will keep the developer
community united.
Vision Principles Foundation Ownership

5. Vision and Principles
◦ What is your project?
◦ What is your project NOT?
◦ Why does it need developer community?
◦ In the time of disagreement and uncertainty,
you need strong principles to lean on.

6. You Need a Good Core
◦ Community is attracted to strong foundation
◦ Core of the project: key functionality, set of algorithms,
interface definitions. Make sure core is healthy.
◦ Sort out the IP. Ask for help. Don’t assume.
◦ Choose the right contribution license. If unsure, don’t make
public.
◦ Don’t take dependencies on the libraries, if you don’t understand
license model
◦ Common mistake: leaving core part or the project private,
i.e. not providing access to community, when it is required
for day-to-day development and debugging.

7. Ownership and Responsibility
◦ Who makes decisions?
◦ Go back to principles. Why do you need developer
community?
◦ You can take where community wants it to go, but where
does it leave business?
◦ Responsible ownership example:
◦ Core team signs off on changes to key areas, code
coverage regressions, large changes
◦ Test failures won’t let you check in, when integration
tests fail, last change is rolled back
◦ Branches: regular snap from dev to stable branch. All
contributions go to dev branch, it integrates into stable
branch at regular cadence

8. Can you grow developer
community without strong
foundation?
Without foundation, you get areas of growth
that cannot be kept together, eventual erosion,
break-out and forks and developer community
abandoning it.
Water ~ human
interactions
Sunlight ~
Environment,
process

9. SUNLIGHT =
ENVIRONMENT
Well defined environment is the sunlight that will
promote sustainable growth
Simplify, Automate, Document
Transparent Planning
Scheduling Model
Design Reviews

10. Simplify, Automate and Document
◦ What we know makes us biased
◦ The feedback from new people on the project is so valuable
◦ Any process too complex to remember is not worth following
◦ Favor automation over documentation
◦ Hackathons are glamorous, but automate’thons and
document’a’thons have much larger ROI
◦ Never let investigation and debugging go to waste:
observe the magic happen and have it documented

11. Transparent Planning
◦ Why do people and projects choose secrecy over
transparency? Ulterior motives or desire to “protect?
◦ Have a visible cadence and plan for everyone to see
◦ Good practice:
◦ link stable branch snap to the milestone
◦ Use tags on GitHub issues to indicate when they are
planned for
◦ Invite people who opened the requests to join the
planning calls and provide context
◦ Great way to attract attention to your project. But be prepared:
anything can happen during free discussion 
Issue
Session collection not
thread safe
ErrorLogger interface
OOMs during report
generation
@sandman
@sandman
@xyz78 M2
M1
Conf20180601

12. Use Design Reviews to Avoid
Surprises at Pull Request Time
◦ When pull request is ready it is too late to question
the how
◦ Too often it leads to wasted effort or sub-optimal
compromise
◦ Solution: design reviews
◦ Require large pull requests reference a design review,
approved by core team
◦ Assign design reviews to core team engineers so they own a
decision
◦ Don’t be afraid to scare off contributors with design
reviews, what scares them more is unpredictable PR
reviews.
Issuev
ErrorLogger interface
ErrorLogger Impl
DesignReview
DesignApproved
@xyz78
@sandman

13. Scheduling Model: Review Now or Code
Later
◦ Reality: you have more requests than developers
◦ Don’t say no, look for options
◦ Verified model for internal teams: propose to
consult and review if implemented by another
team or schedule for later
◦ Make the list of current requests and prioritization
criteria transparent
◦ Create and assign tasks around planning and
prioritization first, then worry about completion

14. What Happens If Project Doesn’t have a
Well Maintained Environment?
You get a ”tundra”, dormant,
growth is crippled, but ready to
wake up and grow.
Software project analogy: project
that is impossible to build, unit
tests, missing documentation to
get started
Soil ~ substance,
foundation
Water ~ human
interactions

15. WATER =
HUMAN
INTERACTIONS
Human interactions is water that will keep nourishing
developer community
React Immediately
Show Empathy and Backbone
Acknowledge and Include
Facilitate Learning

16. React To Questions and
Pull Requests Immediately
◦ Consider reality
◦ We (online users) are competing with goldfish
in whose attention span is bigger
◦ Goldfish is winning
◦ However
◦ most projects won’t have any support
whatsoever, let alone fast reaction
◦ as soon as you respond, the status of your
project is elevated to a different category
◦ if you respond while they are still on it, it is a
guaranteed follow through, you got them
◦ Internal is really no different

17. Show Empathy *and* Backbone
◦ Show Empathy
◦ Be a good physician: understand before you diagnose
◦ Even if you reject the contribution, don’t ignore the symptoms.
◦ Even if they end up forking your project and not contributing,
aim to understand
◦ Show Backbone
◦ Example from a Design Interview
◦ In times of uncertainty go back to your principles and why’s
◦ Why did you create the repo?
◦ How badly do you want this contribution?
◦ Your reputation and sanity of your team is more important

18. Acknowledge and Include
◦ Give all credit to outside contributors
◦ @mention them as often as you can: in
code reviews, in suggestions to other
contributors, weekly summary, hero board
◦ Include them to design discussions, reach
out for advice

19. Make your Project Someone’s Learning
Opportunity
◦ Real project experience if the critical (and
missing) part for many student developers,
especially those with less known schools
◦ Open source projects sponsored by big
companies provide this opportunity
◦ Add the learning component: difficulty rating,
language track, proficiency scores.
Issue
ErrorLogger interface
Add error log sorting
L300 @xyz78
@sandman
c++
ReactJS
L200

20. Project with good foundation and
process but without human support?
Soil ~ substance,
foundation
Sunlight ~
Environment,
process
Feels like a desert or ghost town: why all the well
defined foundation and processes if no one is
there to contribute or code review? In reality:
rare and easiest to fix.

21. Putting it All Together
Vision
Principles
Foundation
Simplify, Automate, Document
Transparent Planning
Scheduling Model
Design Reviews
Ownership
React Immediately
Show Empathy and Backbone Acknowledge and Include
Facilitate Learning

22. Thank you