couple of minor edits to atmospheric_physics dev workflow; improve li…

…nking to the new workflow page

docs/atmospheric_physics/development_workflow.md

@@ -8,6 +8,7 @@ The general workflow for adding a feature, bug-fix, or modification to atmospher
 
   1.  [**Open an issue.**](#1-open-an-issue)
   2.  **[Add your code modifications](#3-update-your-code-with-changes-from-the-official-repo) to a branch on your [fork](#2-create-a-fork-if-you-havent-already).**
+  3.  **[Add/amend unit tests](#5-unit-testing)**
   3.  **[Open a PR](#5-creating-a-pull-request-pr) from your branch to the `development` branch.**
   4.  **Respond to any reviewer requests.**
   5.  **Fix any failing tests.**
@@ -89,6 +90,40 @@ where `cool_new_feature` is an example branch name (you can use any name you wan
 
 **2.  Apply your code modifications and/or script additions, and perform at least one test making sure that your modifications work as expected.**
 
+**3.  Add all the files that you want to commit.  There are multiple ways to do this, but one of the safer ways is to first check your status:**
+
+```
+   git status
+```
+
+This will provide a list of all modified files.  For each one of those files whose modifications you want to add to the main package, you will do the following:
+
+```
+   git add awesome_scheme.meta
+```
+
+Where `awesome_script.meta` should be replaced with whatever your file name is.  Do this for each file you want to include.  If you are confident that every file listed by `git status` needs to be added, then you can do it all at once by doing:
+
+```
+   git add -A
+```
+
+You can then type `git status` again, at which point all of the files you added should be "staged" for commit.
+
+**4.  Commit your changes to your local branch:**
+
+```
+   git commit -m "<message>"
+```
+
+where `<message>` is a short descriptor or sentence stating what the commits are for, e.g. "Fixed color bar bug" or "Added significance hatching".
+
+**5.  Push your committed changes to your fork:**
+
+```
+   git push
+```
+
 ### 5. Unit Testing
 
 Also make sure that the unit tests all pass and verify if your changes can be unit tested and added to the test suite. 
@@ -119,15 +154,15 @@ For modules that are currently being built with CMake, independent of any extern
 
 If a module is independent of any external library modules or is dependent on modules already unit tested, it is very likely that it can be added to the testing infrastructure.
 
-#### Adding a new pFUnit test
+##### Adding a new pFUnit test
 
 If you are adding a new file, add it to the list of files being built by the `test/unit-test/CMakeLists.txt`, and if it builds successfully, add a corresponding unit test.  The current workflow is to take your new file in `schemes/{path_to_file}/new_file.F90` and add a corresponding test file in `test/unit-test/tests/{path_to_file}/test_{new_file}.pf`.
 
 To add a test:
 
   1.  Ensure you need to have a currently existing CMake infrastructure.
   2.  Add the code being tested added to a library via `add_library(LIBNAME ...)` in the `test/unit-test/CMakeLists.txt` file.
-  3.  Create a new pFUnit test file to a corresponding directory matching the source file path into the unit-test directory.  For example, if adding a file to `schemes/utilities/new_file.F90`, create a new test file called `test/unit-test/tests/utilities/test_new_file.pf`.
+  3.  Create a new pFUnit test file to a corresponding directory matching the source file path into the unit-test directory.  For example, if your update added the file `schemes/utilities/new_file.F90`, create a new test file called `test/unit-test/tests/utilities/test_new_file.pf`.
   3.  Add `add_pfunit_ctest(TESTNAME TEST_SOURCES test_new_file.pf LINK_LIBRARIES LIBNAME)` in the `CMakeLists.txt` file in the test directory corresponding to the new test file (ex. `test/unit-testing/tests/utilities/CMakeLists.txt` in this example).
   4.  Add subroutines to the `test_new_file.pf` file of the form:
 ```fortran
@@ -151,41 +186,7 @@ At a minimum, unit tests for ESCOMP source code should:
   3.  Have as explicit of names as possible.  There are going to be hundreds of names in each test report and having the ability for a reviewer/contributor to be able to look at a test and intuitively understand what said test is doing is paramount (this is obviously going to vary slightly based on preference but the goal is to have a test name be as intuitive as possible).
   4. Have clear and consise comments on what is being tested above each set of assert statements.
 
-**3.  Add all the files that you want to commit.  There are multiple ways to do this, but one of the safer ways is to first check your status:**
-
-```
-   git status
-```
-
-This will provide a list of all modified files.  For each one of those files whose modifications you want to add to the main package, you will do the following:
-
-```
-   git add awesome_scheme.meta
-```
-
-Where `awesome_script.meta` should be replaced with whatever your file name is.  Do this for each file you want to include.  If you are confident that every file listed by `git status` needs to be added, then you can do it all at once by doing:
-
-```
-   git add -A
-```
-
-You can then type `git status` again, at which point all of the files you added should be "staged" for commit.
-
-**4.  Commit your changes to your local branch:**
-
-```
-   git commit -m "<message>"
-```
-
-where `<message>` is a short descriptor or sentence stating what the commits are for, e.g. "Fixed color bar bug" or "Added significance hatching".
-
-**5.  Push your committed changes to your fork:**
-
-```
-   git push
-```
-
-### 5. Creating a Pull Request (PR)
+### 6. Creating a Pull Request (PR)
 
 **1.  Go to the [ESCOMP atmospheric_physics repo](https://github.com/ESCOMP/atmospheric_physics), and click on the "Pull requests" tab.**
 

docs/conversion/back-to-cam.md

@@ -39,7 +39,7 @@ cprnc <file1> <file2>
 ## Committing your changes
 
 - Open a PR in [ESCOMP/atmospheric_physics](https://github.com/ESCOMP/atmospheric_physics) for your parameterization and any interstitial code (including diagnostics) using the code in your sandbox
-    - Make sure you include a ChangeLog and NamesNotInDictionary.txt file as specified [here](https://github.com/ESCOMP/atmospheric_physics/wiki/Development-workflow#changelog-and-namesnotindictionarytxt)
+    - Be sure to follow the workflow (including adding unit tests and updating the NamesNotInDictionary.txt file) described in the atmospheric_physics [development workflow](../atmospheric_physics/development_workflow.md)
 - Open a PR in [ESCOMP/CAM](https://github.com/ESCOMP/CAM) for your changes in CAM (if calling lists changed) or it may as simple as a PR to update the atmospheric_physics tag in `.gitmodules`. Don't forget to make a ChangeLog.
     - Be sure to include the `ccpp-conversion` label on your PR
 - If any changes were made to CAM-SIMA (more than likely, at least an update to the atmospheric_physics submodule will probably be needed), open a PR in [ESCOMP/CAM-SIMA](https://github.com/ESCOMP/CAM-SIMA).