diff --git a/README.md b/README.md
index 2c5c68ef4c15f1d6c05dd0e6090e7cb01588ae9d..e0e0879468e9e196db9d51c8c62835f2945e01e3 100644
--- a/README.md
+++ b/README.md
@@ -1,40 +1,74 @@
# asc-public-docs
-
## Getting started
-To make it easy for you to get started with GitLab, here's a list of recommended next steps.
+### Cloning and Rendering the Docs Locally
-Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
+```bash
+# 1. Clone the forked repository to your local machine:
+git clone git@code.usgs.gov:astrogeology/asc-public-docs.git
+cd asc-public-docs/
-## Add your files
+# 2. Create a branch to track your work
+git checkout -b your-branch-name
-- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
+# 3. install dependencies
+pip install -r requirements.txt
+# 4. Make your changes to the code
+# ...
+
+# 5. Preview your changes, in the root of the repo run
+mkdocs serve
+
+# 6. Push your changes to the branch
+git push origin your-branch-name
```
-cd existing_repo
-git remote add origin https://code.usgs.gov/astrogeology/asc-public-docs.git
-git branch -M main
-git push -uf origin main
-```
-***
+### Adding your files
+
+1. Determine what category your docs belong to by reading [the summary on the README](#understanding-the-doc-system).
+2. Write your either in Markdown or as a Jupyter notebook and add it under the directory for that category.
+3. Update `mkdocs.yml`, add a new file somewhere appropriate under `nav:`
+4. Run `mkdocs serve` to check if your file(s) rendered correctly.
+### Getting Your Changes Reviewed
-## Description
+1. On the merge requests tab of the repository in GitLab, you will see a "New merge request" button. Click on it.
+1. Select your branch (feature/your-feature-branch) from the Source branch dropdown.
+1. Specify the target branch (e.g., master) in the Target branch field.
+1. Fill in the necessary information about your changes, including a descriptive title and a description of what your MR proposes.
+1. Submit the merge request.
+1. Assign reviewers if there isn't any traction for your MR by adding them as reviewers or pinging them in the MR.
+1. Address any feedback or comments provided by the reviewers.
+1. Once all the reviewers have approved your changes, one of the maintainers will merge your MR into the main branch.
+1. The continuous deployment system should automatically deploy your new changes.
+1. Celebrate your contribution! :tada:
-## Contributing Docs
+
+## Understanding The Doc System
Contributors should consider writing new docs under one of our four categories:
-1. Getting Started
+1. Getting Started Tutorials
1. How-To Guides
1. Concepts
1. Software Manuals
-### Getting Started Docs
+We use these four categories to cover the range of potential docs while clarifying to authors and readers for what kind of documentation goes where.
+
+| | Getting Started | How-Tos | Concepts | Manuals |
+|-----------------|-----------------------|--------------------------------|----------------------------|-------------------------------------------------------|
+| **Oriented To** | Learning | Achieving a Goal | Understanding | Referencing |
+| **Composed As** | Step-by-Step Jupyter or Similar Tutorial | General Purpose Guide | Written Summary | Generated Sphinx/Doxygen Site |
+| **Has the Goal of** | Enabling Beginners | Showing How To Solve A Problem | Give Detailed Written Explanations | Give Dry Descriptions of Libraries, Services and Apps |
+| **Example** | Jupyter notebook with toy data on how to ingest and project images | A breakdown of quirks working with Themis Images | Write-up on how ISIS defines projections | ISIS library Doxygen reference |
+
+This website structure borrows from the [Divio documentation system](https://documentation.divio.com/), except adapted to more specifically adhere to how our software is already structured, renamed the categories to be more specific, and have more focus on the composition (or mode of writing) of the docs to reduce ambiguity. One can't expect any categorical structure for software documentation to be orthogonal to eachother. There will always exist some degree of overlap between categories as the quantity of documentation grows. Documentation in one category can easily have overlapping information with those in others. However, composition of the doc (e.g., jupyter notebook with an explicit starting and end point, short how-to guide with code examples but ambigious starting point and end point, written explanation without code, doxygen API reference) is less ambigious that whether or not your docs can be considered a guide or a tutorial.
+
+
+### Getting Started Tutorials
These are longer "learn by doing" exercises that users can follow to learn some extended process using the libraries. These should have the user execute code or run commands from the library to complete a task.
diff --git a/docs/how-to-guides/ISIS Developer Guides/App Testing Cookbook.md b/docs/how-to-guides/ISIS Developer Guides/App Testing Cookbook.md
new file mode 100644
index 0000000000000000000000000000000000000000..f33e2f55d590deba8788a38fe08852953422c9bb
--- /dev/null
+++ b/docs/how-to-guides/ISIS Developer Guides/App Testing Cookbook.md
@@ -0,0 +1,167 @@
+
+# ISIS App Testing Cookbook
+
+
+### Main.cpp Templates
+
+#### Minimum
+
+This is generally used when no logs are printed and special help GUI functionality is needed.
+```C++
+#include "Isis.h"
+
+#include "Application.h"
+#include "app_func.h" # replace with your new header
+
+using namespace Isis;
+
+void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+ app_func(ui);
+}
+```
+
+#### Application with Logs
+
+When the application expects to print PVL logs to standard output. Most common case.
+
+```C++
+#include "Isis.h"
+
+#include "Application.h"
+#include "Pvl.h"
+#include "app_func.h" # replace with your new header
+
+using namespace Isis;
+
+void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+ Pvl appLog;
+ try {
+ app_func(ui, &appLog);
+ }
+ catch (...) {
+ for (auto grpIt = appLog.beginGroup(); grpIt!= appLog.endGroup(); grpIt++) {
+ Application::Log(*grpIt);
+ }
+ throw;
+ }
+
+ for (auto grpIt = appLog.beginGroup(); grpIt!= appLog.endGroup(); grpIt++) {
+ Application::Log(*grpIt);
+ }
+}
+```
+#### Application with GuiLogs
+
+Logs that are only to be printed to the GUI command line in interactive mode.
+
+```C++
+#include "Isis.h"
+
+#include "Application.h"
+#include "SessionLog.h"
+#include "app_func.h" # replace with your new header
+
+using namespace Isis;
+
+void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+ Pvl appLog;
+
+ app_func(ui);
+
+ // in this case, output data are in a "Results" group.
+ PvlGroup results = appLog.findGroup("Results");
+ if( ui.WasEntered("TO") && ui.IsInteractive() ) {
+ Application::GuiLog(results);
+ }
+
+ SessionLog::TheLog().AddResults(results);
+}
+```
+
+#### Application with GUIHELPERS
+
+Some apps require a map with specialized GUIHELPERS, these are GUI tools and shouldn't be co-located with the app function.
+
+```C++
+#define GUIHELPERS
+#include "Isis.h"
+
+#include "Application.h"
+#include "app_func.h" // replace with your new header
+
+using namespace Isis;
+using namespace std;
+
+void helper();
+
+// this map and function definitions are ripped directly from the old main.cpp
+map <QString, void *> GuiHelpers() {
+ map <QString, void *> helper;
+ helper ["Helper"] = (void *) helper;
+ return helper;
+}
+
+void IsisMain() { // this may change depending on whether logs are needed or not
+ UserInterface &ui = Application::GetUserInterface();
+ app_func(ui);
+}
+
+void helper() {
+ // whatever
+}
+```
+
+### Application.h Template
+
+This almost never changes between applications.
+```C++
+#ifndef app_name_h // Change this to your app name in all lower case suffixed with _h (e.g. campt_h, cam2map_h etc.)
+#define app_name_h
+
+#include "Cube.h"
+#include "UserInterface.h"
+
+namespace Isis{
+ extern void app_func(Cube *cube, UserInterface &ui, Pvl *log=nullptr);
+ extern void app_func(UserInterface &ui, Pvl *log=nullptr);
+}
+
+#endif
+```
+
+### GTEST Templates
+
+```C++
+
+#include "Fixtures.h"
+#include "Pvl.h"
+#include "PvlGroup.h"
+#include "TestUtilities.h"
+
+#include "app.h"
+
+#include "gtest/gtest.h"
+
+using namespace Isis;
+
+static QString APP_XML = FileName("$ISISROOT/bin/xml/app.xml").expanded();
+
+TEST_F(SomeFixture, FunctionalTestAppName) {
+ // tempDir exists if the fixture subclasses TempTestingFiles, which most do
+ QString outCubeFileName = tempDir.path() + "/outTemp.cub";
+ QVector<QString> args = {"from="+ testCube->fileName(), "to="+outCubeFileName};
+
+ UserInterface options(APP_XML, args);
+ try {
+ appfoo_func(options);
+ }
+ catch (IException &e) {
+ FAIL() << "Unable to open image: " << e.what() << std::endl;
+ }
+
+ // Assert some stuff
+}
+```
\ No newline at end of file
diff --git a/docs/how-to-guides/ISIS Developer Guides/Class Requirements For Using Doxygen Tags.md b/docs/how-to-guides/ISIS Developer Guides/Class Requirements For Using Doxygen Tags.md
new file mode 100644
index 0000000000000000000000000000000000000000..3e596c0365fe95c606e5b30fb135711eb8f22ef8
--- /dev/null
+++ b/docs/how-to-guides/ISIS Developer Guides/Class Requirements For Using Doxygen Tags.md
@@ -0,0 +1,31 @@
+A new ISIS3 class needs to have the following Doxygen tags filled out just above the class declaration, as in this example below:
+
+```C++
+ /**
+ * @brief Add map templates to a project
+ * Asks the user for a map template and copies it into the project.
+ *
+ * @author 2018-07-05 Summer Stapleton
+ * @internal
+ * @history 2018-07-05 Summer Stapleton - Created ImportMapTemplateWorkOrder
+ * class
+ *
+ */
+ class ImportMapTemplateWorkOrder : public WorkOrder {....
+```
+Sometimes, classes are declared inside the header files for other classes. This happens a lot in the $ISISROOT/src/qisis/objs directory where internal XmlHandler classes are defined to handle object serialization.
+These classes need to be documented as well (as in this example from the ImageList header file):
+
+```C++
+ /**
+ * This class is used to read an images.xml file into an image list
+ *
+ * @author 2012-07-01 Steven Lambright
+ *
+ * @internal
+ */
+ class XmlHandler : public XmlStackedHandler {
+```
+
+All dates need to be filled out the way they are in the examples above (YYYY-MM-DD). Sometimes you will see dates in this format: 2012-??-???? or ????-??-??. Do not do this. Also, do not put any dashes or
+other symbols between the date and the name of the programmer. If these documentation standards are not followed, PHP warnings get output when the nightly builds are run.
\ No newline at end of file
diff --git a/docs/how-to-guides/ISIS Developer Guides/Writing ISIS Tests with CTest and GTest.md b/docs/how-to-guides/ISIS Developer Guides/Writing ISIS Tests with CTest and GTest.md
new file mode 100644
index 0000000000000000000000000000000000000000..aecdd87941d6b1ec4edc28cd42708def3d712b44
--- /dev/null
+++ b/docs/how-to-guides/ISIS Developer Guides/Writing ISIS Tests with CTest and GTest.md
@@ -0,0 +1,265 @@
+# How To Write ISIS Tests with CTest and GTest
+
+??? Tip "Helpful External documentation"
+
+ Consider referencing these as you go along in case you need more in-depth info on how to work with gtest.
+
+ * [gtest primer](https://github.com/google/googletest/blob/main/docs/primer.md) : It is highly recommended that you read over the primer if you are not familiar with gtest.
+ * [Advanced gtest](https://github.com/google/googletest/blob/main/docs/advanced.md) : This document covers a wide range of advanced options for testing tricky logic and customizing test output.
+ * [gmock Introduction](https://github.com/google/googletest/blob/main/docs/gmock_for_dummies.md) : A great introduction to how gmock can be used to remove dependencies from tests.
+ * [gmock Matcher List](https://github.com/google/googletest/blob/main/docs/gmock_cheat_sheet.md#matchers-matcherlist) : This whole document is helpful for gmock, but these matchers have some nice uses in gtest too.
+
+???+ info "App Conversion + Gtest PR Checklist"
+
+ Things that all new test additions need to have done for an ISIS app that is still using the old paradigm.
+
+ - [ ] New .cpp/.h source files added as `<appname>.cpp/<appname>.h` in all lowercase.
+ - [ ] Contents of main.cpp moved into `<appname>.cpp` with a function named `<appname>` in lower camel case.
+ - [ ] Main.cpp replaced with call to app function in `<appname>.cpp`
+ - [ ] New app tests added as `ISIS3/isis/tests/FunctionalTests<appname>.cpp` in upper camel case
+ - [ ] New GTests prefixed with `FunctionalTest<appname>`
+ - [ ] Old Makefile tests removed
+ - [ ] New tests passing on Jenkins
+ - [ ] Old test data removed
+
+## Refactoring ISIS3 Applications
+
+In order to better integrate with the gtest unit test framework, all of our application logic needs to be callable programmatically.
+
+This is a first step towards several places:
+
+1. Improving granularity of application testing
+1. Reducing testData size
+1. Improving application test run time
+
+### Creating a basic callable function
+
+For the rest of this document, we will use `appname` as the name of the application that is being worked on. Simple example at https://github.com/DOI-USGS/ISIS3/tree/dev/isis/src/base/apps/crop
+
+1. In the `appname` folder create two new files, `appname.cpp` and `appname.h`. These files are where the application logic will live.
+1. In `appname.h` and `appname.cpp` create a new function in the `Isis` namespace with the following signature `void appname(UserInterface &ui)`. If the application has a `from` cube, add a second function with the input cube as the first argument `void appname(Cube incube, UserInterface &ui)`.
+1. Copy the contents of the existing `IsisMain` function curretly located in `main.cpp` into the new `void appname(Cube incube, UserInterface &ui)` function. (if the app doesn't take any file parameters (i.e., network, text, cube list...) copy the contents into` void appname(UserInterface &ui)`). If there is no input cube, but there are other input files, add them as input parameters similar to how the input cube was done, see spiceinit and cnetcheck tests for examples).
+1. Modify `void appname(UserInterface &ui)` to open the input cube, usually "from", and/or other files and call the second function `void appname(Cube incube, UserInterface &ui)`
+1. Copy any helper functions or global variables from `main.cpp` into `appname.cpp`. So as to not pollute the `Isis` namespace and avoid redefining symbols
+1. Prototype any helper functions at the top of `appname.cpp` and define them at the bottom of `appname.cpp`. Do not define them in `appname.h`.
+1. Put all of the required includes in `appname.cpp` and `appname.h`.
+1. Remove the call to get the UserInterface from `appname.cpp`; it usually looks like `UserInterface &ui = Application::GetUserInterface();`.
+1. In `main.ccp`, add the following
+
+```C++
+#include "Isis.h"
+
+#include "UserInterface.h"
+#include "appname.h"
+
+using namespace Isis;
+
+void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+ appname(ui);
+}
+```
+
+??? Warning "If your application uses `Application::Log()`"
+ Due to how the Application singleton works, calling `Application::Log()` outside of an actual ISIS application currently causes a segmentation fault. To avoid this, modify the new `appname` function to return a Pvl that contains all of the PvlGroups that need to be logged instead of calling `Application::Log()`. Then, change your `main.cpp` to
+
+ ```C++
+ #include "Isis.h"
+
+ #include "Application.h"
+ #include "Pvl.h"
+ #include "UserInterface.h"
+ #include "appname.h"
+
+ using namespace Isis;
+
+ void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+ Pvl results = appname(ui);
+ for (int resultIndex = 0; resultIndex < results.groups(); resultIndex++) {
+ Application::Log(results.group(resultIndex));
+ }
+ }
+ ```
+
+ Wherever Application::log is called with some pvl group (here called `pvlgroup`), in the app func replace with:
+
+ ```C++
+ if (log){
+ log->addGroup(pvlgroup);
+ }
+ ```
+
+## Creating a more complex callable function
+
+The basic interface that we've created so far is simply a mirror of the application command line interface. In order to further improve the testability of the application, we should break the application down into functional components.
+
+### Separating parameter parsing
+The first step is to separate the UserInterface parsing from the program logic.
+
+All of the UserInterface parsing should be done in the `appname(UserInterface &ui)` function. Then, all of the actual program logic should be moved into another function also called `appname`. The signature for this function can be quite complex and intricate. Several tips for defining the `appname` function signature are in the next sections, but there is not perfect way to do this for every application.
+
+Once the `appname` function is defined, the `appname(UserInterface &ui)` function simply needs to call it with the appropriate parameters once it has parsed the UserInterface.
+
+### Separating I/O
+
+Most ISIS3 applications were designed to read their inputs from files and then output their results to the command line and/or files. Unfortunately, gtest is very poorly setup to test against files and the command line. To work around this, it is necessary to remove as much file and command line output from the new `appname` functions as possible. Here are some examples of how outputs can be separated from the application logic:
+
+1. Anything that would be logged to the terminal should be simply returned via the log pointer. This way, it can be programmatically validated in gtest. This in fact already needs to be done because of [issues](#if-your-application-uses-applicationlog) with `Application::Log()`.
+1. No input filenames should be passed as arguments. All files required by the program should be opened and converted into in-memory objects and then passed to the function. This will help eliminate the need for test data files in many applications. **Make sure that for Cubes the appropriate CubeAttributeInput and CubeAttributeOutput values are set!**
+
+### Process, helper functions, and global variables
+Many ISIS3 applications make sure of the Process class and its sub-classes. While these classes make file I/O easier, they also tightly couple it to the application logic! Some of them can take objects like cubes instead of filenames, but not all of them. They may need to be refactored to use objects instead of filenames. For now, where-ever possible use objects, but it is acceptable to use filenames if an object cannot be used.
+
+Many of the Process sub-classes use process functions to operate on cubes. These helper functions will need to be pushed into the ISIS3 library. There is a chance that there will be symbol conflicts due to multiple applications using functions with the same name. In this case, the function can simply have its name modified. This is also a natural point at which application logic can be segmented and tested separately.
+
+Because of how the Process sub-classes use process functions, many older ISIS3 applications use global variables to pass additional parameters to helper functions. This can cause serious issues because applications are no longer self-contained executables. To help with this, ProcessByBrick and ProcessByLine have been modified to use a [lambda function with captures](https://en.cppreference.com/w/cpp/language/lambda#Lambda_capture) as the process function. All of the previously global variables can now be defined in the `appname` function and then captured in the lambda function.
+
+For example, here's an app called checkerboard which generates an artificial cube with a checkerboard pattern. It requires access to the variable `size` to work but `ProcessByLine.StartProcess` only supports functions `Buffer` objects as input. Therefore, the app uses a global variable in order for the checkerboard function to have `size` in it's scope:
+```C++
+// original foo.cpp
+#include "Isis.h"
+
+// .. some other incs
+
+int size;
+
+void do_process(Buffer &in, Buffer &out) {
+ // do stuff with in, out and size
+}
+
+void isismain() {
+ UserInterface &ui = Application::GetUserInterface();
+ size = ui.GetInteger("SIZE");
+
+ ProcessByLine p;
+
+ p.SetInputCube("FROM");
+ p.SetOutputCube("TO");
+
+ p.StartProcess(do_process);
+}
+```
+
+can be refactored using a lambdas which captures the size variable:
+
+```C++
+// callable foo.cpp
+#include "Isis.h"
+
+// .. some other incs
+
+void IsisMain() {
+ UserInterface &ui = Application::GetUserInterface();
+
+ // int is defined in the scope of main
+ int size = ui.GetInteger("SIZE");
+
+ // lambda equivalent of the checkerboard function, capture is set to get
+ // all local variables by reference
+ auto do_process = [&](Buffer &in, Buffer &out)->void {
+ // do stuff with in, out and size
+ };
+
+ ProcessByLine p;
+
+ p.SetInputCube("FROM");
+ p.SetOutputCube("TO");
+
+ p.StartProcess(do_process);
+}
+```
+
+## Creating a new test suite
+
+### For a Class
+1. Create a new file `ClassNameTests.cpp` in `isis/tests/`. For example, the tests for the Cube class should be in `CubeTests.cpp`.
+1. Add `#include "gmock/gmock.h"` to the file.
+1. Write your test cases.
+1. Delete old tests
+
+### For an Application
+1. Create a new file `FunctionalTestAppname.cpp` in `isis/tests/`. For example, the tests the application `isisimport` should be in `FunctionalTestIsisImport.cpp`.
+1. Add you tests to this file
+1. Delete the tests and all of the test directories
+
+Note: If your tests require the use of ISIS's Null value, you will need to include SpecialPixel.h
+
+### Test names
+We use gtest as our unit testing framework, but use ctest to actually run the tests. Test name can be defined in the test definition (cpp file). The naming convention for gtests is `UnitTest<Object><test case>` for unit tests and `FunctionalTest<app name><test case>` for app tests. Both are upper camel case. The documentation for how this works can be found in [cmake's documentation](https://cmake.org/cmake/help/v3.13/module/GoogleTest.html).
+
+>**Note:** App names are considered a single word for camel case purposes. So when naming a test file or function, only capitalize the first letter of the app name, even if the app name is made up of multiple words.
+
+To run the gtests for a specific class, use `ctest -R ClassName`
+
+To run all gtests, use `ctest -R "\." -E "(_app_|_unit_)"`. Not that this command simply excludes old Makefile based tests that contain the substrings `_app_` and `_unit_` in their respective names.
+
+### Basic tests
+`TEST(Foo, Bar)` will produce the test `Foo.Bar`.
+
+### Test fixtures
+`TEST_F(Foo, Bar)` will also produce the test `Foo.Bar`.
+
+The names of fixtures are at the developer's decretion. Fixtures that require extra data should have their data files placed in ISIS3/isis/tests/data inside a folder matching the fixture name.
+
+### Parameterized tests
+```
+TEST_P(Foo, Bar) {
+...
+}
+INSTANTIATE_TEST_CASE_P(
+ Baz,
+ Foo,
+ ::testing::Values(T x, T y, T z));
+```
+will produce 3 different tests that are named
+1. `Baz/Foo.Bar/x`
+1. `Baz/Foo.Bar/y`
+1. `Baz/Foo.Bar/z`
+
+## General Testing Tips
+
+### Testing exceptions
+Testing for exception throws in gtest can be rather convoluted. Through testing and looking at what others have done, we have settled on using the following setup to test an exception throw:
+
+```
+try {
+ // Code that should throw an IException
+ FAIL() << "Expected an exception to be thrown";
+}
+catch(IException &e) {
+ EXPECT_TRUE(e.toString().toLatin1().contains("Substring of the expected exception message"));
+}
+catch(...) {
+ FAIL() << "Expected an IExcpetion with message message: \"The full expected exception message.\"";
+}
+```
+
+Be sure to choose a substring of the exception message that will uniquely identify it, but only use parts of the string identified in the actual code. Anything like `**USER ERROR**` or `in IsisAml.cpp at 1613` that are added based on user preference settings should not be included in the substring. The IException and Preferences classes test that these are properly added onto the error messages.
+
+Normally, if the error message does not contain the substring, gtest will only output the the expression evaluated to false. To make the failure message more helpful, we add `<< e.toString().toStdString()` which outputs the full error message if the test fails.
+
+### Testing floating point numbers
+Comparison between floating point numbers is a common problem in both writing and testing software. Carefully choosing test data can help avoid comparisons that are likely to cause problems. Whenever possible, use test data such that output values can be exactly stored in a double-precision floating point number (c++ double). For example, if a function takes its input and divides it by 116, a good test input would be 232 because 232/116 = 2 which can be stored exactly in a double. On the other hand, 1 would be a poor test input because 1/116 cannot be precisely stored in a double. If a comparison between numbers that cannot be stored precisely is required, gtest provides [Special Assertions](https://github.com/google/googletest/blob/main/docs/reference/assertions.md#floating-point) to make the comparisons more tolerant to different rounding.
+
+## Test fixtures
+Because each test case is a completely fresh environment, there is often set-up code that is shared between multiple test cases. You can use a test fixture to avoid copying and pasting this set-up code multiple times. See the [gtest documentation](https://github.com/google/googletest/blob/main/docs/primer.md#test-fixtures-using-the-same-data-configuration-for-multiple-tests-same-data-multiple-tests) for how to create and use fixtures in gtest.
+
+In order to conform to our test case naming conventions, all test fixtures need to be named `ClassName_FixtureName`. For example, a fixture that sets up a BundleSettings object in a not-default state for the BundleSettings unit test could be called `BundleSettings_NotDefault`.
+
+### Test parameterization
+If the same process needs to be run with several different inputs, it can be easily automated via [value-parameterized tests](https://github.com/google/googletest/blob/main/docs/advanced.md#value-parameterized-tests). In order to maintain test naming conventions, when you call the `INSTANTIATE_TEST_CASE_P` macro make sure the first parameter is. `ClassName`. For example
+
+```
+INSTANTIATE_TEST_CASE_P(
+ BundleSettings,
+ ConvergenceCriteriaTest,
+ ::testing::Values(BundleSettings::Sigma0, BundleSettings::ParameterCorrections));
+```
+
+will ensure that the tests start with `BundleSettings`.
+
+
+
+!!! Tip
+ See [the ISIS App Testing Notebook](App Testing Cookbook.md) for examples you can copy from.
diff --git a/docs/how-to-guides/Software Management/Public Release Process.md b/docs/how-to-guides/Software Management/Public Release Process.md
new file mode 100644
index 0000000000000000000000000000000000000000..f601d21df50cd63de8f9280cbcf2b46c5edf5a30
--- /dev/null
+++ b/docs/how-to-guides/Software Management/Public Release Process.md
@@ -0,0 +1,394 @@
+# Public Release Process
+
+This document explains the release process for Official Releases, Release Candidates and custom builds (for example: missions).
+
+
+
+# Step-By-Step Instructions
+
+
+
+## Step 1: Check current false positive test failures
+
+
+In this step, we check the currently failing tests. This is currently a judgement call on whether or not the tests are false-positives. This decision should be made by 2+ developers on the development team.
+
+
+
+## Step 2: Update the Github documents
+
+**This step is only required for release candidates and bug fix release. If you are creating a full feature release, skip this step.**
+
+In this step we will update the documents that are stored in the Github repository. Our changes will be going into the dev branch so create a fresh local branch off of the dev branch.
+
+
+### Part A: Collecting the Changes in the Release
+
+* Update the Changelog
+ * For release candidates we need to update the Changelog to label all of the currently unreleased changes as part of this release. Follow the instructions in [CHANGELOG.md](https://raw.githubusercontent.com/DOI-USGS/ISIS3/dev/CHANGELOG.md) for how to do this.
+ * For bug fix releases we need to update the Changelog to label **only the bug fixes** as part of this release. Follow the instructions in [CHANGELOG.md](https://raw.githubusercontent.com/DOI-USGS/ISIS3/dev/CHANGELOG.md) for how to do this.
+* Update code.json with the new version number and the date last modified.
+
+
+### Part B: Update the Authors List
+
+* If there are any new contributors to the project since the last release ensure that they are added to the [.zenodo.json](https://github.com/DOI-USGS/ISIS3/blob/dev/.zenodo.json) document, and update the `AUTHORS.rst` file from the .zenodo.json file by running `python $ISISROOT/scripts/zenodo_to_authors.py <path_to_your_clone>/.zenodo.json <path_to_your_clone>/AUTHORS.rst`.
+
+
+### Part C: Submit a Pull Request
+
+* Submit a pull request into the dev branch with your modifications to the Changelog and the Authors list.
+* For a bug fix release you will also need to [cherry-pick](https://www.atlassian.com/git/tutorials/cherry-pick) the squashed commit from your pull request into the version branch. If you run into merge conflicts it may be easier to simply redo the above steps with the version branch instead of dev.
+
+
+## Step 3: Set Up the Local and Remote Repositories
+
+In this step, we will prepare the local repository to build from as well as update the remote repository hosted on GitHub. Keep in mind that you will be building from this repo on other systems and plan accordingly by cloning this repo into a directory that you will still have access to as you switch between the machines.
+
+
+### Part A: Setup Repository
+
+* Create a fresh branch off of the appropriate version branch. Branches are created for each minor (i.e. 3.x or 4.x) version of ISIS, and each then specific release is associated with a minor version (i.e. 3.x.x or 4.x.x) tag on that version branch.
+
+ * For releases, there should already be a branch for this version created during the release candidate process. If there is not already a branch for this version, you will need to create a branch for this release off of `dev`. If you are doing a release for ISIS 3.10, the git command to create a branch and checkout to it is `git checkout -b 3.10 upstream/dev`. If there is already a version branch: `git checkout -b 3.10 upstream/3.10`
+
+ * For release candidates, there may or may not be a branch for the version. If there is not, create a branch off of `dev`. If there is a version branch: `git checkout -b 3.10 upstream/3.10`.
+
+
+### Part B: Update isis/CMakeLists.txt
+
+* Update the VERSION variable to the latest version number. NOTE: Do not add the _RC#
+
+* Update the RELEASE_STAGE variable:
+
+ * 'stable' is for full releases.
+
+ * 'beta' is for RC's.
+
+ * 'alpha' is for developer release or custom mission builds.
+
+
+
+### Part C: Update recipe/meta.yaml
+
+* Update the version variable to the version of ISIS you are building.
+
+ * If you are building a standard release, use the same version number as in [Part B](#part-b-update-isiscmakeliststxt).
+
+ * If you are building a release candidate, include "_RCx".
+
+ * For the first ISIS3.6.1 release candidate, it would be: "3.6.1_RC1".
+
+ * If you are creating a custom build, include a unique tag.
+
+ * For a custom ISIS3.6.1 CaSSIS build, it would be: "3.6.1_cassis1".
+
+* Ensure the build_number is set to 0.
+
+ * The build number should be incremented for each build produced at the **same version** of source code and should always begin at 0 for each release version.
+
+ * ****Please note that this step is important as this is how the file to be uploaded to Anaconda Cloud is named by conda build. If a file with the same name already exists on USGS-Astrogeology channel in Anaconda Cloud, it will be overwritten with the new upload.****
+
+* Update the `build` section by copying the current contents of `environment.yaml` into the `build` section. Update the `run` section to include any new packages and remove any packages that are no longer needed.
+
+
+
+### Part D: Create a Pull Request
+
+* Make a pull request with your local changes into the version (i.e., the version number created above) branch of the repository.
+
+
+
+<!---
+ * To create a new branch, first prepare your local repo by pulling down the merged changes you made earlier (e.g. `git pull upstream dev`)
+
+ * Next, create a branch with the appropriate name for the release version in the format `<major version>.<minor verson>`, by running for example: `git branch -b 3.10`. After creation, this branch can be pushed directly to upstream. (`git push upstream 3.10`.)--->
+
+
+
+### Part E: Make Github Release
+
+* Draft a new github release.
+
+ * Tag the release.
+
+ * Make sure to change the target from `dev` to the appropriate version branch for your release.
+
+ * The release "Tag version" must be the \<version\> from the meta.yaml file you modified in [Part C](#part-c-update-recipemetayaml).
+
+ * Mission and non-standard builds (including release candidates) must be tagged as pre-release.
+
+ * Name the release.
+
+ * If it is a standard release, name it "ISISX.Y.Z Public Release".
+
+ * If it is a release candidate, name it "ISISX.Y.Z Release Candidate N".
+
+ * Describe the release.
+
+ * If it is a standard release, description should state "The official release for ISIS version X.Y.Z".
+
+ * If it is a release candidate, description should state "[First/Second/Third/...] release candidate for ISIS X.Y.Z".
+
+
+
+## Step 4: Create the Builds for Anaconda Cloud
+
+
+In this step, we will create the build(s) for Anaconda Cloud using the conda-build system. There are two builds for standard releases: one for Linux (built on Ubuntu 18 LTS), and one for Mac (built on Mac OS 10.14). Missions may only need one build and not the other. Communicate with your team as to what they need. Repeat this and the upload process process for each necessary system.
+
+Anaconda leverages caching in many places which can cause issues. If you are getting unexpected issues, try a different installation and/or a different machine.
+
+
+### Part A: Operating System
+
+* Ensure the OS on the machine you are building the release on is the appropriate operating system (Mac OS 11.6 or Ubuntu 18 LTS).
+
+ * If you do not have access to a Ubuntu 18 LTS, you can ssh into prog28.
+
+
+### Part B: Setup Anaconda
+
+* Run `conda clean --all` to clean out your package cache and ensure you pull fresh packages for the build.
+
+* Activate the base environment: ```conda activate```.
+
+* Ensure that you have anaconda-client, conda-build, and conda-verify installed in your base environment
+
+ * You can check by running ```anaconda login```, ```conda build -h```, and ```conda-verify --help```, respectively.
+
+ * If any of these packages are not in your base environment, they can be installed using the following
+
+commands:
+
+`conda install anaconda-client`
+
+`conda install -c anaconda conda-build`
+
+`conda install -c anaconda conda-verify`
+
+ * If running ```anaconda login``` resulted in an error message similar to ```[ERROR] API server not found. Please check your API url configuration``` run the following command and try again: ```anaconda config --set ssl_verify False```
+
+
+### Part C: Run the Build
+
+* Go to the root of the repository you set up in [Step 3 Part A](#part-a-setup-repository). Make sure it is up to date.
+
+ * Switch to the appropriate version branch
+
+```git checkout <version branch>```
+
+ * Ensure you are at the head of the release branch ```git pull upstream <version branch>```
+
+* Run the bash script in the root of the directory: ``` buildCondaRelease.sh```. This script will remove a CMake parameter that is used for jenkins and create a conda build running the conda build command:```conda build recipe/ -c conda-forge -c usgs-astrogeology --override-channels```
+
+ * The -c options are to give conda a channel priority. Without these, conda will always attempt to download from the default Anaconda channel first. (Unlike the environment.yml files, channel priority cannot be defined within the meta.yaml.)
+
+
+
+## Step 5: Test the Conda Build
+
+
+After the conda build completes, it should be tested by uploading it to your personal anaconda cloud account and conda installing it locally.
+
+* Use the command ```anaconda upload -u <conda-cloud-username> <path-to-the-.tar.bz2-file>``` to upload the conda build to your personal anaconda channel.
+
+* Follow the standard [installation instructions](https://github.com/DOI-USGS/ISIS3#isis3-installation-with-conda) to install this package locally for testing, but at the installation step, instead of running `conda install -c usgs-astrogeology isis`, run `conda install -c <conda-cloud-username> -c usgs-astrogeology isis`
+
+* Run an ISIS application, like `spiceinit -h` and insure that it runs without error. This is testing whether the conda environment set up during the install is complete enough to run ISIS.
+
+
+## Step 6: Upload the Build to Anaconda Cloud
+
+
+In this step, we will upload the build(s) that we just created into the Anaconda Cloud to distribute them to our users. Uploading the .tar.bz2 file requires one command, however, non-standard builds (release candidates or custom builds), must be uploaded with a label.
+
+* If you missed the location of the .tar.bz2 file at the bottom of the build, use ```conda build recipe/ --output``` to reprint. This command does not confirm the file exists - only where it *would* be saved with a successful build.
+
+* For a standard release, use the command ```anaconda upload -u usgs-astrogeology <path-to-the-.tar.bz2-file>```
+
+* For an Release Candidate, use the command ```anaconda upload -u usgs-astrogeology -l RC <path-to-the-.tar.bz2-file>```
+
+* For a custom build, specify a custom label and use the command ```anaconda upload -u usgs-astrogeology -l <custom-label> <path-to-the-.tar.bz2-file>```
+
+ * For example, when generating a custom build for the CaSSIS team, we would use the "cassis" label and the command ```anaconda upload -u usgs-astrogeology -l cassis <path-to-the-.tar.bz2-file>```
+
+If the upload fails or displays a prompt for a username and password, try adding an API token for usgs-astrogeology to your environment by running `export ANACONDA_API_TOKEN=<token>`. Ask another developer for the API token. This approach is recommended over adding `-t <token>` to your anaconda upload command, because of a known bug where `-t` is either interpreted as a package type or a token depending on its position in the `anaconda upload` command.
+
+
+## Step 7: Back up the Build
+
+Back up the build by copying the .tar.bz2 to:
+
+ * /work/projects/conda-bld/osx-64/ for Mac OS 11.6.
+
+ * /work/projects/conda-bld/linux-64/ for Ubuntu 18 LTS.
+
+
+## Step 8: Update Data and TestData Areas on rsync Servers
+
+
+This step covers how to update the data on the public s3 buckets. This is where our external users will have access to the data necessary for running ISIS. There are two locations, one is the S3 bucket where users directly download data from. The other is and EFS drive that only accessible internally and is mounted for daily use. See the [internal only documentation](https://code.chs.usgs.gov/asc/ASC_Software_Docs/-/blob/main/ISIS/Maintaining%20ISIS%20Data.md) for more info on how these are setup. Action is only required if there are smithed kernels that need to be uploaded to /usgs_data/.
+
+**Please pay careful attention to where you are rclone'ing the data to on the S3 buckets.
+
+## Step 9: Create Internal Builds/Installs for Astro
+
+
+This step covers creating the builds and the installation environments of ISIS for our internal users here on the ASC campus using the shared anaconda installs. Setting up the conda environments involve installing the conda build of ISIS that we just pushed up to Anaconda, and will follow the instructions found in the README.MD of the isis3 repository. These commands must be run as isis3mgr for permission purposes.
+
+
+### Part A: Shared Anaconda Installs
+
+* You will need to install the new version of ISIS into the two shared Anaconda installs on the ASC campus.
+
+ * For Linux: `/usgs/cpkgs/anaconda3_linux`
+
+ * For MacOS: `/usgs/cpkgs/anaconda3_macOS`
+
+
+### Part B: Installing ISIS
+
+* Follow the standard [installation instructions](https://github.com/DOI-USGS/ISIS3#isis3-installation-with-conda) to install the latest version of ISIS into a new environment.
+
+ * For a standard release, the environment should be named `isisX.Y.Z`.
+
+ * For a release candidate, the environment should be named `isisX.Y.Z-RC#`.
+
+ * For a custom build, the environment should be named `isisX.Y.Z-<custom-label>`.
+
+ * For the step which sets up the data and testData areas, make sure to use the new isis_data and isis_testData directories, i.e.: `python $CONDA_PREFIX/scripts/isisVarInit.py --data-dir=/usgs/cpkgs/isis3/isis_data --test-dir=/usgs/cpkgs/isis3/isis_testData`
+
+* Confirm that the environment has been set-up properly by deactivating it, reactivating it, and running an application of your choice.
+
+
+## Step 10: Update Documentation
+
+
+**This step is only done for standard feature releases.**
+
+This step will update the ISIS documentation on our [website](https://isis.astrogeology.usgs.gov/UserDocs/) for our users worldwide. These commands must be run as isis3mgr for permission purposes.
+
+
+### Part A: Build the documentation
+
+
+* Perform a local build (not a conda build) using the instructions available [here](https://github.com/DOI-USGS/ISIS3/wiki/Developing-ISIS3-with-cmake)
+
+* setisis to the build directory from [Step 3 Part A](#part-a-setup-repository).
+
+* Run the ```ninja docs``` command from this build directory to build the documentation for this version of the code.
+
+
+### Part B: Upload the documentation
+
+This step requires that you have an rclone config for the `asc-docs` bucket. You can get credentials from vault.
+
+In the `$ISISROOT` directory run the following commands, but replace <your-config> with your config for `asc-docs` and <version-number> with the version of ISIS you are releasing. For example if you config is called `s3-docs` and you are releasing 8.1.0, the first command would be `rclone sync --dry-run docs/8.1.0 s3-docs://asc-docs/isis-site/8.1.0/
+
+* Optionally add the `--dry-run` flag to test prior to actually uploading, `rclone sync docs/<version-number> <your-config>://asc-docs/isis-site/<version-number>/`
+* `rclone copy docs/index.html <your-config>://asc-docs/isis-site/`
+
+
+## Step 11: Communicate Availability of Build
+
+
+This step will will communicate that a new version of ISIS is available.
+
+
+### Part A: External Announcement
+
+* Create a new topic under the [ISIS Release Notes](https://astrodiscuss.usgs.gov/c/ISIS/isis-release-notes) category on [astrodiscuss](https://astrodiscuss.usgs.gov/).
+
+* Fill in the following template for the release notes post:
+
+```
+
+## How to install or update to <X.Y.Z>
+
+
+Installation instructions of ISIS can be found in the README on our [github page ](https://github.com/DOI-USGS/ISIS3).
+
+
+If you already have a version of ISIS 4.0.0 or later installed in an anaconda environment, you can update to <X.Y.Z> by activating your existing isis conda environment and running `conda update isis` .
+
+
+### How to get access to <X.Y.Z> at the ASC
+
+
+The new process proposed in the internal [RFC](https://astrodiscuss.usgs.gov/t/internal-rfc-distribution-of-isis3-at-asc/52/26) is now in full effect. Please review the process of using anaconda environments to activate isis [here](https://astrodiscuss.usgs.gov/t/using-the-asc-conda-environment-for-isisx-y-z/106).
+
+
+Once a version of conda is active, run the command: `conda activate isis<X.Y.Z>` to use this newest version of ISIS.
+
+
+## Changes for <X.Y.Z>
+
+<!---
+Copy this release's section of the Changelog here
+-->
+
+
+## Notes
+
+
+The following operating systems are supported for this release:
+
+
+* Ubuntu 18.04
+* macOS Mohave 11.6
+
+(Other Linux/macOS variants may be able to run this release, but are not officially supported.)
+
+
+If you find a problem with this release, please create an issue on our [github issues page](https://github.com/DOI-USGS/ISIS3/issues/new/choose/)
+
+```
+
+* For a Release Candidate, add the following under "Notes":
+
+
+```
+
+There are some important considerations to keep in mind when using this release candidate:
+
+
+* Do not use this version for production work. A stable isisX.XX.XX release will be uploaded after a month.
+* The ISIS online documentation will not be updated until the stable release is announced.
+
+```
+
+
+### Part B: Internal Announcement
+
+
+* Send an email to all of astro (GS-G-AZflg Astro <gs-g-azflg_astro@usgs.gov>) informing them of internal availability.
+
+ * Your e-mail can simply be a link to the external announcement.
+
+## Step 12: Update the Release Schedule
+
+Update the [release schedule](https://github.com/DOI-USGS/ISIS3/wiki/Release-Schedule) with the date of the release and update any future releases with the appropriate dates. Releases should be nominally 3 months apart.
+
+
+## Problems
+
+If you test the conda environment you created for the ISIS build, i.e., isis3.7.1, on prog26 as isis3mgr and get the following warning:
+
+```
+
+Could not find conda environment: <isis version>
+
+You can list all discoverable environments with `conda info --envs`.
+
+```
+
+Run the following command:
+
+```
+
+source /usgs/cpkgs/anaconda3_macOS/etc/profile.d/conda.sh
+
+```
+
+This problem occurs because we are building ISIS with the shared anaconda on cpkgs instead of /jessetest/miniconda3 (which is the version of anaconda being sourced in .bashrc). You may also do a conda activate with a full path to the environment instead of running the above source command.
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
index ce31d28e663eb9a9ee4fca4e514a47190a3eee06..79d76b6ab77358da3e36e830c06ce7d12a36bf15 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1 +1,61 @@
-# Home
\ No newline at end of file
+---
+hide:
+ - navigation
+ - toc
+---
+
+# Where to Look
+
+These docs use a simple system of defining software documentation in four categories based on the composition and goal of a particular piece of documentation:
+
+::cards:: cols=1
+
+[
+ {
+ "title": "Getting Started",
+ "content": "Step-by-step tutorials for beginners to get started with different aspects of the Astro software portfolio; this is the best place to learn new things as a beginner to some of our software or those unfamiliar with particular parts of the code.",
+ "url" : getting-started/index.md
+ },
+ {
+ "title": "How-To Guides",
+ "content": "Examples on how-to complete common software tasks; for intermediate to advanced users who want examples on how to accomplish a particular task.",
+ "url" : how-to-guides/index.md
+ },
+ {
+ "title": "Concepts",
+ "content": "Write-ups that define and explain concepts that apply to our software; this is for anyone who wants a better understanding of particular higher-level concepts.",
+ "url" : concepts/index.md
+},
+ {
+ "title": "Software Manuals",
+ "content": "Links to in-depth software manuals; contains in-depth references to a particular software project's apps and APIs.",
+ "url" : manuals/index.md
+ },
+]
+
+::/cards::
+
+
+## Documentation System
+
+We use these four categories to cover the range of potential docs while clarifying to authors and readers for what kind of documentation goes where.
+
+| | Getting Started | How-Tos | Concepts | Manuals |
+|-----------------|-----------------------|--------------------------------|----------------------------|-------------------------------------------------------|
+| **Oriented To** | Learning | Achieving a Goal | Understanding | Referencing |
+| **Composed As** | Step-by-Step Jupyter or Similar Tutorial | General Purpose Guide | Written Summary | Generated Sphinx/Doxygen Site |
+| **Has the Goal of** | Enabling Beginners | Showing How To Solve A Problem | Give Detailed Written Explanations | Give Dry Descriptions of Libraries, Services and Apps |
+| **Example** | Jupyter notebook with toy data on how to ingest and project images | A breakdown of quirks working with Themis Images | Write-up on how ISIS defines projections | ISIS library Doxygen reference |
+
+This website structure borrows from the [Divio documentation system](https://documentation.divio.com/), except adapted to more specifically adhere to how our software is already structured, renamed the categories to be more specific, and have more focus on the composition (or mode of writing) of the docs to reduce ambiguity. One can't expect any categorical structure for software documentation to be orthogonal to eachother. There will always exist some degree of overlap between categories as the quantity of documentation grows. Documentation in one category can easily have overlapping information with those in others. However, composition of the doc (e.g., jupyter notebook with an explicit starting and end point, short how-to guide with code examples but ambigious starting point and end point, written explanation without code, doxygen API reference) is less ambigious that whether or not your docs can be considered a guide or a tutorial.
+
+## Contributing New Docs and Submitting Issues
+
+Before you consider contributing new documentation, ask yourself what category it belongs in. [Getting-started tutorial](getting-started/index.md), [how-to guide](how-to-guides/index.md), [concepts write-up](concepts/index.md), or a [software manual](manuals/index.md). The page for each category has a more in-depth explanation of what each category entails. Contributors can also reference the above table for a TLDR. New contributions need a merge request (MR) into the website's [git repository](https://code.usgs.gov/astrogeology/asc-public-docs) and go through a review by other contributors before it can get merged and deployed.
+
+Regarding software manuals, issues or contributions should be addressed to the repository for that specific project. The software manuals should have links to their repositories.
+
+You can submit any issues (e.g., addressing grammar errors, factual inacuracies) and find more info on how to contribute new docs through the site's [git repository](https://code.usgs.gov/astrogeology/asc-public-docs).
+
+
+
diff --git a/mkdocs.yml b/mkdocs.yml
index c190f2f6d80596ab39d262b409eec1281f813ef4..1c7e4055226918264f78737ac620c461a2faf39a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -3,15 +3,18 @@ site_name: USGS Astrogeology Software Docs
theme:
name: material
custom_dir: custom_theme/
-
+
+ font:
+ text: Inter
+ code: Roboto Mono
+
features:
+ - navigation.tabs
- navigation.expand
- navigation.path
- - navigation.sections
- - navigation.instant
- - navigation.instant.progress
- - navigation.tabs
-
+ - navigation.indexes
+ - search.suggest
+ - search.suggest
palette:
# Palette toggle for dark mode
@@ -34,7 +37,14 @@ theme:
nav:
- Home: index.md
- Getting Started: getting-started/index.md
- - How-To Guides: how-to-guides/index.md
+ - How-To Guides:
+ - Home: how-to-guides/index.md
+ - Software Management:
+ - ISIS Public Release Process: how-to-guides/Software Management/Public Release Process.md
+ - ISIS Developer Guides:
+ - How To Write ISIS Tests with CTest and GTest: "how-to-guides/ISIS Developer Guides/Writing ISIS Tests with CTest and GTest.md"
+ - App Testing CookBook: "how-to-guides/ISIS Developer Guides/App Testing Cookbook.md"
+ - Class Requirements For Using Doxygen Tags: "how-to-guides/ISIS Developer Guides/Class Requirements For Using Doxygen Tags.md"
- Concepts: concepts/index.md
- Manuals: manuals/index.md
@@ -48,6 +58,21 @@ extra_css:
extra_javascript:
- https://asc-public-docs.s3.us-west-2.amazonaws.com/common/uswds/3.6.0/js/uswds-init.min.js
+plugins:
+ - search
+
markdown_extensions:
- neoteroi.cards
-
+ - tables
+ - attr_list
+ - md_in_html
+ - admonition
+ - pymdownx.details
+ - pymdownx.superfences
+ - def_list
+ - pymdownx.tasklist:
+ custom_checkbox: true
+ clickable_checkbox: true
+ - toc:
+ title: On this page
+ permalink: true
\ No newline at end of file