DOC: Document steps where config options are used

[larsoner]

Used as in informing the documentation?

Yes

We'd basically have to iterate over all steps and grep the arguments used in get_config() and then put that in a table or so…

Originally posted by @hoechenberger in #860 (comment)

[larsoner]

(I learned about this [adding params to documentation] part last week, when I forgot to mention the image_kwargs for the report there; easy to make mistakes as it needs to be added manually)

Yeah we at least added a CI job (I think!) that checks to make sure all _config.py options are in the docs, so CIs yell at you if you don't add them so we stay consistent even if it takes a few commits to get there.

In principle instead we could think about trying to mark up the default _config.py with some # ## Preprocessing headings for example that get found with ast, parsed, and automatically populate .md files. It wouldn't be too difficult but not sure if it would cover everything.

We'd basically have to iterate over all steps and grep the arguments used in get_config() and then put that in a table or so…

Yeah or in addition to or instead of a monolithic table we could figure out how to document it inline with the param itself, like for example

Could have a list of all three decoding steps right at the end, since they are all directly affected by the choice (assuming that's the complete set anyway!). Complementary to a table I guess since when looking at a config option you probably wonder "what steps will this option affect?" in which case the inline list is useful; but when looking at a processing step you might wonder "what options are used in this step?" in which case a table is more useful.

[larsoner]

... for the table half, we already have a step table in https://mne.tools/mne-bids-pipeline/dev/features/steps.html , perhaps we could add config options to each table entry. The table would get a bit long but I think that's okay.

[hoechenberger]

Yeah or in addition to or instead of a monolithic table we could figure out how to document it inline with the param itself, like for example

I wasn't thinking of a table to include it in the docs, but what I had it mind was a look-up table (LUT) we could then use to enrich the docs; my idea would be that every parameter gets an Info button or something that, when clicked on, displays which steps will be affected