Disclaimers

1. I am a member of the physiopy community

2. I have a bias towards the core tenets of Open Science as better scientific practices.

3. I am biased by my own experience - a (mainly) western based, non funded, volunteer based community experience. 

This is a new chapter

This is a new chapter

Take home #0

This is a take home message

1. Open Development

2. physiopy

3. (Some) Do's

1. Open Development

Open Development

Open (Source Scientific Deliverable) Development: the idea of developing a scientific deliverable:

  • in an open and public way
  • sharing it from the beginning of the development
  • fostering a democratic community of contributors in support of the project
  • acknowledging all contributions
  • using version control and (any sort of) testing when necessary.

Two main elements: the deliverable itself and the community around it.

The deliverable is not necessarily code based!

How do we do Open Development?

  1. Identify the "optimal form" of your deliverable.
  2. Find open development projects that get you the closest to your "optimal deliverable", contribute if needed/possible, check licences.
  3. Decide what (permissive) licence the deliverable and any other artefacts you might create during the development will be released under.
  4. Decide and publish contribution rules.
  5. Start open development (share it!): use VCS, test, document the process, write SoPs.
  6. Standardise the development environment: adopt styles and style-checks, add metadata, create containers.
  7. Automatise whatever you can automatise: set up CI/CD workflows
  8. Create releases and assign DOIs to them.
  9. Foster a community around the deliverable.
  10. Publish open access.
  11. Remove embargoes.

The first step in (open) development

Take home #1

Don't reinvent the wheel: look for what you need,
it might be out already in some other form!

 

Contribute to development or join a community:
it might seem harder at first, but it will provide
better artefacts (and improve your network!)

The "other first step"

Minimum Viable Product Unique features


The necessary features



 

The feature nothing else has
Synergies Competitors

Projects or deliverables that match (part of) the seeked features

How can I collaborate with them?
Projects that offer the same
but cannot be collaborated with

Why?

The "other first step"

Minimum Viable Product Unique features
Description of practical operations

Cover respiratory data

Cover cardiac data

Bad data examples		 Community driven

Version controlled

Yearly reviewed
Synergies Competitors
neurokit
ICP Network
physIO toolbox
Pinto 2018 paper
...

2. physiopy

Why physiopy

In neuroimaging, integration of physiological measures to data collection and analyses are still a niche topic. By raising awareness, we can inspire researchers and clinicians become interested in the topic.

*Open Source Software Development is the idea of developing a software publicly, sharing it from the beginning of the development, fostering a democratic community of contributors in support of the project, using version control and software testing.

physiopy adopts a Community driven, BIDS-based, Open Development* approach, aimed at bringing governance back to the users.

Sharing physiological data, toolboxes, and documentation following the concepts of Open Science could improve the exposition to this topic.

Community practices meetings, community consensus, and community guidelines.

Spark interest!

The more we share, the better it becomes

This is (not)
the way!

Of the People, by the People, for the People

Core components

A set of easily adoptable toolboxes

Community of users, developers, and researchers interested in physiology

Clear and approachable documentation

Community practices based on consensus

Core components

physiopy's projects

Raw data

BIDSification

phys. data preprocessing
(peak detect.)

phys. denoising

phys. imaging

Data acquisition

Process description

QA/QC

physiopy's projects

Raw data

phys2bids


peakdet
 

phys2denoise

phys. imaging

Data acquisition

physiopy's documentation
&

Coordinated testing suite

BIDS Extension Proposal

physioQC

Physiopy's Community Practices

physiopy's projects

Raw data

phys2bids


peakdet
 

phys2denoise

phys. imaging

Data acquisition

physiopy's documentation
&

Coordinated testing suite

BIDS Extension Proposal

physioQC

Physiopy's Community Practices


prep4phys

 

physiopy's status

  • Highly inspired by the tedana community and The Turing Way
  • Founded in 2019 by 9 people in 3 labs (during the DC Code Convergence 2019!)
  • It now counts over 35 contributors from over 25 institutions (not all currently active)
  • All contributors are recognised via all-contributors schema and authorship, alphabetically
  • All volunteers are... volunteering (so far)  -  and development spikes during Brainhacks
  • The project had virtually no funds (so far)
  • We got a new governance based on the Minimal Viable Governance model
  • We are also restructuring contributors' guidelines, to make them more friendly!

3. (Some) Do's

Attribution

Aim for readability & standardise styling

a, b = rui()

c = s(a, b)

p(c)
a, b = read_user_input()

c = sum_two_numbers(a, b)

print(c)
def very_important_function(template: str, *variables, file: os.PathLike, engine: str, header: bool = True, debug: bool = False):
    """Applies `variables` to the `template` and writes to `file`."""
    with open(file, 'w') as f:
        ...
        
        
        
        
        
        
        
def very_important_function(
    template: str,
    *variables,
    file: os.PathLike,
    engine: str,
    header: bool = True,
    debug: bool = False,
):
    """Applies `variables` to the `template` and writes to `file`."""
    with open(file, "w") as f:
        ...

physiopy's automation tricks

  • We tend to automatise as much as possible, also to lower barriers to contribution
  • We style our code, automated by pre-commit
  • We release on pipy using semantic versioning (docs in YYYY.m.f), automated by Auto
  • We assign DOI to every(-ish) release using Zenodo
  • We release documentation on Read the Docs using restructured text and markdown
  • All software is released under Apache 2.0 (Practices adopt CC-BY-SA 4.0)
  • We test everything (pytest) with CIs (CircleCI) and keep 95% test coverage with codecov

Take home #2

Keep track of changes as much as you can
Adopt a common style and language

Automatise as much as you can

Find the right balance to keep barriers low!

Engage (others) & disengage (yourself)

  • Keep meeting regularly, even if nothing is happening
  • Give space to other contributors by distancing yourself (the right amount)
  • Discuss a governance and a roadmap together

Contributions and communities

  • Development is a straight(er) line
  • Time effective (on the short run)
  • Low(er) engagement
  • Less mentors
  • Small(er) user base
  • Less tests
  • Consensus not guaranteed
  • Clear attribution
  • Development takes its own path
  • (More) Time consuming
  • High(er) engagement
  • More mentors
  • Big(ger) user base
  • More tests
  • Consensus based
  • Fuzzier attribution

Adapt & juggle

  • Stir the contributors, but follow them
  • It's important to have a roadmap and aims, but flexibility is sometimes key for engagement
  • Be ready to switch focus when and only when
    needed (if it doesn't completely railroad you)
  • Communities are an evolving entity!

Take home #3

There are advantages and disadvantages in working within a community - choose what better fit your aims and interest

Pay attention to engagement and disengagement

Any question [/opinions/objections/...]?

Open meetings every 3rd Thursday
of the month at 16h00 UTC

(But we may reschedule!)

smoia
@SteMoia
s.moia.research@gmail.com
github.com/physiopy
physiopy.github.io
physiopy-community-practices.rtfd.io
physiopy.community@gmail.com

1. Don't reinvent the wheel, join a community

2. Keep track of changes, standardise format, automatise (but attention to barriers!)

3. Choose the governance that makes the most sense for the project, pay attention to engagement

Take home messages

Stefano Moia, 2025

Find the presentation at:

slides.com/smoia

BIDSifying physiological data: phys2bids

physiopy/phys2bids is our flagship repository, introduced in December 2019.

Its aim is reorganising physiological recordings into BIDS format, and it currently supports AcqKnowledge (BIOPAC), Labchart (ADInstruments), Spike2, and GE files.

BIDScoin¹ integrates phys2bids as a plugin, granting it a GUI and facilitating its use.

1. Zwiers, Moia, & Oostenveld, 2022 (Front Neuroinform)

Preprocess physio data: peakdet

physiopy/peakdet was "donated" by its maintaner, Ross Markello, and is currently maintained by physiopy.

Its aim is denoising physiological data and detect peaks in the signal.

It supports automatic peak detection and manual result correction.

Denoising fMRI data: phys2denoise

physiopy/phys2denoise is our second repository, introduced in May 2020.

Its aim is creating denoising regressors for fMRI from physiological recordings.

It is in alpha stage (partially tested code), and it supports common denoising methods based (at the moment) on cardiac and respiratory data.

physiopy's documentation

physiopy's documentation is an important pillar of physiopy's aim, as it is meant to guide new users in their physiological data approach.

 

We are compiling best practices based on bimonthly discussions within the community.

Building open scientific softwares and communities: the case of Physiopy [TOBSW 2025 2]

By Stefano Moia

Building open scientific softwares and communities: the case of Physiopy [TOBSW 2025 2]

CC-BY 4.0 Stefano Moia, 2025. Images are property of the original authors and should be shared following their respective licences. This presentation is otherwise licensed under CC BY 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/4.0/

  • 65

More from Stefano Moia