EarthCube Projects: On Building Community

EarthCube projects take on the work of building community for different reasons: as a way to crowdsource development of best practices, share information and training, get input from a discipline, and find a user base for toolmaking input, feedback, adoption, and continuing development.

While building community is a need that arises for most EarthCube projects and many other scientific endeavors, few of us get advice or training in how to foster a community. Shared experiences of projects in creating and fostering communities was the primary topic of one recent Council of Funded Projects meeting.

Specifically, many projects building tools or data capabilities for geoscience research need a set of scientist users to offer input and testing during the development process, and who can help expand adoption of useful tools once mature. Some projects, like Research Coordination Networks, are primarily communities, often domain-based, with a focused collective task. Some open science efforts require an interacting community of developers and coding scientists from the start. The initial and continued success of many projects hinges surprisingly on community.

Projects were asked simply to share stories of their experiences with engaging communities – realistically, including both positive and negative experiences. Here are some of the threads that emerged.

Several groups were already focused on domain issues before they joined EarthCube efforts, or became or participated with a funded project – so some already had a group of scientists as a starting community. Existing domain listservs and networks were important sources for online community connections. Several collaborative toolmaking projects integrated specific domain collaborations and their research questions into their proposals.

Workshops were important to many of the projects, often at the beginning to establish common ground or a shared vocabulary, facilitate cross-domain communication, trade perspectives, cultivate working relationships, and prioritize needs and goals. At the middle or end of a project, workshops served to offer training, put best practices or tools into action, harvest concluding products to share with broader communities, implement advances and choose next steps. Some workshops were important in generating new collaborations, either among domain scientists, or between domain scientists and computer scientists. One project hired a trained facilitator as workshop lead. Several projects used in-person workgroups followed up with continued remote collaboration to help create specific products (e.g., white papers, published documents, workflows and code, etc.) as targeted project outcomes.

Finding one or two key collaborative scientists to participate within a workshop, working group, or other project effort was seen as critical by several projects. Identification and contact was sometimes assisted by intermediaries. Targeted outreach to specific identified individuals often gave the best results. Holding on to those people, once found and engaged, was a high priority, and required relationship maintenance. Widely seen as more difficult yet very important was identifying and inviting appropriate early career scientists, and finding and actively engaging scientists in underrepresented groups. A potential solution suggested was again the successful targeted outreach approach: requesting recommendations from active labs and key scientists.

A small organizing committee, steering group, or council of experts in particular domains was important to several projects. In some cases these groups were very important in identifying and contacting leads of highly productive labs, or led to avenues for continuing interaction or advisory roles by key scientists themselves.

Product testing and community feedback occurred under a range of event types: workshops, hackathons, field trips, short courses, student summer field courses, and gatherings adjacent to major conferences (especially just before). Often a series of events – not necessarily of the same type – was the best strategy. In at least one case a consultant ( conducted formal tool usability testing and feedback with members of a project’s community.

Communication methods were wide-ranging, and variable in their impact. In-person events, though expensive, were usually very valuable. These were sometimes critical in the case of cross-domain communication. Sometimes in-person events would have benefited from a follow-up event if funds and time had allowed. Projects volunteered that less successful communication methods included low-interaction methods, such as handouts at conferences, survey requests, and newsletters. One project has devoted much attention to building its community of scientists, coders, and – especially – domain scientists who code. They communicated initially only on GitHub (where its website and software modules are built), then branched out to Discourse to accommodate more people, and have public fronts in a blog and on Twitter. While they’re beginning to feel that their communication avenues are fracturing to match multiple audiences, part of their ongoing “glue production” is an in-person presence at many conferences, where they host tutorials or workshops in conjunction with domain scientists using their work. At conferences, they also try to meet socially as a group one evening with anyone in their widening community who is able to attend.

For strengthening and growing your own communities, as well as your community-building skills, we invite you to use the resources described below.

The new Council of Funded Projects began meeting monthly at the end of 2019. It’s a novel effort to support funded projects in their work, allow them to explore topics of common interest together, find areas of overlap, parallel effort, priority need, and potential synergy, help each other succeed, and offer feedback to EarthCube. All funded projects and supporters are welcome to attend monthly virtual meetings. Thanks to the teams who shared their stories or provided input: StraboSpot, Argovis, eODP, BALTO, Heliophysics RCN, Throughput, SeaView, SEN, CRESCYNT, Data Discovery Studio, and Pangeo. Thanks also to members of the CSCCE, Center for Scientific Collaboration and Community Engagement (, for most of the resources listed – people are welcome to join that group for additional support in community-building skill development.


  • Website: CSCCE, Center for Scientific Collaboration and Community Engagement.

  • Slack for CSCCE: email (some EarthCube people are here)

  • Webinar, CSCCE Nov. 2019: “Different types of community within science”

  • Blog: What types of communities are there? Science Edition Part 1 | Part 2 | Part 3

  • Book: The Art of Community (some content available online as look-inside)

  • Book: The Art of Gathering: How We Meet and Why It Matters

  • Book: The surprising power of liberating structures

  • Literature on this Amazon wishlist (see items lower down on the list)

  • Website: Mozilla Open Leadership – training series selection

  • Videos: CMX Summit 2019 (choose talks on community building, not marketing)

  • Book List with blog posts: Social in silico (Lou Woodley)

by Ouida W. Meier, Ph.D., 2020-03-02 (update 2020-04-03: additional resource)

9 views0 comments