Adds documents for guidelines on contributing

CODE_STYLE.md

@@ -30,13 +30,15 @@
   if(file_exists(fileName)) call open_file(fileObj,fileName, is_restart=.false)
   ```
 * Avoid the use of `GOTO` statements
-* Avoid the use of Fortran reserved words as variables (e.g. `DATA`, `NAME`)
+* Avoid the use of 
+[Fortran keywords](https://fortranwiki.org/fortran/show/Keywords) 
+as variables including `NAME` (e.g. `DATA`)
 * Avoid the use of `COMMON` blocks
 
 ### Derived types
 
-* Type names must be in CapitalWord format.
-* Variables names must be in underscore_word format.
+* Type names with more than one word must be in CapitalWord format and end in either _t or _type.
+* Variables names with more than one word must be in underscore_word format.
 * All member variables must be private.
 * Doxygen description on the line before the type definition.
 * Inline doxygen descriptions for all member variables.

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing To libFMS
+# Contributing To FMScoupler
 
 Thank you for taking time to contribute.
 
@@ -13,14 +13,14 @@ please review the [code style guidelines](CODE_STYLE.md).
 ## High Bar for Contribution
 
 Because the FMScoupler is used by all of the models and all of the model 
-components at GFDL, updates face more scrutiny and require more justification 
-and testing.  The additional step of setting up a meeting with Modeling Systems 
-Division (MSD) is required for all updates to ensure that the updates are 
-required at the coupler level.  MSD will reject updates that should/could be 
-made in a component model.
+components at GFDL, updates face enhanced scrutiny and require enhanced 
+justification and testing.  The additional step of setting up a meeting 
+with Modeling Systems Division (MSD) is required for all updates to ensure 
+that the updates are required at the coupler level.  MSD will reject updates 
+that should/could be made in a component model.
 
 
-Table of Contents
+## Table of Contents
 * [High Bar for Contribution](*high-bar-for-contribution)
 * [Code of Conduct](#code-of-conduct)
 * [Quick Start Workflow](#quick-start-workflow)
@@ -46,7 +46,7 @@ uphold this code. Please report unacceptable behavior to
 4. Update the tests and code
 5. Push the commits to your fork
 6. Submit a [pull request](#pull-requests) to the `main` branch
-7. **Set up a meeting with GFDL Modeling Systems Division to scientifically justify the need to make updates at the coupler level**
+7. **Set up a meeting with GFDL Modeling Systems Division and any other itnerested parties to scientifically justify the need to make updates at the coupler level**.
 8. Fulfill requests for changes
 
 Note: Step 7 is an extra necessary step.
@@ -58,9 +58,9 @@ as descriptive as possible.  See the [Issues](#issues) section for more details.
 
 Support for this project is primarily accomplished via this project’s community.
 Additional support may be offered from related communities
-(e.g. [MOM6](https://github.com/NOAA-GFDL/MOM6) or by members of the GFDL
+(e.g. [MOM6](https://github.com/NOAA-GFDL/MOM6)) or by members of the GFDL
 [Modeling Systems](https://www.gfdl.noaa.gov/modeling-systems) Group.  The
-members of the Modeling Systems group are the main developers and maintainers of
+members of the Modeling Systems group are the main maintainers of
 this project.  Modeling Systems is a small group, and our ability to offer
 support is limited.  Please be patient when requesting support.
 
@@ -71,7 +71,8 @@ The issue title should be short and descriptive.  The issue description should
 be clear and concise.  Include enough information to help others reproduce the
 issue, or understand the change requested.  Use
 [GitHub flavored markdown](https://guides.github.com/features/mastering-markdown/)
-to format the message, and include links to references.
+to format the message, and include links to references. Any downstream code 
+updates required for changes should be included in the issue.
 
 ## Pull Requests
 
@@ -82,6 +83,12 @@ GFDL schedule that addresses the needs of the GFDL scientists.  We follow the
 workflow, briefly described in the [Quick Start Workflow](#quick-start-workflow)
 section.
 
+Any changes that are required for a PR in the FMScoupler should be linked.  Merges
+should take place downstream first in order to ensure new dependencies are 
+available.  Changes made to componenet models that change calls in the 
+FMScoupler must include changes to corresponding null/data models in order to 
+maintain the automated build tests.
+
 Please keep the changes in a single pull to be as small as possible to help
 reviewer(s) quickly evaluate changes.  If you do have a large update, try to
 split the update into small, logical pull requests.  If the update includes code

README.md

@@ -3,7 +3,9 @@
 # Flexible Modeling System (FMS) Coupler
 
 Instructions for contribuing to this project can be found in the 
-[Contribution Guidelines](CONTRIBUTING.md)
+[Contribution Guidelines](CONTRIBUTING.md).  Contributing to the FMScoupler involves a higher 
+level of scrutiny and justification.
+
 
 The Flexible Modeling System (FMS) is a software framework for supporting the
 efficient development, construction, execution, and scientific interpretation