Teaming Up: How to Build Your Open Science Collaboration

Mozilla

With the Mozilla Science Global Sprint coming up soon (submissions for project ideas are open until May 11), the community has been coming up with tons of awesome suggestions for projects to work on; meanwhile, new projects on everything from collaborative LaTeX to sleuthing out what references are open access on BMC to a curated bioinformatics reaction pathway database are cropping up on Collaborate, our project to highlight interesting open source and open science projects you can jump into, and learn by doing. But all of these projects have to answer the same question: how do you present an open source project in a way that appeals to people, gets them interested, and attracts collaborators who will stick around? Here are a few tips on what we’ve learned during the first six months of Collaborate:

On Collaborate

Collaborate compiles and curates open source, open science projects, in order to make those projects discoverable and connect them with potential contributors. But once someone finds their way to your project, it’s up to what you present there to convince them to jump in. A few tips for a strong listing:

  • Seek out users. Prolific and long-term volunteer contributors to open-source projects are often those who see themselves as the future users of that project. When describing your project, make sure to illustrate who you think the users will be, how you think they will use the project, and what benefit they’re going to get out of it. Your goal should be for a visitor to read your project summary and say, ‘I would totally use that – let’s make it happen!’
  • Offer some examples. Link to examples of the project in action, that help newcomers understand what the project is and get excited about being involved. If your project is such that it can be demoed on a website, all the better – if it’s not a web-oriented project, consider producing a blogpost that has figures or examples of your work thus far.
  • Describe a roadmap. The ‘Main Deliverables’ section of a Collaborate listing is there to let you describe what sort of high-level things collaborators will get to work on on your project. Don’t worry about nitty-gritty bugs or feature descriptions – that’s what your issue tracker is for. Rather, give a bird’s eye view of the direction you’re hoping to take the work in, and give people an idea of how they could fit into that.

On GitHub

Alright! People are excited about your listing on Collaborate, so they’ve joined your project and forked your repo. How can we turn that initial excitement into enough engagement to stick around and really dig in? A few more tips:

  • Talk to your collaborators. Collaborate will open an issue introducing new collaborators as they express interest in the site; try and respond to this issue within 24 hours. Making newcomers feel welcome is crucial at this stage; let them know you’re interested in working with them, and help them figure out where they can start contributing based on their skills and interests. Same goes for new issues opened – fast engagement signals a collaboration that cares about participation.
  • Have a good Getting Started guide. Confusion on what to do first can kill enthusiasm to participate in a project very quickly. Make sure the README.md of your project contains complete, current and correct instructions on how to set the project up, including any dependencies it may involve.
  • Use that Issue Tracker. The issue tracker is where you can start getting down to the details of what tasks need attention; use liberally, to get the plan out of your head and into a place where people can jump in. Also keep in mind, different issues are suitable for different collaborators; people new to the programming language or topic are best served by detailed, small issues that lay out an exact problem and perhaps a proposed solution, while experienced contributors will be more interested in big, open-ended problems that give them a chance to use their skills and imaginations. A good collaborative project should try to have a mix of both.

All these things point in the same direction – people participate in open projects when they see the value in them, identify personally with them, have a clear path to getting involved, and feel welcomed by the existing community. As always, we’ll help you polish your project listing and repo as it goes up on Collaborate and as we get ready for the Global Sprint. There is a huge and growing list of exciting projects to get involved with; we hope you’ll join us on June 4-5 for the Sprint, and anytime on Collaborate.