First steps towards
a FAIR-er and
more efficient research

	smoia
	@SteMoia
	s.moia.research@gmail.com

Stefano Moia, 2025

Stefano Moia

Maastricht University

Physiopy

OSSIG

Declaration of interests
And biases

SPEAKER NAME: STEFANO MOIA

I have the following interests and relationships to disclose:

I am a member of the physiopy community
I have a bias towards Open Science practices to be better scientific practices

This is a new chapter

Take home #0

This is a take home message

1. Version control systems and git workflow

2. Going public: Licences, releases, DOIs

3. Automation

Version control systems
and git workflow

Does any of these situations look familiar?

I can't work on that project now because my colleague is working on [a different part of] it at the moment...

Version Control

Version Control

Version control systems are a way to manage and track changes to files.

Content

Aggregation/delivery

A classic git(Hub) flow

Create branch "dev"

Add (stage) & Commit

Merge dev into main

Diverging main: conflict?

Merge main into dev

Initialise repository
"Main" branch

Main

Dev

Bug

A classic git(Hub) flow

Create branch "dev"

Commit

Merge dev into main

Diverging main: conflict?

Merge main into dev

Initialise repository
"Main" branch

Fork ("upstream" vs "origin")

Pull from upstream

Merge origin/main into dev

Clone (local repository)

Pull Request

Pull from *

Push to *

Main

Dev

Upstream

Main

Origin

Dev

Main

(local)

Pull requests and Reviews

Some suggestions for...

Keep you contribution small and focused
Make your contribution as clear as possible
Use a review as a learning experience
Be patient: reviewers might ask you some more work than you expected, but it's always to improve your work.

Be kind and patient
Don't limit your review to the apparent changes - depending on the importance of the review, take the time to look at how the whole project might change.
Keep your review to what's necessary for the contribution - if it would be nice to ..., open an issue (or think about making the contribution yourself).

... Authors

... Reviewers

File history

Take home #1

Working with VCS allows you to:

track changes and authors

work in parallel without disruptions

Bonus: it can force a team to double check projects!

Going public:
Licences, releases, DOIs

Disclaimer:

I am not a legal expert.

Double check what I am about to say with your Technology Transfer or Library Office.

License your work

A work that is not licensed is not public (paradox!)

There are many (open source) licences to pick up from, not only code-related.

www.choosealicense.org

The licence should be in the first commit you make.

Personal picks for science: Apache 2.0 and CC-BY-ND-4.0
(consider L-GPLv3.0 and CC-BY-4.0 too)

Stefano Moia, 2025

Licence compatibility

Understand licensing and ownership

Check the licence of code, data, and libraries you are "borrowing".
Pay attention to single vs double licensing (e.g. academic vs commercial).
Check licence compatibility.
Remember that institutions might have rights to what their employees do:
However, they can also help you with licensing and license enforcement.

EPFL is the owner of its employees’ inventions and software. Inventors or authors in case of software have the right to one-third of net revenue resulting from the commercialization of their inventions with some exceptions according to directives.

License your work in the right way

Put a copy of the licence or a link to it as close as possible to "borrowed" material, if not in it.
If any license requires its adoption for derivatives (e.g. GPL), you must licence your work with the same licence.
You can ask the original authors to change their licence (e.g. GPL to L-GPL) or give you special permissions.
Remember to add licences disclaimers in all of your files.

[...]

if __name__ == "__main__":
    _main(sys.argv[1:])


"""
Copyright 2022, Stefano Moia & EPFL.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
"""

License your work in the right way

MATLAB users:

If you include external functions/scripts/libraries, your work is considered a derivative. Report licence, authors, and origin of the code inside them and respect their licence.
Alternatively, don't include anything but state requirements / create install scripts.
If you are releasing a build, the build is considered a derivative.

Python users:

If you copy-paste code, your work is a derivative.
Imports are trickier:
- Technically, GPL or © licences triggers on import.
- Practically, it's a really grey area. Make those imports optional, and specify their licences as clearly as possible.

Take home #Licenses

Licensing is as complicated as it is important.

Double check licenses of borrowed material, report them in your own work
for licence tracking.

Licence your work
and implement the licence properly.

Release

Making your project public is important: it will attract more users/readers and (possibly) more contributors.

Create a "release", and if the project is code-related, package it and distribute it!

Make your project identifiable (and citable)

{
    "license": "Apache-2.0", 
    "title": "physiopy/phys2bids: BIDS formatting of physiological recordings",
    "upload_type": "software",
    "creators": [
      [...]
        {
            "orcid": "0000-0002-7796-8795",
            "affiliation": "Florida International University", 
            "name": "Katie Bottenhorn"
        }, 
      [...]
    ], 
    "access_right": "open"
}

Publish!

If your project is software related, think about publishing it.

While there are various journals that can be targeted for a software publication, JOSS is free and completely integrated in GitHub.

Take home #2

Go public:

licence your work,

create a release,

assign a DOI to it!

Automation

Let automation do the hard work

CI/CD workflows are your friend.

Continuous Integration: frequently integrating new changes into the main branch of a tool. Normally, workflows run automatic steps at each integration, e.g. automatic testing.
Continous Deployment: frequently deploying (releasing) new versions of a tool using automated workflows (e.g. right after integration).

Workflows can require a bit more work to be set up, but they can save a lot of time and energy in the long run!

Release automagically

https://intuit.github.io/auto/

Automation pt. 1: git hooks

pip install pre-commit  # Install via pip, or
# Comes installed with development extras
pip install -e /path/to/phys2cvr[dev]

cd /path/to/phys2cvr
pre-commit init
pre-commit run

(Local and remote) simple automations, e.g:

Code style
File checks (empty lines, indent, executables)
Language and typos (!!!)

Style & basic checks: pre-commit
Tests: CircleCI & Codecov
Versions and Releases: Auto and Github
DOIs (citable objects): Zenodo
Documentation: Read the Docs

Automation at work

Let's not reinvent the wheel

Take advantage of the marketplace: there is a very high probability that what you are looking for is already available.

Take home #3

Set up workflows to test, build, and release/publish your project.

They will not only help you, but also increase the stability and reliability of your outcome.

Automate, automate, automate!

That's all folks!

Stefano Moia, 2025

Find the presentation at:

slides.com/smoia

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

	smoia
	@SteMoia
	s.moia.research@gmail.com

Take home messages

Stefano Moia, 2025

Find the presentation at:

slides.com/smoia

1. Working with git(Hub) allows you to work in parallel and track changes & authors over time.

2. Go public: licence your work, create releases, assign a DOI!

3. Set up workflows to increase deliverable reliability, and don't forget to automate!

Oh, and don't forget!

Oh, and don't forget!

First steps towards a FAIR-er and more efficient research [OHBM2025]

By Stefano Moia

First steps towards a FAIR-er and more efficient research [OHBM2025]

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/

First steps towards a FAIR-er and more efficient research

Declaration of interests And biases

SPEAKER NAME: STEFANO MOIA

This is a new chapter

This is a new chapter

Take home #0

This is a take home message

1. Version control systems and git workflow

2. Going public: Licences, releases, DOIs

3. Automation

Version control systems and git workflow

Does any of these situations look familiar?

Version Control

Version Control

Version Control

A classic git(Hub) flow

A classic git(Hub) flow

Pull requests and Reviews

Pull requests and Reviews

Some suggestions for...

... Authors

... Reviewers

File history

Take home #1

Working with VCS allows you to:

track changes and authors work in parallel without disruptions

Bonus: it can force a team to double check projects!

Going public: Licences, releases, DOIs

Disclaimer:

I am not a legal expert.

Double check what I am about to say with your Technology Transfer or Library Office.

License your work

Licence compatibility

Understand licensing and ownership

License your work in the right way

License your work in the right way

Take home #Licenses

Licensing is as complicated as it is important.

Double check licenses of borrowed material, report them in your own work for licence tracking.

Licence your work and implement the licence properly.

Release

Make your project identifiable (and citable)

Publish!

Take home #2

Go public:

licence your work, create a release, assign a DOI to it!

Automation

Let automation do the hard work

Release automagically

Automation pt. 1: git hooks

Automation at work

Let's not reinvent the wheel

Take home #3

Set up workflows to test, build, and release/publish your project. They will not only help you, but also increase the stability and reliability of your outcome.

Automate, automate, automate!

That's all folks!

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

Take home messages

1. Working with git(Hub) allows you to work in parallel and track changes & authors over time.

2. Go public: licence your work, create releases, assign a DOI!

3. Set up workflows to increase deliverable reliability, and don't forget to automate!

Oh, and don't forget!

Oh, and don't forget!

First steps towards a FAIR-er and more efficient research [OHBM2025]

More from Stefano Moia

First steps towards
a FAIR-er and
more efficient research

Declaration of interests
And biases

Version control systems
and git workflow

track changes and authors

work in parallel without disruptions

Going public:
Licences, releases, DOIs

Double check licenses of borrowed material, report them in your own work
for licence tracking.

Licence your work
and implement the licence properly.

licence your work,

create a release,

assign a DOI to it!

Set up workflows to test, build, and release/publish your project.

They will not only help you, but also increase the stability and reliability of your outcome.