Merge branch 'main' into unit-testing-case-insensitive-comparisons

.github/ISSUE_TEMPLATE/internal-epic.yml

@@ -0,0 +1,66 @@
+name: 🧠️ Epic
+description: This is an epic ticket intended for use by the maintainers and product managers of `dbt-adapters`
+title: "[<project>] <title>"
+labels: ["epic"]
+body:
+  - type: markdown
+    attributes:
+      value: This is an epic ticket intended for use by the maintainers and product managers of `dbt-adapters`
+
+  - type: input
+    attributes:
+      label: Short description
+      description: |
+        What's the one-liner that would tell everyone what we're doing?
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Context
+      description: |
+        Provide the "why". What's the motivation? Why are we doing it now?
+        Will this apply to all adapters or does this support a specific subset (e.g. only SQL adapters, only Snowflake, etc.)?
+        Is this updating existing functionality or providing all new functionality?
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Objectives
+      description: |
+        What are the goals we are trying to achieve? Provide use cases if available.
+      placeholder: |
+        - [ ] Add option to ...
+        - [ ] Allow adapter maintainers to configure ...
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Consequences
+      description: |
+        Will this impact dbt Labs' ability, or a partner's ability, to make a related change? Call that out for discussion.
+        Review `Impact:<team>` labels to ensure they capture these consequences.
+      placeholder: |
+        Example:
+        - This change impacts `dbt-core` because we updated how relations are managed. (Add the `Impact:[Core]` label.)
+        - This allows internal analytics to do more robust analysis of infrastructure usage (Add the `Impact:[Analytics]` label.)
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Implementation tasks
+      description: |
+        Provide a list of GH issues that will build out this functionality. This may start empty.
+      placeholder: |
+        - [ ] https://github.com/dbt-labs/dbt-adapters/issues/123
+        - [ ] https://github.com/dbt-labs/dbt-postgres/issues/456
+      value: |
+        ```[tasklist]
+        ### Implementation tasks
+        - [ ]
+        ```
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/internal-feature-implementation.yml

@@ -0,0 +1,67 @@
+name: 🛠️ Feature Implementation
+description: This is a feature implementation ticket intended for use by the maintainers of `dbt-adapters`
+title: "[<project>] <title>"
+labels: ["user docs","enhancement","refinement"]
+body:
+  - type: markdown
+    attributes:
+      value: This is a feature implementation ticket intended for use by the maintainers of `dbt-adapters`
+
+  - type: checkboxes
+    attributes:
+      label: Housekeeping
+      description: >
+        A couple friendly reminders:
+          1. Remove the `user docs` label if the scope of this work does not require changes to https://docs.getdbt.com/docs: no end-user interface (e.g. yml spec, CLI, error messages, etc) or functional changes.
+          2. Only remove the `refinement` label if you're confident this is ready to estimate and/or you've received feedback from at least one other engineer.
+          3. Will this change need to be backported? Add the appropriate `backport 1.x.latest` label(s).
+          4. Will this impact other teams? Add the appropriate `Impact:[Team]` labels.
+      options:
+        - label: I am a maintainer of `dbt-adapters`
+          required: true
+
+  - type: textarea
+    attributes:
+      label: Short description
+      description: |
+        Describe the scope of this feature, a high-level implementation approach and any tradeoffs to consider.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Context
+      description: |
+        Provide the "why", motivation, and alternative approaches considered -- linking to previous refinement issues, spikes and documentation as appropriate.
+    validations:
+      required: false
+
+  - type: textarea
+    attributes:
+      label: Acceptance criteria
+      description: |
+        What is the definition of done for this feature? Include any relevant edge cases and/or test cases.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Suggested tests
+      description: |
+        Provide scenarios to test. Include both positive and negative tests if possible. Link to existing similar tests if appropriate.
+      placeholder: |
+         1. Test with no `materialized` field in the model config. Expect pass.
+         2. Test with a `materialized` field in the model config that is not valid. Expect ConfigError.
+    validations:
+      required: true
+
+  - type: textarea
+    attributes:
+      label: Consequences
+      description: |
+        Will this impact dbt Labs' ability, or a partner's ability, to make a related change? Call that out for discussion.
+        Review `Impact:<team>` labels to ensure they capture these consequences.
+      placeholder: |
+        Example: This change impacts `dbt-databricks` because we updated a macro in `dbt-spark`. (Add the `Impact:[Databricks]` label.)
+    validations:
+      required: true