Add documentation footer.

Also apply typos in pre-commit and clean up many MD links.

.pre-commit-config.yaml

@@ -44,3 +44,7 @@ repos:
     - --license-file=LICENSE
     - --add=Part of row, released under the BSD 3-Clause License.
     - --comment-prefix=//
+- repo: https://github.com/crate-ci/typos
+  rev: v1.21.0
+  hooks:
+    - id: typos

DESIGN.md

@@ -52,11 +52,6 @@ Row is yet another workflow engine that automates the process of executing **act
 Ideas:
 * List scheduler jobs and show useful information.
 * Cancel scheduler jobs specific to actions and/or directories.
-* Command to uncomplete an action for a set of directories. This would remove the product files and
-  update the cache.
-* Some method to clear any cache (maybe this instead of uncomplete?). This would allow
-  users to discover changed action names, changed products, manually uncompleted
-  actions, and deal with corrupt cache files.
 
 ## Overview
 

README.md

@@ -62,5 +62,6 @@ dir6      completed            0.3
 
 ## History
 
-**Row** is a spiritual successor to
-[signac-flow](https://docs.signac.io/projects/flow/en/latest/).
+**Row** is a spiritual successor to [signac-flow][flow].
+
+[flow]: https://docs.signac.io/projects/flow/en/latest/.

doc/src/SUMMARY.md

@@ -55,7 +55,7 @@
 - [Release notes]()
 - [Migrating from signac-flow](signac-flow.md)
 - [For developers](developers/index.md)
-  - [Contributing]()
+  - [Contributing](developers/contributing.md)
   - [Code style](developers/style.md)
   - [Testing](developers/testing.md)
   - [Documentation](developers/documentation.md)

doc/src/developers/contributing.md

@@ -0,0 +1,90 @@
+# Contributing
+
+Contributions are welcomed via [pull requests on GitHub][github]. Contact the **row**
+developers before starting work to ensure it meshes well with the planned development
+direction and standards set for the project.
+
+[github]: https://github.com/glotzerlab/gsd/row
+
+## Features
+
+### Implement functionality in a general and flexible fashion
+
+New features should be applicable to a variety of use-cases. The **row** developers can
+assist you in designing flexible interfaces.
+
+### Maintain performance of existing code paths
+
+Expensive code paths should only execute when requested.
+
+## Version control
+
+### Base your work off the correct branch
+
+- Base all new work on `trunk`.
+
+### Propose a minimal set of related changes
+
+All changes in a pull request should be closely related. Multiple change sets that are
+loosely coupled should be proposed in separate pull requests.
+
+### Agree to the Contributor Agreement
+
+All contributors must agree to the Contributor Agreement before their pull request can
+be merged.
+
+### Set your git identity
+
+Git identifies every commit you make with your name and e-mail. [Set your identity][id]
+to correctly identify your work and set it identically on all systems and accounts where
+you make commits.
+
+[id]: http://www.git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup
+
+## Source code
+
+### Use a consistent style
+
+The **Code style** section of the documentation sets the style guidelines for **row**
+code.
+
+### Document code with comments
+
+Use **Rust** documentation comments for classes, functions, etc. Also comment complex
+sections of code so that other developers can understand them.
+
+### Compile without warnings
+
+Your changes should compile without warnings.
+
+## Tests
+
+### Write unit tests
+
+Add unit tests for all new functionality.
+
+### Validity tests
+
+The developer should run research-scale simulations using the new functionality and
+ensure that it behaves as intended. When appropriate, add a new test to `validate.py`.
+
+## User documentation
+
+### Write user documentation
+
+Document all new configuration keys, command line options, command line tools,
+and any important user-facing change in the mdBook documentation.
+
+### Tutorial
+
+When applicable, update or write a new tutorial.
+
+
+### Add developer to the credits
+
+Update the contributors documentation to name each developer that has contributed to the
+code.
+
+### Propose a change log entry
+
+Propose a short concise entry describing the change in the pull request description.

doc/src/developers/style.md

@@ -1,7 +1,30 @@
 # Code style
 
-**Row** code follows the
-[Rust style guide](https://doc.rust-lang.org/style-guide/index.html).
+## Rust
 
-**Row's** [pre-commit](https://pre-commit.com/) configuration applies style fixes
-with `rustfmt` checks for common errors with `clippy`.
+**Row's** rust code follows the [Rust style guide][1]. **Row's** [pre-commit][2]
+configuration applies style fixes with `rustfmt` checks for common errors with `clippy`.
+
+[1]: https://doc.rust-lang.org/style-guide/index.html
+[2]: https://pre-commit.com/
+
+## Python
+
+**Row's** pre-commit configuration both formats and checks Python code with `ruff`.
+
+## Markdown
+
+Wrap **Markdown** files at 88 characters wide, except when not possible (e.g. when
+formatting a table). Follow layout and design patterns established in existing markdown
+files.
+
+## Spelling/grammar
+
+Contributors **must** configure their editors to perform spell checking (and preferably
+grammar checking as well). **Row's** pre-commit runs
+[typos](https://github.com/crate-ci/typos) which has a low rate of false positives.
+Developers *should* also configure a more thorough checker of their choice to ensure
+that code comments and documentation are free of errors. Suggested tools:
+* [typos](https://github.com/crate-ci/typos)
+* [ltex-ls](https://github.com/valentjn/ltex-ls)
+* [cspell](https://cspell.org/)

doc/src/developers/testing.md

@@ -14,8 +14,9 @@ with any test that is automatically run concurrently. Check for this with:
 ```bash
 rg --multiline "#\[test\]\n *fn"
 ```
-(see the [saftey discussion](https://doc.rust-lang.org/std/env/fn.set_var.html) in
-`std::env` for details.
+(see the [safety discussion][1] in `std::env` for details).
+
+[1]: https://doc.rust-lang.org/std/env/fn.set_var.html
 
 ## Cluster-specific tests
 
@@ -26,8 +27,9 @@ describes how to run the tests.
 ## Tutorial tests
 
 The tutorial scripts in `doc/src/guide/*.sh` are runnable. These are described in the
-documentation using mdBook's anchor feature to include
-[portions of files](https://rust-lang.github.io/mdBook/format/mdbook.html) in the
+documentation using mdBook's anchor feature to include [portions of files][2] in the
 documentation as needed. This way, the tutorial can be tested by executing the script.
 This type of testing validates that the script *runs*, not that it produces the correct
 output. Developers should manually check the tutorial script output as needed.
+
+[2]: https://rust-lang.github.io/mdBook/format/mdbook.html

doc/src/guide/python/actions.md

@@ -8,8 +8,10 @@ This guide will show you how to structure all of your actions in a single file:
 `actions.py`. This layout is inspired by **row's** predecessor: **signac-flow**
 and its `project.py`.
 
-> Note: If you are familiar with **signac-fow**, see
-> [migrating from signac-flow](../../signac-flow.md) for many helpful tips.
+> Note: If you are familiar with **signac-fow**, see [migrating from signac-flow][1]
+> for many helpful tips.
+
+[1]: ../../signac-flow.md
 
 To demonstrate the structure of a project, let's build a workflow that computes the
 sum of squares. The focus of this guide is on structure and best practices. You need to
@@ -35,11 +37,12 @@ Execute:
 ```
 to initialize the signac workspace and populate it with directories.
 
-> Note: If you aren't familiar with **signac**, then go read the
-> [*basic* tutorial](https://docs.signac.io/en/latest/tutorial.html#basics). Come back
-> to the **row** documentation when you get to the section on *workflows*. Or, for
-> extra credit, reimplement the **signac** tutorial workflow in **row** after you finish
-> reading this guide.
+> Note: If you aren't familiar with **signac**, then go read the [*basic* tutorial][2].
+> Come back to the **row** documentation when you get to the section on *workflows*. Or,
+> for extra credit, reimplement the **signac** tutorial workflow in **row** after you
+> finish reading this guide.
+
+[2]: https://docs.signac.io/en/latest/tutorial.html#basics
 
 ## Write actions.py
 

doc/src/guide/tutorial/index.md

@@ -2,6 +2,7 @@
 
 This section is a tutorial aimed at users who are new to not only **row**, but also HPC
 resources in general. It assumes that you have already learned the basics of the shell.
-If you are unfamiliar with the shell, check out
-[Software Carpentry: The Unix Shell](https://swcarpentry.github.io/shell-novice/)
+If you are unfamiliar with the shell, check out [Software Carpentry: The Unix Shell][1]
 or any other book/tutorial you prefer.
+
+[1]: https://swcarpentry.github.io/shell-novice/

doc/src/guide/tutorial/submit.md

@@ -30,10 +30,11 @@ node, GPU, etc...). Your final script must request the correct `--partition` to
 the command and charge accounts properly. `clusters.toml` describes rules by which
 **row** automatically selects partitions when it generates job scripts.
 
-> Note: Feel free to ask on the
-> [discussion board](https://github.com/glotzerlab/row/discussions) if you need help
+> Note: Feel free to ask on the [discussion board][discussion] if you need help
 > writing configuration files for your cluster.
 
+[discussion]: https://github.com/glotzerlab/row/discussions
+
 Check that the output of `row show cluster` and `row show launchers` is what you expect
 before continuing.
 

doc/theme/index.hbs

@@ -223,7 +223,7 @@
 						<div class="right">
 						<a href="https://umich.edu">
 						<img class="right" src="{{ path_to_root }}images/umich-block-M.svg" alt="University of Michigan logo" style="width: 84px" />
-						</a> 
+						</a>
 						</div>
 						<div style="clear:both" />
 					</main>

validate/validate.py

@@ -10,12 +10,12 @@
 * `cat <cluster-name>/output/*.out`
 
 The submitted jobs check serial, threaded, MPI, MPI+threads, GPU, and
-MPI+GPU jobs to ensure that they run sucessfully and are scheduled to the
+MPI+GPU jobs to ensure that they run successfully and are scheduled to the
 selected resources. Check `*.out` for any error messages. Then check
 `<cluster-name>/output/*.out` for `ERROR`, `WARN`, and `PASSED` lines.
 `validate.py` prints: `ERROR` when the launched job has a more restrictive
 binding than requested; `WARN` when the binding is less restrictive; and
-'PASSED' when there are at least enough  avaialble resources to execute.
+'PASSED' when there are at least enough  available resources to execute.
 
 To test a non-built-in cluster:
 * Configure your cluster in `cluster.toml`.