WIP towards admin ADR

docs/architecture-decisions/0008-choose-administrative-ui-strategy.md

@@ -0,0 +1,53 @@
+# 8. Choose administrative UI strategy
+
+Date: 2024-07-11
+
+## Status
+
+Accepted
+
+## Context
+
+The issue motivating this decision, and any context that influences or constrains the decision.
+
+## Options considered
+
+While there are a large number of [gems which attempt to provide an
+administrative interface](https://ruby.libhunt.com/gems/admin-interface), we only focused on a handful for this decision. Those
+options were:
+
+### Administrate gem
+
+https://rubygems.org/gems/administrate
+
+Administrate is the option we've used for our ETD application, which has been a
+mixed experience. While it has been nice to get content administration easily,
+the process of customizing these interfaces to implement business logic has
+meant customizing built-in templates, which then need to be maintained as the
+underlying gem continues to develop.
+
+### Avo gem
+
+https://rubygems.org/gems/avo
+
+Avo has been mentioned favorably in some recent community discussions among
+Rails developers, and it is included as one of the options in a demonstration
+app that compares several commonly-used gems.
+
+Unfortunately, Avo wants to push users to subscribe to its hosted service, and
+the data flowing through TACOS is sensitive enough that it should not be sent
+to these types of platforms without significant vetting.
+
+### No gem - bespoke administration
+
+Need to say words here about building our own admin UI.
+
+## Decision
+
+We will use Administrate for now, but keep a very close eye on how much we are
+customizing its UI. Our first instinct, rather than customize the Administrate
+gem, should be to build out our own admin UI using Rails-native affordances.
+
+## Consequences
+
+What becomes easier or more difficult to do and any risks introduced by the change that will need to be mitigated.