Document initial architectural decisions related to GDT

[jazairi]

Why these changes are being introduced:

We plan to develop the GIS Data Tool UI as an extension of TIMDEX UI. We need to do so without disrupting the existing TIMDEX UI applications, while also planning for a potential future state in which those applications may include geospatial data.

Relevant ticket(s):

• https://mitlibraries.atlassian.net/browse/GDT-123

How this addresses that need:

This adds an ADR to confirm our initial plan for the GDT UI.

Side effects of this change:

• We will be adding the flipflop gem in a future PR to manage a gdt feature flag.
• We will update the theme gem to add app names to headers (and potentially customize local navs).
• One decision in the ADR is contingent upon a decision we've yet to make, regarding whether we will want to display GIS results in non-GDT TIMDEX UI apps. I've phrased that as more of a potential decision that will likely require a subsequent ADR if we choose to go that route.

Developer

• All new ENV is documented in README
• All new ENV has been added to Heroku Pipeline, Staging and Prod
• ANDI or Wave has been run in accordance to
  our guide and
  all issues introduced by these changes have been resolved or opened as new
  issues (link to those issues in the Pull Request details above)
• Stakeholder approval has been confirmed (or is not needed)

Code Reviewer

• The commit message is clear and follows our guidelines
  (not just this pull request message)
• There are appropriate tests covering any new functionality
• The documentation has been updated or is unnecessary
• The changes have been verified
• New dependencies are appropriate or there were no changes

Requires database migrations?

NO

Includes new or updated dependencies?

NO (but dependencies will be added if approved)

[JPrevost]

Solid write up. I'd prefer to consequence-y statements move to Consequences, but it's minor and non-blocking.

[github-actions]

Pull Request Test Coverage Report for Build 7671984019

Warning: This coverage report may be inaccurate.

We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 99.429%

---

Totals
Change from base Build 7645028747:	0.0%
Covered Lines:	348
Relevant Lines:	350

---

💛 - Coveralls

[JPrevost]

typo cam should be can

[matt-bernhardt]

I'm comfortable with everything in this document except for one possible interpretation of the theme gem solution. I don't think this is what we're talking about, but I want to make sure (or give myself time to get comfortable with that option)

[matt-bernhardt]

I'm comfortable with things like "the theme gem supports an environment variable which implementing sites can use to put their own name in the header", but am nervous about things like "the theme gem has two nav templates, one for GIS and one for RDI. Which one gets loaded is determined by an environment variable".

[jazairi]

That's fair. I was a bit iffy on managing nav variations from the theme gem, too. I think we can scope this to app names and manage navs in their corresponding codebases.

[jazairi]

@matt-bernhardt Just pushed up a commit (well, technically two commits) in response to your feedback. Let me know if the updated language addresses your concern!

[matt-bernhardt]

This looks good to me - thanks for listening to my concerns about the theme gem. This seems like a good way forward.