Organize the developer docs into a "Pilcrow for Developers" book.

The audience for this is developers looking to make changes to Pilcrow, either on the server, on the included client, or via its data model. Most of the material here is drawn from existing documents, but organized somewhat more coherently.

I've left some space for client documentation, though no such documents exist yet.

2 files changed, 50 insertions, 0 deletions

diff --git a/docs/developer/tools/formatting.md b/docs/developer/tools/formatting.md
new file mode 100644
index 0000000..90044eb
--- /dev/null
+++ b/docs/developer/tools/formatting.md
@@ -0,0 +1,29 @@
+# Formatting
+
+We use automated tools, rather than human effort, to maintain a consistent code formatting convention, where possible. This is handled by two tools:
+
+- Javascript, Markdown, and JSON files are formatted using [prettier].
+- Rust is formatted using [rustfmt].
+
+[prettier]: https://prettier.io
+[rustfmt]: https://doc.rust-lang.org/cargo/commands/cargo-fmt.html
+
+## Tools
+
+- To check that code formatting rules are being followed, run
+  `tools/check-format`. This should be run any time you're making changes, and is part of the optional
+  `git-hooks/pre-commit` hook script.
+
+- To reformat the whole project, run `tools/reformat`.
+
+You can also run the individual formatting tools directly. The tool scripts listed above contain the specific commands needed.
+
+## Formatting and code review
+
+Checking in changes produced solely using
+`tools/reformat` or its constituent commands doesn't require review if it's the only thing you're doing. We assume that these tools make sound changes, and that the code style configured for the project is acceptable by default.
+
+However, formatting changes carry an outsized risk of merge conflicts, so they almost always require
+_coordination_. This risk is more severe for larger formatting changes. If you make a formatting fix, it's incumbent on you to follow up on it and to assist other developers with conflicts.
+
+In general, we try to avoid these by fixing formatting issues before they pile up, but if you plan to commit a formatting fix, please check for outstanding work that may conflict with it. You may even want to delay or rescope formatting fixes to accommodate others' in-progress changes.
diff --git a/docs/developer/tools/linting.md b/docs/developer/tools/linting.md
new file mode 100644
index 0000000..47420bb
--- /dev/null
+++ b/docs/developer/tools/linting.md
@@ -0,0 +1,21 @@
+# Linting
+
+We use automated tools, rather than human effort, to spot possible bugs or dubious structural choices, where possible. This is handled by three tools:
+
+- Javascript is linted using [eslint].
+- Rust is linted using [cargo check] and [clippy].
+
+[eslint]: https://eslint.org/
+[cargo check]: https://doc.rust-lang.org/cargo/commands/cargo-check.html
+[clippy]: https://doc.rust-lang.org/cargo/commands/cargo-clippy.html
+
+## Tools
+
+- To check for detectable lints, run
+  `tools/check-lint`. This should be run whenever making changes, and is part of the optional
+  `git-hooks/pre-commit` hook script.
+
+- To fix lints that have automatic fixes, run
+  `tools/delint`.
+
+You can also run the individual lint tools directly. The tool scripts listed above contain the specific commands needed.