For @ryanhammonds : while you are doing a check through the codebases and familiarizing yourself with the code, I think we should try and add more Examples in docstrings.

Here's roughly what I'm thinking:

• Do a sweep through of the codebase itself, getting familiar with the code, and doing a quick 'audit' check through the code
• If you notice any broader issues or problems, then you can open issues, and if you see any nitpicks, typos, etc, you can edit them directly to merge
• As you go, see if and where it might make sense to add an Examples section to the docstring. As a starting point, I'd say functions / classes listed in the API page are all candidates to have doctest examples.
• Add any Examples sections that you think would be useful to docstrings, and follow doctest format for them all
• PR the updates of the docstrings updates, and any small tweaks

Notes on doctest:

• Doctest examples can be set up to be executed (with or without a tested output) or use the # doctest:+SKIP directive, after the example line, to indicate it shouldn't be run
• It's somewhat open ended (up to you) when doctests should be set to run or skip, but I would say don't add too much set-up code just for the sake of having it execute.
• To a certain extent, doctest examples can show quick versions of stuff that's covered in the tutorials. Try to use them to show clear and specific cases people might want to try.
• Please add a thing to run doctests (specifically) into the summary.sh file (like in fooof), and/or some other way check & run these examples.
• Note that you can run doctests in specific files with python -m doctest -v file.py, or run a whole module, with pytest, with pytest --doctest-modules --ignore=module/tests module (that also includes the option to ignore explicit test files)