Add a changelog to track changes to the project as they happen

This helps document what changed between releases.

See Tech Team RFC-019:

https://github.com/dxw/tech-team-rfcs/blob/master/rfc-019-use-changelogs-to-track-changes.md

.github/pull_request_template.md

@@ -1,3 +1,5 @@
+<!-- Do you need to update the changelog? -->
+
 ## Changes in this PR
 
 ## Screenshots of UI changes

CHANGELOG.md

@@ -0,0 +1,10 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog 1.0.0].
+
+## [Unreleased]
+
+[unreleased]: TODO
+[keep a changelog 1.0.0]: https://keepachangelog.com/en/1.0.0/

README.md

@@ -24,9 +24,22 @@ TODO: Add getting started steps
 
 TODO: Add testing instructions
 
+## Making changes
+
+When making a change, update the [changelog](CHANGELOG.md) using the
+[Keep a Changelog 1.0.0](https://keepachangelog.com/en/1.0.0/) format. Pull
+requests should not be merged before any relevant updates are made.
+
+## Releasing changes
+
+When making a new release, update the [changelog](CHANGELOG.md) in the release
+pull request.
+
 ## Architecture decision records
 
-We use ADRs to document architectural decisions that we make. They can be found in doc/architecture/decisions and contributed to with the [adr-tools](https://github.com/npryce/adr-tools).
+We use ADRs to document architectural decisions that we make. They can be found
+in doc/architecture/decisions and contributed to with the
+[adr-tools](https://github.com/npryce/adr-tools).
 
 ## Managing environment variables
 
@@ -45,4 +58,5 @@ TODO: Where can people find the service and the different environments?
 
 ## Source
 
-This repository was bootstrapped from [dxw's `rails-template`](https://github.com/dxw/rails-template).
+This repository was bootstrapped from
+[dxw's `rails-template`](https://github.com/dxw/rails-template).

doc/architecture/decisions/0002-use-a-changelog-for-tracking-changes-in-a-release.md

@@ -0,0 +1,27 @@
+# 2. Use a changelog for tracking changes in a release
+
+Date: 2019-09-13
+
+## Status
+
+Accepted
+
+## Context
+
+Documenting changes for a release can be challenging. It often involves reading
+back through commit messages and PRs, looking for and classifying changes, which
+is a time consuming and error prone process.
+
+## Decision
+
+We will use a changelog (`CHANGELOG.md`) in the
+[Keep a Changelog 1.0.0](https://keepachangelog.com/en/1.0.0/) format to be
+updated when code changes happen, rather than at release time.
+
+## Consequences
+
+This will make compiling releases much simpler, as the process for determining
+changes in a release is simply a matter of looking at the changelog.
+
+This does add some overhead to making code changes, and requires that releases
+update the changelog as part of their process, but those overheads are small.