Definitely. I think we can link the two repositories anyways, so we can remove the zip file from the existing and keep it on the separate repo (will have to update existing scripts/instructions/actions).

I'd be fine moving the subject data to its own OSF repository if the move takes place,.

Awesome! Datalad also now has an OSF extension. Should we consider using this to stay consistent with the IntroMRI lesson and also continue pushing the concepts of dataset version control?

It would allow us to use datalad clone osf://<osf_project// to download the data.

That sounds good to me - I think when this first started there wasn't an extension yet.

Since this is a relatively quick and easy change, I've gone ahead and created a new OSF repo for this and linked it with the old one (data is still present on both for now). The new repo is here: https://osf.io/t7afj/

It follows the same structure as before ds000221_subject/ds000221_sub-010006.zip

We will have to update the scripts and instructions.

Sounds good for advocating in favor for datalad. Please, correct if I'm wrong, but using datalad is then independent of the NeuroLibre hosting, right?

Also, I'd avoid mixing datalad with the binder-related issues in #178: I'd leave transitioning to datalad to a separate, dedicated PR. Otherwise, we'd be introducing further inconsistencies.

Using datalad would also tie into NeuroLibre hosting. If we create a new repository on OSF, we would need to use the datalad OSF extension in order to push the data. And also, this changes what we include in the dataset json file, which contains instructions for downloading the data.