Documentation: Add external use cases to User's Guide

[georgemccabe]

In the METplus Engineering meeting on 5/23/2023, we discussed including external use case examples to the User's Guide.

Some notes from the meeting:

• Preference for interleaving them, but add an “External” keyword. Perhaps segregate them or visually identify them as being external?
• Include ‘[EXTERNAL]’ keyword and then gray out the thumbnail or something to set the user’s level of expectation for detail.
• An example of the external use case repository: https://github.com/NOAA-EMC/EVS/tree/develop

Describe the Task

Provide a description of the task here.

Time Estimate

Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.

Sub-Issues

• This issue should be done as part of this work: Documentation: Develop an RST template for use cases #918

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

• 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.

[j-opatz]

After creating a draft template for internal use cases, external use cases will clearly need to be approached in a different manner and have their own template. What I'd like to try and avoid with this template is repetition for completeness on the METplus side: if there is preexisting documentation for the repo/use case, we shouldn't require the reentry of all of that information, but enough to give a user the knowledge they need to know if the use case is applicable/usable for their situation.

Some documentation content I think external cases should contain:

• Header where the primary stat analysis tool name is replaced with [EXTERNAL], followed by a brief description of the use cases content. This description should make it clear if the linked material is a single use case, or an entire repository that may have multiple uses.
• Link to the repository/use case
• Link to any additional documentation on the repository/use case
• Point of contact for more information
• A status of if the repository/use case is under active development, in operations, or unchanged (could be multiple statuses)
• Data sources that are routinely used for the use case/repository
• Brief overview of what the repo/use case does. Think of this as a combination of the METplus Components and METplus Workflow sections for internal use cases. Even if more thorough documentation exists for this, this needs to be filled out. A link can be provided here directly to the more thorough documentation.
• How to run the use case. If it is a repository consisting of multiple use cases, then a single example. If the documentation of how to run the use case exists elsewhere, this needs to be filled out. A link can be provided here directly to the more thorough documentation.
• Keywords that help categorize the use case. A new keyword, ExternalUseCase, should be created and added to each of these.
• An image that is greyscale. First thought is the image should be the same for all external cases, but open to suggestions.

[j-opatz]

During a team meeting on this subject (11/06), the following decisions were made:

• create a new section in the METplus wrappers User's Guide where we very briefly discuss the organizations' use of METplus, a synopsis, a point of contact, whether its operational or research use, and a link to a website that hopefully discusses the details more fully
• there should be a delineation between labs to allow for different usages of METplus.
• as for where this section lives, a new section close to 7.3 would be best. This sectional separation between repository use cases and community usage of METplus should be enough to allow documentation users to note the difference.
• First trials can come from presentations with the 2022 METplus users workshop
• The name for this section should include "community" rather than "external"
• For introduction at the beginning of the section, we should indicate that the contents listed have not been tested by METplus automated testing and results are not guaranteed. Gather external input data will also be required and is the responsibility of the user to obtain