ADR 0002: Best practices guide

.github/pull_request_template.md

@@ -17,4 +17,6 @@ resolves #
 
 - [ ] I have read [the contributing guide](https://github.com/dbt-labs/actions/blob/main/CONTRIBUTING.md) and understand what's expected of me
 - [ ] I have signed the [CLA](https://docs.getdbt.com/docs/contributor-license-agreements)
-- [ ] I have run this code in development and it appears to resolve the stated issue 
+- [ ] I have run this code in development and it appears to resolve the stated issue
+- [ ] This code adheres to the [Style Guide](/docs/arch/adr-0001-style-guide.md)
+- [ ] This code adheres to the [Best Practices Guide](/docs/arch/adr-0002-best-practices-guide.md)

README.md

@@ -11,7 +11,7 @@ Actions and workflows should be self documented.  See individual actions for mor
 - [Parse Semver Action](parse-semver)
 - [Python Package Info Action](py-package-info)
 - [Fetch Repository branches](fetch-repo-branches)
-- [Fetch COntainer Tags](fetch-container-tags)
+- [Fetch Container Tags](fetch-container-tags)
 
 ### Workflows
 
@@ -51,7 +51,12 @@ Actions and workflows should be self documented.  See individual actions for mor
 - Want to report a bug or request a feature? Let us know and open [an issue](https://github.com/dbt-labs/actions/issues/new)
 - Want to help us build oss actions? Check out the [Contributing Guide](https://github.com/dbt-labs/actions/blob/HEAD/CONTRIBUTING.md)
 
+## ADRs
+
+Would you like to know why things look the way they do?
+Do you have questions about where to put something, or how to do something?
+Check out our [ADR section](docs/arch/README.md) to see if you can find you answer there.
+
 ## Code of Conduct
 
 Everyone interacting in the project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the [dbt Code of Conduct](https://community.getdbt.com/code-of-conduct).
-

docs/arch/README.md

@@ -0,0 +1,22 @@
+# Architectural Design Records (ADRs)
+
+For any architectural/engineering decisions we make, we will create an ADR (Architectural Design Record)
+to keep track of what decision we made and why. This allows us to refer back to decisions in the future
+and see if the reasons we made a choice still holds true. This also allows for others to more easily understand the code.
+ADRs will follow this process:
+
+- They will live in the repo, under a directory `docs/arch`
+- They will be written in markdown
+- They will follow the naming convention `adr-NNNN-<decision-title>.md`
+    - `NNNN` will just be a counter starting at `0001` and will allow us easily keep the records in chronological order.
+- The common sections that each ADR should have are:
+    - Title
+    - Context
+    - Options
+    - Decision
+    - Consequences
+- Use this article as a reference: [https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)
+
+## Contents
+
+- [ADR-0001: Style guide](ard-0001-style-guide.md)

docs/arch/adr-0002-best-practices-guide.md

@@ -0,0 +1,17 @@
+# Best Practices Guide
+
+## Context
+
+This guide provides a baseline that ensures actions meet basic security, reusability, and performance criteria.
+
+## Options
+
+This style guide is a collection of individual options. Instead of providing permutations of these options,
+this ADR provides a [section](#proposal) for an initial proposal for several best practices guide topics
+and a [section](#decision) that contains the agreed upon practices.
+
+## Proposal
+
+## Decision
+
+## Consequences

docs/arch/templates/default.md

@@ -0,0 +1,33 @@
+# { Title }
+
+## Context
+
+{ A brief problem statement. Why do we need to make this decision? }
+
+## Options
+
+- { Option 1 }
+- ...
+
+### { Option 1 }
+
+#### Pro's
+
+- { Pro 1 }
+- ...
+
+#### Con's
+
+- { Con 1 }
+- ...
+
+## Decision
+
+#### Selected: { Option x }
+
+{ Justification }
+
+## Consequences
+
+- [+] { Positive consequence }
+- [-] { Negative consequence }