/ Community/ Science

Collaborative Communities at CZI Human Cell Atlas Meeting

At the end of April we joined scientists working on Chan Zuckerberg Science's (CZI) Human Cell Atlas (HCA) project to facilitate a session on collaboration for scientists. Improving communities ability to collaborate is a core focus of the Code for Science & Society mission. We facilitate in-person events, share our processes openly, and join community groups like the Open Source Alliance for Open Scholarship and Joint Roadmap for Open Source Tools to advance this mission. Our unique perspective on collaboration and open source comes from work with projects and people across domains from science to the arts. What does this facilitation process look like? Read on to find out!

A successful collaboration depends on people and communication. Learning how to leverage tools like Git is part of the process. To develop a sustainable collaborative process, we work through a blockers and concerns to create a project-specific method for collaboration. Our process looks a little different each time and is shaped by the needs of the group.

Facilitating Collaboration with Git for Computational Biology #

At the CZI HCA event, we worked with research scientists for two hours with the goal of improving their collaborative processes. The participants represented a mix of computational biologists, bench biologists, students, postdocs, and faculty. Most of the people at the session were familiar with Git but not regularly using it for collaboration. It's often easier to learn Git than it is to develop a Git-based workflow for a group. The basics of Git can be covered in a day. Developing a lab workflow that is sustainable takes communication, iteration, and commitment.

Starting with terms and concepts #

To ensure a successful session, we make sure everyone is comfortable with the terms and on the same page. We began with a terminology review of Git. This helps to raise a questions (e.g. when to make a branch vs when to fork) that we return to later. We also reviewed the role of common files, such as a README, that help set a project's norms and expectations.

Motivations and blockers #

After discussing terminology, we to motivations and blockers. We wanted to surface attendee motivations and blockers in team collaboration. To get at this information, we asked attendees to answer the following questions:

  • What's the easiest part of your daily collaborations?
  • What do you want to improve?
  • What is keeping your team from using a Git-based workflow?

What's easy? #

To identify and create standardized communication and software development practices for their labs, we started with what's working. We ask the question "What's the easiest part of your daily collaborations?" to start participants off thinking about what works for them now. Later, when we discuss blockers, we can return to "what's easy" and re-frame the blocker in terms of what the participants have identified as easy for them. We saw answers such as:

  • in-person conversations
  • regular communications they have with their lab
  • when I know who is responsible for what
  • we know who needs to make decisions
  • communication is clear

Two categories of answers came up. Conversations with people and situations where expectations are clear are the core of well-done group collaboration.
(One participant who runs a research group brought up SCRUM, see Adapting Scrum to Managing a Research Group for more.)

What needs work? #

By asking "What do you want to improve?" we looked for common themes motivating participants to attend the session. Most of the participants already knew how to use Git. However, a knowledge of Git does not guarantee a smooth collaboration and a successful project.

There were two categories of responses: technical skills and project management. Some participants wanted to improve their working knowledge of Git, for example a person who understands branches but is not sure that they're doing right and is looking for best practices. Other participants wanted to improve their team's approach to project management and were interested in implementing code review, standups, and other processes to keep the team working together efficiently. Some of the answers were:

  • get a handle on branches, forks, merges
  • get everyone on team aligned doing things the same way
  • getting feedback regularly
  • code review

Code for Science and Society has put a lot of effort into understanding and developing systems for diverse teams. We've seen that the best process tends to be the one that can be adopted and sustained. In our discussions of best practices, we surfaced some key points, reviewed open source best practices, shared community resources like openopensource.org, and discussed how to use issue templates.

Blockers #

With a view of what was easy for participants and what they wanted to improve, we then moved on to discuss the specific blockers. We did this by asking, "What is keeping your team from a Git-based workflow?" Interestingly, the main blockers were things we classify as people problems rather than technical problems. Examples included:

  • people in my lab have different levels of understanding of Git
  • communication — lack of common language, lack of Git familiarity
  • some people don't like change
  • students have projects of their own and don't have collaboration needs

While most of our participants had a good understanding of Git, not everyone in their work groups are at the same level. This creates situations where there is no common process or understanding. Fortunately, team members don't need a deep understanding of Git to collaborate. People who are not familiar with Git can use the GitHub web interface to submit issues and comments, contribute to project management with GitHub Projects, and write documentation and user guides. This is critical to helping those people develop comfort with GitHub and incorporating them into a Git-based workflow, even if they won't be making commits for a while.

The last two points raised by participants fall into the "we don't need to bother with this" category. Some people don't like change. However, we have seen people who are resistant to change get on board quickly once they see a project progressing. An open source style workflow allows anyone in the group to see project progress, and this tends to have a motivating effect on supervisors and others.

The flip side of "we don't need to bother with this" is a scientist who is used to working independently. In most groups there is an expectation that their code and methods will be reused by future lab members. Even an independent project can benefit from code review. We encourage people to onboard independent workers with a code review process that formalizes and documents the comments that are already happening in the lab. (See this Gist on code review and scientific review in labs. See also Mozilla Science's Code Review in Labs)

Initiating a standard collaborative process #

The majority people who attended this session were looking for advice on best practices that were specific and relevant to their work and processes. There's no magic recipe for a good collaboration. Attendees were able to connect with other groups who collaborate with Git. At an event like the CZI HCA meeting, the opportunity to make connections with other groups working towards better project management on similar projects is valuable. Finally, by creating a space for honest discussion, we set up groups to evaluate their existing project management workflows, surface and discuss blockers to best practices with their labs, and push for improvements.

We're always interested in working with groups to bring the best of open source workflows to projects in new domains. If you're interested in working with us — reach out! hi@codeforscience.org