Documentation: Update Documentation Overview and Conventions

Replace italics below with details for this issue.

Describe the Task

Literal include This feature is used often in the Release Guide. But there are other places it can also be used. Using a literal include ensures only having to update the documentation in one place. It is also important to use a relative path (e.g. "../../") to get to the correct directory of the file being referenced in the literal include. This will keep the file linking to the correct version and branch.
Julie curated this example: As an example, refer to the METplus User's Guide. See this line in the PointStat.py which uses RST's .. literalinclude:: and renders on the web in what appears to be a code block in this section.

==============

Substitution References (This section can be included before or after the Literal Blocks)

Substitution references are replacements in the text as defined in the rst_epilog in the docs/conf.py file. For example, instead of hard coding the MET version in the METplus documentation, a variable met_version can be set to a value (e.g. 12.0.0) in the docs/conf.py file in the following way:

met_version = 12.0.0

Then, this variable is used in the rst_epilog to set up the substitution, along with other variables. For example, in the docs/conf.py file the following is defined:

rst_epilog = f"""
.. |copyright|    replace:: {copyright}
.. |author_list|  replace:: {author_list}
.. |release_date| replace:: {release_date}
.. |release_year| replace:: {release_year}
.. |release_info| replace:: {release_info}
.. |python_version| replace:: {python_version}
.. |met_version| replace:: {met_version}
"""

The value 12.0.0 would then be replaced in the documentation wherever |met_version| is used in .rst files. For example:

MET version |met_version| or above

See Substitutions and rst_epilog for more information.

Time Estimate

Estimate the amount of work required here. Issues should represent approximately 1/2 day of work.

Sub-Issues

Consider breaking the task down into sub-issues.

[ ] Add a checkbox for each sub-issue here.

Relevant Deadlines

List relevant project deadlines here or state NONE.

Funding Source

Define the source of funding and account keys here or state NONE.

Define the Metadata

Assignee

[x] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Projects and Milestone

[ ] Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE ASSIGNMENT label
[ ] Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

[ ] METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Task Checklist

See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding Source.
[ ] Fork this repository or create a branch of develop. Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Add any new Python packages to the METplus Components Python Requirements table.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop. Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow. Select: Reviewer(s) and Development issues Select: Repository level development cycle Project for the next official release Select: Milestone as the next official version
[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

dtcenter / METplus