everything looks nice, but I wonder if the separation of the functions in separate folders is helpful, we should probably discuss this first. Moving development to the Function folder is not helpful, the Function folder contains functions that are used (and initialized), the development folder should not be initialized. I would vote against initializing each function folder separately. I like the new README a lot!

• I would also keep Development apart as it was
• No opinion on subfolders of Functions, but we totally keep mex under Functions as I have already modified the compilation script ;)
• Totally agree with renaming the master scripts - very good work!
• Very good with the templates and tutorials!

OK so:

• let's move the development folder back (and we can create an issue of moving it (partly) to CustomScripts)
• let's revert the function folders (unless we have a good motivation why to do this, I liked the previous setting; the prefix of the function should be more important than it's location, e.g., we also have xASL_im_ functions inside /Modules/ASL/. So a function shouldn't be judged by its location.
• I'm also very happy with all other changes!

I personally find it quite hard to navigate with all functions in the same directory. Especially for newer or unexperienced developers it's harder to keep the overview. It's also helpful to have more structure so that we can easily document like with the shown readme.

In SubModules ASL there are only wrappers. In the population module there are a few stat, im and other functions. Maybe that's rather a thing that could be cleaned up, too. Like I said in the issue, I just thought it could make sense to rethink some things to make it easier for people to work with and on xasl.

So those are the main reasons why I would move the functions to sub-directories and generally revamp the structure.

I don't care that much about the location of Development. We can move it back if you want. I was just trying to hide it a bit, because IMHO it's not common to have unfinished/untested functions in released software. That's one of the main reasons why I think we don't need it at all. If you download any other framework you wouldn't expect to find unfinished not fully working code.

I personally find it quite hard to navigate with all functions in the same directory. Especially for newer or unexperienced developers it's harder to keep the overview. It's also helpful to have more structure so that we can easily document like with the shown readme.

As said. No strong opinion on that. But I agree that this is might be confusing for some people, so I'm fine with subdirectories.
I personally hate that some things are in External/DCMTK and some in External/DCMTK/SPMmodified - that makes it super-complicated. But that's because of license issues and until a smart lawyer finds out a better solution, we have to stick to that.

In SubModules ASL there are only wrappers. In the population module there are a few stat, im and other functions. Maybe that's rather a thing that could be cleaned up, too. Like I said in the issue, I just thought it could make sense to rethink some things to make it easier for people to work with and on xasl.

ASL and Structural modules are a great example where wrappers are in modules and functions in functions. And I agree that for Import and Population, this is somehow messy. Import would definitively need a revamp in names as some imp files should be wrp but we should make a separate issue for that and agree on what to do exactly before we do that ;) Same for population.

I don't care that much about the location of Development. We can move it back if you want. I was just trying to hide it a bit, because IMHO it's not common to have unfinished/untested functions in released software. That's one of the main reasons why I think we don't need it at all. If you download any other framework you wouldn't expect to find unfinished not fully working code.

Good point. But I am not sure if hiding it makes it any better :) Still, it is not just some unfinished code. It is a code that should be used with caution and code that we actually do use for some specific studies. But not so specific that we could move it to CustomScripts. So I would move it back to root (no need to revert, we just move again) and update the init-path. And we make a new issue where we discuss some further changes. For example (but lets write those to the new issue and find a consensus first):

• ConfigFiles can be deleted in 2.0.0
• CreateTestDataSet - do we still need that?
• Outdated - can be removed
• All other functions - we can judge on a case-by-case basis what can be removed and what still needs to stay

@HenkMutsaerts What do you think?

• Let's move the development code to CustomScripts in a new issue indeed. I wouldn't delete though, but move to CustomScripts instead (e.g. ConfigFiles & CreateTestDataSet).
• Looking at the folders now, I actually like it. Few exceptions:
  • I would move everything in General to Initialization, except for xASL_num2str and xASL_str2num, these can go to /External/SPMmodified/xASL
  • Imaging is incorrect, should be ImageProcessing (Imaging means obtaining an image, e.g., by an MRI scanner)

Nice work!