Community Building & Data Governance

Build self-sustaining communities around shared data missions — with governance structures, shared infrastructure, and training that outlast any single engagement.

The Problem

You have a data challenge that spans organisations — multiple teams, institutions, or even entire fields need to agree on shared terminology, coordinate their practices, and maintain resources collectively. But without governance structures, shared tooling, and clear processes, these efforts fragment: duplicated work, incompatible resources, and communities that dissolve when funding cycles end.

Building a shared data resource is a technical problem. Sustaining it is a community problem.

What You Get

A functioning community around your shared data mission: governance structures that enable collective decision-making, shared infrastructure that reduces duplicated effort, standard operating procedures that ensure consistency, and training programmes that onboard new contributors. The goal is a community that sustains itself — not one that depends on me.

How It Works

1. Governance Design

I help you establish how decisions get made:

  • Scope and charter: What does the community own? What’s in scope, what isn’t?
  • Decision-making processes: How are contentious issues resolved? Who has authority over what?
  • Contribution guidelines: How do new members participate? What are the expectations?
  • Roles and responsibilities: Technical working groups, editorial boards, community managers

These structures need to be lightweight enough to actually work, but robust enough to handle disagreements. I draw on years of experience co-leading the OBO Foundry Technical Working Group and contributing to LinkML’s community governance.

2. Shared Infrastructure

I deploy tooling that makes collaboration practical:

  • Standardised workflows: Common processes for creating, reviewing, and releasing shared resources — built on the Ontology Development Kit (ODK) and adapted to your domain
  • Quality standards: Automated validation that ensures contributions meet community-agreed criteria
  • CI/CD pipelines: Reproducible builds and releases so every team benefits from the same infrastructure
  • Registry and discovery: Making your community’s resources findable and citable

The key principle: shared infrastructure should reduce the burden on individual teams, not add to it.

3. Standard Operating Procedures

I document the processes that make your community consistent:

  • Curation SOPs: How terms are added, reviewed, and maintained
  • Metadata standards: What information every resource must carry
  • Release processes: When and how shared resources are published
  • Conflict resolution: What happens when contributors disagree

SOPs are only useful if people follow them. I design them to be lightweight, practical, and integrated into existing workflows.

4. Training and Onboarding

I build the educational infrastructure that sustains the community:

  • Onboarding materials: Getting new contributors productive quickly
  • Training workshops: Hands-on sessions for domain experts, curators, and developers
  • Reference documentation: Tutorials, best practices, and FAQs
  • Seminar series: Regular knowledge sharing within the community

I co-founded OBO Academy to solve exactly this problem for the ontology community — and the same approach works for any domain.

5. Community Growth

I help you grow beyond the founding team:

  • Stakeholder engagement: Identifying and recruiting organisations that should be at the table
  • Open science practices: Making your community’s work accessible and contribution-friendly
  • Sustainability planning: Governance and infrastructure that survive funding transitions and staff turnover

Why This Approach

Most shared data initiatives fail not because the technical work is bad, but because the community around it doesn’t hold together. People build a great resource, then it drifts because there’s no governance, no shared tooling, and no way to onboard new contributors.

I’ve spent years building this kind of community infrastructure — for the OBO Foundry (150+ ontologies, 120+ ODK deployments), for SSSOM (a mapping standard now adopted across biomedical research, clinical data, and industry), and for LinkML (where I contribute to strategic planning and community governance). Very few people have experience building communities around shared data missions at this scale. I know what works, what doesn’t, and what it takes to make these efforts self-sustaining.

Case Study

See how the OBO Foundry grew from inconsistent practices across dozens of ontologies into a coordinated community with shared infrastructure, governance, and training — now serving as a model for how other scientific domains organise open data efforts.

Get in touch to discuss how I can help build a community around your shared data mission.