Attracting the Invisible Contributors

Tips to make your open source project more welcoming and inclusive to potential contributors

Transcript

1. Attracting the Invisible Contributors Making Your Open Source Project More Welcoming @charlottecodes
2. Who are the Invisible Contributors? • Students • Self-taught coders • Users who want to contribute @charlottecodes
3. How to use this content • For insights into diverse viewpoints • If you maintain/contribute to an open source project ◦ DON’T: Assume it’s a lost cause and ignore it ◦ DO: Make small changes at an appropriate pace ◦ DON’T: Declare unilaterally that things are changing ◦ DO: Ask for alternative suggestions from people who may object to changes ◦ DON’T: Completely disregard opinions of existing contributors ◦ DO: Stand firm that existing contributors should be welcoming • Use as a framework to help your company be more attractive to a diversity of candidates @charlottecodes
4. Sticky vs Slippery A sticky project: • Has multiple long-term contributors • Generally sees communication from people who look it up A slippery project: • May have a few long-term contributors • Sees minimal or no communication from people who look it up @charlottecodes
5. What makes a project sticky or slippery? • Communication • Documentation • Kindness • Terminology • Code of Conduct @charlottecodes
6. Communication Make it easy for people to communicate with your team! • Accessible to non-technical people • Archived interactions • Minimal downloads or installation of chat tools @charlottecodes
7. IRC Pros: • Free to use • Accessible from anywhere Cons: • Opaque to new users (difficult to understand for people not used to older tech) • No archive of old messages • In many instances, no authentication of users
8. Slack Pros: • Free option • Most people are familiar with its usage • Web access as well as apps for most OSs Cons: • Not open source • Requires signup/registration
9. Zulip Pros: • Open source • Python-powered • Familiar interface (similar to other modern team chat apps) • Available multi-platform (web/desktop/mobile) • Can be self-hosted if desired Cons: • Requires signup/registration
10. Documentation • User-focused vs developer-focused • Dev environment setup • PR submission process • Expectations after submission @charlottecodes
11. Examples of Good Developer Documentation • BeeWare (https://beeware.org/contributing/how/) • Pandas (https://pandas-docs.github.io/pandas-docs-travis/development/contributing.html) • Zulip (https://github.com/zulip/zulip/blob/master/CONTRIBUTING.md) • Your project soon??
12. Kindness • Be kind to ALL questions or submissions • Remember that Invisible Contributors will be reading what you write • You can reject without being unkind @charlottecodes
13. Responses to a Confusing Question • “I’m not sure what you’re asking. When you say X, are you referring to Y or something else?” • “If I understand your question, you might find the answer at [best-guess-documentation]. If your answer isn’t there, come let us know and we’ll try to help you figure it out!” • “I’m not sure why that’s happening. Could you show us what you did that resulted in that?”
14. Responses to a “Bad” Code Contribution • “I don’t think this will mesh well with [other-feature]. Did you talk through this with anyone on [chat-or-mailing-list]?” • “This isn’t something that we want to support. If you’d like to turn it into a plugin instead, you’re welcome to do that and handle the support yourself.” • “There are a lot of things in this PR that conflict with our style guide [link]. If you need help identifying them, feel free to ask in [chat-or-mailing-list].”
15. Terminology • Minimal jargon • Non-offensive • Pay attention if people tell you there are problems @charlottecodes
16. Examples of Off-Putting Terminology • “master/slave” (try instead: primary/secondary, active/fallback) • “OCD/anal” (try instead: particular, exacting, picky) • “guys” to refer to a group (try instead: people, folks, team, y’all, yinz) • “grandfathered in” (try instead: carried over) • “whitelist/blacklist” (try instead: safelist/blocklist) • “so easy your mother/grandmother/girlfriend could do it” • “real name” (try instead: legal name, full name)
17. Code of Conduct • Don’t re-invent the wheel • Your project is not your living room, expect to behave professionally • Enforcement is critical @charlottecodes
18. Enforcing a Code of Conduct • All of the prior points apply just as much, if not more, when enforcing CoC • Be kind, and don’t accept attacks from any source during resolution ◦ Accusations, if reasonable, are not attacks • Be prepared to remove/ban people from your project if necessary • Consider CoC enforcement workshops if this all sounds overwhelming! @charlottecodes
19. Adopting a Code of Conduct • Good example for a project (Django): https://www.djangoproject.com/conduct/ • Good example for an event (PyCon): https://us.pycon.org/2019/about/code-of-conduct/ • Good example for an organization (Vox): http://code-of-conduct.voxmedia.com/ • Tips for writing/adapting your own: https://projectinclude.org/writing_cocs# • Example of an organization providing workshops: https://otter.technology
20. Thank You! Questions? @charlottecodes