Update CONTRIBUTING.md

CONTRIBUTING.md

@@ -1,22 +1,51 @@
-## **For Developers**
+# Contributing to `fremor`
 
-* Developers are free to use this repository's `README.md` to familiarize with the CLI and save time from having to install any dependencies, but development within a Conda environment is heavily recommended regardless
-* Gain access to the repository with `git clone --recursive git@github.com:NOAA-GFDL/fremor.git` or your fork's link (recommended) and an SSH RSA key
-    - Once inside the repository, developers can test local changes by running a `pip install .` inside of the root directory after activating a virtual environment, installing the fremor package locally with the newest local changes on top of the installed Conda fremor dependencies. the `-e` flag can be used for an editable installation
-    - Test as a normal user would use the CLI
-* Create a GitHub issue to reflect your contribution's background and reference it with Git commits
+Thank you for considering contributing to `fremor`!
 
-### **Opening Pull Requests and Issues**
-Please use one of the templates present in this repository to open a PR or an issue, and fill out the template to the best of your ability.
-With few exceptions, pull requests always require an issue.
+## Code of Conduct
+By participating in this project, you are expected to uphold our [Code of Conduct](CODE_OF_CONDUCT.md).
 
-### **Adding Tools From Other Repositories**
+## Issues and Feature Requests
+* **Create an Issue:** Before opening a pull request, it helps maintainers greatly to create a GitHub issue to reflect your contribution's background.
+* **Use Templates if You Like:** If desired for extra structure, use one of the templates present in this repository.
+* **Prioritize Clarity and Specifics:** Understandability is key, and achievable specifics keep developers sane.
 
-* Currently, the solution to this task is to approach it using Conda packages. The tool that is being added must reside within a repository that contains a meta.yaml that includes Conda dependencies like the one in this repository and ideally a setup.py (may be subject to change due to deprecation) that may include any potentially needed pip dependencies
-    - Once published as a Conda package, ideally on the [NOAA-GFDL channel](https://anaconda.org/NOAA-GFDL), an addition can be made to the "run" section under the "requirements" category in the meta.yaml of the fremor following the syntax `channel::package`
-    - On pushes to the main branch, the [package](https://anaconda.org/NOAA-GFDL/fremor) will automatically be updated using the workflow file
-
-### **MANIFEST.in**
+## Local Development Setup
+Developers should use virtual environments for their development, as `fremor` is primarily intended for use within them (`conda` or otherwise). 
+While using the tool outside of a virtual environment is possible, it is not tested in our CI pipelines.
 
-* In the case where non-python files like templates, examples, and outputs are to be included in the fremor package, MANIFEST.in can provide the solution. Ensure that the file exists within the correct folder, and add a line to the MANIFEST.in following [this syntax](https://setuptools.pypa.io/en/latest/userguide/miscellaneous.html)
+To set up your local development environment:
 
+1. *Clone the repository:*
+    ```bash
+    # omit --recursive if you don't want tables as submodules
+    git clone --recursive [https://github.com/NOAA-GFDL/fremor.git](https://github.com/NOAA-GFDL/fremor.git)
+    cd fremor
+    ```
+
+2. *Create the `conda` environment, activate, install:*
+    ```bash
+    conda env create -f environment.yaml
+    conda activate fremor
+    pip install -e .
+    ```
+
+3. *Run tests with `pytest` and lint with `pylint` after hacking:*
+    ```bash
+    pytest fremor/tests/
+    pylint --rcfile pylintrc fremor
+    ```
+
+
+
+## Opening a Pull Request
+Forks and branches are welcome, but branches are only useable by a privileged, trusted few who work with 
+this repository. First time contributors must always make their first contribution from a fork.
+
+**Workflow:** Branch off of `main` for your feature or bug fix, and (generally) treat `main` as the trunk
+
+**Committing:** Commit your changes and be sure to reference the original GitHub issue in your commit message. The more atomic, the better!
+
+**CI Checks:** Ensure all GitHub Actions (such as `create_test_conda_env`, `pylint`) pass successfully.
+
+> **Note:** For maintainers pushing a new published release, please see the specific Release Procedure outlined in the [README.md](README.md).