Growing Developer Community One Pull Request At a Time
- 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
Editor's Notes
- #3: For some time now I have been working in the environment where major part of the success on my team relies on how successful we were in igniting interest of developer community both within our organization and externally. It is about influencing without formal authority, they have other choices. So I summarized my thoughts about how you can get their hearts and minds. From the instant your project is open for public contributions or you are looking for internal teams to add contributions, everything you do and how, including structure, process, timing, communication and guidance has to be deliberate and well-thought. In my current role as Engineering Manager at Facebook, I support a team that is responsible for an internal service that calculates video metrics. Our contribution model relies on multiple internal teams enabling their custom metric generation scenarios, ranging from straightforward to very complex changes involving complex business logic. In both cases we would have never been able to accomplish what we did without contributions from developers, however how you go about inviting and facilitating developers makes night and day difference. At Microsoft and I led the team that owned and maintained more than 10 GitHub repositories for Microsoft Applications Insights SDK libraries, with the most active one of them 100+ commits per week. Different challenges: authority to influence internal contributions, but no resources to promote the repos externally From the instant your software project becomes available online for others to see, learn about and contribute, everything that you do, and how you do it, including timing, efficiency, consistency and tone of your communication, documentation is critically important, it has to be deliberate and well-thought.
- #4: What does it take to grow a plant. I really hope we don’t have agricultural experts. When showed by 5 year old this draft he told me that they learnt about fertilizer in their daycare. Any metaphor that has become a cliché is the easiest to remember. Soil = substance. What does your project do? Why do you need a developer community, is it a good reason? Driving your vision through community efforts, discovering what functionality to expose in API layer Sun = environment. Is your repo a friendly place? How easy it is get started, is it easy to build and run, is there automated build, code coverage measurement, unit tests and documentation. Water = Interactions that power your repo. What happens without them? Think of best idea and best initial setup but no developers, code reviews left untouched. Can you imagine a project with best foundation and bet process, not people to follow..
- #6: Don't postpone the hard questions. Don't think, let me get the community first and then we'll figure it out because the community can sense that you don't know. What kind of plant are you trying to grow: a flower, a cactus, a forest. Maybe you don’t need a developer community and your project is best served internally For a software project, this is when you have a pull request with 100 comments and key developers on your project are disagreeing, this is when you need the strong foundation.
- #7: It needs to be have a core unifying theme and not merely be a collection of utilities. If exposing publicly, choose right contribution license. If unsure, don't don't it.
- #8: Simple democracy doesn’t put responsibility on you but where does it leave your business? Ironically that’s often not what community wants, community wants to rely on the core team. Most successful projects have thousands of contributions from all developers around the world, but they still have a core team responsible for stability, snapping the builds, working directly with core clients. Outsource work, but never outsource your key responsibility. We’ve used this approach at Microsoft with SDK libraries. With a service you want to make this cadence daily.
- #9: You have the right processes and and people willing to help, but no strong foundation. This project won’t last long. You will get areas of strong subprojects generally clustered around visions and individuals, but there will be nothing to keep them together.
- #11: Good process: First think that comes to mind is simple, simplicity. Any process too complex to remember is probably not worth following. You either go with simple or automated. You can also with complex and well documented but it people will be doing it as a favor to you, you will burn your credibility if you push on it too hard Typical examples: running tests that requires not one but 5 steps and separate machine. Obtaining coverage that takes 1 hour and causes your machine to run out of memory.
- #12: People and projects choose not to be transparent when they have ulterior motives. So we think and we turn away. Unfortunately, it is sometimes that they are attempting to hide it from us for our own good. They don’t want to worry our pretty little heads. Story: we had internal audit to do and we were prioritizing the requirements for the audit. Unfortunately the partners didn't know that and assumed seeing no activity that we are about to abandon the repo. When you are not being transparent with your contributors they feel like you are hiding something from them.
- #14: I am alternating between practices more applicable for internal and external.
- #15: Software project analogy: project that is plagued with unnecessary complexity, lacking development process, lacking planning. Things happen but they happen very slowly, very inefficiently.
- #17: We are competing with goldfish for bigger attention span. Goldfish is winning. However
- #18: Not time consuming in the long run, because you notice patterns design interview bogus requests: system that handles orders, now can you handle messages? junior: implement and break coherence and foundation OR rudely object
- #19: Don’t be stingy with credit and recognition You don’t give up any control when you include
- #20: Students will take this experience and use it as a building block for their career portfolio.
- #22: With a bit of luck it will all produce a good developer community