The gains and hurdles of making science a community effort
The case of Physiopy
| smoia | |
| @SteMoia | |
| s.moia.research@gmail.com |
Taiwan, 17.06.25
Faculty of Psychology and Neuroscience, Maastricht University, Maastricht, The Netherlands; Open Science Special Interest Group (OHBM); physiopy (https://github.com/physiopy)
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?
- Identify the "optimal form" of your deliverable.
- Find open development projects that get you the closest to your "optimal deliverable", contribute if needed/possible, check licences.
- Decide what (permissive) licence the deliverable and any other artefacts you might create during the development will be released under.
- Decide and publish contribution rules.
- Start open development (share it!): use VCS, test, document the process, write SoPs.
- Standardise the development environment: adopt styles and style-checks, add metadata, create containers.
- Automatise whatever you can automatise: set up CI/CD workflows
- Create releases and assign DOIs to them.
- Foster a community around the deliverable.
- Publish open access.
- 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
Keep track of everything
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!
Discuss good practices and learn together
Acknowledge contributions
Independently from its kind, projects can accept different types of contributions.
Different communities may have different entry requirements, contribution recognitions, or follow different contribution workflows.
Make (and look for) a contributors' guidelines
(and a code of conduct).
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
That's all folks!
Find the presentation at:
slides.com/smoia
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
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.
