Have you developed something useful, and want to build a community around it? Before you encourage people to find you and your project, you need to make both easily findable. It is not hard, but surprisingly many miss or disregard this crucial initial step. You also need to figure out what type of people you want to find, and where they currently are.
Top tips for managing your open-source project community effectively
Image courtesy of Shane Rounce
By Malin Sandström, INCF Community Engagement Officer
This guide is part of the Research Software Camp: research accessibility web content series.
Make yourself & tool/project findable
- Use your real name (unless you have good reasons to be anonymous), or a short, readable nickname (because a readable nickname is more memorable and therefore more useful than a cryptic one).
- Choose a reasonable, non-colliding name for your project/tool. Maybe you picked a cryptic working name; if so, it will be worthwhile to change it. Check if the name is free on Github, Twitter, and the internet at large – places where people would look for a tool like yours.
- Get a website with a reasonably memorable URL. Github pages are great for this: toolname.io is a useful choice.
- Join your community's channels: community calls, forums, Slacks, mailing lists and so on, any place where your intended community is active.
- Use the welcome/introductions channel/thread/tag, if there is one, and introduce yourself and your tool (preferably in that order).
- Resist the urge to spam the forum with information, unless you are announcing a tool release or other tool-related update, or if you can answer a question.
- But do engage with the community members where possible – helping someone with something or giving a good answer to a question are both great introductions.
Find out who your current users are, and where
Knowing the channels your community uses is the first step; knowing what they need and value is the second. Listening in for a while on community forums, calls and discussions should give you a few good starting points.
During this step, unless you have superhuman memory for people, you will thank yourself later if you take notes on key people you find, or at least add them, along with some key details, to your address book. A minimal set of useful things besides full name, affiliation and location are usually contact details (including social media handles), the name(s) of their project(s), a related link or two, and a few words on why this person is relevant to keep track of.
If you do this mapping step well, you will be able to look at your collected community members and see if you are missing something or someone. It is also useful to have this common basis if you ever expand and take on more project owners or managers.
Make it easy for new users to enter your community
Anyone you want to engage in your project is likely already busy, and committed to quite a few other things. If someone doesn’t respond to your first try at communication, don’t take it as rejection; try again at least once, and offer a range of options to interested people for keeping updated.
Newsletters are the new calling cards. When you go to a webpage, the first thing that will happen (or the first thing after those annoying cookie information banners) is increasingly often a pop-up pleading: Subscribe to our newsletter! But not everyone reads newsletters, or even if they subscribe, their newsletter notifications are buried under hundreds of more urgent emails. So, diversify your update mechanisms.
Established good form is having a low-traffic “announcements” mailing list that contains only new release announcements and other very important information. This can of course be a Slack channel or dedicated forum category or tag, but the general principle is: do not crowd the channel you use for your crucial updates, that means you will bury them under too much other information. Someone new to your community should be able to find relevant information quickly and easily.
With that in mind, try to figure out the most common questions a new user will likely have, and collect them in an easily found FAQ (Frequently Asked Questions) list. Expand as needed. This will save you time and effort over time.
Guiding new users is fun, but can also be a bit repetitive. Some time spent early on putting together a helpful tutorial or quick-start guide to refer everyone to as a start will increase the baseline of your future interactions. Once you get some active users, adding a user forum/support channel/user’s mailing list makes it possible for users to also request help from and give help to other users – making your life a further little bit easier.
Make it easy for new users to make their first contribution
Now for the real trick; converting your users to contributors. Increasing findability and lowering the barriers to participation will be an effective strategy for this step too. But none of that matters much if you skimp on documentation. Have clear, readable and most of all: updated documentation. Link to it visibly, perhaps in several places. Use a modern documentation platform rather than a text file (ReadtheDocs is the most widely used platform, with its tool Sphinx).
- Organise and name your projects clearly and with some sort of logical structure. If you have many different projects, pin the most relevant ones to the top.
- Label your issues: indicate good first issues with labels, and label your other issues too, especially the tricky ones so that new users can avoid them.
- Version your tool logically, and be clear on what dependencies are needed for your software to run, including their versions.
- Assume new users might be new to this. Write a short outline of expected actions and outcomes for a new contribution, and put it somewhere visible.
- Provide extended training materials that go beyond absolute beginner tutorials.
- Have a well thought through Code of Conduct with contact details to a named person, see the Whitaker lab CoC for a good example.
Make it rewarding for users to continue contributing
Write a useful, inviting and inclusive contributor guide (see the ROpenSci community contributor guide for a good example).
Make new contributions visible: in release notes, in update emails, in a contributors list. And thank contributors visibly! Don’t be too picky about what merits acknowledgement – include a broad range of possible contributions, not just bug fixes and new features. Non-coders or new coders can still help with the surrounding issues - writing and structuring documentation, doing PR, building and updating web pages, handling community.
Inspiring example: the BIDS contributor list.
Make space for contributors to grow
Once you have users, you can help them level up in performance and engagement. This is strategic, partly because it makes them more likely to stay around and continue contributing, but also because you will probably have more fun and less bugs with more people onboard.
Growing takes different directions for different people. Be inventive! Making space for someone else’s growth might include leaving them a fun issue to deal with, sharing your strategy for future development, moving them up a permission level, or asking them to help with newcomers.