[dev] add commit style

dev/style.md

@@ -31,3 +31,40 @@
 - `Ctrl+X` to perform action
 
  where "perform action" is the literal command helpstr.
+
+# issues
+
+For bugs that have a Github issue number, include the bug number on the same line as the primary fix, with two spaces before the `#` and no spaces after (like `break  #1234`).  We've started doing this for PRs also.  It's a bit of clutter but I'd like to see the code littered with these tiny notations of the bugfixes, so we can see at a glance where the battle scars are, and to avoid regressions if the function ever gets rewritten.
+
+Any issue numbers fixed in a commit should also be appended to the git commit summary line, including the leading `#`.
+
+## commit style
+
+Most existing commits only have a compact one-line summary, and this is fine.
+Additional information in the body is welcomed, in proportion to the time and complexity of the implementation (and especially for one-line bugfixes that a deceptive amount of effort).
+
+Subject lines should generally fit under 50 characters but it's not rigidly enforced; it's better to have a clearer message at the cost of a few overflow characters.
+
+Most commit messages should look like:
+
+    [graph-] fix graph ranges for xmax, ymax < 1  #1673 #1697
+
+The trailing `-` is for cases when the entire commit is safe and/or desirable to take in a patch release--tightly constrained and the code afterwards is unilaterally improved.
+When we put together a patch release, we scan commit messages for this marker to see which ones should be included.
+Ideally only and all `-` marked commits since the last release, would be in a patch release.
+
+The tag should be the module name if the commit is focused on a particular module.
+These tags are also used for code that doesn't affect functionality directly:
+
+* `docs` for documentation-only commits
+* `tests` for test-only commits (test framework and core tests)
+* `dev` for non-code commits that are still relevant to development: release notes, packaging, git/github configuration, CI, file renames, etc.
+* `api` for deliberate or sweeping changes to the API
+* `www` for changes that only update the website
+* `nfc`: guaranteed non-functional changes not in one of the above categories
+
+For brevity, don't use generic verbs like `fix` or `use` (and especially not `utilize`), and don't repeat the module name in the summary.
+
+In general:
+   - commits should be rebased instead of merged, for a more linear and less cluttered commit log
+   - try to squash features into a single commit (but don't over-squash either)