this is already a great improvement!

• we call it the "stimulus" computer; but now I think, is it really "stimulus"? It's rather something like sourceLSL and sourceOther ? Do you know what I mean? Not sure we should rename it right now because it would be much more effort surely...
• SubjectInfo doesnt fit correctly, because e.g. tasks are also in there, maybe fileSelection or so? also the anonymization thing is more a BIDS config thing? maybe to a other or BIDS section?
• allTasks = [] # List of all possible tasks in the dataset. This will automatically be updated when new tasks are found during the conversion. - why do we need this, e.g. why is this something to be configured?

1. Yes, Stimulus in general was used as we termed it like that in the lab, but yes, it doesn't make quite sense independently. We could name it later to sourceOther and then change the field name to expectedBehFiles and sourceOther used say.
   With this, we have to obviously change the field names across the code, which is quite doable. The only thing that could be done later is refactoring the logs for the log file.
2. I totally agree - FileSelection and BidsConfig make more sense. I will divide this into two.
3. Good question. It was a long time ago, when we thought that the project_config.toml would also serve as project metadata, and hence the tasks field gets populated by itself based on the recording. I clarified that in the comment. But we can totally remove that.

1. then let's do this if it is really not much work; But this would change the global config file as well right?
2. nice
3. let's rather remove it then; I think the pid/doi is fine to populate there (maybe choose an empty value instead of 123456 as default?) because theoretically one could have a dataverse created already ;-)

maybe one more thing, should we have a metadata section (title, description, license, other metdata for BIDS?), and a dataverse-specific (e.g. subject, doi (why pid actually?)) section?

3. think the pid/doi is fine to populate there (maybe choose an empty value instead of 123456 as default?) because theoretically one could have a dataverse created already ;-)

1. Yes, the global config would change as well (PROJECT_STIM_ROOT). We need to change the name of the project_stimulus folder also, and update the documentation accordingly. And the lab settings change as well. Actually refactoring is not that difficult in the package/codebase but would need some time.But someone also needs to then change the global settings in the lab and get used to the new term.
2. Okay will do it as an empty value by default.
3. For BIDS metadata, which can go in the newly proposed BidsConfig section. Currently the title, description etc etc are same for Dataverse and BIDS, do we need different ones for both?

• I can do the lab thing, have to go there eventually anyway to push some MNELAB changes
• same metadata is good!

Sounds good to me. So we then change all the project_stimulus folder name to project_other and PROJECT_STIM_ROOT -> PROJECT_OTHER?
I can't think of any generic name that fits any other modality :( . It is just to make everything consistent.

project_-stim_root = project_other_root?

1. Refactored all the PROJECT_STIMULUS_ROOT to PROJECT_OTHER_ROOT and project_stimulus to project_other in the codebase and documentation
2. Separated [SubjectInfo] into [FileSelection] and [BIDSConfig] and removed the [Tasks] field.

otherFilesUsed is currently not in use, it only checks whether the expectedOtherFiles is false

if this is true, do we even need both?

otherFilesUsed is currently not in use, it only checks whether the expectedOtherFiles is false

LSLAutoBIDS/lslautobids/convert_to_bids_and_upload.py

Line 433 in 0cc634b

other = data["OtherFilesInfo"]["expectedOtherFiles"]

if this is true, do we even need both?

Now it is like if otherFilesUsed is True only then the expected files and experiment files are checked for upload if not then the fields of expectedotherfiles etc are ignored.