From 22b23c90bc46462ef8e438689fc23bea9556b388 Mon Sep 17 00:00:00 2001
From: Steve Goldman <32876747+s-goldman@users.noreply.github.com>
Date: Tue, 7 Nov 2023 15:51:37 -0500
Subject: [PATCH] Initial setup for ADRs

---
 doc/ADR_readme.md | 35 +++++++++++++++++++++++++++++++++++
 doc/ADRs.md       | 28 ++++++++++++++++++++++++++++
 2 files changed, 63 insertions(+)
 create mode 100644 doc/ADR_readme.md
 create mode 100644 doc/ADRs.md

diff --git a/doc/ADR_readme.md b/doc/ADR_readme.md
new file mode 100644
index 000000000..293e69d2b
--- /dev/null
+++ b/doc/ADR_readme.md
@@ -0,0 +1,35 @@
+# Architectural Decision Records
+
+This directory is used to host architectural decision records (ADRs). These are used to outline high-level decisions about the codebase. 
+
+## Suggestions for writing good ADRs
+
+Characteristics of a good ADR:
+
+  * Rationale: Explain the reasons for doing the particular AD. This can include the context (see below), pros and cons of various potential choices, feature comparions, cost/benefit discussions, and more.
+
+  * Specific: Each ADR should be about one AD, not multiple ADs.
+
+  * Timestamps: Identify when each item in the ADR is written. This is especially important for aspects that may change over time, such as costs, schedules, scaling, and the like.
+
+  * Immutable: Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR.
+
+Characteristics of a good "Context" section in an ADR:
+
+  * Explain your organization's situation and business priorities.
+
+  * Include rationale and considerations based on social and skills makeups of your teams.
+
+  * Include pros and cons that are relevant, and describe them in terms that align with your needs and goals.
+
+Characteristics of good "Consequences" section in an ADR:
+
+  * Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow ups, and more.
+
+  * Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates needs for more smaller decisions.
+
+  * Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, in order to learn and grow.
+
+A new ADR may take the place of a previous ADR:
+
+  * When an AD is made that replaces or invalidates a previous ADR, then a new ADR should be created
\ No newline at end of file
diff --git a/doc/ADRs.md b/doc/ADRs.md
new file mode 100644
index 000000000..68f028724
--- /dev/null
+++ b/doc/ADRs.md
@@ -0,0 +1,28 @@
+# Updating WCS in Headers
+
+## Context
+
+In updating WCS information there was a worry that information about datasets used in research would be lost.
+
+## Decision
+
+In order to ensure reproducibility and the ability to share consistent datasets "headerlets" were created. These hold the wcs inforamtion without any data.  
+
+## Consequences
+
+Headerlets can now be used to easily update and select WCS for datasets. Headerlets are files with the _hlet.fits suffix
+
+
+# Updating APERTURE keyword through poller
+
+## Context
+
+Two types of poller files exist. Full poller files, that include all of the necessary information, and simple poller files that include only the filenames; additional information is taken from the header. We needed a way to update a header keyword ("APERTURE") and it was found that the easiest way to do this was to pass the keyword through the second column of the poller file.
+
+## Decision
+
+The second column of a poller file is now reserved (for WFPC2) for passing the aperture keyword through the code to update the header keyword. For other instruments, the code treats a two-column poller file as a simple (filename-only) poller file. 
+
+## Consequences
+
+Caution must be taken is using variations of the poller file while processing WFPC2 data.
\ No newline at end of file