Because I don't know a better way to do it, let's use an example from the azure pipelines yaml documentation:
resources:
pipelines:
- pipeline: string # identifier for the resource used in pipeline resource variables
project: string # project for the source; optional for current project
source: string # name of the pipeline that produces an artifact
version: string # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
branch: string # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
trigger: # triggers are not enabled by default unless you add trigger section to the resource
branches: # branch conditions to filter the events, optional; Defaults to all branches.
include: [ string ] # branches to consider the trigger events, optional; Defaults to all branches.
exclude: [ string ] # branches to discard the trigger events, optional; Defaults to none.
tags: [ string ] # list of tags to evaluate for trigger event, optional; 2020.1 and greater
stages: [ string ] # list of stages to evaluate for trigger event, optional; 2020.1 and greater
The configuration options on readthedocs should have comment after every parameter explaining it.
I also suggest avoiding abbreviations and using camelCase. i.e.
algorithm:
position:
method: string # Do you really have multiple methods yet? If there is only one method, then don't have this parameter.
initial: int # The initial guess for the position
signal:
method: string
initial:
maxSize: int # [mu] The SI abbreviation for microns is μm?
avgSize: int # [mu] The SI abbreviation for microns is μm?
absoluteTolerance: int # Don't know what this parameter means
Because I don't know a better way to do it, let's use an example from the azure pipelines yaml documentation:
The configuration options on readthedocs should have comment after every parameter explaining it.
I also suggest avoiding abbreviations and using camelCase. i.e.