Merge remote-tracking branch 'origin/dev' into refactor/theme-nested-semantic-tokens

Author: TylerAPfledderer

.github/ISSUE_TEMPLATE/suggest_quiz.yaml

@@ -0,0 +1,34 @@
+name: Suggest quiz
+description: Add, update, delete questions for a quiz on ethereum.osg
+title: Add/Update/Delete quiz question
+labels: ["feature :sparkles", "quiz :books:"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Before suggesting additions, updates, or deletions of quiz content, make sure you've read our [contributing guidelines for quizzes](https://ethereum.org/en/contributing/quizzes/).
+  - type: input
+    id: page
+    attributes:
+      label: Page URL
+      description: URL for the page the quiz can be found on, or should be added to
+    validations:
+      required: true
+  - type: textarea
+    id: question_content
+    attributes:
+      label: Question content
+      description: Suggest questions to add, update, or delete based on contribution guideline
+    validations:
+      required: true
+  - type: checkboxes
+    id: work_on
+    attributes:
+      label: Would you like to work on this issue?
+      options:
+        - label: "Yes"
+          required: false
+        - label: "No"
+          required: false
+    validations:
+      required: true

.github/workflows/chromatic.yml

@@ -5,7 +5,11 @@ name: Chromatic Publish and Testing
 
 # Event for the workflow
 on:
-  push:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+      - ready_for_review
     paths:
       # Only run on file changes in any of these paths
       - "src/components/**/*"

.github/workflows/docsearch-crawl.yml

@@ -12,6 +12,7 @@ module.exports = {
     "@storybook/addon-a11y",
     "@chakra-ui/storybook-addon",
   ],
+  staticDirs: ["../static"],
   babel: async (options) => ({
     ...babelConfig,
   }),

.github/workflows/docsearchConfig.json

@@ -2,6 +2,9 @@ import { action } from "@storybook/addon-actions"
 
 import theme from "../src/@chakra-ui/gatsby-plugin/theme"
 
+import "../static/fonts/inter-font-face.css"
+import "../static/fonts/ibm-plex-font-face.css"
+
 const chakraBreakpointArray = Object.entries(theme.breakpoints)
 
 // Gatsby's Link overrides:

.github/workflows/docsearchConfigScript.js

@@ -144,12 +144,12 @@ In case you want to test them as if you were in a Netlify env, you can install t
 - See [how decisions are made on content changes](https://ethereum.org/en/contributing/#how-decisions-about-the-site-are-made)
 - Acceptable PRs will be approved & merged into the `dev` branch
 
-Learn more about how we review pull requests [here](docs/deploy-and-review-process.md).
+Learn more about how we review pull requests [here](docs/review-process.md).
 
 ### 8. Release
 
 - `master` is continually synced to Netlify and will automatically deploy new commits to ethereum.org
-- The [website team](https://ethereum.org/en/contributing/#how-decisions-about-the-site-are-made) will create deploys and merge `dev` into `master`. This happens on Tuesdays and Thursdays every week. More info on deploys and review process [here](docs/deploy-and-review-process.md).
+- Learn more about how we deploy the site [here](docs/deploy-process.md)
 - You can [view the history of releases](https://github.com/ethereum/ethereum-org-website/releases), which include PR highlights
 
 <hr style="margin-top: 3em; margin-bottom: 3em;">

.storybook/main.js

@@ -0,0 +1,96 @@
+# Ethereum.org deploy process
+
+Ethereum.org follows a [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow for managing and deploying the codebase.
+
+## Deploy process
+
+The current process for deployment involves a 2-day QA cycle to test a release candidate. A release candidate is created on Tuesday, will have 2 days of testing, and then released to production on Thursday assuming no blocking bugs are found.
+
+The typical workflow will be as follows:
+
+1. A branch is created off of the `dev` branch, and pull requests for the branch are created into `dev`
+2. Pull requests are reviewed, and merged into `dev`
+3. On Tuesday, a pull request is created into the `staging` branch
+   - At this point, the `staging` branch will be the release candidate. At this point, no new features are added into staging for the release, only release blocking bugfixes.
+4. During the next 2 days (Tuesday - Thursday) QA testing on the release candidate takes place
+   - During QA testing, any bugs found will be filed under two categories:
+     - Release blocking: if a bug is considered blocking for the release, create an issue and triage for a pull request to fix before release
+     - Non-release blocking: if a bug is not blocking a release, create an issue and triage normally
+5. If any release blocking bugfixes are merged into `staging`, bring those changes into `dev`
+6. When a release candidate is ready for release, merge into `master` and deploy to production on Thursday
+7. Create a tag for the new version in master
+8. Merge tag into `staging` and `dev`
+
+```
+master  O (tag) - - - - - - - - - - - - O (tag)
+
+        |                             /
+
+staging O - - - - - - - - - O - - - O
+
+        |                 /          \
+
+dev     O - - - - O - - - - O - - O - O
+
+          \       \        /      /
+
+feature1    \   _  \ _ _ O     /
+
+feature 2             \ _ _  O
+```
+
+## Release blocking bugfix process
+
+In the event that a bug was found in `staging` during the QA cycle that blocks a release, the following steps will take place to address the bug:
+
+1. Create an issue in GitHub documenting the bug
+2. Triage issue to a developer
+3. Developer will create a branch off of `staging`
+4. Work on bugfix
+5. Create a pull request into `staging`
+6. Merge into `staging` after review
+7. Merge `staging` back into `dev` after the bugfix has been merged
+
+```
+master O (tag) - - - - - - - - - - - - - - - - - - - O (tag)
+
+        |                                         /
+
+        |                bugfix O - O           /
+
+        |                     /      \        /
+
+staging O - - - - - - - - - O - - - - O - -  O
+
+        |                 /                   \
+
+dev     O - - - - O - - O - O - - - O - - - - - O
+```
+
+## Hotfix process
+
+In the event that a hotfix is found in production and needs to be addressed before the next release
+
+1. Create an issue in GitHub documenting the bug
+2. Triage issue to a developer
+3. Developer will create a branch off of `master`
+4. Work on hotfix
+5. Create a pull request into `master`
+6. After review, merge hotfix pull request into `master` and release into production
+7. Merge `master` into `staging` and `dev` branches
+
+```
+    hotfix O - - - O
+
+         /           \
+
+master  O - - - - - - - O (tag)
+
+        |               |
+
+staging O - - - - - - - O
+
+        |               |
+
+dev     O - - O - - - - O
+```