Merge remote-tracking branch 'origin/dev' into feat/stats

Author: TylerAPfledderer

.all-contributorsrc

@@ -100,7 +100,7 @@ body:
     id: layer_2_dapp_ecosystem
     attributes:
       label: Link to dapp ecosystem (if applicable)
-      description: "Please provide a link to the dapp ecosystem. (ex: https://portal.arbitrum.one/, https://www.optimism.io/apps/all)"
+      description: "Please provide a link to the dapp ecosystem. (ex: https://portal.arbitrum.io/, https://www.optimism.io/apps)"
   - type: input
     id: layer_2_token_contract_list
     attributes:

.github/ISSUE_TEMPLATE/suggest_layer2.yaml

@@ -59,5 +59,5 @@ jobs:
 
       - name: Create Pull Request
         run: |
-          gh auth login --with-token <<< ${{ secrets.GITHUB_TOKEN }}
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
           gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update translation contributors from Crowdin - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/get-crowdin-contributors.yml

@@ -60,5 +60,5 @@ jobs:
 
       - name: Create Pull Request
         run: |
-          gh auth login --with-token <<< ${{ secrets.GITHUB_TOKEN }}
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
           gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update translation progress from Crowdin - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/get-translation-progress.yml

@@ -0,0 +1,59 @@
+name: Import community events
+
+on:
+  schedule:
+    - cron: "0 0 * * SUN" # Runs every Sunday at midnight
+  workflow_dispatch:
+
+jobs:
+  create_pr:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out code
+        uses: actions/checkout@master
+
+      - name: Set up Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 18
+
+      - name: Install dependencies
+        run: yarn install
+
+      - name: Set up git
+        run: |
+          git config --global user.email "[email protected]"
+          git config --global user.name "GitHub Action"
+
+      - name: Generate timestamp and readable date
+        id: date
+        run: |
+          echo "TIMESTAMP=$(date +'%Y%m%d%H%M%S')" >> $GITHUB_ENV
+          echo "READABLE_DATE=$(date +'%B %-d')" >> $GITHUB_ENV
+
+      - name: Fetch latest dev and create new branch
+        run: |
+          git fetch origin dev
+          git checkout -b "automated-update-${{ env.TIMESTAMP }}" origin/dev
+
+      - name: Run script
+        run: yarn events-import
+        env:
+          GOOGLE_API_KEY: ${{ secrets.GOOGLE_API_KEY }}
+
+      - name: Commit and push
+        run: |
+          git add -A
+          git commit -m "Update community events"
+          git push origin "automated-update-${{ env.TIMESTAMP }}"
+
+      - name: Create PR body
+        run: |
+          echo "This PR was automatically created to update community events from external community spreadsheet." > pr_body.txt
+          echo "This workflows runs every Sunday at 00:00 (UTC)." >> pr_body.txt
+          echo "Source: https://docs.google.com/spreadsheets/d/1NEu_FCc1hnGAuRgPmbXXpf0h2lCrCOlMKbbFEqgkVDQ" >> pr_body.txt
+
+      - name: Create Pull Request
+        run: |
+          gh auth login --with-token ${{ secrets.GITHUB_TOKEN }}
+          gh pr create --base dev --head "automated-update-${{ env.TIMESTAMP }}" --title "Update community events from external spreadsheet - ${{ env.READABLE_DATE }}" --body-file pr_body.txt

.github/workflows/import-community-events.yml

@@ -17,5 +17,5 @@ jobs:
               issue_number: context.issue.number,
               owner: context.repo.owner,
               repo: context.repo.repo,
-              labels: ["needs-triage"]
+              labels: ["needs triage 📥"]
             })

.github/workflows/issue-triage-label.yml

@@ -18,7 +18,7 @@ It's as easy as running `yarn storybook` to boot up a dedicated localhost to see
 
 ## Setting up a component's stories
 
-> 🚨 NOTE: This project uses Storybook v7. The following documentation outlines preferences in setup as it relates to this version. You can refer to the [main docs](https://storybook.js.org/docs/get-started/install) if you need any additional details
+> 🚨 NOTE: This project uses Storybook v7, using the Component Story Format v3 and the `satisfies` keyword to define the type of the meta object. The following documentation outlines preferences in setup as it relates to this version. You can refer to the [main docs](https://storybook.js.org/docs/get-started) if you need any additional details
 
 A Storybook "story" is an instance of a component in a certain state or with certain parameters applied to show an alternative version of the component.
 
@@ -57,9 +57,11 @@ export const Basic: Story = {
 
 **Note**: with the `title` option, we write this based on the groupings set by the Design System. Groupings are declared with forward slashes. (i.e. `Atoms / Form / Input`). See the Storybook docs for details on [Naming conventions](https://storybook.js.org/docs/7.0/react/writing-stories/naming-components-and-hierarchy)
 
+Also, please view the Figma file for the [proposed structure for the Design System](https://www.figma.com/file/Ne3iAassyfAcJ0AlgqioAP/DS-to-storybook-structure?type=design&node-id=42%3A50&mode=design&t=RGkyouvTilzF42y0-1) to provide the correct groupings.
+
 We will maintain this structure for every story file, regardless of simplicity.
 
-Should the component accept props on all or some renders, you can provide an `args` prop for each story and supply the necessary data. And if there is children, use the `render` prop to pass the args and supply children elements.
+Should the component accept props on all or some renders, you can provide an `args` prop for each story and supply the necessary data. This can be done in place of the render if only a single instance of the given component is needed with no other components. If the `children` prop is used, it can still be used in the `args` prop.
 
 Let's say for a `Button` component with different style variants...
 
@@ -77,15 +79,15 @@ export default meta
 type Story = StoryObj<typeof meta>;
 
 export const Solid: Story = {
-  render: (args) => <Button {...args}>A Button</Button>,
   args: {
     variant: 'solid',
+    children: 'A Button'
   }
 }
 export const Outline: Story = {
-  render: (args) => <Button {...args}>A Button</Button>,
   args: {
     variant: 'outline',
+    children: 'A Button'
   }
 }
 
@@ -94,26 +96,51 @@ export const Outline: Story = {
  * they should be shown under one story, so they can be seen side-by-side in the GUI
  * for reviewers to easily compare.
  * This can also be done for various sizes or other like alterations
+ *
+ * 🚨 If prop content is supplied directly to the component and the `args` prop is not used,
+ * do not use the `StoryObj` type. This is especially important when a story rendering multiple versions
+ * of the component.
  */
 
 // Assuming `solid` is the default variant in the Chakra theme config
-export const Variants = () => (
-  <VStack>
-    <Button>A Solid Button</Button>
-    <Button variant="outline">An Outline Button</Button>
-    <Button variant="unstyled">An Unstyled Button</Button>
-  </VStack>
-)
+export const Variants = {
+  render: () => (
+    <VStack>
+      <Button>A Solid Button</Button>
+      <Button variant="outline">An Outline Button</Button>
+      <Button variant="unstyled">An Unstyled Button</Button>
+    </VStack>
+  )
+}
 ```
 
-If only one story is provided for a component, the name of the exported object should match the name in the `title` meta option. (If the title is `Atoms / Form / Button` then the object should be named `Button`) This will hoist the display name up to the parent level in the Storybook dashboard's sidebar.
+### Story file containing a single story
+
+If only one story is provided for a component, the name of the exported object should match the name in the `title` meta option. (If the title is `Atoms / Form / Button` then the object should be named `Button`) This will hoist the display name up to the parent level in the Storybook dashboard's sidebar. This will also mean you have to rename the import of the component. Call it `ButtonComponent`, say.
+
+```tsx
+import ButtonComponent from "."
+
+const meta = {
+  title: "Atoms / Form / Button",
+  component: ButtonComponent,
+} satisfies Meta<typeof ButtonComponent>
+
+export default meta
+
+export const Button: StoryObj<typeof meta> = {
+  render: () => <ButtonComponent />,
+}
+```
 
 As you go and make adjustments to the component itself or it's variant styles, Storybook will hot reload and those changes will appear in the stories that emphasize them.
 
 ## Storybook Dashboard
 
 The dashboard where you view each story has a number of different addons available to check the story thoroughly.
 
+![Screenshot of Storybook Dashboard for Ethereum.org](https://github.com/ethereum/ethereum-org-website/assets/65234762/7dea7692-6a6d-4f1c-b7cb-db177bcab44d)
+
 Outlined below are each area going from left to right in the selections.
 
 | Toolbar above the preview                | Panel below the preview                                                                                                                                                                                                                                                    |

README.md

@@ -4,17 +4,17 @@ This documentation outlines the current process for how issues are triaged for t
 
 ## Issue creation process
 
-Whenever a new issue is opened, it will automatically be labeled with a `needs-triage` label. The `needs-triage` label means that the core team needs to look at the issue, and nobody should work on it yet to avoid unnecessary work. This label will be removed after the issue has been triaged by a core contributor.
+Whenever a new issue is opened, it will automatically be labeled with a `needs triage 📥` label. The `needs triage 📥` label means that the core team needs to look at the issue, and nobody should work on it yet to avoid unnecessary work. This label will be removed after the issue has been triaged by a core contributor.
 
 ## Triage process
 
-The core team will review issues with the `needs-triage` label within 5 days. In order for an issue to be considered triaged, one of the following will need to happen:
+The core team will review issues with the `needs triage 📥` label within 5 days. In order for an issue to be considered triaged, one of the following will need to happen:
 
 1. The issue will be closed if it is not needed, a duplicate, or spam.
 2. If an issue needs more discussion, the `GH grooming` tag will be added, and the issue will be discussed next GitHub grooming. After this call, action items will be recorded and the issue will be considered triaged.
 3. The issue is labeled with the appropriate tags for work needed (ex: `design required`, `dev required`, etc.) and open it up for assignment. More on this below.
 
-After an issue has been triaged, the `needs-triage` label will be removed from the issue.
+After an issue has been triaged, the `needs triage 📥` label will be removed from the issue.
 
 ## Assignment process
 

docs/applying-storybook.md

@@ -0,0 +1,53 @@
+# Custom header IDs for markdown documents
+
+Html ID attributes are used to create links to specific sections of a document. In markdown, **custom header IDs** should be assigned to all header lines (lines that begin with one-or-more hash marks, `#`).
+
+## Markdown syntax
+
+A custom heading ID should follow these rules:
+
+- Placed at the end of a heading line, preceded by a space, followed by a line break
+- Wrapped in curly braces
+- Starts with a hash-mark
+- Uses kebab-case string
+- Unique for the current page
+
+For example:
+
+```markdown
+## My heading {#my-heading}
+
+### A subheading {#a-subheading}
+
+#### Or a longer title that can be shortened {#long-heading}
+```
+
+Note that for short headers, simply lowercasing and using hyphens instead of spaces is sufficient. For longer headers, a shortened concise version of the header is encouraged. Must not repeat the same ID on the same page.
+
+## How are these used?
+
+When these headers are rendered, they come with a link icon attached to it that can be used to quickly link to that section of the document.
+
+Extending the above example, if we wanted to link to the `A subheading` section of the above document (for example living at path `/docs`), you could use the link`/docs#a-subheading` to link directly to that section.
+
+See a live example on ethereum.org: [https://ethereum.org/en/developers/docs/blocks/#block-anatomy](https://ethereum.org/en/developers/docs/blocks/#block-anatomy)
+
+## When to use custom header IDs
+
+### English content
+
+These should be created for header on every new English markdown document.
+
+### Translated content
+
+English files are uploaded to Crowdin for translation. Header ID's should be _inherited_ from the English version, and remain unchanged during translation.
+
+This is to ensure that the translated content can be linked to from other documents and external links, without breaking the path. This is similar to why path and filenames are not translated, but remain in English to simplify linking and referencing.
+
+See a live example on ethereum.org: [https://ethereum.org/es/developers/docs/blocks/#block-anatomy](https://ethereum.org/en/developers/docs/blocks/#block-anatomy)
+
+Notice the header ID is still in English (`#block-anatomy`), but links to the Spanish (`/es/`) version of the site, at the correct section.
+
+## When are these not needed?
+
+Markdown files in the repo `/docs` (such as this one) do not require custom header IDs, as they are not yet displayed on the website, and do not have translated versions.