[MISC] consistently use "directory" instead of "folder" as a term

.github/workflows/codespell.yml

@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
       - uses: codespell-project/actions-codespell@master
         with:
           skip: js,*.svg

.github/workflows/markdown_style.yml

@@ -6,7 +6,7 @@ jobs:
   markdown-style:
     runs-on : ubuntu-latest
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
     - name: Setup NodeJS
       uses: actions/setup-node@v2
       with:

.github/workflows/no-bad-latin.yml

@@ -31,10 +31,10 @@ jobs:
     # This section collects together the steps involved in running the test
     steps:
     # Checkout the repository. Relies on another GH-Action.
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
     # Set up the Python version. Relies on another GH-Action.
     - name: Setup Python 3.7
-      uses: actions/setup-python@v1
+      uses: actions/setup-python@v3
       with:
         python-version: 3.7
     # Install Python dependencies

.github/workflows/schemacode_ci.yml

@@ -20,7 +20,7 @@ jobs:
     outputs:
       skip: ${{ steps.result_step.outputs.ci-skip }}
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
         with:
           fetch-depth: 0
       - id: result_step
@@ -43,10 +43,10 @@ jobs:
       run:
         shell: bash
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
 
       - name: "Set up Python"
-        uses: actions/setup-python@v2
+        uses: actions/setup-python@v3
         with:
             python-version: ${{ matrix.python-version }}
 
@@ -74,10 +74,10 @@ jobs:
     name: Lint schemacode
     steps:
       - name: Check out source repository
-        uses: actions/checkout@v2
+        uses: actions/checkout@v3
 
       - name: Set up Python environment
-        uses: actions/setup-python@v2
+        uses: actions/setup-python@v3
         with:
           python-version: "3.7"
 

.github/workflows/yml_lint.yml

@@ -6,9 +6,9 @@ jobs:
   yml-lint:
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v2
+    - uses: actions/checkout@v3
     - name: Set up Python
-      uses: actions/setup-python@v1
+      uses: actions/setup-python@v3
       with:
         python-version: 3.9
     - name: Install dependencies

CONTRIBUTING.md

@@ -415,7 +415,7 @@ specification, do not hesitate to make a suggestion by showing a draft in a GitH
 After discussion and approval by the community, you can then submit your image
 in a pull request.
 
-Images should be added to an `images` folder that is at the same level as the Markdown file
+Images should be added to an `images` directory that is at the same level as the Markdown file
 where your image will be added. For example if you want to add a figure `figure01.png` to
 `src/05-derivatives/01-introduction.md` then your image should go to
 `src/05-derivatives/images/figure01.png`.
@@ -629,7 +629,7 @@ reviewer as a co-author.
 ## Making a change to the BIDS-schema
 
 Several aspects of the specification are defined in a set of YAML files in the
-`src/schema` folder. The content of those files is described in a dedicated
+`src/schema` directory. The content of those files is described in a dedicated
 [README file](./src/schema/README.md).
 
 ### 1. Ensure that changes to the specification are matched in the schema

macros_doc.md

@@ -17,7 +17,7 @@ in the BIDS specification.
    - [Do I need learn how to program to use those macros?](#do-i-need-learn-how-to-program-to-use-those-macros)
    - [Anything else I need to know if I need to insert a new macro call?](#anything-else-i-need-to-know-if-i-need-to-insert-a-new-macro-call)
    - [How-To and Examples](#how-to-and-examples)
-      - [Writing folder content examples](#writing-folder-content-examples)
+      - [Writing directory content examples](#writing-directory-content-examples)
       - [Generating tables](#generating-tables)
          - [Modifying a term in the table](#modifying-a-term-in-the-table)
          - [Why would you NOT want to modify the content of the yml file directly ?](#why-would-you-not-want-to-modify-the-content-of-the-yml-file-directly-)
@@ -113,7 +113,7 @@ correct terms in the schema. This process is illustrated in the next section.
 
 Note that under the hood the macros themselves call python code that can be
 found in the
-[`tools` folder](https://github.com/bids-standard/bids-specification/tree/master/tools).
+[`tools` directory](https://github.com/bids-standard/bids-specification/tree/master/tools).
 If you are interested in creating a new macro for users, this would be useful.
 
 ## Anything else I need to know if I need to insert a new macro call?
@@ -146,7 +146,7 @@ and a guide for editing at <link>.
 
 ## How-To and Examples
 
-### Writing folder content examples
+### Writing directory content examples
 
 One of the simplest macro we use helps us create consistent "file tree" examples
 that would look like this in the final document:
@@ -173,7 +173,7 @@ To do this get this output, your macro call would look like this:
 ) }}
 ```
 
-When you have complex files and folder structure, we suggest you use this
+When you have complex files and directory structure, we suggest you use this
 [Jupyter notebook](tools/filetree_example.ipynb) for sandboxing your example
 before you insert the macro call into the markdown document.
 

src/01-introduction.md

@@ -40,7 +40,7 @@ and the INCF Neuroimaging Data Sharing (NIDASH) Task Force.
 While working on BIDS we consulted
 many neuroscientists to make sure it covers most common experiments, but at the
 same time is intuitive and easy to adopt. The specification is intentionally
-based on simple file formats and folder structures to reflect current lab
+based on simple file formats and directory structures to reflect current lab
 practices and make it accessible to a wide range of scientists coming from
 different backgrounds.
 

src/02-common-principles.md

@@ -140,7 +140,7 @@ T2 volume does not need to be included, but when it is available it should be
 saved under a particular filename specified in the standard. This standard
 aspires to describe a majority of datasets, but acknowledges that there will be
 cases that do not fit. In such cases one can include additional files and
-subfolders to the existing folder structure following common sense. For example
+subdirectories to the existing directory structure following common sense. For example
 one may want to include eye tracking data in a vendor specific format that is
 not covered by this standard. The most sensible place to put it is next to the
 continuous recording file with the same naming scheme but different extensions.
@@ -156,7 +156,7 @@ Two prominent examples of entities are `subject` and `session`.
 
 For a data file that was collected in a given `session` from a given
 `subject`, the filename MUST begin with the string `sub-<label>_ses-<label>`.
-If the `session` level is omitted in the folder structure, the filename MUST begin
+If the `session` level is omitted in the directory structure, the filename MUST begin
 with the string `sub-<label>`, without `ses-<label>`.
 
 Note that `sub-<label>` corresponds to the `subject` entity because it has
@@ -165,10 +165,10 @@ correspond to a unique identifier of that subject, such as `01`.
 The same holds for the `session` entity with its `ses-` key and its `<label>`
 value.
 
-The extra session layer (at least one `/ses-<label>` subfolder) SHOULD
+The extra session layer (at least one `/ses-<label>` subdirectory) SHOULD
 be added for all subjects if at least one subject in the dataset has more than
 one session.
-If a `/ses-<label>` subfolder is included as part of the directory hierarchy,
+If a `/ses-<label>` subdirectory is included as part of the directory hierarchy,
 then the same [`ses-<label>`](./99-appendices/09-entities.md#ses)
 key/value pair MUST also be included as part of the filenames themselves.
 Acquisition time of session can
@@ -252,16 +252,16 @@ recommending a particular naming scheme for including different types of
 source data (such as the raw event logs or parameter files, before conversion to BIDS).
 However, in the case that these data are to be included:
 
-1.  These data MUST be kept in separate `sourcedata` folder with a similar
-    folder structure as presented below for the BIDS-managed data. For example:
+1.  These data MUST be kept in separate `sourcedata` directory with a similar
+    directory structure as presented below for the BIDS-managed data. For example:
     `sourcedata/sub-01/ses-pre/func/sub-01_ses-pre_task-rest_bold.dicom.tgz` or
     `sourcedata/sub-01/ses-pre/func/MyEvent.sce`.
 
-1.  A README file SHOULD be found at the root of the `sourcedata` folder or the
-    `derivatives` folder, or both.
+1.  A README file SHOULD be found at the root of the `sourcedata` directory or the
+    `derivatives` directory, or both.
     This file should describe the nature of the raw data or the derived data.
     We RECOMMEND including the PDF print-out with the actual sequence
-    parameters generated by the scanner in the `sourcedata`  folder.
+    parameters generated by the scanner in the `sourcedata`  directory.
 
 Alternatively one can organize their data in the following way
 
@@ -285,17 +285,17 @@ Alternatively one can organize their data in the following way
 ) }}
 
 In this example, where `sourcedata` and `derivatives` are not nested inside
-`rawdata`, **only the `rawdata` subfolder** needs to be a BIDS-compliant
+`rawdata`, **only the `rawdata` subdirectory** needs to be a BIDS-compliant
 dataset.
-The subfolders of `derivatives` MAY be BIDS-compliant derivatives datasets
+The subdirectories of `derivatives` MAY be BIDS-compliant derivatives datasets
 (see [Non-compliant derivatives](#non-compliant-derivatives) for further discussion).
 This specification does not prescribe anything about the contents of `sourcedata`
-folders in the above example - nor does it prescribe the `sourcedata`,
-`derivatives`, or `rawdata` folder names.
+directories in the above example - nor does it prescribe the `sourcedata`,
+`derivatives`, or `rawdata` directory names.
 The above example is just a convention that can be useful for organizing raw,
 source, and derived data while maintaining BIDS compliance of the raw data
-folder. When using this convention it is RECOMMENDED to set the `SourceDatasets`
-field in `dataset_description.json` of each subfolder of `derivatives` to:
+directory. When using this convention it is RECOMMENDED to set the `SourceDatasets`
+field in `dataset_description.json` of each subdirectory of `derivatives` to:
 
 ```JSON
 {
@@ -307,18 +307,18 @@ field in `dataset_description.json` of each subfolder of `derivatives` to:
 
 Derivatives can be stored/distributed in two ways:
 
-1.  Under a `derivatives/` subfolder in the root of the source BIDS dataset
-    folder to make a clear distinction between raw data and results of data
+1.  Under a `derivatives/` subdirectory in the root of the source BIDS dataset
+    directory to make a clear distinction between raw data and results of data
     processing.
     A data processing pipeline will typically have a dedicated directory
     under which it stores all of its outputs.
     Different components of a pipeline can, however, also be stored under different
-    subfolders.
+    subdirectories.
     There are few restrictions on the directory names;
     it is RECOMMENDED to use the format `<pipeline>-<variant>` in cases where
     it is anticipated that the same pipeline will output more than one variant
     (for example, `AFNI-blurring` and `AFNI-noblurring`).
-    For the sake of consistency, the subfolder name SHOULD be
+    For the sake of consistency, the subdirectory name SHOULD be
     the `GeneratedBy.Name` field in `data_description.json`,
     optionally followed by a hyphen and a suffix (see
     [Derived dataset and pipeline description][derived-dataset-description]).
@@ -395,7 +395,7 @@ session subdirectory within the corresponding subject directory; and so on.
 
 Nothing in this specification should be interpreted to disallow the
 storage/distribution of non-compliant derivatives of BIDS datasets.
-In particular, if a BIDS dataset contains a `derivatives/` sub-directory,
+In particular, if a BIDS dataset contains a `derivatives/` subdirectory,
 the contents of that directory may be a heterogeneous mix of BIDS Derivatives
 datasets and non-compliant derivatives.
 
@@ -817,7 +817,7 @@ Describing dates and timestamps:
 
 ### Single session example
 
-This is an example of the folder and file structure. Because there is only one
+This is an example of the directory and file structure. Because there is only one
 session, the session level is not required by the format. For details on
 individual files see descriptions in the next section:
 
@@ -862,7 +862,7 @@ individual files see descriptions in the next section:
 
 ## Unspecified data
 
-Additional files and folders containing raw data MAY be added as needed for
+Additional files and directories containing raw data MAY be added as needed for
 special cases.
 All non-standard file entities SHOULD conform to BIDS-style naming conventions, including
 alphabetic entities and suffixes and alphanumeric labels/indices.

src/03-modality-agnostic-files.md

@@ -105,8 +105,8 @@ In contrast to raw BIDS datasets, derived BIDS datasets MUST include a
    }
 ) }}
 
-If a derived dataset is stored as a subfolder of the raw dataset, then the `Name` field
-of the first `GeneratedBy` object MUST be a substring of the derived dataset folder name.
+If a derived dataset is stored as a subdirectory of the raw dataset, then the `Name` field
+of the first `GeneratedBy` object MUST be a substring of the derived dataset directory name.
 That is, in a directory `<dataset>/derivatives/<pipeline>[-<variant>]/`, the first
 `GeneratedBy` object should have a `Name` of `<pipeline>`.
 

src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md

@@ -161,7 +161,7 @@ diffusion and functional MRI may also be *intended for* estimating the
 *B<sub>0</sub>* field nonuniformity inside the scanner (in other words,
 *mapping the field*) without the acquisition of additional MRI schemes
 such as gradient-recalled echo (GRE) sequences that are stored under the
-`fmap/` folder of the BIDS structure.
+`fmap/` directory of the BIDS structure.
 
 The modality labels `dwi` (under `dwi/`), `bold` (under `func/`),
 `asl` (under `perf/`), `sbref` (under `dwi/`, `func/` or `perf/`), and

src/04-modality-specific-files/02-magnetoencephalography.md

@@ -44,8 +44,8 @@ If multiple *Tasks* were performed within a single *Run*,
 the task description can be set to `task-multitask`.
 The `*_meg.json` file SHOULD contain details on the *Tasks*.
 
-Some manufacturers' data storage conventions use folders which contain data
-files of various nature: for example, CTF's `.ds` format, or BTi/4D's data folder.
+Some manufacturers' data storage conventions use directories which contain data
+files of various nature: for example, CTF's `.ds` format, or BTi/4D's data directory.
 Yet other manufacturers split their files once they exceed a certain size
 limit.
 For example Neuromag/Elekta/Megin, which can produce several files
@@ -475,7 +475,7 @@ Empty-room MEG recordings capture the environmental and recording system's
 noise.
 In the context of BIDS it is RECOMMENDED to perform an empty-room recording for
 each experimental session.
-It is RECOMMENDED to store the empty-room recording inside a subject folder
+It is RECOMMENDED to store the empty-room recording inside a subject directory
 named `sub-emptyroom`.
 The label for the [`task-<label>`](../99-appendices/09-entities.md#task) entity in the empty-room recording SHOULD be
 set to `noise`.

src/04-modality-specific-files/04-intracranial-electroencephalography.md

@@ -525,7 +525,7 @@ other task events. Electrical stimulation parameters can be described in columns
 called `electrical_stimulation_<label>`, with labels chosen by the researcher and
 optionally defined in more detail in an accompanying `_events.json` file (as
 per the main BIDS spec). Functions for complex stimulation patterns can, similar
-as when a video is presented, be stored in a folder in the `/stimuli/` folder.
+as when a video is presented, be stored in a directory in the `/stimuli/` directory.
 For example: `/stimuli/electrical_stimulation_functions/biphasic.tsv`
 
 Example:

src/04-modality-specific-files/05-task-events.md

@@ -127,17 +127,17 @@ for additional information and examples.
 Additional information about the stimuli can be added in the `events.tsv`
 and `events.json` files.
 
-This can be done by using a `/stimuli` folder or by reference to a stimuli database.
+This can be done by using a `/stimuli` directory or by reference to a stimuli database.
 
-### Stimuli folder
+### Stimuli directory
 
-The stimulus files can be added in a `/stimuli` folder
-(under the root folder of the dataset; with optional subfolders) AND using a
+The stimulus files can be added in a `/stimuli` directory
+(under the root directory of the dataset; with optional subdirectories) AND using a
 `stim_file` column in `events.tsv` mentioning which stimulus file was used
 for a given event,
 
 There are no restrictions on the file formats of the stimuli files,
-but they should be stored in the `/stimuli` folder.
+but they should be stored in the `/stimuli` directory.
 
 {{ MACROS___make_columns_table(
    {

src/04-modality-specific-files/07-behavioral-experiments.md

@@ -5,7 +5,7 @@
 In addition to logs from behavioral experiments performed alongside imaging data
 acquisitions, one can also include data from experiments performed with no neural
 recordings.
-The results of those experiments can be stored in the `beh` folder using the same
+The results of those experiments can be stored in the `beh` directory using the same
 formats for event timing (`_events.tsv`), metadata (`_events.json`),
 physiological (`_physio.tsv.gz`, `_physio.json`)
 and other continuous recordings (`_stim.tsv.gz`, `_stim.json`)
@@ -31,10 +31,10 @@ In addition to the metadata that is either:
 
 -   RECOMMENDED for sidecar JSON files for [tabular data](../02-common-principles.md#tabular-data), or
 
--   REQUIRED for some data that can be found in the `beh` folder
+-   REQUIRED for some data that can be found in the `beh` directory
     (for example `SamplingFrequency` and `StartTime` for `*_<physio|stim>.tsv.gz` files),
 
-it is RECOMMENDED to add the following metadata to the JSON files of this folder:
+it is RECOMMENDED to add the following metadata to the JSON files of this directory:
 
 {{ MACROS___make_metadata_table(
    {

src/04-modality-specific-files/10-microscopy.md

@@ -208,7 +208,7 @@ JSON metadata may be defined per sample or per chunk as appropriate, as per the
 In microscopy, many pyramidal file formats store multiple resolutions for the same acquisition.
 In the case where a multiple resolutions file format is converted to single resolution file format,
 only the higher resolution file is present in the raw data.
-Lower resolutions files MUST be placed under the `derivatives` folder and use the
+Lower resolutions files MUST be placed under the `derivatives` directory and use the
 [`res-<label>`](../99-appendices/09-entities.md#res) entity.
 
 For example: