ci: Enforce Conventional Commit PR titles (#255)

Closes #254 

Enforces conventional commit messages on this repository, to allow
greater automation of change logs, releases etc.

Author: DiamondJoseph

.github/dependabot.yml

@@ -13,6 +13,8 @@ updates:
       actions:
         patterns:
           - "*"
+    commit-message:
+      prefix: "chore"
 
   - package-ecosystem: "pip"
     directory: "/"
@@ -22,3 +24,5 @@ updates:
       dev-dependencies:
         patterns:
           - "*"
+    commit-message:
+      prefix: "chore"

.github/workflows/pr.yml

@@ -0,0 +1,15 @@
+name: PR Conventional Commit Validation
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened, edited]
+
+jobs:
+  validate-pr-title:
+    runs-on: ubuntu-latest
+    steps:
+      - name: PR Conventional Commit Validation
+        uses:  ytanikin/[email protected]
+        with:
+          task_types: '["feat","fix","docs","test","ci","refactor","perf","chore","revert"]'
+          add_label: 'false'

docs/explanations/decisions/0021-conventional-commits.md

@@ -0,0 +1,24 @@
+# 21. Semantic Versioning and Conventional Commits
+
+Date: 2025-04-07
+
+## Status
+
+Proposed
+
+## Context
+
+The template is in a period of both upheaval and uptake, where new users may adopt its use amidst major version changes.
+To give some certainty to users, we should document changes and highlight important ones.
+As dependency management becomes more automated, we should ensure that semantic versioning is used accurately, and make allowances for automation.
+
+## Decision
+
+Commits to the default branch of the copier template should be made using [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), and the Conventional Commit standard should be used to identify the next released version and create changelogs/release notes.
+
+## Consequences
+
+A [GitHub Action](https://github.com/ytanikin/PRConventionalCommits) has been configured to ensure that PRs may not be merged without being in the form of a Conventional Commit.
+PRs will be squash-and-merged, with the complete git history of the change preserved in the PR but only a single commit on the default branch.
+PR commit messages will be taken from the title and body of the PR, ensuring that the commit will be compatible with the standard.
+Tooling (dependabot etc.) will be configured to make compatible PRs.

docs/explanations/decisions/0022-spec-0.md

@@ -0,0 +1,19 @@
+# 22. Follow NEP 0029 release cycle
+
+Date: 2025-05-09
+
+## Status
+
+Proposed
+
+## Context
+
+The scientific Python ecosystem, whilst continuing to move to benefit from new Python features, must maintain support for existing projects and provide a reasonable time-frame and predictability for breaking changes. Multiple libraries therefore make use of the [NEP-0029 deprecation policy](https://numpy.org/neps/nep-0029-deprecation_policy.html). We should follow suite.
+
+## Decision
+
+This template will follow the NEP-0029 deprecation policy.
+
+## Consequences
+
+The matrix of supported Python versions will be periodically updated to those expected by the policy. When versions of Python are dropped, this will be considered a Major change for the purposes of Semantic Versioning and ADR #21.