diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 38281783ef9..fad32a7e224 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -1,10 +1,27 @@
# Lower entries on this list take precedence
# Anything unmatched by selectors below
-* @annafil @runleonarun
+* @runleonarun
+
+# Cloud docs and images are assigned to Leona
+/website/docs/docs/dbt-cloud/dbt-cloud-changelog.md @runleonarun
+/website/docs/docs/dbt-cloud/ @runleonarun
+/website/src/pages/dbt-cloud/ @runleonarun
+/website/static/img/docs/dbt-cloud/ @runleonarun
+
+# Blog content assigned to Developer experience team
+/website/blog/ @runleonarun
+
+
+
+# Adapter & Package Development Docs
+/website/docs/docs/supported-data-platforms.md/ @runleonarun @dataders
+/website/docs/reference/warehouse-profiles/ @runleonarun @dataders
+/website/docs/reference/resource-configs/ @runleonarun @dataders
+/website/docs/guides/building-packages @runleonarun @amychen1776 @dataders @dbeatty10
+/website/docs/contributing/building-a-new-adapter @runleonarun @dataders @dbeatty10
+/website/docs/contributing/testing-a-new-adapter @runleonarun @dataders @dbeatty10
+/website/docs/guides/creating-new-materializations @runleonarun @dataders @dbeatty10
+/website/docs/docs/dbt-cloud/cloud-configuring-dbt-cloud/ @runleonarun @dataders @dbeatty10
+
-# Cloud docs and images are assigned to Drew
-/website/docs/docs/dbt-cloud/dbt-cloud-changelog.md @drewbanin @alexbethea22
-/website/docs/docs/dbt-cloud/ @drewbanin
-/website/src/pages/dbt-cloud/ @drewbanin
-/website/static/img/docs/dbt-cloud/ @drewbanin
diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml
new file mode 100644
index 00000000000..9349000f66b
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/config.yml
@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+ - name: Want to see new content? Open a discussion!
+ url: https://github.com/dbt-labs/docs.getdbt.com/discussions/new
+ about: You can open a discussion to propose new content for the dbt product documentation.
+ - name: Have questions about dbt? Join the Community!
+ url: https://www.getdbt.com/community/join-the-community
+ about: You can join the dbt Labs Community to ask and answer questions.
diff --git a/.github/ISSUE_TEMPLATE/contribute-to-developer-blog.yml b/.github/ISSUE_TEMPLATE/contribute-to-developer-blog.yml
new file mode 100644
index 00000000000..f138b9e4e06
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/contribute-to-developer-blog.yml
@@ -0,0 +1,54 @@
+name: Contribute to the dbt Developer Blog
+description: >
+ For proposing a new post on the dbt Developer Blog.
+labels: ["content","developer blog"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ We're excited to hear about your idea for the dbt Developer Blog. This template will help lay out the proposed post and then we will work with on next steps!
+
+ - type: input
+ id: contact
+ attributes:
+ label: Contact Details
+ description: How can we get in touch with you?
+ placeholder: your preferred email and/or dbt Slack handle
+ validations:
+ required: true
+
+ - type: checkboxes
+ id: read-contribution
+ attributes:
+ label: I have read the dbt Developer Blog contribution guidelines.
+ description: You can find the contribution guide [here](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/developer-blog.md)
+ options:
+ - label: I have read the dbt Developer Blog contribution guidelines.
+ validations:
+ required: true
+
+ - type: checkboxes
+ id: author_type
+ attributes:
+ label: Which of these best describes you?
+ options:
+ - label: I am a dbt Community member or partner contributing to the Developer Blog
+ - label: I work for dbt Labs and am creating this issue for a community or marketing approved piece.
+ validations:
+
+
+ - type: textarea
+ attributes:
+ label: >
+ What is the topic of your post?
+ description: |
+ Please provide a short (~ 1 paragraph) summary as well as who this post is targeted towards (ie people interested in learning more about dbt snapshots or advanced Jinja users)
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Link to an initial outline.
+ description: Please link to a short outline in Notion, or Google Docs
+ validations:
+ required: true
diff --git a/.github/ISSUE_TEMPLATE/improve-docs.yml b/.github/ISSUE_TEMPLATE/improve-docs.yml
new file mode 100644
index 00000000000..57dc64cc312
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/improve-docs.yml
@@ -0,0 +1,42 @@
+name: Improve content
+description: Make a suggestion to improve the content in an existing page.
+labels: ["content","improvement"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ * You can ask questions or submit ideas for the dbt docs in [Discussions](https://github.com/dbt-labs/docs.getdbt.com/discussions)
+ * Before you file an issue read the [Contributing guide](https://github.com/dbt-labs/docs.getdbt.com#contributing).
+ * Check to make sure someone hasn't already opened a similar [issue](https://github.com/dbt-labs/docs.getdbt.com/issues).
+
+ - type: checkboxes
+ id: contributions
+ attributes:
+ label: Contributions
+ description: Please read the contribution docs before opening an issue or pull request.
+ options:
+ - label: I have read the contribution docs, and understand what's expected of me.
+
+ - type: textarea
+ attributes:
+ label: Link to the page on docs.getdbt.com requiring updates
+ description: Please link to the page or pages you'd like to see improved.
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: What part(s) of the page would you like to see updated?
+ description: |
+ - Give as much detail as you can to help us understand the change you want to see.
+ - Why should the docs be changed? What use cases does it support?
+ - What is the expected outcome?
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Additional information
+ description: Add any other context or screenshots about the feature request here.
+ validations:
+ required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/improve-the-site.yml b/.github/ISSUE_TEMPLATE/improve-the-site.yml
new file mode 100644
index 00000000000..e0556d7374f
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/improve-the-site.yml
@@ -0,0 +1,42 @@
+name: Improve the docs.getdbt.com site
+description: Make a suggestion or report a problem about the technical implementation of docs.getdbt.com.
+labels: ["engineering"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ * You can ask questions or submit ideas for the dbt docs in [Discussions](https://github.com/dbt-labs/docs.getdbt.com/discussions)
+ * Before you file an issue read the [Contributing guide](https://github.com/dbt-labs/docs.getdbt.com#contributing).
+ * Check to make sure someone hasn't already opened a similar [issue](https://github.com/dbt-labs/docs.getdbt.com/issues).
+
+ - type: checkboxes
+ id: contributions
+ attributes:
+ label: Contributions
+ description: Please read the contribution docs before opening an issue or pull request.
+ options:
+ - label: I have read the contribution docs, and understand what's expected of me.
+
+ - type: textarea
+ attributes:
+ label: What page(s) or areas on docs.getdbt.com are affected?
+ description: Include links to pages where you're seeing a problem or making a suggestion. Also include screenshots, what browser you're using, etc.
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: What changes are you suggesting?
+ description: |
+ - Give as much detail as you can to help us understand the change you want to see.
+ - Why should the docs be changed?
+ - What is the expected outcome?
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Additional information
+ description: Any additional information, configuration, or data that might be necessary to reproduce the issue.
+ validations:
+ required: false
\ No newline at end of file
diff --git a/.github/ISSUE_TEMPLATE/new-dbt-feature.yml b/.github/ISSUE_TEMPLATE/new-dbt-feature.yml
new file mode 100644
index 00000000000..fa46a189fc4
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/new-dbt-feature.yml
@@ -0,0 +1,33 @@
+name: Start docs project for a new feature
+description: For dbt PMs to add docs for their new or updated dbt product features.
+labels: ["content","upcoming release"]
+body:
+ - type: markdown
+ attributes:
+ value: |
+ * Before you file an issue read the [Contributing guide](https://github.com/dbt-labs/docs.getdbt.com#contributing).
+ * Check to make sure someone hasn't already opened a similar [issue](https://github.com/dbt-labs/docs.getdbt.com/issues).
+
+ - type: checkboxes
+ id: contributions
+ attributes:
+ label: Contributions
+ description: This applies to new, unreleased content.
+ options:
+ - label: I am a PM or subject matter expert at dbt who is responsible for this feature.
+
+ - type: textarea
+ attributes:
+ label: Where does this content belong?
+ description: |
+ - Give as much detail as you can to help us understand where you expect the content to live.
+ validations:
+ required: true
+
+ - type: textarea
+ attributes:
+ label: Link to source material
+ description: |
+ Use the [source material template](https://docs.google.com/document/d/1lLWGMXJFjkY4p7r8ZKhBX73dOLmIjgXZBYq39LqmAJs/edit) to provide source material for this feature.
+ validations:
+ required: true
\ No newline at end of file
diff --git a/.github/issue_template.md b/.github/issue_template.md
deleted file mode 100644
index 4f32d903281..00000000000
--- a/.github/issue_template.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## Steps to reproduce:
-
-
-## Expected results:
-
-
-## Actual results
-
-
-## Extra details
-
diff --git a/.github/labeler.yml b/.github/labeler.yml
new file mode 100644
index 00000000000..595db45cd66
--- /dev/null
+++ b/.github/labeler.yml
@@ -0,0 +1,8 @@
+developer blog:
+- website/blog/**/*
+
+guides:
+- website/docs/docs/guides/**/*
+
+content:
+- website/docs/**/*
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 19112fa74a5..5ae7e9f4d6d 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -2,6 +2,8 @@
## To-do before merge
@@ -12,14 +14,10 @@ Include any notes about things that need to happen before this PR is merged, e.g
- [ ] Ensure PR #56 is merged
-->
-## Pre-release docs
-Is this change related to an unreleased version of dbt?
-- [ ] Yes: please
- - update the base branch to `next`
- - add Changelog components: `[New/Changed] in v0.x.0`
- - add links to the "New and changed documentation" section of the latest [Migration Guide](../website/docs/docs/guides/migration-guide)
-- [ ] No: please ensure the base branch is `current`
-- [ ] Unsure: we'll let you know!
+## Prerelease docs
+If this change is related to functionality in a prerelease version of dbt (delete if not applicable):
+- [ ] I've added versioning components, as described in ["Versioning Docs"](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/versioningdocs.md)
+- [ ] I've added a note to the prerelease version's [Migration Guide](https://github.com/dbt-labs/docs.getdbt.com/tree/current/website/docs/guides/migration/versions)
## Checklist
If you added new pages (delete if not applicable):
@@ -29,3 +27,4 @@ If you added new pages (delete if not applicable):
If you removed existing pages (delete if not applicable):
- [ ] The page has been removed from `website/sidebars.js`
- [ ] An entry has been added to `_redirects`
+- [ ] [Run link testing](https://github.com/dbt-labs/docs.getdbt.com#running-the-cypress-tests-locally) to update the links that point to the deleted page
diff --git a/.github/workflows/mark_pr_as_done.yml b/.github/workflows/add_pr_to_project.yml
similarity index 96%
rename from .github/workflows/mark_pr_as_done.yml
rename to .github/workflows/add_pr_to_project.yml
index 5fdad116526..a08840f98d0 100644
--- a/.github/workflows/mark_pr_as_done.yml
+++ b/.github/workflows/add_pr_to_project.yml
@@ -1,7 +1,7 @@
-name: Mark PR as done
+name: Add PR to project
on:
- pull_request:
- types: [closed]
+ pull_request_target:
+ types: [opened,reopened]
jobs:
track_pr:
@@ -57,7 +57,7 @@ jobs:
with:
name: "data.json"
json: ${{ steps.get_project_info.outputs.data }}
-
+
- name: Extract date field ID
uses: sergeysova/jq-action@v2
id: date_field_id
@@ -77,8 +77,8 @@ jobs:
id: status_field_value
with:
cmd:
- jq '.organization.projectNext.fields.nodes[] | select(.name== "Status") |.settings | fromjson.options[] | select(.name=="Done") |.id' data.json
-
+ jq '.organization.projectNext.fields.nodes[] | select(.name== "Status") |.settings | fromjson.options[] | select(.name=="Triage") |.id' data.json
+
- name: Set fields
id: set_fields
uses: octokit/graphql-action@v2.x
@@ -88,7 +88,7 @@ jobs:
$project: ID!
$item: ID!
$status_field: ID!
- $status_value: ID!
+ $status_value: String!
$date_field: ID!
$date_value: String!
) {
diff --git a/.github/workflows/create_next_pr.yml b/.github/workflows/create_next_pr.yml
new file mode 100644
index 00000000000..becef0db654
--- /dev/null
+++ b/.github/workflows/create_next_pr.yml
@@ -0,0 +1,18 @@
+on:
+ push:
+ branches:
+ - "current"
+
+jobs:
+ pull-request:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v2
+ - name: pull-request
+ uses: repo-sync/pull-request@v2
+ with:
+ source_branch: "current"
+ destination_branch: "next"
+ pr_title: "Merge current branch into next"
+ pr_body: "*An automated PR to keep the next branch up to date with current*"
+ github_token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.github/workflows/cypress_tests.yml b/.github/workflows/cypress_tests.yml
new file mode 100644
index 00000000000..1973e0ef43e
--- /dev/null
+++ b/.github/workflows/cypress_tests.yml
@@ -0,0 +1,47 @@
+name: cypress tests
+
+on:
+ pull_request:
+ branches:
+ - current
+
+jobs:
+ start-workflow:
+ name: start workflow
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v2
+
+ - name: install node
+ uses: actions/setup-node@v2
+ with:
+ node-version: '16.13.1'
+
+ - name: npm install
+ run: cd website && npm ci
+
+ - name: setup env
+ run: |
+ PR_NUMBER=$(jq --raw-output .pull_request.number ${{ github.event_path }})
+ echo "PR_NUMBER=${PR_NUMBER}" >> ${GITHUB_ENV}
+
+ - name: run cypress e2e
+ uses: cypress-io/github-action@v4
+ with:
+ command: npx cypress run
+ browser: chrome
+ working-directory: website
+ spec: cypress/e2e/*.cy.js
+ wait-on: https://deploy-preview-${{ env.PR_NUMBER }}--docs-getdbt-com.netlify.app
+ wait-on-timeout: 600
+ env:
+ CYPRESS_BASE_URL: https://deploy-preview-${{ env.PR_NUMBER }}--docs-getdbt-com.netlify.app
+
+ - name: Screenshot artifact upload
+ uses: actions/upload-artifact@v2
+ if: failure()
+ with:
+ name: cypress-screenshots
+ path: cypress/screenshots
\ No newline at end of file
diff --git a/.github/workflows/labeler.yml b/.github/workflows/labeler.yml
new file mode 100644
index 00000000000..057208eda32
--- /dev/null
+++ b/.github/workflows/labeler.yml
@@ -0,0 +1,14 @@
+name: "Pull Request Labeler"
+on:
+- pull_request_target
+
+jobs:
+ triage:
+ permissions:
+ contents: read
+ pull-requests: write
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/labeler@v4
+ with:
+ repo-token: "${{ secrets.GITHUB_TOKEN }}"
diff --git a/.github/workflows/labelsizer.yml b/.github/workflows/labelsizer.yml
new file mode 100644
index 00000000000..d1ad5776597
--- /dev/null
+++ b/.github/workflows/labelsizer.yml
@@ -0,0 +1,24 @@
+name: labeler
+
+on: [pull_request_target]
+
+jobs:
+ labeler:
+ runs-on: ubuntu-latest
+ name: Label the PR size
+ steps:
+ - uses: codelytv/pr-size-labeler@v1.8.1
+ with:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ xs_label: 'size: x-small'
+ xs_max_size: '10'
+ s_label: 'size: small'
+ s_max_size: '50'
+ m_label: 'size: medium'
+ m_max_size: '250'
+ l_label: 'size: large'
+ l_max_size: '100000'
+ xl_label: 'size: x-large'
+ fail_if_xl: 'false'
+ files_to_ignore: ''
+
diff --git a/.github/workflows/mark_issue_as_done.yml b/.github/workflows/mark_issue_as_done.yml
deleted file mode 100644
index 3408a4fa72d..00000000000
--- a/.github/workflows/mark_issue_as_done.yml
+++ /dev/null
@@ -1,123 +0,0 @@
-name: Mark issue as done
-on:
- issues:
- types: [closed]
-
-jobs:
- track_issue:
- runs-on: ubuntu-latest
-
- steps:
- - uses: octokit/graphql-action@v2.x
- name: Get project data
- id: get_project_info
- with:
- query: |
- query($org: String!, $number: Int!) {
- organization(login: $org){
- projectNext(number: $number) {
- id
- fields(first:20) {
- nodes {
- id
- name
- settings
- }
- }
- }
- }
- }
- org: 'dbt-labs'
- number: 14
- headers: 'GraphQL-Features: projects_next_graphql'
- env:
- GITHUB_TOKEN: ${{ secrets.PROJECT_NEXT }}
-
- - uses: octokit/graphql-action@v2.x
- name: Add Issue to Project
- id: add_issue
- with:
- query: |
- mutation($project:ID!, $issue:ID!) {
- addProjectNextItem(input: {projectId: $project, contentId: $issue}) {
- projectNextItem {
- id
- }
- }
- }
- project: ${{ fromJSON(steps.get_project_info.outputs.data).organization.projectNext.id }}
- issue: ${{ github.event.issue.node_id}}
- headers: 'GraphQL-Features: projects_next_graphql'
- env:
- GITHUB_TOKEN: ${{ secrets.PROJECT_NEXT }}
-
- - name: create-json
- id: create-json
- uses: jsdaniell/create-json@1.1.2
- with:
- name: "data.json"
- json: ${{ steps.get_project_info.outputs.data }}
-
- - name: Extract date field ID
- uses: sergeysova/jq-action@v2
- id: date_field_id
- with:
- cmd:
- jq '.organization.projectNext.fields.nodes[] | select(.name == "Date") | .id' data.json
-
- - name: Extract status field ID
- uses: sergeysova/jq-action@v2
- id: status_field_id
- with:
- cmd:
- jq '.organization.projectNext.fields.nodes[] | select(.name == "Status") | .id' data.json
-
- - name: Extract status field value
- uses: sergeysova/jq-action@v2
- id: status_field_value
- with:
- cmd:
- jq '.organization.projectNext.fields.nodes[] | select(.name== "Status") |.settings | fromjson.options[] | select(.name=="Done") |.id' data.json
-
- - name: Set fields
- id: set_fields
- uses: octokit/graphql-action@v2.x
- with:
- query: |
- mutation (
- $project: ID!
- $item: ID!
- $status_field: ID!
- $status_value: ID!
- $date_field: ID!
- $date_value: String!
- ) {
- set_status: updateProjectNextItemField(input: {
- projectId: $project
- itemId: $item
- fieldId: $status_field
- value: $status_value
- }) {
- projectNextItem {
- id
- }
- }
- set_date_posted: updateProjectNextItemField(input: {
- projectId: $project
- itemId: $item
- fieldId: $date_field
- value: $date_value
- }) {
- projectNextItem {
- id
- }
- }
- }
- GITHUB_TOKEN: ${{ secrets.PROJECT_NEXT }}
- project: ${{ fromJSON(steps.get_project_info.outputs.data).organization.projectNext.id }}
- headers: 'GraphQL-Features: projects_next_graphql'
- item: ${{ fromJSON(steps.add_issue.outputs.data).addProjectNextItem.projectNextItem.id }}
- status_field: ${{ steps.status_field_id.outputs.value }}
- status_value: ${{ steps.status_field_value.outputs.value }}
- date_field: ${{ steps.date_field_id.outputs.value }}
- date_value: ${{ github.event.issue.created_at }}
diff --git a/.gitignore b/.gitignore
index 5395ea795d6..49c7bdb5b3e 100755
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,6 @@ website/build/
website/yarn.lock
website/node_modules
website/i18n/*
+
+# Local Netlify folder
+.netlify
diff --git a/README.md b/README.md
index 69968a648bb..6203bbaba9a 100644
--- a/README.md
+++ b/README.md
@@ -1,37 +1,72 @@
-A [docusaurus](https://v2.docusaurus.io/) site that powers [docs.getdbt.com](https://docs.getdbt.com/).
+_We use [docusaurus](https://v2.docusaurus.io/) to power [docs.getdbt.com](https://docs.getdbt.com/)._
-## Branching
+#### Table of Contents
-There are two long-lived branches in this repo:
-- `current`: This branch is what is reflected at at [docs.getdbt.com](https://docs.getdbt.com/)
-- `next`: This branch represent the next release of dbt, and is deployed [next.docs.getdbt.com](https://next.docs.getdbt.com/)
+* [Code of Conduct](#Code-of-conduct)
+* [Contributing](#contributing)
+* [Writing content](#writing-content)
+* [Running the docs site locally](#running-the-docs-site-locally)
+
+# Code of conduct
+
+Please review the dbt docs contributors [code of conduct](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/contributor-code-of-conduct.md).
+Creating an inclusive and equitable environment for our documents is more important than any other aspect. Syntax errors can be corrected, but trust, once lost, is difficult to gain back.
+
+# Contributing
-## Contributing
We welcome contributions from community members to this repo:
-- **Fixes**: If you notice an error (there are likely many), use the `Edit this page` button at the bottom of each page to suggest a change. We recommend you contribute small changes directly from the GitHub interface.
-- **New documentation**: If you contributed code in [dbt-core](https://github.com/fishtown-analytics/dbt), we encourage you to also write the docs here!
-- **Refactors**: At this time, we are unable to support community members who wish to re-write sections of docs.getdbt.com. We hope to change this in the future!
+- **Fixes**: When you notice an error, you can use the `Edit this page` button at the bottom of each page to suggest a change.
+- **New documentation**: If you contributed code in [dbt-core](https://github.com/dbt-labs/dbt-core), we encourage you to also write the docs here! Please reach out in the dbt community if you need help finding a place for these docs.
+- **Major rewrites**: You can [file an issue](https://github.com/dbt-labs/docs.getdbt.com/issues/new?assignees=&labels=content%2Cimprovement&template=improve-docs.yml) or [start a discussion](https://github.com/dbt-labs/docs.getdbt.com/discussions) to propose ideas for a content area that requires attention.
+
+You can use components documented in the [docusaurus library](https://v2.docusaurus.io/docs/markdown-features/).
+
+# Writing content
+
+When writing content, you should refer to the [style guide](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-style-guide.md) and [content types](/contributing/content-types.md) to help you understand our writing standards and how we break down information in the product documentation.
+
+## Versioning and single-sourcing content
+
+We now enable you to reuse content between different docs pages, version pages, and establish product variables in the dbt Labs product documentation. To learn more about how to single source content between versions, product variables, and other content, see [Single-sourcing content](/contributing/single-sourcing-content.md).
+
+## Adding tabbed components to a page
+
+You can add code snippets and other content in a tabbed view. To learn more about adding tabbed components, see [Adding page components](/contributing/adding-page-components.md).
+
+# Running the Docs site locally
+
+You can click a link available in a netlify bot PR comment to see and review your changes rendered on a staging server. You are also able to see and review your proposed modifications locally on your computer. Our setup instructions use [homebrew](https://brew.sh/):
-### Running the Docs site locally
+## Prerequisites
-We recommend locally rendering changes made to the docs site so you can review your proposed modifications. Our setup instructions use [homebrew](https://brew.sh/):
+* (Mac Terminal) Install [Xcode Command Line Tools](https://developer.apple.com/download/more/)
+ - Open a terminal window, run `xcode-select --install`, and follow the on-screen prompts in the pop-up window.
+* (Mac and Linux) Install [homebrew](https://brew.sh/)
+ - Copy and paste `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` in to a terminal window and follow the prompts. Once the installation has completed, follow the **Next Steps** instructions listed in terminal.
+* (Windows) Install [Node.js](https://nodejs.org/en/download/)
-0. If applicable, install [Xcode Command Line Tools](https://developer.apple.com/download/more/); you'll likely need an AppleID for this. You will also need [homebrew](https://brew.sh/).
-2. Install `node`: `brew install node`
-3. Clone this repo: `git clone git@github.com:fishtown-analytics/docs.getdbt.com.git`
-4. `cd` into the repo: `cd docs.getdbt.com`
-5. `cd` into the `website` subdirectory: `cd website`
-6. Install the required node packages: `npm install`
-7. Build the website: `npm start`
-8. Before pushing your changes to a branch, check that all links work by using the `make build` script.
+1. (Mac and Linux only) Install `node`: `brew install node`
+2. Clone this repo: `git clone https://github.com/dbt-labs/docs.getdbt.com.git`
+3. `cd` into the repo: `cd docs.getdbt.com`
+4. `cd` into the `website` subdirectory: `cd website`
+5. Install the required node packages: `npm install` (optional — install any updates)
+6. Build the website: `npm start`
+7. Before pushing your changes to a branch, check that all links work by using the `make build` script.
-Advisory:
-- Currently an `npm install` produces a number of dependency warnings, in particular several claiming that `docusaurus/core` is missing. Rest assured, this message is a red herring. As of writing this, no 2.0.0 package exists, so you won't have much luck trying to install it. Feel free to ignore those warnings.
+Advisory:
- If you run into an `fatal error: 'vips/vips8' file not found` error when you run `npm install`, you may need to run `brew install vips`. Warning: this one will take a while -- go ahead and grab some coffee!
-You can also check out [this Loom video](https://www.loom.com/share/7037780b86eb4f16953664b8f15f1e21) that I recorded for co-workers — it covers setting up docs.getdbt.com locally, and adding a page with links and images. Heads up — this was very much something I did on the fly, so is not super polished!
+## Running the Cypress tests locally
-## Custom components
-Check out [docs.getdbt.com/styles](https://docs.getdbt.com/styles) for examples of different components that can be used in these docs.
+Method 1: Utilizing the Cypress GUI
+1. `cd` into the repo: `cd docs.getdbt.com`
+2. `cd` into the `website` subdirectory: `cd website`
+3. Install the required node packages: `npm install`
+4. Run `npx cypress open` to open the Cypress GUI, and choose `E2E Testing` as the Testing Type, before finally selecting your browser and clicking `Start E2E testing in {broswer}`
+5. Click on a test and watch it run!
-You can also use components directly from the [docusaurus library](https://v2.docusaurus.io/docs/markdown-features/).
+Method 2: Running the Cypress E2E tests headlessly
+1. `cd` into the repo: `cd docs.getdbt.com`
+2. `cd` into the `website` subdirectory: `cd website`
+3. Install the required node packages: `npm install`
+4. Run `npx cypress run`
diff --git a/RELEASE.md b/RELEASE.md
deleted file mode 100644
index 2793687c403..00000000000
--- a/RELEASE.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# Releasing docs
-
-There are two long-lived branches of this repo:
- - `current` is the version of dbt released at [docs.getdbt.com](docs.getdbt.com)
- - `next` reflects the next version of dbt to be releases. It is accessible at [docs-next.getdbt.com](docs-next.getdbt.com), and a warning banner is displayed on the site.
-
-- Any fixes or revisions to existing docs should be merged into `current`
-- Any pre-release docs should be merged into `next`
-- The `next` branch should be rebased from `current` somewhat regularly
-
-When new versions of dbt are released:
-1. Rebase `next` on top of `current`. The workflow might look something like this:
-```
-(current) $ git fetch
-(current) $ git pull
-(current) $ git checkout next
-(next) $ git pull
-(next) $ git rebase current -i
-```
-2. Make a PR from `next` onto `current`
-3. Merge the PR once the deploy preview builds successfully
diff --git a/_redirects b/_redirects
index 8e4c451cf54..f820d2420ad 100644
--- a/_redirects
+++ b/_redirects
@@ -1,3 +1,7 @@
+/useful_components https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/adding-page-components.md 302
+/guides/legacy/managing-environments /docs/building-a-dbt-project/managing-environments 302
+/docs/running-a-dbt-project/dbt-api /docs/introduction 301
+/img/docs/dbt-cloud/dbt-cloud-enterprise/icon.png https://www.getdbt.com/ui/img/dbt-icon.png 301!
/dbt-cli/installation-guides/centos /dbt-cli/install/overview 302
/dbt-cli/installation-guides/centos /dbt-cli/install/overview 302
/dbt-cli/installation-guides/install-from-source /dbt-cli/install/from-source 302
@@ -5,14 +9,15 @@
/dbt-cli/installation-guides/ubuntu-debian /dbt-cli/install/overview 302
/dbt-cli/installation-guides/windows /dbt-cli/install/overview 302
/dbt-cli/installation /dbt-cli/install/overview 302
+/dbt-jinja-functions /reference/dbt-jinja-functions 302
/docs /docs/introduction 302
/docs/adapter /docs/writing-code-in-dbt/jinja-context/adapter 302
/docs/analyses /docs/building-a-dbt-project/analyses 302
/docs/api-variable /docs/writing-code-in-dbt/api-variable 302
/docs/archival /docs/building-a-dbt-project/archival 302
/docs/artifacts /docs/dbt-cloud/using-dbt-cloud/artifacts 302
-/docs/best-practices /docs/guides/best-practices 302
/docs/bigquery-configs /reference/resource-configs/bigquery-configs 302
+/reference/resource-properties/docs /reference/resource-configs/docs 302
/docs/building-a-dbt-project/building-models/bigquery-configs /reference/resource-configs/bigquery-configs 302
/docs/building-a-dbt-project/building-models/configuring-models /reference/model-configs
/docs/building-a-dbt-project/building-models/enable-and-disable-models /reference/resource-configs/enabled 302
@@ -36,7 +41,7 @@
/docs/building-a-dbt-project/using-operations /docs/building-a-dbt-project/hooks-operations 302
/docs/building-a-new-adapter /docs/contributing/building-a-new-adapter 302
/docs/building-models /docs/building-a-dbt-project/building-models 302
-/docs/building-packages /docs/guides/building-packages 302
+/docs/building-packages /guides/legacy/building-packages 302
/docs/centos /dbt-cli/installation 302
/docs/clean /reference/commands/clean 302
/docs/cloud-choosing-a-dbt-version /docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-choosing-a-dbt-version 302
@@ -67,8 +72,8 @@
/docs/connecting-your-database /docs/dbt-cloud/cloud-configuring-dbt-cloud/connecting-your-database 302
/docs/contributor-license-agreements /docs/contributing/contributor-license-agreements 302
/docs/creating-a-project /docs/building-a-dbt-project/dbt-projects/creating-a-project 302
-/docs/creating-new-materializations /docs/guides/creating-new-materializations 302
-/docs/custom-schema-tests /docs/guides/writing-custom-schema-tests 302
+/docs/creating-new-materializations /guides/legacy/creating-new-materializations 302
+/docs/custom-schema-tests /guides/legacy/writing-custom-generic-tests 302
/docs/dbt-api /docs/running-a-dbt-project/dbt-api 302
/docs/dbt-cloud-enterprise /docs/dbt-cloud/dbt-cloud-enterprise 302
/docs/dbt-cloud/cloud-configuring-repositories /docs/dbt-cloud/cloud-configuring-dbt-cloud/cloud-configuring-repositories 302
@@ -94,9 +99,21 @@
/docs/getting-started-with-jinja /docs/building-a-dbt-project/jinja-macros 302
/docs/global-cli-flags /reference/global-cli-flags 302
/docs/graph /docs/writing-code-in-dbt/jinja-context/graph 302
-/docs/guides/migration-guide/upgrading-to-014 /docs/guides/migration-guide/upgrading-to-0-14-0 302
-/docs/guides/migration-guide/upgrading-from-0-10-to-0-11 /docs/guides/migration-guide/upgrading-to-0-11-0 302
-/docs/guides/writing-custom-schema-tests /docs/guides/writing-custom-generic-tests
+/docs/guides/building-packages /guides/legacy/building-packages 302
+/docs/guides/creating-new-materializations /guides/legacy/creating-new-materializations 302
+/docs/guides/debugging-errors /guides/legacy/debugging-errors 302
+/docs/guides/debugging-schema-names /guides/legacy/debugging-schema-names 302
+/docs/guides/getting-help /guides/legacy/getting-help 302
+/docs/guides/managing-environments /guides/legacy/managing-environments 302
+/docs/guides/navigating-the-docs /guides/legacy/navigating-the-docs 302
+/docs/guides/understanding-state /guides/legacy/understanding-state 302
+/docs/guides/videos /guides/legacy/videos 302
+/docs/guides/writing-custom-generic-tests /guides/legacy/writing-custom-generic-tests 302
+/docs/guides/writing-custom-schema-tests /guides/legacy/writing-custom-generic-tests 302
+/docs/guides/best-practices#choose-your-materializations-wisely /guides/legacy/best-practices#choose-your-materializations-wisely 302
+/docs/guides/best-practices#version-control-your-dbt-project /guides/legacy/best-practices#version-control-your-dbt-project 302
+/docs/best-practices /guides/legacy/best-practices 302
+/docs/guides/best-practices /guides/best-practices 302
/docs/hooks /docs/building-a-dbt-project/hooks-operations 302
/docs/init /reference/commands/init 302
/docs/install-from-source /dbt-cli/installation 302
@@ -108,13 +125,13 @@
/docs/log /docs/writing-code-in-dbt/jinja-context/log 302
/docs/macos /dbt-cli/installation 302
/docs/macros /docs/building-a-dbt-project/macros 302
-/docs/managing-environments /docs/guides/managing-environments 302
+/docs/managing-environments /guides/legacy/managing-environments 302
/docs/materializations /docs/building-a-dbt-project/building-models/materializations 302
/docs/model-selection-syntax /reference/node-selection/syntax 302
/docs/modules /docs/writing-code-in-dbt/jinja-context/modules 302
/docs/on-run-end-context /docs/writing-code-in-dbt/jinja-context/on-run-end-context 302
+/docs/overview /docs/introduction 302
/docs/package-management /docs/building-a-dbt-project/package-management 302
-/docs/profile /docs/available-adapters 302
/docs/profile-bigquery /reference/warehouse-profiles/bigquery-profile 302
/docs/profile-mssql /reference/warehouse-profiles/mssql-profile 302
/docs/profile-postgres /reference/warehouse-profiles/postgres-profile 302
@@ -176,7 +193,6 @@
/docs/snowflake-configs /reference/resource-configs/snowflake-configs 302
/docs/source /reference/commands/source 302
/docs/statement-blocks /docs/writing-code-in-dbt/jinja-context/statement-blocks 302
-/docs/supported-databases /docs/available-adapters 302
/docs/supported-databases/profile-bigquery /reference/bigquery-profile 302
/docs/supported-databases/profile-mssql /reference/mssql-profile 302
/docs/supported-databases/profile-postgres /reference/postgres-profile 302
@@ -193,15 +209,12 @@
/docs/this /docs/writing-code-in-dbt/jinja-context/this 302
/docs/tojson /docs/writing-code-in-dbt/jinja-context/tojson 302
/docs/ubuntu-debian /dbt-cli/installation 302
-/docs/upgrading-to-0-14-1 /docs/guides/migration-guide/upgrading-to-0-14-1 302
-/docs/upgrading-to-0-16-0 /docs/guides/migration-guide/upgrading-to-0-16-0 302
-/docs/upgrading-to-014 /docs/guides/migration-guide/upgrading-to-014 302
/docs/use-an-existing-project /docs/building-a-dbt-project/dbt-projects/use-an-existing-project 302
/docs/using-custom-aliases /docs/building-a-dbt-project/building-models/using-custom-aliases 302
/docs/using-custom-database /docs/building-a-dbt-project/building-models/using-custom-databases 302
/docs/using-custom-schemas /docs/building-a-dbt-project/building-models/using-custom-schemas 302
/docs/using-dbt-cloud /docs/dbt-cloud/using-dbt-cloud 302
-/docs/using-jinja /tutorial/using-jinja 302
+/docs/using-jinja /guides/getting-started/learning-more/using-jinja 302
/docs/using-operations /docs/building-a-dbt-project/hooks-operations 302
/docs/using-sources /docs/building-a-dbt-project/using-sources 302
/docs/using-sql-headers /reference/resource-configs/sql_header 302
@@ -210,12 +223,12 @@
/docs/using-variables /docs/building-a-dbt-project/building-models/using-variables 302
/docs/var /docs/writing-code-in-dbt/jinja-context/var 302
/docs/version /reference/global-cli-flags#version 302
-/docs/videos /docs/guides/videos 302
+/docs/videos /guides/legacy/videos 302
/docs/viewpoint /docs/about/viewpoint 302
/docs/windows /dbt-cli/installation 302
/docs/writing-code-in-dbt/class-reference /reference/dbt-classes 302
-/docs/writing-code-in-dbt/extending-dbts-programming-environment/creating-new-materializations /docs/guides/creating-new-materializations 302
-/docs/writing-code-in-dbt/extending-dbts-programming-environment/custom-schema-tests /docs/guides/writing-custom-schema-tests 302
+/docs/writing-code-in-dbt/extending-dbts-programming-environment/creating-new-materializations /guides/legacy/creating-new-materializations 302
+/docs/writing-code-in-dbt/extending-dbts-programming-environment/custom-schema-tests /guides/legacy/writing-custom-schema-tests 302
/docs/writing-code-in-dbt/getting-started-with-jinja /docs/building-a-dbt-project/jinja-macros 302
/docs/writing-code-in-dbt/jinja-context/adapter /reference/dbt-jinja-functions/adapter 302
/docs/writing-code-in-dbt/jinja-context/as_text /reference/dbt-jinja-functions/as_text 302
@@ -252,8 +265,10 @@
/docs/writing-code-in-dbt/jinja-context/toyaml /reference/dbt-jinja-functions/toyaml 302
/docs/writing-code-in-dbt/jinja-context/var /reference/dbt-jinja-functions/var 302
/docs/writing-code-in-dbt/macros /docs/building-a-dbt-project/jinja-macros 302
-/docs/writing-code-in-dbt/using-jinja /tutorial/using-jinja 302
-/faqs/getting-help/ /docs/guides/getting-help/ 302
+/docs/writing-code-in-dbt/using-jinja /guides/getting-started/learning-more/using-jinja 302
+/faqs/getting-help/ /guides/legacy/getting-help 302
+/migration-guide/upgrading-to-0-17-0 /guides/migration/versions 302
+/migration-guide/upgrading-to-0-18-0 /guides/migration/versions 302
/reference/accounts /dbt-cloud/api 302
/reference/api /dbt-cloud/api 302
/reference/connections /dbt-cloud/api 302
@@ -261,6 +276,7 @@
/reference/declaring-properties /reference/configs-and-properties 302
/reference/dbt-artifacts /reference/artifacts/dbt-artifacts 302
/reference/environments /dbt-cloud/api 302
+/reference/events /reference/events-logging 302
/reference/jobs /dbt-cloud/api 302
/reference/model-selection-syntax /reference/node-selection/syntax 302
/reference/project-configs/on-run-end /reference/project-configs/on-run-start-on-run-end 302
@@ -278,3 +294,86 @@ https://tutorial.getdbt.com/* https://docs.getdbt.com/:splat 301!
/reference/project-configs/source-paths /reference/project-configs/model-paths 302
/reference/project-configs/data-paths /reference/project-configs/seed-paths 302
/reference/project-configs/modules-paths /reference/project-configs/packages-install-path 302
+/docs/dbt-cloud/using-dbt-cloud/cloud-slack-notifications /docs/dbt-cloud/using-dbt-cloud/cloud-notifications 302
+/reference/warehouse-profiles/presto-profile /reference/profiles.yml 302
+/setting-up /guides/getting-started/getting-set-up/setting-up-bigquery 302
+/tutorial/setting-up /guides/getting-started 302
+/tutorial/test-and-document-your-project /guides/getting-started/building-your-first-project/test-and-document-your-project 302
+/tutorial/build-your-first-models /guides/getting-started/building-your-first-project/build-your-first-models 302
+/tutorial/deploy-your-project /guides/getting-started/building-your-first-project/schedule-a-job 302
+/tutorial/using-jinja /guides/getting-started/learning-more/using-jinja 302
+/tutorial/refactoring-legacy-sql /guides/getting-started/learning-more/refactoring-legacy-sql 302
+/tutorial/2b-create-a-project-dbt-cli.md /guides/getting-started/learning-more/getting-started-dbt-core 302
+/tutorial/create-a-project-dbt-cli /guides/getting-started/learning-more/getting-started-dbt-core 302
+/tutorial/2a-create-a-project-dbt-cloud.md /guides/getting-started 302
+/tutorial/create-a-project-dbt-cloud /guides/getting-started 302
+/tutorial/getting-started /guides/getting-started 302
+/docs/dbt-cloud/cloud-changelog /docs/dbt-cloud/release-notes 302
+/faqs/all /docs/faqs 301!
+/faqs/* /docs/faqs/:splat 301
+/tutorial/learning-more/* /guides/getting-started/learning-more/:splat 301
+/tutorial/getting-set-up/* /guides/getting-started/getting-set-up/:splat 301
+/tutorial/building-your-first-project/* /guides/getting-started/building-your-first-project/:splat 301
+/tutorial/refactoring-legacy-sql /guides/getting-started/learning-more/refactoring-legacy-sql 302
+/blog/change-data-capture-metrics /blog/change-data-capture 301
+/blog/model-timing-tab /blog/how-we-shaved-90-minutes-off-model 301
+# supported data platforms page
+/docs/profile /docs/supported-data-platforms 302
+/docs/available-adapters /docs/supported-data-platforms 302
+/docs/supported-databases /docs/supported-data-platforms 302
+# migration and legacy guides
+/docs/guides/migration-guide/upgrading-to-0-14-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-15-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-16-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-17-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-18-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-19-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-from-0-10-to-0-11 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-014 /guides/migration/versions 302
+/docs/upgrading-to-014 /guides/migration/versions 302
+/docs/upgrading-to-0-14-1 /guides/migration/versions 302
+/docs/upgrading-to-0-16-0 /guides/migration/versions 302
+/docs/guides/migration-guide/upgrading-to-0-20-0 /guides/migration/versions/upgrading-to-v0.20 302
+/docs/guides/migration-guide/upgrading-to-0-21-0 /guides/migration/versions/upgrading-to-v0.21 302
+/docs/guides/migration-guide/upgrading-to-1-0-0 /guides/migration/versions/upgrading-to-v1.0 302
+/docs/guides/migration-guide/upgrading-to-v1.0 /guides/migration/versions/upgrading-to-v1.0 302
+/docs/guides/getting-help /guides/legacy/getting-help 302
+/docs/guides/migration-guide/* /guides/migration/versions/:splat 301!
+/docs/guides/* /guides/legacy/:splat 301!
+docs/contributing/building-a-new-adapter /docs/contributing/adapter-development/3-building-a-new-adapter 302
+docs/contributing/testing-a-new-adapter /docs/contributing/adapter-development/4-testing-a-new-adapter 302
+docs/contributing/documenting-a-new-adapter /docs/contributing/adapter-development/5-documenting-a-new-adapter 302
+/docs/building-a-new-adapter /docs/contributing/adapter-development/3-building-a-new-adapter 301!
+/reference/warehouse-profiles/impala-profile /reference/warehouse-setups/impala-setup 302
+/reference/warehouse-profiles/exasol-profile /reference/warehouse-setups/exasol-setup 302
+/reference/warehouse-profiles/layer-profile /reference/warehouse-setups/layer-setup 302
+/reference/warehouse-profiles/postgres-profile /reference/warehouse-setups/postgres-setup 302
+/reference/warehouse-profiles/greenplum-profile /reference/warehouse-setups/greenplum-setup 302
+/reference/warehouse-profiles/alloydb-profile /reference/warehouse-setups/alloydb-setup 302
+/reference/warehouse-profiles/azuresynapse-profile /reference/warehouse-setups/azuresynapse-setup 302
+/reference/warehouse-profiles/snowflake-profile /reference/warehouse-setups/snowflake-setup 302
+/reference/warehouse-profiles/rockset-profile /reference/warehouse-setups/rockset-setup 302
+/reference/warehouse-profiles/trino-profile /reference/warehouse-setups/trino-setup 302
+/reference/warehouse-profiles/glue-profile /reference/warehouse-setups/glue-setup 302
+/reference/warehouse-profiles/duckdb-profile /reference/warehouse-setups/duckdb-setup 302
+/reference/warehouse-profiles/vertica-profile /reference/warehouse-setups/vertica-setup 302
+/reference/warehouse-profiles/clickhouse-profile /reference/warehouse-setups/clickhouse-setup 302
+/reference/warehouse-profiles/athena-profile /reference/warehouse-setups/athena-setup 302
+/reference/warehouse-profiles/iomete-profile /reference/warehouse-setups/iomete-setup 302
+/reference/warehouse-profiles/mssql-profile /reference/warehouse-setups/mssql-setup 302
+/reference/warehouse-profiles/tidb-profile /reference/warehouse-setups/tidb-setup 302
+/reference/warehouse-profiles/materialize-profile /reference/warehouse-setups/materialize-setup 302
+/reference/warehouse-profiles/redshift-profile /reference/warehouse-setups/redshift-setup 302
+/reference/warehouse-profiles/databricks-profile /reference/warehouse-setups/databricks-setup 302
+/reference/warehouse-profiles/bigquery-profile /reference/warehouse-setups/bigquery-setup 302
+/reference/warehouse-profiles/dremio-profile /reference/warehouse-setups/dremio-setup 302
+/reference/warehouse-profiles/oracle-profile /reference/warehouse-setups/oracle-setup 302
+/reference/warehouse-profiles/teradata-profile /reference/warehouse-setups/teradata-setup 302
+/reference/warehouse-profiles/singlestore-profile /reference/warehouse-setups/singlestore-setup 302
+/reference/warehouse-profiles/sqlite-profile /reference/warehouse-setups/sqlite-setup 302
+/reference/warehouse-profiles/spark-profile /reference/warehouse-setups/spark-setup 302
+/reference/warehouse-profiles/mindsdb-profile /reference/warehouse-setups/mindsdb-setup 302
+/reference/warehouse-profiles/ibmdb2-profile /reference/warehouse-setups/ibmdb2-setup 302
+/reference/warehouse-profiles/firebolt-profile /reference/warehouse-setups/firebolt-setup 302
+/reference/warehouse-profiles/mysql-profile /reference/warehouse-setups/mysql-setup 302
+/reference/warehouse-profiles/hive-profile /reference/warehouse-setups/hive-setup 302
diff --git a/contributing/adding-page-components.md b/contributing/adding-page-components.md
new file mode 100644
index 00000000000..1a43cbe8a81
--- /dev/null
+++ b/contributing/adding-page-components.md
@@ -0,0 +1,90 @@
+## Using warehouse components
+
+You can use the following components to provide code snippets for each supported warehouse. You can see a real-life example in the docs page, "[Initialize your database](https://docs.getdbt.com/guides/getting-started/getting-set-up/setting-up-databricks#initialize-your-dbt-project)."
+
+Identify code by labeling with the warehouse names:
+
+```js
+
+
+
+
+
+```
+
+## Using tabs for multiple resources
+
+You can use the following components to provide code snippets in a tabbed view. You can see a real-life example in the docs page, "[Building models](https://docs.getdbt.com/docs/building-a-dbt-project/building-models#building-dependencies-between-models)."
+
+Identify code and code files by labeling with the component they are describing:
+
+```code
+
+
+
+
+
+
+ ```sql
+
+ {{ config(
+
+ ) }}
+
+ select ...
+
+
+ ```
+
+
+
+
+
+ ```yml
+ models:
+ [](resource-path):
+
+
+ ```
+
+
+
+
+
+
+
+
+
+ ```yml
+ sources:
+ [](resource-path):
+
+
+ ```
+
+
+
+
+
+
+```
\ No newline at end of file
diff --git a/contributing/content-style-guide.md b/contributing/content-style-guide.md
new file mode 100644
index 00000000000..d59eb98e118
--- /dev/null
+++ b/contributing/content-style-guide.md
@@ -0,0 +1,417 @@
+# Content style guide
+
+Welcome to the content style guide for docs.getdbt.com! We aim to provide docs that help readers accomplish their goals. To this end, we should focus on clarity and meaning in our sentences, and follow up with consistency and grammatical correctness when we can.
+
+This guide includes standards we want to emphasize, likely because we've made deliberate decisions about them. You can refer to [_The Microsoft Writing Style Guide_](https://docs.microsoft.com/en-us/style-guide/welcome/) and the [_Chicago Manual of Style_](https://www.chicagomanualofstyle.org/home.html) for those nagging questions like, "[Should I use an Em dash, En dash or hyphen?](https://docs.microsoft.com/en-us/style-guide/punctuation/dashes-hyphens/)"
+
+### Table of Contents
+* [Callouts](#callouts)
+* [Text formatting](#Text-formatting)
+* [UI elements](#UI-elements)
+* [Titles](#Titles)
+* [Placeholder text](#Placeholder-text)
+* [Oxford comma](#Oxford-comma)
+* [Lists](#Lists)
+* [Tables](#Tables)
+* [Word choice & terminology](#Word-choice-&-terminology)
+* [Links](#Links)
+* [Images](#Images)
+* [Talk to us](#Talk-to-us)
+
+## Callouts
+
+Callouts highlight important or high-value information that readers need to know. We want callouts to stand out, so we should keep their content to a minimum, avoiding general information, permissions, or prerequisites. Too much information can make it difficult to absorb. Imagine driving down one block with five stop signs!?!
+
+Use callouts sparingly for high-value information — avoid including general information, permissions, or prerequisites in callouts.
+
+## Text formatting
+You consider many elements when designing technical docs, and the way you format text can help you achieve a well-articulated design. With consistency of use, well-formatted text creates a single voice when there are multiple authors/contributors, increases the readability of the content, and further establishes an organization's branding.
+
+### Italics
+Use italics to decorate text for emphasis.
+
+:white_check_mark: Do _not_ leave any personal belongings on the bus.
+
+### Bold
+Don't use bold for emphasis. It's reserved for titles, headers, and UI elements.
+
+:white_check_mark: Click **Pay** to complete your purchase.
+
+:x: **DO NOT** lock the door.
+
+### Code
+Use code font to decorate text for:
+
+|Text |Example |
+|-----|--------|
+| source code (like SQL, YAML, and JavaScript) | `select * from customers` |
+| [placeholder text](#placeholder-text) | `CUSTOMER_ID` |
+| directory paths | `/opt/homebrew/bin/` |
+| directory names | The file is in the `etc` directory. |
+| filenames | Update your `dbt_project.yml` to configure this |
+| git branch names | When done, merge your PR to `main` |
+| commands | To check the status of a running cluster, use the `ghe-cluster-status` command |
+| arguments, parameters, keys | Update the `name` in your YAML file |
+
+Use [code blocks](#code-blocks) for longer or more complex commands. Do _not_ use multiple font decorations on text as it can cause it to be visually busy and so harder to read; for example, avoid inline links in command names.
+
+### Code blocks
+
+Keep lines in code samples to about 60 characters, to avoid requiring readers to scroll horizontally in the code block. Locate explanatory text before the code block, rather than using comments inside the code block.
+
+Within code blocks:
+
+* Avoid using markup before the command output.
+* Only use $ before the command itself if you’re showing the command’s output in the same block.
+
+#### Code block examples
+
+Provide context for code examples referring to a larger file by showing the relevant section of the file, so that users understand how to edit their own code.
+
+:white_check_mark: Use:
+
+```yaml
+name: my_dbt_project
+version: 1.0.0
+
+config-version: 2
+
+vars:
+ # The `start_date` variable will be accessible in all resources
+ start_date: '2021-06-01'
+```
+
+:x: Avoid:
+```yaml
+config-version: 2
+
+vars:
+ # The `start_date` variable will be accessible in all resources
+ start_date: '2021-06-01'
+```
+
+## UI elements
+
+Similar to [text formatting](#text-formatting), consistent use of how we refer to the user interface (UI) elements can help increase the scannability and readability of the docs for our readers.
+
+The following sections describe the guidelines for documenting UI elements.
+
+### Buttons
+
+Bold the button name and use the term click.
+
+:white_check_mark: Click **Submit** to create a new branch.
+
+:x: Click the **Submit** button to create a new branch.
+
+### Checkboxes
+
+Bold the name of the checkbox. You can use the terms select, choose, or clear.
+
+:white_check_mark: Select the **New** option.
+
+:white_check_mark: Clear the **New** option.
+
+:x: Check the **New** option.
+
+:x: Uncheck the **New** option.
+
+### Dropdown menus
+
+Bold the name of the dropdown menu and also the names of its list items. You can use the terms select or choose.
+
+:white_check_mark: In the **Create** menu, select the **From a template** option.
+
+:white_check_mark: Choose **Create** > **From a template** to create a new page.
+
+### Radio buttons
+
+Bold the name of the radio button. You can use the terms select, choose, or clear.
+
+:white_check_mark: Choose the **Small size** option.
+
+:white_check_mark: Clear the **Small size** option.
+
+:x: Click the **Small size** radio button.
+
+### Text fields
+
+Bold the name of the text field and use the term enter for user input.
+
+:white_check_mark: In the **Address** field, enter your company's address.
+
+### Location of UI elements
+
+When referring to UI elements, describe its position in the software application to help users locate it easily. You can use upper, lower, center, left, and right to do this.
+
+:white_check_mark: Use the search box in the upper left corner to explore more topics.
+
+:white_check_mark: You can view alerts in the lower right corner of the tool.
+
+:white_check_mark: You can manage your projects in the file explorer on the left side of the page.
+
+:white_check_mark: Access all guides from the Guides menu at the top of the page.
+
+
+### UI text
+
+When referring to different sections of the IDE, use the name of the section and bold it. Avoid using the terms panel and pane.
+
+:white_check_mark: In the **Settings** section, choose the default address for your account.
+
+:x: You can review all your past orders from the **History** pane.
+
+## Titles
+
+People make use of titles in many places like table headers, section headings (such as an H2, H3, or H4), page titles, sidebars, and so much more.
+
+When generating titles or updating them, use sentence case. It sets a more conversational tone to the docs—making the content more approachable and creating a friendly feel.
+
+We've defined five content types you can use when contributing to the docs (as in, writing or authoring). Learn more about title guidelines for [each content type](https://github.com/dbt-labs/docs.getdbt.com/blob/current/contributing/content-types.md).
+
+## Placeholder text
+
+Placeholder text is something that the user should replace with their own text. For example, their website domain name.
+
+Use all capital letters([screaming snake case](https://fission.codes/blog/screaming-snake-case/)) to indicate text that changes in the user interface or that the user needs to supply in a command or code snippet. Avoid surrounding it in brackets or braces, which someone might copy and use, producing an error.
+
+Identify what the user should replace the placeholder text with in the paragraph preceding the code snippet or command.
+
+:white_check_mark: The following is an example of configuring a connection to a Redshift database. In your YAML file, you must replace `CLUSTER_ID` with the ID assigned to you during setup:
+
+```yaml
+my-redshift-db:
+ target: dev
+ outputs:
+ dev:
+ type: redshift
+ method: iam
+ cluster_id: CLUSTER_ID
+
+```
+
+## Oxford comma
+
+Use an Oxford comma (serial comma) when you have a series with three or more terms.
+
+The sentence below could mean my parents are Maria and Lin or it could mean they are people I love in addition to my parents.
+
+:x: I love my parents, Maria and Lin.
+
+Removing this ambiguity by using Oxford commas makes content easier to translate.
+
+:white_check_mark: I love my parents, Maria, and Lin.
+
+## Lists
+
+People often scan technical documentation until they find the information they’re looking for, instead of reading it line by line. Lists are a great way to present content in a scannable format.
+
+There are bulleted (unordered) lists and numbered (ordered) lists. If the list items can be in any order, use a bulleted list. For a prioritized list or a set of steps, use a numbered list.
+
+Guidelines for making lists are:
+- There are at least two items.
+- All list items follow a consistent, grammatical structure (like each item starts with a verb, each item begins with a capitalized word, each item is a sentence fragment).
+- Lists items don't end in commas, semicolons, or conjunctions (like "and", "or"). However, you can use periods if they’re complete sentences.
+- Introduce the list with a heading or, if it's within text, as a complete sentence or as a sentence fragment followed by a colon.
+
+If the list starts getting lengthy and dense, consider presenting the same content in a different format such as a table, as separate subsections, or a new guide.
+
+### Examples of lists
+
+A bulleted list with introductory text:
+
+> A dbt project is a directory of `.sql` and .yml` files. The directory must contain at a minimum:
+>
+> - Models: A model is a single `.sql` file. Each model contains a single `select` statement that either transforms raw data into a dataset that is ready for analytics, or, more often, is an intermediate step in such a transformation.
+> - A project file: A `dbt_project.yml` file, which configures and defines your dbt project.
+
+A bulleted list with sentence fragments:
+
+> Supported languages:
+> - Python
+> - Java
+> - C++
+
+A numbered list following an H2 heading:
+
+> ## Check out a new git branch
+>
+> 1. Make sure you're in the Develop interface. If you're not, click the hamburger menu, then click `Develop`. The main branch is now set as read-only mode so you'll need to create a new branch.
+>
+> 2. Click **+ create new branch** and enter `add-customers-model` for the branch name.
+
+## Tables
+Tables provide a great way to present complex information and can help the content be more scannable for users, too.
+
+There are many ways to construct a table, like row spanning and cell splitting. Make sure the content is clear, concise, and presents well on the web page (like avoid awkward word wrapping).
+
+Guidelines for making tables are:
+- Introduce the table with a heading or, if it's within text, as a complete sentence or as a sentence fragment followed by a colon.
+- Use a header row
+- Use sentence case for all content, including the header row
+- Content can be complete sentences, sentence fragments, or single words (like `Currency`)
+
+If the table starts getting cumbersome and hard to read (that is, bad UX), consider presenting the same content in a different format such as a definition list. Consider your design of the content, too (like using flag icons instead of country names as it takes up less space on a page). Or, you could split the content so they’re in separate subsections, separate tabs, or separate pages (like by data warehouse or programming language).
+
+### Examples of tables
+
+A table with introductory text:
+
+> You can use **custom schemas** in dbt to build models in a schema other than your target schema. By default, dbt generates a model's schema name by concatenating the custom schema to the target schema, as follows: `_;`.
+>
+> | Target schema | Custom schema | Resulting schema |
+> | ------------- | ------------- | ---------------- |
+> | <target_schema> | None | <target_schema> |
+> | analytics | None | analytics |
+> | dbt_alice | None | dbt_alice |
+> | <target_schema> | <custom_schema> | <target_schema>\_<custom_schema> |
+> | analytics | marketing | analytics_marketing |
+> | dbt_alice | marketing | dbt_alice_marketing |
+
+A table following an H3 heading:
+
+> ### Arguments
+> | Name | Description | Values |
+> | -----| ----------- | ------ |
+> | `-help` | Displays information on how to use the command. | Doesn't take any values. |
+> | `-readable` | Print output in human readable format. |
`true`
`false`
|
+> | `-file` | Print output to file instead of stdout. | Name of the file. |
+
+## Word choice & terminology
+
+### Abbreviations
+
+According to The American Heritage Dictionary, an abbreviation is "[a] shortened form of a word or phrase used chiefly in writing to represent the complete form" but, unlike the acronym, it's letters aren't pronounced together as one full word.
+
+### Acronyms
+
+Spell out acronyms the first time they’re used in an article, except in titles or headers. If an uncommon abbreviation appears in the title, define it in the first couple of lines of the body text.
+
+_Do_ provide the full word or phrase being abbreviated before the abbreviation itself and encapsulate within parentheses.
+ * *Example: Integrated Development Environment (IDE)*
+
+**DO NOT** use an acronym if its only used once. Please use the full word or phrase for its one-time use.
+
+### Latin abbreviations
+
+Avoid using Latin abbreviations. These terms are harder to localize/translate.
+
+Some common Latin abbreviations and other words to use instead:
+
+| Avoid | Use | Example |
+|--------------------|------------|---------|
+| i.e. | that is | Use incremental models when your dbt runs are becoming too slow (that is, don't start with incremental models) |
+| e.g. |
for example
like
|
Join both the dedicated #adapter-ecosystem channel in dbt Slack and the channel for your adapter's data store (for example, #db-sqlserver and #db-athena)
Using Jinja in SQL provides a way to use control structures (like `if` statements and `for` loops) in your queries
|
+| etc. |
and more
and so forth
|
A continuous integration environment running pull requests in GitHub, GitLab, and more
While reasonable defaults are provided for many such operations (like `create_schema`, `drop_schema`, `create_table`, and so forth), you might need to override one or more macros when building a new adapter
|
+
+
+### Prepositions
+
+Avoid ending a sentence with a preposition unless the rewritten sentence would sound awkward or too formal.
+
+### Product names
+
+Product names, trademarks, services, and tools should be written as proper nouns, unless otherwise specified by the company or trademark owner.
+
+### Terms to use or avoid
+
+Use industry-specific terms and research new/improved terminology. Also refer to the Inclusive Language section of this style guide for inclusive and accessible language and style.
+
+**DO NOT** use jargon or language familiar to a small subset of readers or assume that your readers understand ALL technical terms.
+
+Use | Avoid
+-- | --
+type (in the user interface) | enter (in the user interface)
+enter (in the command line) | type (in the command line)
+email | e-mail
+on dbt | on a remote server
+person, human | client, customer
+press (a key) | hit, tap
+recommended limit | soft limit
+sign in | log in, login
+sign up | signup
+terminal | shell
+username | login
+
+
+## Links
+
+Links embedded in documentation are about trust. Users trust that we will lead them to sites or pages related to their reading content. In order to maintain that trust, it is important that links are transparent, up-to-date, and lead to legitimate resources.
+
+### Link format
+
+Hyperlinks should be text only, please avoid image-based links. The text should clearly state the destination.
+
+ :x: For more information, visit https://docs.getdbt.com
+
+ :x: For more information, [_Click Here_](https://docs.getdbt.com/)
+
+ ✅ For more information, visit the [_dbt Labs doc site_](https://docs.getdbt.com/).
+
+### Link destinations
+
+The link destination should be directly related to the topic of the document. There are many valid destinations, including educational material, third-party product instructions, explanations of a limitation, FAQs, and other pages on the dbt Labs site.
+
+Some destination types should be avoided entirely:
+* Sales or promotional material.
+* General landing pages - link to specific information.
+* Content that is hidden behind paywalls or that requires credentials to access.
+* Untrusted or otherwise questionable sites that might contain dubious information, malware, or suspicious behavior.
+* Personal sites such as file sharing folders or blogs.
+* Instant downloads (the user clicks the link and the download begins immediately). If you need to host a file, please contact dbt Labs for a solution.
+
+
+## Images
+
+### Alt text
+
+In order to include people using screen readers, remember to add alternate text for images. Every image should include an alt attribute that provides a complete description of the image for the user. For more information, see “Images, image maps, and multimedia” in Microsoft’s Style Guide.
+
+### Icons
+When describing icons that appear on-screen, use the [_Google Material Icons_](https://fonts.google.com/icons?selected=Material+Icons) reference page as a guide.
+
+:x:Click on the hamburger menu icon
+
+:white_check_mark:Click on the menu icon
+
+### Image names
+
+Two words that are either adjectives or nouns describing the name of a file separated by an underscore `_` (known as `snake_case`). The two words can also be separated by a hyphen (`kebab-case`).
+* Types and Examples
+ * `snake_case`
+ * *gitlab_setup.jpg*
+ * `kebab-case`
+ * *sso-setup.jpg*
+
+### Screenshots
+
+There are scenarios where a visual aid may be beneficial, especially when creating a document highlighting navigation. Screenshots provide a lightweight alternative to videos and are much easier to produce, edit, and insert into documents. Due to their limitations, they should be used sparingly.
+
+It is important to remember that all of dbt Labs documentation is currently in English only. Users might require screen readers or translation programs to read content and these will not pick up the text within screenshots.
+
+#### How to take a screenshot
+
+Both macOS and Windows include tools that allow you to capture and manipulate screenshots. You can use alternatives based on your preferences, but avoid programs that place a watermark over the content.
+
+* [How to take screenshots in MacOS](https://support.apple.com/en-us/HT201361#:~:text=How%20to%20take%20a%20screenshot,to%20save%20to%20your%20desktop.)
+* [How to take screenshots with the Snipping Tool in Windows](https://support.microsoft.com/en-us/windows/use-snipping-tool-to-capture-screenshots-00246869-1843-655f-f220-97299b865f6b#:~:text=Press%20Ctrl%20%2B%20PrtScn%20keys.,that%20you%20want%20to%20capture.)
+
+#### Screenshot guidelines
+
+Once you have determined that a screenshot will add value to the document where words alone can't, refer to these guidelines for capturing the information:
+
+* Use screenshots to highlight navigation, on-screen elements, and other noteworthy product visuals.
+* Avoid using screenshots to demonstrate inputs and outputs. All code snippets and sample results should be in the documents as text fields.
+* Use concise filenames that are relevant to the content contained within. Enumerate them if they are part of a sequence.
+
+ :x: screenshot-august0822.jpg
+
+ :white_check_mark: viewing-admins-01.jpg
+
+* Redact all sensitive information from the screenshot — names, email addresses, phone numbers, or anything that could be considered personally identifiable information (PII) should be obfuscated.
+* Avoid URL and bookmark bars in the screenshot and limit the scope to the product and page being documented.
+
+## Talk to us
+Your feedback helps drive us forward. At dbt Labs, we want you to get involved if you see areas in the documentation that need improvement. That might include becoming a docs contributor or simply filing a GitHub issue so we know where to look. We have an incredible community of contributors, and our documents reflect that.
+
+dbt Labs is growing, and a team of technical writers is now handling reviews and requests. This style guide will continue to grow as we identify more ways to make the documents easily accessible to all users.
diff --git a/contributing/content-types.md b/contributing/content-types.md
new file mode 100644
index 00000000000..f1094e29b2c
--- /dev/null
+++ b/contributing/content-types.md
@@ -0,0 +1,167 @@
+# Content types
+
+These content types can all form articles. Some content types can form sections within a larger article.
+
+# TOC
+
+* [Conceptual](#conceptual)
+* [Referential](#referential)
+* [Procedural](#procedural)
+* [Guide](#guide)
+* [Quickstart](#quickstart-guide)
+
+
+## Conceptual
+
+Conceptual content provides a clear, high-level overview of a feature or topic. Conceptual content should be clear enough for a novice audience but also include relevant information for advanced users. Conceptual content should contextualize a task within the reader’s workflow, such as including use cases or examples.
+
+Conceptual content can be found in a standalone article or in a conceptual section within another article.
+Most major features or parts of the product will get their own conceptual article.
+For smaller or more specific conceptual sections that accompany one or more procedures, we instead place conceptual content within guides.
+
+### Contents of a conceptual article or header
+
+Describe in plain language what the feature, product, or topic is
+Describe its purpose and why it’s useful to the reader (value proposition)
+If relevant, describe how the feature or topic works without getting into too much irrelevant technical detail
+Highlight any details the reader needs to know to use the feature
+Include next steps for getting started with the feature (whether through further reading links or content within the article itself)
+
+### Titles for conceptual content
+
+Conceptual articles or headers of conceptual sections should always start with “About [topic]”
+Always use a noun in the place of the topic, not a gerund
+
+### Examples of conceptual content
+
+* Conceptual articles
+TBD
+* Conceptual sections within other articles
+TBD
+
+## Referential
+
+Referential content provides detailed information that customers need to access or select from to use a specific part of the product.
+
+Referential content can be found in a standalone article or in a referential section within another article.
+
+* Some major subjects may require their own referential article, especially if there is a large amount of referential content, such as for search syntax or YAML syntax.
+* For smaller or more specific referential sections that accompany conceptual or procedural information, like a list of a feature’s supported languages or hardware requirements, we’ll add referential sections in context within procedural or conceptual content.
+
+### Contents of a referential article or header
+
+* Use an introductory sentence or an entire conceptual section to introduce relevant information about the referential content. This should be general enough to apply to all of the following content.
+
+* Present the actual referential content clearly and consistently.
+* For subjects with a single element to explain, use a list.
+ * Example: TBD
+* For subjects with multiple elements, use a table
+ * Example: TBD
+* For longer referential content, such as YAML syntax for workflows, use headers consistently:
+ * H3 headers for each distinct section
+ * H4 headers for subsections, such as examples
+ * Example: TBD
+
+Formatting API reference documentation (TBD)
+
+### Title guidelines for referential content
+Referential articles or headers of referential sections should clearly describe the contents of the section, and generally begin with nouns
+Titles should include enough information to be accessible to novice users and fully describe the contents of each section
+Titles should avoid stacked nouns - use prepositions to break up long strings of nouns
+
+### Examples of referential content
+
+* Referential articles
+TBD
+* Referential sections within other articles
+TBD
+* Placeholder: Referential REST content
+* Placeholder: Referential GraphQL content
+
+## Procedural
+
+Procedural articles tell users how to complete a single task from start to finish, most often using numbered steps. Procedural content should contextualize a task within the reader’s workflow, such as including use cases or examples.
+
+Procedural content can be found in a standalone article or in a procedural section within another article. If an article contains a procedure, it’s always considered either a procedural article (single procedure) or a guide (multiple procedures). For details on creating articles with multiple procedural sections, see the section on guides below.
+
+When creating multiple related procedures, or when describing how to both do and undo a setting or action, you should consider gathering all of the procedures into a guide rather than creating multiple individual articles.
+* If disabling or undoing a procedure requires the same steps and has no detailed implications, then you do not need to write a separate procedure for undoing the setting.
+* If disabling or undoing a procedure requires different steps or has important or detailed implications, create a guide with an agnostic title (unless there are significant reasons to create separate individual procedural articles for both doing and undoing a task).
+
+Procedural content should include troubleshooting tips as frequently as possible. See the troubleshooting section below for more information.
+### Title guidelines for procedural articles
+* Procedural articles or procedural sections within articles should be task-based and begin with a gerund
+* Use active and specific verbs (occasionally this takes some brainstorming or hitting a thesaurus)
+* Titles should specifically describe the task contained within the article or header
+* Article title length: maximum 80 characters, 60 if possible
+
+#### Examples of procedural articles:
+* Adding information to your account
+* Setting up metrics in dbt Projects
+* Setting up continuous integration
+
+## Guide
+
+Guides (formerly called long-form procedural articles) are highly-approachable articles that group information in context to help readers complete a complex task or set of related tasks. Guides eliminate duplication and ensure the customer finds contextual content in the right place. Guides may be a set of tasks within the reader’s larger workflow, such as including use cases.
+
+Guides combine the content types within a single article to illustrate an entire workflow within a single page, rather than splitting the workflow out into separate pieces. Guides containing multiple procedures help us scale as more options are added to the product. Users may need to complete different procedures within the guide at different times, or refer back to the guide for conceptual content or to complete a followup task.
+Example usage: If there is a large number of the same type of setting, use a guide that gathers all of the tasks in context.
+
+Guides must include a table of contents.
+You can replicate the guide’s title in a header if needed.
+
+### Contents of guides
+
+* Guides contain multiple headers.
+* Guides contain at least one procedural section, plus at least one additional conceptual, referential, or procedural section.
+* Content within guides follows the content order used throughout the site.
+* Guides should include troubleshooting sections as frequently as possible. See the troubleshooting section below for more information.
+
+### Title guidelines for guides
+
+* Titles of guides should be task-based and begin with a gerund
+* Titles should be general enough to describe the range of information and tasks contained within the article
+* Titles should describe the setting being toggled and should be agnostic about what setting the reader chooses, e.g., “Setting repository visibility” instead of “Making a private repository public”
+
+### Examples of guides
+TBD
+
+## Quickstart guide
+
+Quickstart guides are a type of article that enable the user to complete a discrete, focused task in a single sitting, illustrating an entire workflow in a single page. Quickstart guides follow the guide model, with a few exceptions noted here - see the guides section above for anything not covered here.
+
+Quickstart guides are generally more conversational in tone than our other documentation.
+
+### Contents of quickstart guides
+
+* Table of contents
+* Introduction:
+ * Clarifies audience
+ * Clearly states prerequisites and prior knowledge needed
+ * States what the user will accomplish or build
+ * Includes an example of a successful project
+ * Does not include the expected amount of time that it may take users to complete the task, as this is highly dependent on the experience level of the user and can be demoralizing for beginners
+* Procedural sections
+ * Based on the audience for the guide, the steps can be less explicit and formal than those used in procedural content. You do not have to use existing reusables to form these steps if the audience doesn’t require that level of detail.
+ * Use: “From your profile, click **Settings, and then click **Developer settings**.”
+ * Avoid: In the upper-right corner of any page, click your profile photo, then click **Settings**. In the left sidebar, click **Developer settings**.
+ * Link out to other articles or resources rather than replicating them, to avoid interrupting the flow of information in the quickstart.
+ * Give visual cues. Use code blocks and screenshots heavily to help reassure users that they're performing the correct actions.
+ * Provide real examples. For example, don't tell a user to "Enter a commit message," give them an appropriate example commit message that matches the previous steps.
+* Troubleshooting
+ * Acknowledge what may go wrong in the task and list a few common problems readers might run into with solutions.
+* Conclusion
+ * Review what the user has accomplished or built. Refer back to the project provided in the introduction as an example of a successful project.
+* Next steps
+ * Include 2-3 actionable next steps that the user take after completing the guide. Link off to other related information like:
+ * Projects that illustrate the introduced concepts
+ * Relevant information
+ * Relevant Learning courses
+ * Relevant published talks, blog posts, or Community posts
+
+### Title guidelines for quickstart guides
+* Follow the title guidelines for guides
+* Don’t use “quickstart” or “guide” in the title
+
+Examples
+TBD
diff --git a/contributing/contributor-code-of-conduct.md b/contributing/contributor-code-of-conduct.md
new file mode 100644
index 00000000000..4e2f1a3be32
--- /dev/null
+++ b/contributing/contributor-code-of-conduct.md
@@ -0,0 +1,39 @@
+## Documentation contributor code of conduct
+
+dbt Labs is privileged to have a passionate community of supporters from all over the world. The contributors to the community represent the very best of what we can accomplish when people work collaboratively. The code of conduct is the cornerstone of informative, accessible, and inclusive documentation.
+
+### Be inclusive
+
+It is critical that all of dbt Labs documentation is inclusive and respectful of the audience, which consists of people in widely varying circumstances from all over the planet. When writing documentation, use words that are inclusive, anti-racist, and accessible.
+
+Individual words might be small, but together they can create community, belonging, and equity. Be empathetic in all word and style choices. Be accurate when referring to people and communities.
+
+
+Here are resources to help you think about inclusive and accessible language and style:
+* [18F Content Guide on Inclusive Language](https://content-guide.18f.gov/inclusive-language/)
+* [Plain language guidelines (US Gov)](https://www.plainlanguage.gov/guidelines/)
+* MailChimp Content Style Guide:
+ * [Writing About People](https://styleguide.mailchimp.com/writing-about-people/)
+ * [Writing for Accessibility](https://styleguide.mailchimp.com/writing-for-accessibility/)
+* [Readability Guidelines (UK)](https://readabilityguidelines.co.uk/)
+* [Conscious Style Guide](https://consciousstyleguide.com/)
+
+### Be respectful
+
+dbt Labs greatly admire the people who use dbt, partner with the organization, and implement our open source code. We strive for the tone of our documentation to reflect this and never make the reader feel patronized.
+
+Please don't use a disparaging tone when writing about another organization’s product or services. Remain neutral (or positive) and remove any personal feelings you might have from the content.
+
+Through mutual respect for one another, we can enlighten the world.
+
+### Be mindful
+
+Users represent a wide variety of positions in organizations across the world. The goal is to make our documents as appealing and easy to understand to as many people as possible. The dbt Labs style guide is a framework, but the experience you bring to the docs is what will give the most value to our readers.
+
+dbt Labs currently only publishes the content in English, but there are many users who are not native speakers. Keep the wording clear and professional. Avoid idioms, jokes, and anything else that might muddle the point.
+
+Write in straightforward language that requires minimal effort to parse or translate. This helps us reach a wider audience.
+
+### Be collaborative
+
+Community members and dbt Labs staff are in this together. We are a passionate group working towards a common goal — making dbt accessible to everyone. Just as we value community feedback, we are prepared to give feedback to all contributors, fostering an environment of friendly and respectful conversation. Together we can accomplish more than we ever could as individuals. You are an integral part of dbt Labs, and your enthusiasm for collaboration is essential to dbt Labs success.
diff --git a/contributing/developer-blog.md b/contributing/developer-blog.md
new file mode 100644
index 00000000000..1ad3c271ed3
--- /dev/null
+++ b/contributing/developer-blog.md
@@ -0,0 +1,65 @@
+
+* [Contributing](#contributing)
+* [Core Principles](#core-principles)
+
+## Contributing
+
+The dbt Developer Blog is a place where analytics practitioners can go to share their knowledge with the community. Analytics Engineering is a discipline we’re all building together. The developer blog exists to cultivate the collective knowledge that exists on how to build and scale effective data teams.
+
+### What makes a good developer blog post?
+
+- The short answer: Practical, hands on analytics engineering tutorials and stories
+ - [Slim CI/CD with Bitbucket](https://docs.getdbt.com/blog/slim-ci-cd-with-bitbucket-pipelines)
+ - [So You Want to Build a dbt Package](https://docs.getdbt.com/blog/so-you-want-to-build-a-package)
+ - [Founding an Analytics Engineering Team](https://docs.getdbt.com/blog/founding-an-analytics-engineering-team-smartsheet)
+- See the [Developer Blog Core Principles](#core-principles)
+
+### How do I submit a proposed post?
+
+To submit a proposed post, open a `Contribute to the dbt Developer Blog` issue on the [Developer Hub repo](https://github.com/dbt-labs/docs.getdbt.com/issues/new/choose). You will be asked for:
+
+- A short (one paragraph) summary of the post you’d like to publish
+- An outline of the post
+
+You’ll hear back from a member of the dbt Labs teams within 7 days with one of three responses:
+
+- The post looks good to go as is! We’ll ask you to start creating a draft based off of the initial outline you submitted
+- Proposed changes to the outline. This could be additional focus on a topic you mention that’s of high community interest or a tweak to the structure to help with narrative flow
+- Not a fit for the developer blog right now. We hugely appreciate *any* interest in submitting to the Developer Blog - right now our biggest backlog is capacity to help folks get these published. See below on how we are thinking about and evaluating potential posts.
+
+### What is the process once my blog is accepted?
+
+Once a blog is accepted, we’ll ask you for a date when we can expect the draft by. Typically we’ll ask that you can commit to having this ready within a month of submitting the issue.
+
+Once you submit a draft, we’ll return a first set of edits within 5 business days.
+
+The typical turnaround time from issue creation to going live on the developer blog is ~4 to 6 weeks.
+
+### What happens after my blog is published?
+
+We’ll share the blog on the dbt Labs social media channels! We also encourage you to share on the dbt Slack in #i-made-this.
+
+### What if my post doesn’t get approved?
+
+We want to publish as many community contributors as possible, but not every post will be a fit for the Developer Blog. That’s ok! There are many different reasons why we might not be able to publish a post right now and none of them reflect on the quality of the proposed post.
+
+- **dbt Labs capacity**: We’re committed to providing hands-on feedback and coaching throughout the process. Our goal is not just to generate great developer blogs - it’s to help build a community of great writers / practitioners who can share their knowledge with the community for years to come. This necessarily means we will be able to take on a lower absolute number of posts in the short term, but will hopefully be helpful for the community long term.
+- **Focus on narrative / problem solving - not industry trends**: The developer blog exists, primarily, to tell the stories of analytics engineering practitioners and how they solve problems. The idea is that reading the developer blog gives a feel for what it is like to be a data practitioner on the ground today. This is not a hard and fast rule, but a good way to approach this is “How I/we solved X problem” rather than “How everyone should solve X problem”.
+
+We are very interested in stacks, new tools and integrations and will happily publish posts about this - with the caveat that the *focus* of the post should be solving real world problems. Hopefully if you are writing about these, this is something that you have used yourself in a hands on, production implementation.
+
+- **Right sized scope**: We want to be able to cover a topic in-depth and dig into the nuances. Big topics like “How should you structure your data team” or “How to ensure data quality in your organization” will be tough to cover in the scope of a single post. If you have a big idea - try subdividing it! “How should you structure your data team” could become “How we successfully partnered with our RevOps team on improving lead tracking” and “How to ensure data quality in your organization” might be “How we cleaned up our utm tracking”.
+
+### What if I need help / have questions:
+
+- Feel free to post any questions in #community-writers on the dbt Slack.
+
+## Core Principles
+
+- 🧑🏻🤝🧑🏾 The dbt Developer blog is written by humans **- individual analytics professionals sharing their insight with the world. To the extent feasible, a community member posting on the developer blog is not staking an official organizational stance, but something that *they* have learned or believe based on their work. This is true for dbt Labs employees as well.
+- 💍 Developer blog content is knowledge rich - these are posts that readers share, bookmark and come back to time and time again.
+- ⛹🏼♂️ Developer blog content is written by and for *practitioners* - end users of analytics tools (and sometimes people that work with practitioners).
+- ⭐ Developer blog content is best when it is *the story which the author is uniquely positioned to tell.* Authors are encouraged to consider what insight they have that is specific to them and the work they have done.
+- 🏎️ Developer blog content is actionable - readers walk away with a clear sense of how they can use this information to be a more effective practitioner. Posts include code snippets, Loom walkthroughs and hands-on, practical information that can be integrated into daily workflows.
+- 🤏 Nothing is too small to share - what you think is simple has the potential to change someone's week.
+- 🔮 Developer blog content is present focused —posts tell a story of a thing that you've already done or are actively doing, not something that you may do in the future.
diff --git a/contributing/single-sourcing-content.md b/contributing/single-sourcing-content.md
new file mode 100644
index 00000000000..1c47b87b977
--- /dev/null
+++ b/contributing/single-sourcing-content.md
@@ -0,0 +1,254 @@
+# Single-sourcing content
+
+* [About versioning](#adding-a-new-version)
+ * [Using end-of-life dates](#using-end-of-life-dates)
+ * [Versioning entire pages](#versioning-entire-pages)
+ * [Versioning blocks of content](#versioning-blocks-of-content)
+* [Using global variables](#using-global-variables)
+* [Reusing snippets of content](#reusing-snippets-of-content)
+
+## About versioning
+
+Versions are managed in the `versions` array located in the `website/dbt-versions.js` file. This array holds all versions which are selectable from the versions dropdown in the navigation.
+
+**The first version in the array is the latest version.** This is the default version when a visitor loads the page.
+
+### Adding a new version
+
+To add a new version to the site, a new object must be added to the `versions` array in the same format as existing versions. This object holds two properties: **version** and **EOLDate (See End of Life Dates below)**.
+
+Example Version:
+
+```jsx
+exports.versions = [
+ {
+ version: "1.2",
+ EOLDate: "2023-01-01"
+ }
+]
+```
+
+The **version** property is the value which shows in the nav dropdown. This value is compared to the VersionBlock component on a docs page to determine whether that section should be visible for the current active version (See the **Versioning the Sidebar** section on using the VersionBlock component).
+
+### Using end-of-life dates
+
+The **EOLDate** property determines when a version is no longer supported. A version is supported up until 1 year after its release.
+
+When a documentation page is viewed, the **EOLDate** property for the active version is compared to today’s date. If the current version has reached, or is nearing the end of support, a banner will show atop the page, notifying the visitor of the end-of-life status.
+
+Two different versions of the banner will show depending on the end-of-life date:
+
+- When the version is within 3 months of the **EOLDate.**
+- When the version has passed the **EOLDate.**
+
+#### Updating EOL date banner language
+
+The content for these two EOLDate banners are located in the `website/src/theme/DocPage/index.js` file, in the `EOLBannerText` property.
+
+### Versioning entire pages
+
+If a Docs page should not be available for the selected version, it is possible to version the entire page. This is managed in the `versionedPages` array within the `website/dbt-versions.js` file.
+
+Two things occur when a page is not available for the selected version:
+
+- A banner will appear atop the page, noting this page covers a new feature which isn’t available for the selected version.
+- The page is removed from the sidebar
+
+
+Example of how to version a page in the `dbt-versions.js` file:
+
+```jsx
+exports.versionedPages = [
+ {
+ "page": "docs/supported-data-platforms",
+ "firstVersion": "0.21",
+ }
+]
+```
+
+### Properties for versioning an entire page
+
+**page** (mandatory): The path of the Docs page to version. This string must match the string for the page in the `sidebars.js` file.
+
+**firstVersion** (optional): Sets the first version which this page is available.
+
+**lastVersion** (optional): Sets the last version which this page is available.
+
+## Versioning blocks of content
+
+The **VersionBlock** component provides the ability to version a specific piece of content on a docs page.
+
+This component can be added directly to a markdown file in a similar way as other components (FAQ, File, Lightbox).
+
+### Versioning properties
+
+- **firstVersion** (optional): Sets the first version this piece of content is available for.
+ - Defaults to **0** if not set.
+- **lastVersion** (optional): Sets the last version this piece of content is available for.
+ - If **lastVersion** prop not set, it will be available from the **firstVersion,** up to the latest version.
+
+Both properties can be used together to set a range where the content should show. In the example below, this content will only show if the selected version is between **0.21** and **1.0**:
+
+```markdown
+
+
+ Versioned content here
+
+
+```
+
+### Example for versioning entire pages
+
+On the [Docs Defer page](https://docs.getdbt.com/reference/node-selection/defer), tabs are used to show different versions of a piece of code. **v0.21.0 and later** shows `--select`, while **v-.20.x and earlier** changes this to `--models`.
+
+
+
+Below is how we can implement the same versioning using the new **VersionBlock** component:
+
+You see this block when the selected version is >= 0.21:
+
+```markdown
+
+
+
+```shell
+$ dbt run --select [...] --defer --state path/to/artifacts
+$ dbt test --select [...] --defer --state path/to/artifacts
+\```
+
+
+```
+
+You see this version block when the selected version is <= 0.20
+
+```markdown
+
+
+```shell
+$ dbt run --models [...] --defer --state path/to/artifacts
+$ dbt test --models [...] --defer --state path/to/artifacts
+\```
+
+
+```
+
+## Using global variables
+
+---
+
+Global variables can be configured for use throughout the docs.
+
+Using a global variable requires two steps:
+
+1. Set the variable in the `website/dbt-global-variables.js` file.
+2. Use the **Var** component to add the global variable to a page.
+
+```jsx
+// The dbtCore property is the identifer for the variable,
+// while the name property is the value shown on the page.
+
+exports.dbtVariables = {
+ dbtCore: {
+ name: "dbt Core"
+ }
+}
+```
+
+```markdown
+// is converted to dbt Core
+
+You can install on the command line by using one of these recommended methods:
+```
+
+### Versioning global variables
+
+It is possible to version global variables as well. This creates the ability to show different variations of a string based off the current version a visitor has selected.
+
+To extend our `dbt-global-variables.js` file above, we can add a new variable: *note - these versions are not accurate and only shown for this example.*
+
+```jsx
+// A new variable called dbtCloud is added below
+// This variable includes a versions array
+// "Sinter" will replace "dbt Cloud" for versions 0.21 or lower
+
+exports.dbtVariables = {
+ dbtCore: {
+ name: "dbt Core"
+ },
+ dbtCloud: {
+ name: "dbt Cloud",
+ versions: [
+ {
+ "name": "Sinter",
+ "version": "0.21"
+ }
+ ]
+ }
+}
+```
+
+```markdown
+You can get started with by [Signing up](https://www.getdbt.com/signup/).
+```
+
+In the above example, the **dbtCloud** property has a default name of “dbt Cloud”. The naming for variables cascade down, meaning “dbt Cloud” will show for all versions, until version **0.21** or lower is selected. At that point “Sinter” will replace “dbt Cloud”.
+
+### Global variables properties
+
+**name** (required): Expects the identifier for a global variable.
+
+### Global variables example
+
+The global `` component can be used inline, for example:
+
+```markdown
+This piece of markdown content explains why is awesome.
+```
+
+However, a Var component cannot start a new line of content. Fortunately, a workaround exists to use the Var component at the beginning of a line of content.
+
+To use the component at the beginning of a sentence, add a non-breaking space character before the component:
+
+```markdown
+// When starting a new line with a global variable,
+// a non-breaking space is required
+
+// Works
+ is awesome!
+
+// Does not work
+ is awesome!
+```
+
+## Reusing snippets of content
+
+The Snippet component allows for content to be reusable throughout the Docs. This is very similar to the existing FAQ component.
+
+Creating and using a snippet requires two steps:
+
+1. Create a new markdown snippet file in the `website/snippets` directory.
+2. Use the `` component within a Docs file.
+
+### Snippet properties
+
+**src:** Expects the file name of the snippet which lives in the snippets directory
+
+### Snippet example
+
+To create a new snippet to use throughout the site, first we will create a new markdown snippet within the snippets directory:
+
+```markdown
+## Header 2
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nullam fermentum porttitor dui, id scelerisque enim scelerisque at.
+```
+
+Now, we can add this snippet to a Docs file with the Snippet component:
+
+```markdown
+Docs content here.
+
+
+
+Docs content here.
+```
diff --git a/netlify.toml b/netlify.toml
index 298ac05fdd5..6ab92757410 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -1,8 +1,2 @@
-# for deployments of prerelease docs
-[context.next]
- command = "make build-prerelease"
-
-[context.next.environment]
- PRERELEASE = "true"
- ALGOLIA_API_KEY = "044414e92a8b8137a33fd276d4533895"
- ALGOLIA_INDEX_NAME = "dbt_next"
+[build]
+ functions = "functions"
diff --git a/website/.gitignore b/website/.gitignore
index b60fa977326..e0c5b212ea1 100644
--- a/website/.gitignore
+++ b/website/.gitignore
@@ -8,8 +8,13 @@
.docusaurus
.cache-loader
+# cypress artifacts
+/cypress/videos
+/cypress/screenshots
+
# misc
.DS_Store
+.env
.env.local
.env.development.local
.env.test.local
diff --git a/website/.swcrc b/website/.swcrc
new file mode 100644
index 00000000000..046ec0b01c1
--- /dev/null
+++ b/website/.swcrc
@@ -0,0 +1,23 @@
+{
+ "jsc": {
+ "parser": {
+ "syntax": "ecmascript",
+ "jsx": true,
+ "dynamicImport": false,
+ "privateMethod": false,
+ "functionBind": false,
+ "exportDefaultFrom": false,
+ "exportNamespaceFrom": false,
+ "decorators": false,
+ "decoratorsBeforeExport": false,
+ "topLevelAwait": false,
+ "importMeta": false
+ },
+ "transform": null,
+ "target": "es5",
+ "loose": false,
+ "externalHelpers": false,
+ // Requires v1.2.50 or upper and requires target to be es2016 or upper.
+ "keepClassNames": false
+ }
+}
diff --git a/website/Makefile b/website/Makefile
index f75e64951db..9ba2bd80303 100644
--- a/website/Makefile
+++ b/website/Makefile
@@ -20,7 +20,3 @@ build:
cat ../_redirects | grep 'docs/' | awk '{ print "/v0.10" $$1 "\t" $$2 "\t" $$3 }' >> build/_redirects
cat ../_headers > build/_headers
-
-build-prerelease:
- make build
- cat ../_headers > build/_headers
diff --git a/website/blog/2016-03-11-blog-post.md b/website/blog/2016-03-11-blog-post.md
deleted file mode 100755
index cf2ba296067..00000000000
--- a/website/blog/2016-03-11-blog-post.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Blog Title
-author: Blog Author
-authorURL: http://twitter.com/
-authorFBID: 100002976521003
----
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus elementum massa eget nulla aliquet sagittis. Proin odio tortor, vulputate ut odio in, ultrices ultricies augue. Cras ornare ultrices lorem malesuada iaculis. Etiam sit amet libero tempor, pulvinar mauris sed, sollicitudin sapien.
-
-
-
-Mauris vestibulum ullamcorper nibh, ut semper purus pulvinar ut. Donec volutpat orci sit amet mauris malesuada, non pulvinar augue aliquam. Vestibulum ultricies at urna ut suscipit. Morbi iaculis, erat at imperdiet semper, ipsum nulla sodales erat, eget tincidunt justo dui quis justo. Pellentesque dictum bibendum diam at aliquet. Sed pulvinar, dolor quis finibus ornare, eros odio facilisis erat, eu rhoncus nunc dui sed ex. Nunc gravida dui massa, sed ornare arcu tincidunt sit amet. Maecenas efficitur sapien neque, a laoreet libero feugiat ut.
-
-Nulla facilisi. Maecenas sodales nec purus eget posuere. Sed sapien quam, pretium a risus in, porttitor dapibus erat. Sed sit amet fringilla ipsum, eget iaculis augue. Integer sollicitudin tortor quis ultricies aliquam. Suspendisse fringilla nunc in tellus cursus, at placerat tellus scelerisque. Sed tempus elit a sollicitudin rhoncus. Nulla facilisi. Morbi nec dolor dolor. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Cras et aliquet lectus. Pellentesque sit amet eros nisi. Quisque ac sapien in sapien congue accumsan. Nullam in posuere ante. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Proin lacinia leo a nibh fringilla pharetra.
-
-Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Proin venenatis lectus dui, vel ultrices ante bibendum hendrerit. Aenean egestas feugiat dui id hendrerit. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Curabitur in tellus laoreet, eleifend nunc id, viverra leo. Proin vulputate non dolor vel vulputate. Curabitur pretium lobortis felis, sit amet finibus lorem suscipit ut. Sed non mollis risus. Duis sagittis, mi in euismod tincidunt, nunc mauris vestibulum urna, at euismod est elit quis erat. Phasellus accumsan vitae neque eu placerat. In elementum arcu nec tellus imperdiet, eget maximus nulla sodales. Curabitur eu sapien eget nisl sodales fermentum.
-
-Phasellus pulvinar ex id commodo imperdiet. Praesent odio nibh, sollicitudin sit amet faucibus id, placerat at metus. Donec vitae eros vitae tortor hendrerit finibus. Interdum et malesuada fames ac ante ipsum primis in faucibus. Quisque vitae purus dolor. Duis suscipit ac nulla et finibus. Phasellus ac sem sed dui dictum gravida. Phasellus eleifend vestibulum facilisis. Integer pharetra nec enim vitae mattis. Duis auctor, lectus quis condimentum bibendum, nunc dolor aliquam massa, id bibendum orci velit quis magna. Ut volutpat nulla nunc, sed interdum magna condimentum non. Sed urna metus, scelerisque vitae consectetur a, feugiat quis magna. Donec dignissim ornare nisl, eget tempor risus malesuada quis.
diff --git a/website/blog/2017-04-10-blog-post-two.md b/website/blog/2017-04-10-blog-post-two.md
deleted file mode 100755
index 3ab4637bd5b..00000000000
--- a/website/blog/2017-04-10-blog-post-two.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: New Blog Post
-author: Blog Author
-authorURL: http://twitter.com/
-authorFBID: 100002976521003
----
-
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus elementum massa eget nulla aliquet sagittis. Proin odio tortor, vulputate ut odio in, ultrices ultricies augue. Cras ornare ultrices lorem malesuada iaculis. Etiam sit amet libero tempor, pulvinar mauris sed, sollicitudin sapien.
-
-
-
-Mauris vestibulum ullamcorper nibh, ut semper purus pulvinar ut. Donec volutpat orci sit amet mauris malesuada, non pulvinar augue aliquam. Vestibulum ultricies at urna ut suscipit. Morbi iaculis, erat at imperdiet semper, ipsum nulla sodales erat, eget tincidunt justo dui quis justo. Pellentesque dictum bibendum diam at aliquet. Sed pulvinar, dolor quis finibus ornare, eros odio facilisis erat, eu rhoncus nunc dui sed ex. Nunc gravida dui massa, sed ornare arcu tincidunt sit amet. Maecenas efficitur sapien neque, a laoreet libero feugiat ut.
-
-Nulla facilisi. Maecenas sodales nec purus eget posuere. Sed sapien quam, pretium a risus in, porttitor dapibus erat. Sed sit amet fringilla ipsum, eget iaculis augue. Integer sollicitudin tortor quis ultricies aliquam. Suspendisse fringilla nunc in tellus cursus, at placerat tellus scelerisque. Sed tempus elit a sollicitudin rhoncus. Nulla facilisi. Morbi nec dolor dolor. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Cras et aliquet lectus. Pellentesque sit amet eros nisi. Quisque ac sapien in sapien congue accumsan. Nullam in posuere ante. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Proin lacinia leo a nibh fringilla pharetra.
-
-Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Proin venenatis lectus dui, vel ultrices ante bibendum hendrerit. Aenean egestas feugiat dui id hendrerit. Orci varius natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Curabitur in tellus laoreet, eleifend nunc id, viverra leo. Proin vulputate non dolor vel vulputate. Curabitur pretium lobortis felis, sit amet finibus lorem suscipit ut. Sed non mollis risus. Duis sagittis, mi in euismod tincidunt, nunc mauris vestibulum urna, at euismod est elit quis erat. Phasellus accumsan vitae neque eu placerat. In elementum arcu nec tellus imperdiet, eget maximus nulla sodales. Curabitur eu sapien eget nisl sodales fermentum.
-
-Phasellus pulvinar ex id commodo imperdiet. Praesent odio nibh, sollicitudin sit amet faucibus id, placerat at metus. Donec vitae eros vitae tortor hendrerit finibus. Interdum et malesuada fames ac ante ipsum primis in faucibus. Quisque vitae purus dolor. Duis suscipit ac nulla et finibus. Phasellus ac sem sed dui dictum gravida. Phasellus eleifend vestibulum facilisis. Integer pharetra nec enim vitae mattis. Duis auctor, lectus quis condimentum bibendum, nunc dolor aliquam massa, id bibendum orci velit quis magna. Ut volutpat nulla nunc, sed interdum magna condimentum non. Sed urna metus, scelerisque vitae consectetur a, feugiat quis magna. Donec dignissim ornare nisl, eget tempor risus malesuada quis.
diff --git a/website/blog/2017-09-25-testing-rss.md b/website/blog/2017-09-25-testing-rss.md
deleted file mode 100755
index b7ff8129ceb..00000000000
--- a/website/blog/2017-09-25-testing-rss.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Adding RSS Support - RSS Truncation Test
-author: Eric Nakagawa
-authorURL: http://twitter.com/ericnakagawa
-authorFBID: 661277173
----
-1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
-
-This should be truncated.
-
-This line should never render in XML.
diff --git a/website/blog/2017-09-26-adding-rss.md b/website/blog/2017-09-26-adding-rss.md
deleted file mode 100755
index eeb4f0477e5..00000000000
--- a/website/blog/2017-09-26-adding-rss.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Adding RSS Support
-author: Eric Nakagawa
-authorURL: http://twitter.com/ericnakagawa
-authorFBID: 661277173
----
-
-This is a test post.
-
-A whole bunch of other information.
diff --git a/website/blog/2017-10-24-new-version-1.0.0.md b/website/blog/2017-10-24-new-version-1.0.0.md
deleted file mode 100755
index 60761c02dc6..00000000000
--- a/website/blog/2017-10-24-new-version-1.0.0.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-title: New Version 1.0.0
-author: Eric Nakagawa
-authorURL: http://twitter.com/ericnakagawa
-authorFBID: 661277173
----
-
-This blog post will test file name parsing issues when periods are present.
diff --git a/website/blog/2019-05-01-how-we-structure-dbt-projects.md b/website/blog/2019-05-01-how-we-structure-dbt-projects.md
new file mode 100644
index 00000000000..361373ae9d5
--- /dev/null
+++ b/website/blog/2019-05-01-how-we-structure-dbt-projects.md
@@ -0,0 +1,265 @@
+---
+title: "How We Structure our dbt Projects"
+description: "As the maintainers of dbt, and analytics consultants, at Fishtown Analytics we build a lot of dbt projects. Over time, we’ve developed internal conventions on how we structure them."
+slug: how-we-structure-our-dbt-projects
+canonical_url: https://discourse.getdbt.com/t/how-we-structure-our-dbt-projects/355
+
+authors: [claire_carroll]
+
+tags: [dbt tutorials]
+hide_table_of_contents: false
+
+date: 2019-05-01
+is_featured: true
+---
+
+
+As the maintainers of dbt, and analytics consultants, at [Fishtown Analytics](https://www.getdbt.com/dbt-labs/about-us/) (now dbt Labs) we build a lot of dbt projects. Over time, we’ve developed internal conventions on how we structure them.
+
+This article does not seek to instruct you on how to design a final model for your stakeholders — it won’t cover whether you should denormalize everything into one wide master , or have many tables that need to be joined together in the BI layer. There are entire books on this topic. Instead, use this as a guide once you’ve already got an idea of what you’re building for how you should break the transformations up into separate dbt models.
+
+
+
+It’s important to note that **this is not the only, or the objectively best, way to structure a dbt project**. Rather, this document reflects our current opinions. These opinions are strongly influenced by:
+
+* our views on data model design; which in turn are influenced by:
+* the kinds of analytics problems we are solving for clients
+* the data stack we typically work within, in which multiple data sources are loaded by third party tools, and the is optimized for analytical queries (therefore we aren’t tightly bounded by performance optimization considerations).
+
+Our opinions are **almost guaranteed to change over time** as we update our views on modeling, are exposed to more analytics problems, and data stacks evolve. It’s also worth clearly stating here: the way we structure dbt projects makes sense for our projects, but may not be the best fit for yours! This article exists on Discourse so that we can have a conversation – I would love to know how others in the community are structuring their projects.
+
+In comparison, the (recently updated) [best practices](/guides/best-practices) reflect principles that we believe to be true for any dbt project. Of course, these two documents go hand in hand – our projects are structured in such a way that makes the those principles easy to observe, in particular:
+
+* Limit references to raw data
+* Rename and recast fields once
+* Group your models in directories
+* Add tests to your models
+* Consider the information architecture of your data warehouse
+* Separate source-centric and business-centric transformations
+
+If you want to see what the code for one of our projects looks like, check out [this demonstration dbt project](https://github.com/dbt-labs/dbt-learn-demo/tree/day2-dbt-training/models).
+
+We also recently held (and recorded) an office hours on this topic – this article provides a high level outline, but there’s a lot more detail and discussion in the [video](https://youtu.be/xzKLh342s08).
+
+Lastly, before I dive in, a huge thank you to Jeremy Cohen for not only teaching me a lot of the material in this article, but also for doing a lot of the groundwork that went into this article – entire sections of this article are in fact lifted from his work.
+
+## Data transformation 101
+-----------------------------------------------------
+
+The data in any of our projects has three distinct checkpoints:
+
+1. **Sources**: Schemas and tables in a source-conformed structure (i.e. tables and columns in a structure based on what an API returns), loaded by a third party tool.
+2. **Staging models**: The atomic unit of data modeling. Each model bears a one-to-one relationship with the source data table it represents. It has the same granularity, but the columns have been renamed, recast, or usefully reconsidered into a consistent format.
+3. **Marts models**: Models that represent business processes and entities, abstracted from the data sources that they are based on.
+
+In a simple project, these may be the only models you build; more complex projects may have a number of intermediate models that help along this journey, as well as accessories to these models (see below).
+
+Still confused? An example might help! Let’s think about a software business that uses both Stripe and Braintree to collect subscription payments. Their three stages of modeling might look like:
+
+1. **Sources**: Payment records from the Stripe API and payment records from the Braintree API, loaded into their data warehouse by a third party tool.
+2. **Staging models**: Both the Stripe and Braintree payments are recast into a consistent shape, with consistent column names.
+3. **Marts models**: A monthly recurring revenue (MRR) model that classifies revenue per customer per month as new revenue, upgrades, downgrades, and churn, to understand how a business is performing over time. It may be useful to note whether the revenue was collected via Stripe or Braintree, but they are not fundamentally separate models.
+
+Of note here is that there is a distinct change that occurs between the staging and marts checkpoints – sources and staging models are source-centric, whereas marts models are business-centric.
+
+In our dbt projects, this leads us to our first split in our `models/` directory which helps us make this distinction:
+
+```
+ ├── dbt_project.yml
+ └── models
+ ├── marts
+ └── staging
+
+```
+
+## Staging raw data
+---------------------------------------
+
+The goal of the staging layer is to create staging models. Staging models take raw data, and clean and prepare them for further analysis. For a user querying the data warehouse, a relation with a `stg_` prefix indicates that:
+
+* Fields have been renamed and recast in a consistent way.¹
+* Datatypes, such as timezones, are consistent.
+* Light cleansing, such as replacing empty string with NULL values, has occurred.
+* If useful, flattening of objects might have occurred.
+* There is a that is both unique and not null (and tested).
+
+Staging models can have joins in them to field additional columns for context or enrichment; add rows through unions and remove them through filters; deduplicate a natural key or hash together a [surrogate one](/blog/sql-surrogate-keys).
+
+Because we often work with multiple data sources, in our `staging` directory, we create one directory per source.
+
+
+```
+ ├── dbt_project.yml
+ └── models
+ ├── marts
+ └── staging
+ ├── braintree
+ └── stripe
+```
+
+Each staging directory contains at a minimum:
+
+
+* One staging model for each object that is useful for analytics:
+ * Named `stg___