By Raniere Silva, Malvika Sharan, Colin Sauze, Yo Yehudi, Claire Wyatt (authors’ names are arranged in no particular order)

This post is part of the CW20 speed blog posts series.

As researchers, scientists, or techies we look for ways to use our skills to solve pressing, current issues. We have responded to the COVID-19 pandemic with a sudden surge of hackathons, data modelling projects, task forces, and working groups. This has resulted in an unprecedented desire to pull together, which is surely an ideal way to move forward. Nevertheless, forming effective collaborations is a challenging process, even in the best of times. So, how can we ensure that the teams and research communities we form during the time of urgency are built on the foundation of excellent science and community practices?

To help researchers address this issue, especially when starting a project during the COVID-19 pandemic, we have compiled recommendations drawn from our experience as a community and technical experts. We hope that this post will prompt people to think critically not just about the technicalities of the work, but also the social environment in which it is being conducted. 

10 recommendations for managing a nascent team or community

What If you started a project with a thought like, “I have this great idea that I want to try on COVID-19 data!”? There is nothing to worry about if you’re the only one working on it, but the moment you share your idea with others in your network inviting them to join you - you become responsible for making people feel included in your project. 

As a project lead, you want to set up a welcoming and inclusive environment and create the first set of visions and goals for your collaborators. You cannot assume that everyone you collaborate with knows what is expected of them when they start to work with others on your project. Therefore it’s important to set the right expectations from the beginning for your community, even though you might not have planned on having one (see additional background in Malvika’s talk from CW20).

In the best case scenario, you would have already planned for community collaboration in your research project, but if that was not the case, then the checklist provided below will help you in making this process thoughtful and structured. The practices listed here are derived from, and limited by the experiences of the authors who participate in several successful Open Research communities and lead community-driven projects such as The Carpentries, Mozilla Open Leaders, The Turing Way and Open Life Science, hence they may need to be adapted for projects that are very different in nature.

1. Choose a communication platform: 

• When leading an open project, use collaborative and open platforms such as GitHub. 
• Evaluate if you need any real-time communications such as a text chat system like Slack and Riot/Matrix, or if a mailing list or forum be sufficient. 
• Consider a separate internal communication platform for your community members and an external one for showing what you’ve done to the rest of the world. A Twitter account or a simple non-technical website can be useful external platforms.
• Make sure that there is a very low barrier to joining your platform. See The Carpentries and The Turing Way for examples.

2. Provide a project summary file:

• The first document in your project should be a project summary file, which on GitHub repository will be a README.md file. 
• This will provide basic information about your project so that people can evaluate why your project will be interesting for them. Here is a template by the GitHub user PurpleBooth.
• In this file, include what your project vision and goals are, why the project is useful, what the possible milestones in the project are, how a contributor or user can get started, who they can reach out to for help, and what is currently missing in the project in terms of stakeholders, skills, or scope.
• You can use emojis, GIFs, videos or your personal narrative to make your project relatable. See The Atom project for example.

3. Select a Code of conduct: 

• Add an Open Source Project Code of Conduct to your project. Don’t use it as a token, put intentional effort into it. 
• When using GitHub, you can add a “CODE_OF_CONDUCT.md” file in your GitHub repository. 
• List the expected and unacceptable behaviours, describe the reporting and enforcement process, explicitly define the scope and use an inclusive tone  (see instructions here).
• Whenever you update your code of conduct, invite comments from your members to ensure that their concerns are addressed. This can be done on GitHub issues, or Pull Requests.

4. Provide contribution guidelines and interaction pathways:

• A thoughtful guideline helps people decide which pathway they can choose to contribute to your project, or if at all they want to be in your community. 
• Make sure that your community interactions and different pathways to contribute are open, inclusive and clearly stated. If people can’t figure out how to contribute they will drop off without help. Here is a template provided by the GitHub user PurpleBooth.
• Value different types of contributions. Coding projects are not only about code, therefore list documentation and other management skills as well. 
• You can use persona and pathway exercise to brainstorm who could be your possible community members.

5. Create a basic management/leadership structure:

• A leadership structure in an open project should aim to empower others and develop agency and accountability in your community. 
• You can start by listing different tasks within your project and inviting your members to lead those tasks.
• Provide appropriate incentives and acknowledgement for contributions made by your community members.
• Create opportunities for members to share some leadership responsibilities with you in the project.
• When inviting suggestions and ideas from the community, provide a first set of plans where your community can develop from. 

6. Provide contact details wherever useful:

• Clarifying responsibilities for different members will allow people to reach out to the right person with any query.
• Add details of the designated contact persons for technical problems, leadership questions or any report on Code of Conduct.
• This will be particularly useful if something needs immediate resolution.

7. Identify failed approaches, and stop:

• Development happens in an iterative manner. Revisit your plans and ideas in regular intervals and involve your members in the process. 
• Check if there are parallel developments or multiple approaches that can be changed. Importantly, recognise what isn’t working for your project.
• Fail fast, fail informatively. Document and share why you failed and how you change your project or approaches going forward. 
• For Open Research communities you can maintain transparency when discussing failures and successes but refrain from singling out or blaming others. 

8. Have documentation and dissemination plans for your project:

• Communication is important. With new members coming all the time, it is important that they are able to find the information they need without asking you. 
• Investing in the documentation of plans will free you from repetitive questions regarding past decisions or the decision making process your project uses.
• A good place to store the documentation is wiki or platforms like GitHub where information can be updated by your community members democratically.
• To disseminate outputs of your project, you want something permanent that can be shared and cited, for example, by using their digital object identifier (DOI). Fighsare and Zenodo are good examples of platforms that can provide you with DOI for all your shareable data.

9. Address technical issues:

• Make sure that you have plans in place for people who want to contribute to your project but might deviate from your original goals very fast without supervision or guidance. 
• If a certain skill or practice is required for your project, you should be able to point people to relevant resources so that they can engage with your project effectively. Provide short video or online tutorials on skills that your collaborators might need. 
• It's important to promote practices such as code review and testing to ensure the reproducibility of your work.
• Reach out to other communities with specific expertise to save effort and time that can be invested on other tasks. 
• Encourage data and code sharing with the use of appropriate licenses, but also make ethical decisions around data privacy.

    10. Acknowledge differences and value them:

• Make sure that you invite perspectives from your members who can help you maintain heterogeneity and fair distribution in leadership, methods, dataset and solutions that can be reproduced for different scenarios or across different platforms. 
• Start by identifying who your stakeholders are. Are they given opportunities to be heard? If crucial voices and viewpoints are missing in your project, how can you invite them in? Talk to an expert (clinician, epidemiologist, etc.) if you are not one yourself. 
• Always remember that different stakeholders can introduce new but critical and often unexpected viewpoints and help you avoid incorrect or ineffective assumptions.

Conclusion

Keeping a team engaged is a continuous activity that requires regular checking in and evaluation. Based on each evaluation we can change and improve our workflow and community practices. During this unprecedented time, while we navigate through the COVID-19 pandemic situation and apply our collective knowledge to tackle the problem at hand, we don’t have the benefit of time to carry out such evaluation. Therefore it is even more important to be intentional when creating teams and communities and apply the tried and tested best practices from the beginning. We hope that the practices recommended in this post will give a good starting point for building successful collaboration through your projects.