fix(playwright): Use actual viewport height for tiled screenshot scroll calculations

The configured SCREENSHOT_TILED_VIEWPORT_HEIGHT (default 2000px) was larger than
Playwright's actual browser viewport (~768-1200px), causing scroll increments to
skip content between tiles. Now we fetch the actual viewport height and use
min(configured, actual) for scroll calculations to ensure complete content coverage.

Added regression test to verify tiles properly cover all content when configured
viewport exceeds actual viewport size.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

.github/CODEOWNERS

@@ -20,7 +20,7 @@
 
 # Notify PMC members of changes to GitHub Actions
 
-/.github/ @villebro @geido @eschutho @rusackas @betodealmeida @nytai @mistercrunch @craig-rueda @kgabryje @dpgaspar
+/.github/ @villebro @geido @eschutho @rusackas @betodealmeida @nytai @mistercrunch @craig-rueda @kgabryje @dpgaspar @sadpandajoe
 
 # Notify PMC members of changes to required GitHub Actions
 

.github/dependabot.yml

@@ -5,7 +5,7 @@ updates:
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
 
   - package-ecosystem: "npm"
     ignore:
@@ -18,7 +18,7 @@ updates:
       - dependency-name: "jest-environment-jsdom"
     directory: "/superset-frontend/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -40,21 +40,21 @@ updates:
   - package-ecosystem: "npm"
     directory: ".github/actions"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     open-pull-requests-limit: 10
     versioning-strategy: increase
 
   - package-ecosystem: "npm"
     directory: "/docs/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     open-pull-requests-limit: 10
     versioning-strategy: increase
 
   - package-ecosystem: "npm"
     directory: "/superset-websocket/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -63,7 +63,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-websocket/utils/client-ws-app/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -75,7 +75,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-calendar/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -85,7 +85,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-histogram/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -95,7 +95,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-partition/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -105,7 +105,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-world-map/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -115,7 +115,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/plugin-chart-pivot-table/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -125,7 +125,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-chord/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -135,7 +135,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-horizon/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -145,7 +145,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-rose/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -155,7 +155,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-preset-chart-deckgl/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -165,7 +165,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/plugin-chart-table/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -175,7 +175,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-country-map/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -185,7 +185,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-map-box/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -195,7 +195,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-sankey/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -205,7 +205,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-preset-chart-nvd3/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -215,7 +215,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/plugin-chart-word-cloud/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -225,7 +225,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-event-flow/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -235,7 +235,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-paired-t-test/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -245,7 +245,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-sankey-loop/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -255,7 +255,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/plugin-chart-echarts/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -265,7 +265,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/preset-chart-xy/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -275,7 +275,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-heatmap/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -285,7 +285,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-parallel-coordinates/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -295,7 +295,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/legacy-plugin-chart-sunburst/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -305,7 +305,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/plugins/plugin-chart-handlebars/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -315,7 +315,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/packages/generator-superset/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -325,7 +325,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/packages/superset-ui-chart-controls/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -339,7 +339,7 @@ updates:
       - dependency-name: "react-markdown"
       - dependency-name: "remark-gfm"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -349,7 +349,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/packages/superset-ui-demo/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot
@@ -359,7 +359,7 @@ updates:
   - package-ecosystem: "npm"
     directory: "/superset-frontend/packages/superset-ui-switchboard/"
     schedule:
-      interval: "monthly"
+      interval: "daily"
     labels:
       - npm
       - dependabot

.github/workflows/bump-python-package.yml

@@ -41,7 +41,7 @@ jobs:
         uses: ./.github/actions/setup-supersetbot/
 
       - name: Set up Python ${{ inputs.python-version }}
-        uses: actions/setup-python@v5
+        uses: actions/setup-python@v6
         with:
           python-version: "3.10"
 

.github/workflows/check_db_migration_confict.yml

@@ -27,7 +27,7 @@ jobs:
       - name: "Checkout ${{ github.ref }} ( ${{ github.sha }} )"
         uses: actions/checkout@v5
       - name: Check and notify
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{ github.token }}
           script: |

.github/workflows/claude.yml

@@ -44,7 +44,7 @@ jobs:
       pull-requests: write
     steps:
       - name: Comment access denied
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           script: |
             const message = `👋 Hi @${{ github.event.comment.user.login || github.event.review.user.login || github.event.issue.user.login }}!

.github/workflows/codeql-analysis.yml

@@ -41,7 +41,7 @@ jobs:
 
       # Initializes the CodeQL tools for scanning.
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@v3
+        uses: github/codeql-action/init@v4
         with:
           languages: ${{ matrix.language }}
           # If you wish to specify custom queries, you can do so here or in a config file.
@@ -53,6 +53,6 @@ jobs:
 
       - name: Perform CodeQL Analysis
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: github/codeql-action/analyze@v3
+        uses: github/codeql-action/analyze@v4
         with:
           category: "/language:${{matrix.language}}"

.github/workflows/embedded-sdk-release.yml

@@ -29,7 +29,7 @@ jobs:
         working-directory: superset-embedded-sdk
     steps:
       - uses: actions/checkout@v5
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@v5
         with:
           node-version-file: './superset-embedded-sdk/.nvmrc'
           registry-url: 'https://registry.npmjs.org'

.github/workflows/embedded-sdk-test.yml

@@ -19,7 +19,7 @@ jobs:
         working-directory: superset-embedded-sdk
     steps:
       - uses: actions/checkout@v5
-      - uses: actions/setup-node@v4
+      - uses: actions/setup-node@v5
         with:
           node-version-file: './superset-embedded-sdk/.nvmrc'
           registry-url: 'https://registry.npmjs.org'

.github/workflows/ephemeral-env-pr-close.yml

@@ -33,7 +33,7 @@ jobs:
       pull-requests: write
     steps:
       - name: Configure AWS credentials
-        uses: aws-actions/configure-aws-credentials@v4
+        uses: aws-actions/configure-aws-credentials@v5
         with:
           aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
           aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
@@ -69,7 +69,7 @@ jobs:
 
       - name: Comment (success)
         if: steps.describe-services.outputs.active == 'true'
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{github.token}}
           script: |

.github/workflows/ephemeral-env.yml

@@ -63,7 +63,7 @@ jobs:
       - name: Get event SHA
         id: get-sha
         if: steps.eval-label.outputs.result == 'up'
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
           script: |
@@ -94,7 +94,7 @@ jobs:
             core.setOutput("sha", prSha);
 
       - name: Looking for feature flags in PR description
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         id: eval-feature-flags
         if: steps.eval-label.outputs.result == 'up'
         with:
@@ -116,7 +116,7 @@ jobs:
             return results;
 
       - name: Reply with confirmation comment
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         if: steps.eval-label.outputs.result == 'up'
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}
@@ -189,7 +189,7 @@ jobs:
             --extra-flags "--build-arg INCLUDE_CHROMIUM=false"
 
       - name: Configure AWS credentials
-        uses: aws-actions/configure-aws-credentials@v4
+        uses: aws-actions/configure-aws-credentials@v5
         with:
           aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
           aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
@@ -225,7 +225,7 @@ jobs:
           persist-credentials: false
 
       - name: Configure AWS credentials
-        uses: aws-actions/configure-aws-credentials@v4
+        uses: aws-actions/configure-aws-credentials@v5
         with:
           aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
           aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
@@ -248,7 +248,7 @@ jobs:
 
       - name: Fail on missing container image
         if: steps.check-image.outcome == 'failure'
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{ github.token }}
           script: |
@@ -318,7 +318,7 @@ jobs:
           echo "ip=$(aws ec2 describe-network-interfaces --network-interface-ids ${{ steps.get-eni.outputs.eni }} | jq -r '.NetworkInterfaces | first | .Association.PublicIp')" >> $GITHUB_OUTPUT
       - name: Comment (success)
         if: ${{ success() }}
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{github.token}}
           script: |
@@ -331,7 +331,7 @@ jobs:
             });
       - name: Comment (failure)
         if: ${{ failure() }}
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           github-token: ${{github.token}}
           script: |

.github/workflows/github-action-validator.yml

@@ -17,7 +17,7 @@ jobs:
         uses: actions/checkout@v5
 
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version: '20'
 

.github/workflows/labeler.yml

@@ -9,7 +9,7 @@ jobs:
       pull-requests: write
     runs-on: ubuntu-24.04
     steps:
-    - uses: actions/labeler@v5
+    - uses: actions/labeler@v6
       with:
         sync-labels: true
 

.github/workflows/no-hold-label.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
     - name: Check for 'hold' label
-      uses: actions/github-script@v7
+      uses: actions/github-script@v8
       with:
         github-token: ${{secrets.GITHUB_TOKEN}}
         script: |

.github/workflows/pre-commit.yml

@@ -39,7 +39,7 @@ jobs:
           echo "HOMEBREW_REPOSITORY=$HOMEBREW_REPOSITORY" >>"${GITHUB_ENV}"
           brew install norwoodj/tap/helm-docs
       - name: Setup Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version: '20'
 

.github/workflows/release.yml

@@ -42,7 +42,7 @@ jobs:
 
       - name: Install Node.js
         if: env.HAS_TAGS
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
 

.github/workflows/showtime-trigger.yml

@@ -37,7 +37,7 @@ jobs:
     steps:
       - name: Security Check - Authorize Maintainers Only
         id: auth
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         with:

.github/workflows/superset-applitool-cypress.yml

@@ -63,7 +63,7 @@ jobs:
         with:
           run: testdata
       - name: Setup Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies

.github/workflows/superset-applitools-storybook.yml

@@ -36,7 +36,7 @@ jobs:
           submodules: recursive
           ref: master
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install eyes-storybook dependencies

.github/workflows/superset-docs-deploy.yml

@@ -36,7 +36,7 @@ jobs:
           persist-credentials: false
           submodules: recursive
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './docs/.nvmrc'
       - name: Setup Python

.github/workflows/superset-docs-verify.yml

@@ -21,12 +21,14 @@ jobs:
       - uses: actions/checkout@v5
       # Do not bump this linkinator-action version without opening
       # an ASF Infra ticket to allow the new version first!
-      - uses: JustinBeckwith/linkinator-action@v1.11.0
+      - uses: JustinBeckwith/linkinator-action@3d5ba091319fa7b0ac14703761eebb7d100e6f6d  # v1.11.0
         continue-on-error: true # This will make the job advisory (non-blocking, no red X)
         with:
-          paths: "**/*.md, **/*.mdx, !superset-frontend/CHANGELOG.md"
+          paths: "**/*.md, **/*.mdx"
           linksToSkip: >-
-            ^https://github.com/apache/(superset|incubator-superset)/(pull|issue)/\d+,
+            ^https://github.com/apache/(superset|incubator-superset)/(pull|issues)/\d+,
+            ^https://github.com/apache/(superset|incubator-superset)/commit/[a-f0-9]+,
+            superset-frontend/.*CHANGELOG\.md,
             http://localhost:8088/,
             http://127.0.0.1:3000/,
             http://localhost:9001/,
@@ -41,12 +43,12 @@ jobs:
             http://theiconic.com.au/,
             https://dev.mysql.com/doc/refman/5.7/en/innodb-limits.html,
             ^https://img\.shields\.io/.*,
-            https://vkusvill.ru/
-            https://www.linkedin.com/in/mark-thomas-b16751158/
-            https://theiconic.com.au/
-            https://wattbewerb.de/
-            https://timbr.ai/
-            https://opensource.org/license/apache-2-0
+            https://vkusvill.ru/,
+            https://www.linkedin.com/in/mark-thomas-b16751158/,
+            https://theiconic.com.au/,
+            https://wattbewerb.de/,
+            https://timbr.ai/,
+            https://opensource.org/license/apache-2-0,
             https://www.plaidcloud.com/
   build-deploy:
     name: Build & Deploy
@@ -61,7 +63,7 @@ jobs:
           persist-credentials: false
           submodules: recursive
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './docs/.nvmrc'
       - name: yarn install

.github/workflows/superset-e2e.yml

@@ -109,7 +109,7 @@ jobs:
           run: testdata
       - name: Setup Node.js
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies

.github/workflows/superset-helm-release.yml

@@ -101,7 +101,7 @@ jobs:
           CR_RELEASE_NAME_TEMPLATE: "superset-helm-chart-{{ .Version }}"
 
       - name: Open Pull Request
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           script: |
             const branchName = '${{ env.branch_name }}';

.github/workflows/superset-playwright.yml

@@ -99,7 +99,7 @@ jobs:
           run: testdata
       - name: Setup Node.js
         if: steps.check.outputs.python || steps.check.outputs.frontend
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
       - name: Install npm dependencies

.github/workflows/superset-translations.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: Setup Node.js
         if: steps.check.outputs.frontend
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file:  './superset-frontend/.nvmrc'
       - name: Install dependencies

.github/workflows/supersetbot.yml

@@ -26,7 +26,7 @@ jobs:
     steps:
       - name: Quickly add thumbs up!
         if: github.event_name == 'issue_comment' && contains(github.event.comment.body, '@supersetbot')
-        uses: actions/github-script@v7
+        uses: actions/github-script@v8
         with:
           script: |
             const [owner, repo] = process.env.GITHUB_REPOSITORY.split('/')

.github/workflows/tag-release.yml

@@ -60,7 +60,7 @@ jobs:
           build: "true"
 
       - name: Use Node.js 20
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version: 20
 
@@ -112,7 +112,7 @@ jobs:
           fetch-depth: 0
 
       - name: Use Node.js 20
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version: 20
 

.github/workflows/tech-debt.yml

@@ -30,7 +30,7 @@ jobs:
         uses: actions/checkout@v5
 
       - name: Set up Node.js
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@v5
         with:
           node-version-file: './superset-frontend/.nvmrc'
 

.pre-commit-config.yaml

@@ -68,7 +68,7 @@ repos:
         files: ^superset-frontend/.*\.(js|jsx|ts|tsx)$
       - id: eslint-docs
         name: eslint (docs)
-        entry: bash -c 'cd docs && FILES=$(echo "$@" | sed "s|docs/||g") && yarn eslint --fix --ext .js,.jsx,.ts,.tsx --quiet $FILES'
+        entry: bash -c 'cd docs && FILES=$(echo "$@" | sed "s|docs/||g") && yarn eslint --fix --quiet $FILES'
         language: system
         pass_filenames: true
         files: ^docs/.*\.(js|jsx|ts|tsx)$

CONTRIBUTING.md

@@ -5,7 +5,7 @@
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
+ with the License.  You may obtain a copy of the License at
 
    http://www.apache.org/licenses/LICENSE-2.0
 
@@ -16,9 +16,23 @@
  specific language governing permissions and limitations
  under the License.
 -->
+# Contributing to Apache Superset
+
 Contributions are welcome and are greatly appreciated! Every
 little bit helps, and credit will always be given.
 
-All matters related to contributions have moved to [this section of
-the official Superset documentation](https://superset.apache.org/docs/contributing/). Source for the documentation is
-[located here](https://github.com/apache/superset/tree/master/docs/docs).
+## Developer Portal
+
+All developer and contribution documentation has moved to the Apache Superset Developer Portal:
+
+**[📚 View the Developer Portal →](https://superset.apache.org/developer_portal/)**
+
+The Developer Portal includes comprehensive guides for:
+- [Contributing Overview](https://superset.apache.org/developer_portal/contributing/overview)
+- [Development Setup](https://superset.apache.org/developer_portal/contributing/development-setup)
+- [Submitting Pull Requests](https://superset.apache.org/developer_portal/contributing/submitting-pr)
+- [Contribution Guidelines](https://superset.apache.org/developer_portal/contributing/guidelines)
+- [Code Review Process](https://superset.apache.org/developer_portal/contributing/code-review)
+- [Development How-tos](https://superset.apache.org/developer_portal/contributing/howtos)
+
+Source for the Developer Portal documentation is [located here](https://github.com/apache/superset/tree/master/docs/developer_portal).

Dockerfile

@@ -26,6 +26,9 @@ ARG BUILDPLATFORM=${BUILDPLATFORM:-amd64}
 # Include translations in the final build
 ARG BUILD_TRANSLATIONS="false"
 
+# Build arg to pre-populate examples DuckDB file
+ARG LOAD_EXAMPLES_DUCKDB="false"
+
 ######################################################################
 # superset-node-ci used as a base for building frontend assets and CI
 ######################################################################
@@ -143,8 +146,8 @@ RUN if [ "${BUILD_TRANSLATIONS}" = "true" ]; then \
 ######################################################################
 FROM python-base AS python-common
 
-# Build arg to pre-populate examples DuckDB file
-ARG LOAD_EXAMPLES_DUCKDB="false"
+# Re-declare build arg to receive it in this stage
+ARG LOAD_EXAMPLES_DUCKDB
 
 ENV SUPERSET_HOME="/app/superset_home" \
     HOME="/app/superset_home" \

docs/DOCS_CLAUDE.md

@@ -0,0 +1,642 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# LLM Context Guide for Apache Superset Documentation
+
+This guide helps LLMs work with the Apache Superset documentation site built with Docusaurus 3.
+
+## 📍 Current Directory Context
+
+You are currently in the `/docs` subdirectory of the Apache Superset repository. When referencing files from the main codebase, use `../` to access the parent directory.
+
+```
+/Users/evan_1/GitHub/superset/     # Main repository root
+├── superset/                      # Python backend code
+├── superset-frontend/             # React/TypeScript frontend
+└── docs/                         # Documentation site (YOU ARE HERE)
+    ├── docs/                     # Main documentation content
+    ├── developer_portal/         # Developer guides (currently disabled)
+    ├── components/               # Component playground (currently disabled)
+    └── docusaurus.config.ts      # Site configuration
+```
+
+## 🚀 Quick Commands
+
+```bash
+# Development
+yarn start                 # Start dev server on http://localhost:3000
+yarn stop                 # Stop running dev server
+yarn build                # Build production site
+yarn serve                # Serve built site locally
+
+# Version Management (USE THESE, NOT docusaurus commands)
+yarn version:add:docs <version>              # Add new docs version
+yarn version:add:developer_portal <version>  # Add developer portal version  
+yarn version:add:components <version>        # Add components version
+yarn version:remove:docs <version>           # Remove docs version
+yarn version:remove:developer_portal <version> # Remove developer portal version
+yarn version:remove:components <version>      # Remove components version
+
+# Quality Checks
+yarn typecheck            # TypeScript validation
+yarn eslint              # Lint TypeScript/JavaScript files
+```
+
+## 📁 Documentation Structure
+
+### Main Documentation (`/docs`)
+The primary documentation lives in `/docs` with this structure:
+
+```
+docs/
+├── intro.md                # Auto-generated from ../README.md
+├── quickstart.mdx          # Getting started guide
+├── api.mdx                 # API reference with Swagger UI
+├── faq.mdx                 # Frequently asked questions
+├── installation/           # Installation guides
+│   ├── installation-methods.mdx
+│   ├── docker-compose.mdx
+│   ├── docker-builds.mdx
+│   ├── kubernetes.mdx
+│   ├── pypi.mdx
+│   └── architecture.mdx
+├── configuration/          # Configuration guides
+│   ├── configuring-superset.mdx
+│   ├── alerts-reports.mdx
+│   ├── caching.mdx
+│   ├── databases.mdx
+│   └── [more config docs]
+├── using-superset/         # User guides
+│   ├── creating-your-first-dashboard.md
+│   ├── exploring-data.mdx
+│   └── [more user docs]
+├── contributing/           # Contributor guides
+│   ├── development.mdx
+│   ├── testing-locally.mdx
+│   └── [more contributor docs]
+└── security/              # Security documentation
+    ├── security.mdx
+    └── [security guides]
+```
+
+### Developer Portal (`/developer_portal`) - Currently Disabled
+When enabled, contains developer-focused content:
+- API documentation
+- Architecture guides
+- CLI tools
+- Code examples
+
+### Component Playground (`/components`) - Currently Disabled
+When enabled, provides interactive component examples for UI development.
+
+## 📝 Documentation Standards
+
+### File Types
+- **`.md` files**: Basic Markdown documents
+- **`.mdx` files**: Markdown with JSX - can include React components
+- **`.tsx` files in `/src`**: Custom React components and pages
+
+### Frontmatter Structure
+Every documentation page should have frontmatter:
+
+```yaml
+---
+title: Page Title
+description: Brief description for SEO
+sidebar_position: 1  # Optional: controls order in sidebar
+---
+```
+
+### MDX Component Usage
+MDX files can import and use React components:
+
+```mdx
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+<Tabs>
+  <TabItem value="npm" label="npm" default>
+    ```bash
+    npm install superset
+    ```
+  </TabItem>
+  <TabItem value="yarn" label="yarn">
+    ```bash
+    yarn add superset
+    ```
+  </TabItem>
+</Tabs>
+```
+
+### Code Blocks
+Use triple backticks with language identifiers:
+
+````markdown
+```python
+def hello_world():
+    print("Hello, Superset!")
+```
+
+```sql title="Example Query"
+SELECT * FROM users WHERE active = true;
+```
+
+```bash
+# Installation command
+pip install apache-superset
+```
+````
+
+### Admonitions
+Docusaurus supports various admonition types:
+
+```markdown
+:::note
+This is a note
+:::
+
+:::tip
+This is a tip
+:::
+
+:::warning
+This is a warning
+:::
+
+:::danger
+This is a danger warning
+:::
+
+:::info
+This is an info box
+:::
+```
+
+## 🔄 Version Management
+
+### Version Configuration
+Versions are managed through `versions-config.json`:
+
+```json
+{
+  "docs": {
+    "disabled": false,
+    "lastVersion": "6.0.0",        // Default version shown
+    "includeCurrentVersion": true,  // Show "Next" version
+    "onlyIncludeVersions": ["current", "6.0.0"],
+    "versions": {
+      "current": {
+        "label": "Next",
+        "path": "",
+        "banner": "unreleased"     // Shows warning banner
+      },
+      "6.0.0": {
+        "label": "6.0.0",
+        "path": "6.0.0",
+        "banner": "none"
+      }
+    }
+  }
+}
+```
+
+### Creating New Versions
+**IMPORTANT**: Always use the custom scripts, NOT native Docusaurus commands:
+
+```bash
+# ✅ CORRECT - Updates both Docusaurus and versions-config.json
+yarn version:add:docs 6.1.0
+
+# ❌ WRONG - Only updates Docusaurus, breaks version dropdown
+yarn docusaurus docs:version 6.1.0
+```
+
+### Version Files Created
+When versioning, these files are created:
+- `versioned_docs/version-X.X.X/` - Snapshot of current docs
+- `versioned_sidebars/version-X.X.X-sidebars.json` - Sidebar config
+- `versions.json` - List of all versions
+
+## 🎨 Styling and Theming
+
+### Custom CSS
+Add custom styles in `/src/css/custom.css`:
+
+```css
+:root {
+  --ifm-color-primary: #20a7c9;
+  --ifm-code-font-size: 95%;
+}
+```
+
+### Custom Components
+Create React components in `/src/components/`:
+
+```tsx
+// src/components/FeatureCard.tsx
+import React from 'react';
+
+export default function FeatureCard({title, description}) {
+  return (
+    <div className="card">
+      <h3>{title}</h3>
+      <p>{description}</p>
+    </div>
+  );
+}
+```
+
+Use in MDX:
+
+```mdx
+import FeatureCard from '@site/src/components/FeatureCard';
+
+<FeatureCard
+  title="Fast"
+  description="Lightning fast queries"
+/>
+```
+
+## 📦 Key Dependencies
+
+- **Docusaurus 3.8.1**: Static site generator
+- **React 18.3**: UI framework
+- **Ant Design 5.26**: Component library
+- **@superset-ui/core**: Superset UI components
+- **Swagger UI React**: API documentation
+- **Prism**: Syntax highlighting
+
+## 🔗 Linking Strategies
+
+### Internal Links
+Use relative paths for internal documentation:
+
+```markdown
+[Installation Guide](./installation/docker-compose)
+[Configuration](../configuration/configuring-superset)
+```
+
+### External Links
+Always use full URLs:
+
+```markdown
+[Apache Superset GitHub](https://github.com/apache/superset)
+```
+
+### Linking to Code
+Reference code in the main repository:
+
+```markdown
+See the [main configuration file](https://github.com/apache/superset/blob/master/superset/config.py)
+```
+
+## 🛠️ Common Documentation Tasks
+
+### Adding a New Guide
+1. Create the `.mdx` file in the appropriate directory
+2. Add frontmatter with title and description
+3. Update sidebar if needed (for manual sidebar configs)
+
+### Adding API Documentation
+The API docs use Swagger UI embedded in `/docs/api.mdx`:
+
+```mdx
+import SwaggerUI from "swagger-ui-react";
+import "swagger-ui-react/swagger-ui.css";
+
+<SwaggerUI url="/api/v1/openapi.json" />
+```
+
+### Adding Interactive Examples
+Use MDX to create interactive documentation:
+
+```mdx
+import CodeBlock from '@theme/CodeBlock';
+import MyComponentExample from '!!raw-loader!../examples/MyComponent.tsx';
+
+<CodeBlock language="tsx">{MyComponentExample}</CodeBlock>
+```
+
+## 📋 Documentation Checklist
+
+When creating or updating documentation:
+
+- [ ] Clear, descriptive title in frontmatter
+- [ ] Description for SEO in frontmatter
+- [ ] Proper heading hierarchy (h1 -> h2 -> h3)
+- [ ] Code examples with language identifiers
+- [ ] Links verified (internal and external)
+- [ ] Images have alt text
+- [ ] Admonitions used for important notes
+- [ ] Tested locally with `yarn start`
+- [ ] No broken links (check with `yarn build`)
+
+## 🔍 Searching and Navigation
+
+### Sidebar Configuration
+Sidebars are configured in `/sidebars.js`:
+
+```javascript
+module.exports = {
+  CustomSidebar: [
+    {
+      type: 'doc',
+      label: 'Introduction',
+      id: 'intro',
+    },
+    {
+      type: 'category',
+      label: 'Installation',
+      items: [
+        {
+          type: 'autogenerated',
+          dirName: 'installation',
+        },
+      ],
+    },
+  ],
+};
+```
+
+### Search
+Docusaurus includes Algolia DocSearch integration configured in `docusaurus.config.ts`.
+
+## 🚫 Common Pitfalls to Avoid
+
+1. **Never use `yarn docusaurus docs:version`** - Use `yarn version:add:docs` instead
+2. **Don't edit versioned docs directly** - Edit current docs and create new version
+3. **Avoid absolute paths in links** - Use relative paths for maintainability
+4. **Don't forget frontmatter** - Every doc needs title and description
+5. **Test builds locally** - Run `yarn build` before committing
+
+## 🔧 Troubleshooting
+
+### Dev Server Issues
+```bash
+yarn stop     # Kill any running servers
+yarn clear    # Clear cache
+yarn start    # Restart
+```
+
+### Build Failures
+```bash
+# Check for broken links
+yarn build
+
+# TypeScript issues
+yarn typecheck
+
+# Linting issues
+yarn eslint
+```
+
+### Version Issues
+If versions don't appear in dropdown:
+1. Check `versions-config.json` includes the version
+2. Verify version files exist in `versioned_docs/`
+3. Restart dev server
+
+## 📚 Resources
+
+- [Docusaurus Documentation](https://docusaurus.io/docs)
+- [MDX Documentation](https://mdxjs.com/)
+- [Superset Contributing Guide](../CONTRIBUTING.md)
+- [Main Superset Documentation](https://superset.apache.org/docs/intro)
+
+## 📖 Real Examples and Patterns
+
+### Example: Configuration Documentation Pattern
+From `docs/configuration/configuring-superset.mdx`:
+
+```mdx
+---
+title: Configuring Superset
+hide_title: true
+sidebar_position: 1
+version: 1
+---
+
+# Configuring Superset
+
+## superset_config.py
+
+Superset exposes hundreds of configurable parameters through its
+[config.py module](https://github.com/apache/superset/blob/master/superset/config.py).
+
+```bash
+export SUPERSET_CONFIG_PATH=/app/superset_config.py
+```
+```
+
+**Key patterns:**
+- Links to source code for reference
+- Code blocks with bash/python examples
+- Environment variable documentation
+- Step-by-step configuration instructions
+
+### Example: Tutorial Documentation Pattern
+From `docs/using-superset/creating-your-first-dashboard.mdx`:
+
+```mdx
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+## Creating Your First Dashboard
+
+:::tip
+In addition to this site, [Preset.io](http://preset.io/) maintains an updated set of end-user
+documentation at [docs.preset.io](https://docs.preset.io/).
+:::
+
+### Connecting to a new database
+
+<img src={useBaseUrl("/img/tutorial/tutorial_01_add_database_connection.png")} width="600" />
+```
+
+**Key patterns:**
+- Import Docusaurus hooks for dynamic URLs
+- Use of admonitions (:::tip) for helpful information
+- Screenshots with useBaseUrl for proper path resolution
+- Clear section hierarchy with ### subheadings
+- Step-by-step visual guides
+
+### Example: API Documentation Pattern
+From `docs/api.mdx`:
+
+```mdx
+import SwaggerUI from "swagger-ui-react";
+import "swagger-ui-react/swagger-ui.css";
+
+## API Documentation
+
+<SwaggerUI url="/api/v1/openapi.json" />
+```
+
+**Key patterns:**
+- Embedding interactive Swagger UI
+- Importing necessary CSS
+- Direct API spec integration
+
+### Common Image Patterns
+
+```mdx
+// For images in static folder
+import useBaseUrl from "@docusaurus/useBaseUrl";
+
+<img src={useBaseUrl("/img/feature-screenshot.png")} width="600" />
+
+// With caption
+<figure>
+  <img src={useBaseUrl("/img/dashboard.png")} alt="Dashboard view" />
+  <figcaption>Superset Dashboard Interface</figcaption>
+</figure>
+```
+
+### Multi-Tab Code Examples
+
+```mdx
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+<Tabs
+  defaultValue="docker"
+  values={[
+    {label: 'Docker', value: 'docker'},
+    {label: 'Kubernetes', value: 'k8s'},
+    {label: 'PyPI', value: 'pypi'},
+  ]}>
+  <TabItem value="docker">
+    ```bash
+    docker-compose up
+    ```
+  </TabItem>
+  <TabItem value="k8s">
+    ```bash
+    kubectl apply -f superset.yaml
+    ```
+  </TabItem>
+  <TabItem value="pypi">
+    ```bash
+    pip install apache-superset
+    ```
+  </TabItem>
+</Tabs>
+```
+
+### Configuration File Examples
+
+```mdx
+```python title="superset_config.py"
+# Database connection example
+SQLALCHEMY_DATABASE_URI = 'postgresql://user:password@localhost/superset'
+
+# Security configuration
+SECRET_KEY = 'YOUR_SECRET_KEY_HERE'
+WTF_CSRF_ENABLED = True
+
+# Feature flags
+FEATURE_FLAGS = {
+    'ENABLE_TEMPLATE_PROCESSING': True,
+    'DASHBOARD_NATIVE_FILTERS': True,
+}
+```
+```
+
+### Cross-Referencing Pattern
+
+```mdx
+For detailed configuration options, see:
+- [Configuring Superset](./configuration/configuring-superset)
+- [Database Connections](./configuration/databases)
+- [Security Settings](./security/security)
+
+External resources:
+- [SQLAlchemy Documentation](https://docs.sqlalchemy.org/)
+- [Flask Configuration](https://flask.palletsprojects.com/config/)
+```
+
+### Writing Installation Guides
+
+```mdx
+## Prerequisites
+
+:::warning
+Ensure you have Python 3.9+ and Node.js 16+ installed before proceeding.
+:::
+
+## Installation Steps
+
+1. **Clone the repository**
+   ```bash
+   git clone https://github.com/apache/superset.git
+   cd superset
+   ```
+
+2. **Install Python dependencies**
+   ```bash
+   pip install -e .
+   ```
+
+3. **Initialize the database**
+   ```bash
+   superset db upgrade
+   superset init
+   ```
+
+:::tip Success Check
+Navigate to http://localhost:8088 and login with admin/admin
+:::
+```
+
+### Documenting API Endpoints
+
+```mdx
+## Chart API
+
+### GET /api/v1/chart/
+
+Returns a list of charts.
+
+**Parameters:**
+- `page` (optional): Page number
+- `page_size` (optional): Number of items per page
+
+**Example Request:**
+```bash
+curl -X GET "http://localhost:8088/api/v1/chart/" \
+  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"
+```
+
+**Example Response:**
+```json
+{
+  "count": 42,
+  "result": [
+    {
+      "id": 1,
+      "slice_name": "Sales Dashboard",
+      "viz_type": "line"
+    }
+  ]
+}
+```
+```
+
+---
+
+**Note**: This documentation site serves as the primary resource for Superset users, administrators, and contributors. Always prioritize clarity, accuracy, and completeness when creating or updating documentation.

docs/developer_portal/architecture/overview.md

@@ -1,348 +1,194 @@
 ---
-title: Architecture Overview
+title: Extension Architecture
 sidebar_position: 1
-hide_title: true
 ---
 
 <!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
 
-      http://www.apache.org/licenses/LICENSE-2.0
+  http://www.apache.org/licenses/LICENSE-2.0
 
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
 -->
 
-# Extension Architecture Overview
+# Superset Extension Architecture
 
-The Superset extension architecture is designed to be modular, secure, and performant. This document provides a comprehensive overview of how extensions work and interact with the Superset host application.
+Apache Superset's extension architecture enables developers to enhance and customize the platform without modifying the core codebase. Inspired by the successful VS Code Extensions model, this architecture provides well-defined, versioned APIs and clear contribution points that allow the community to build upon and extend Superset's functionality.
 
-## Core Principles
+## Core Concepts
 
-### 1. Lean Core
-Superset's core remains minimal, with features delegated to extensions wherever possible. Built-in features use the same APIs as external extensions, ensuring API quality through dogfooding.
+### Extensions vs Plugins
 
-### 2. Explicit Contribution Points
-All extension points are clearly defined and documented. Extensions declare their capabilities in metadata files, enabling predictable lifecycle management.
+We use the term "extensions" rather than "plugins" to better convey the idea of enhancing and expanding Superset's core capabilities in a modular and integrated way. Extensions can add new features, modify existing behavior, and integrate deeply with the host application through well-defined APIs.
 
-### 3. Versioned APIs
-Public interfaces follow semantic versioning, ensuring backward compatibility and safe evolution of the platform.
+### Lean Core Philosophy
 
-### 4. Lazy Loading
-Extensions load only when needed, minimizing performance impact and resource consumption.
+Superset's core remains minimal, with many features delegated to extensions. Built-in features are implemented using the same APIs available to external extension authors, ensuring consistency and validating the extension architecture through real-world usage.
 
-### 5. Composability
-Architecture patterns and APIs are reusable across different Superset modules, promoting consistency.
+## Architecture Overview
 
-### 6. Community-Driven
-The system evolves based on real-world feedback, with new extension points added as needs emerge.
-
-## System Architecture
-
-```mermaid
-graph TB
-    subgraph "Superset Host Application"
-        Core[Core Application]
-        API[Extension APIs]
-        Loader[Extension Loader]
-        Manager[Extension Manager]
-    end
-
-    subgraph "Core Packages"
-        FrontendCore["@apache-superset/core<br/>(Frontend)"]
-        BackendCore["apache-superset-core<br/>(Backend)"]
-        CLI["apache-superset-extensions-cli"]
-    end
-
-    subgraph "Extension"
-        Metadata[extension.json]
-        Frontend[Frontend Code]
-        Backend[Backend Code]
-        Bundle[.supx Bundle]
-    end
-
-    Core --> API
-    API --> FrontendCore
-    API --> BackendCore
-    Loader --> Manager
-    Manager --> Bundle
-    Frontend --> FrontendCore
-    Backend --> BackendCore
-    CLI --> Bundle
-```
-
-## Key Components
-
-### Host Application
-
-The Superset host application provides:
-
-- **Extension APIs**: Well-defined interfaces for extensions to interact with Superset
-- **Extension Manager**: Handles lifecycle, activation, and deactivation
-- **Module Loader**: Dynamically loads extension code using Webpack Module Federation
-- **Security Context**: Manages permissions and sandboxing for extensions
+The extension architecture consists of several key components:
 
 ### Core Packages
 
 #### @apache-superset/core (Frontend)
-- Shared UI components and utilities
-- TypeScript type definitions
-- Frontend API implementations
-- Event system and command registry
+Provides essential building blocks for extensions:
+- Shared UI components
+- Utility functions
+- Type definitions
+- Frontend APIs for interacting with the host
 
 #### apache-superset-core (Backend)
-- Python base classes and utilities
+Exposes backend functionality:
 - Database access APIs
-- Security and permission helpers
-- REST API registration
+- Security models
+- REST API extensions
+- SQLAlchemy models and utilities
 
-#### apache-superset-extensions-cli
-- Project scaffolding
-- Build and bundling tools
-- Development server
-- Package management
+### Extension CLI
 
-### Extension Structure
+The `apache-superset-extensions-cli` package provides commands for:
+- Scaffolding new extension projects
+- Building and bundling extensions
+- Development workflows with hot-reload
+- Packaging extensions for distribution
 
-Each extension consists of:
+### Host Application
 
-- **Metadata** (`extension.json`): Declares capabilities and requirements
-- **Frontend**: React components and TypeScript code
-- **Backend**: Python modules and API endpoints
-- **Assets**: Styles, images, and other resources
-- **Bundle** (`.supx`): Packaged distribution format
+Superset acts as the host, providing:
+- Extension registration and management
+- Dynamic loading of extension assets
+- API implementation for extensions
+- Lifecycle management (activation/deactivation)
 
-## Module Federation
+## Extension Points
 
-Extensions use Webpack Module Federation for dynamic loading:
+Extensions can contribute to various parts of Superset:
 
-```javascript
-// Extension webpack.config.js
-new ModuleFederationPlugin({
-  name: 'my_extension',
-  filename: 'remoteEntry.[contenthash].js',
-  exposes: {
-    './index': './src/index.tsx',
-  },
-  externals: {
-    '@apache-superset/core': 'superset',
-  },
-  shared: {
-    react: { singleton: true },
-    'react-dom': { singleton: true },
-  }
-})
-```
+### SQL Lab Extensions
+- Custom panels (left, right, bottom)
+- Editor enhancements
+- Query processors
+- Autocomplete providers
+- Execution plan visualizers
 
-This allows:
-- **Independent builds**: Extensions compile separately from Superset
-- **Shared dependencies**: Common libraries like React aren't duplicated
-- **Dynamic loading**: Extensions load at runtime without rebuilding Superset
-- **Version compatibility**: Extensions declare compatible core versions
+### Dashboard Extensions (Future)
+- Custom widget types
+- Filter components
+- Interaction handlers
 
-## Extension Lifecycle
+### Chart Extensions (Future)
+- New visualization types
+- Data transformers
+- Export formats
+
+## Technical Foundation
+
+### Module Federation
+
+Frontend extensions leverage Webpack Module Federation for dynamic loading:
+- Extensions are built independently
+- Dependencies are shared with the host
+- No rebuild of Superset required
+- Runtime loading of extension assets
+
+### API Versioning
+
+All public APIs follow semantic versioning:
+- Breaking changes require major version bumps
+- Extensions declare compatibility requirements
+- Backward compatibility maintained within major versions
+
+### Security Model
+
+- Extensions disabled by default (require `ENABLE_EXTENSIONS` flag)
+- Built-in extensions follow same security standards as core
+- External extensions run in same context as host (sandboxing planned)
+- Administrators responsible for vetting third-party extensions
+
+## Development Workflow
+
+1. **Initialize**: Use CLI to scaffold new extension
+2. **Develop**: Work with hot-reload in development mode
+3. **Build**: Bundle frontend and backend assets
+4. **Package**: Create `.supx` distribution file
+5. **Deploy**: Upload through API or management UI
+
+## Example: Dataset References Extension
+
+A practical example demonstrating the architecture:
 
-### 1. Registration
 ```typescript
-// Extension registered with host
-extensionManager.register({
-  name: 'my-extension',
-  version: '1.0.0',
-  manifest: manifestData
-});
-```
-
-### 2. Activation
-```typescript
-// activate() called when extension loads
-export function activate(context: ExtensionContext) {
-  // Register contributions
-  const disposables = [];
-
-  // Add panel
-  disposables.push(
-    context.core.registerView('my-panel', MyPanel)
+// Frontend activation
+export function activate(context) {
+  // Register a new SQL Lab panel
+  const panel = core.registerView('dataset_references.main',
+    <DatasetReferencesPanel />
   );
 
-  // Register command
-  disposables.push(
-    context.commands.registerCommand('my-command', {
-      execute: () => { /* ... */ }
-    })
-  );
+  // Listen to query changes
+  const listener = sqlLab.onDidQueryRun(editor => {
+    // Analyze query and update panel
+  });
 
-  // Store for cleanup
-  context.subscriptions.push(...disposables);
+  // Cleanup on deactivation
+  context.subscriptions.push(panel, listener);
 }
 ```
 
-### 3. Runtime
-- Extension responds to events
-- Provides UI components when requested
-- Executes commands when triggered
-- Accesses APIs as needed
-
-### 4. Deactivation
-```typescript
-// Automatic cleanup of registered items
-export function deactivate() {
-  // context.subscriptions automatically disposed
-  // Additional cleanup if needed
-}
-```
-
-## Contribution Types
-
-### Views
-Extensions can add panels and UI components:
-
-```json
-{
-  "views": {
-    "sqllab.panels": [{
-      "id": "my-panel",
-      "name": "My Panel",
-      "icon": "ToolOutlined"
-    }]
-  }
-}
-```
-
-### Commands
-Define executable actions:
-
-```json
-{
-  "commands": [{
-    "command": "my-extension.run",
-    "title": "Run Analysis",
-    "icon": "PlayCircleOutlined"
-  }]
-}
-```
-
-### Menus
-Add items to existing menus:
-
-```json
-{
-  "menus": {
-    "sqllab.editor": {
-      "primary": [{
-        "command": "my-extension.run",
-        "when": "editorHasSelection"
-      }]
-    }
-  }
-}
-```
-
-### API Endpoints
-Register backend REST endpoints:
-
 ```python
+# Backend API extension
 from superset_core.api import rest_api
+from .api import DatasetReferencesAPI
 
-@rest_api.route('/my-endpoint')
-def my_endpoint():
-    return {'data': 'value'}
+# Register custom REST endpoints
+rest_api.add_extension_api(DatasetReferencesAPI)
 ```
 
-## Security Model
-
-### Permissions
-- Extensions run with user's permissions
-- No elevation of privileges
-- Access controlled by Superset's RBAC
-
-### Sandboxing
-- Frontend code runs in browser context
-- Backend code runs in Python process
-- Future: Optional sandboxed execution
-
-### Validation
-- Manifest validation on upload
-- Signature verification (future)
-- Dependency scanning
-
-## Performance Considerations
-
-### Lazy Loading
-- Extensions load only when features are accessed
-- Code splitting for large extensions
-- Cached after first load
-
-### Bundle Optimization
-- Tree shaking removes unused code
-- Minification reduces size
-- Compression for network transfer
-
-### Resource Management
-- Automatic cleanup on deactivation
-- Memory leak prevention
-- Event listener management
-
-## Development vs Production
-
-### Development Mode
-```python
-# superset_config.py
-ENABLE_EXTENSIONS = True
-LOCAL_EXTENSIONS = ['/path/to/extension']
-```
-- Hot reloading
-- Source maps
-- Debug logging
-
-### Production Mode
-- Optimized bundles
-- Cached assets
-- Performance monitoring
-
-## Future Enhancements
-
-### Planned Features
-- Enhanced sandboxing
-- Extension marketplace
-- Inter-extension communication
-- Theme contributions
-- Chart type extensions
-
-### API Expansion
-- Dashboard extensions
-- Database connector API
-- Security provider interface
-- Workflow automation
-
 ## Best Practices
 
-### Do's
-- ✅ Use TypeScript for type safety
-- ✅ Follow semantic versioning
-- ✅ Handle errors gracefully
-- ✅ Clean up resources properly
-- ✅ Document your extension
+### Extension Design
+- Keep extensions focused on specific functionality
+- Use versioned APIs for stability
+- Handle cleanup properly on deactivation
+- Follow Superset's coding standards
 
-### Don'ts
-- ❌ Access private APIs
-- ❌ Modify global state directly
-- ❌ Block the main thread
-- ❌ Store sensitive data insecurely
-- ❌ Assume API stability in 0.x versions
+### Performance
+- Lazy load assets when possible
+- Minimize bundle sizes
+- Share dependencies with host
+- Cache expensive operations
 
-## Learn More
+### Compatibility
+- Declare API version requirements
+- Test across Superset versions
+- Provide migration guides for breaking changes
+- Document compatibility clearly
 
-- [API Reference](../api/frontend)
-- [Development Guide](../getting-started)
-- [Security Guidelines](./security)
-- [Performance Optimization](./performance)
+## Future Roadmap
+
+Planned enhancements include:
+- JavaScript sandboxing for untrusted extensions
+- Extension marketplace and registry
+- Inter-extension communication
+- Advanced theming capabilities
+- Backend hot-reload without restart
+
+## Getting Started
+
+Ready to build your first extension? Check out:
+- [Extension Project Structure](/developer_portal/extensions/extension-project-structure)
+- [API Reference](/developer_portal/api/frontend)
+- [CLI Documentation](/developer_portal/cli/overview)
+- [Frontend Contribution Types](/developer_portal/extensions/frontend-contribution-types)

docs/developer_portal/capabilities/common-capabilities.md

@@ -0,0 +1,55 @@
+---
+title: Common Plugin Capabilities
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Common Plugin Capabilities
+
+🚧 **Coming Soon** 🚧
+
+Explore the shared functionality and common patterns available to all Superset plugins.
+
+## Topics to be covered:
+
+- Plugin lifecycle hooks (initialization, activation, deactivation)
+- Accessing Superset's core services and APIs
+- State management and data persistence
+- Event handling and plugin communication
+- Internationalization (i18n) support
+- Error handling and logging
+- Plugin configuration management
+- Accessing user context and permissions
+- Working with datasets and queries
+- Plugin metadata and manifests
+
+## Core Services Available
+
+- **API Client** - HTTP client for backend communication
+- **State Store** - Redux store access
+- **Theme Provider** - Access to current theme settings
+- **User Context** - Current user information and permissions
+- **Dataset Service** - Working with data sources
+- **Chart Service** - Chart rendering utilities
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/capabilities/extending-workbench.md

@@ -0,0 +1,62 @@
+---
+title: Extending the Workbench
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extending the Workbench
+
+🚧 **Coming Soon** 🚧
+
+Discover how to extend Superset's main interface and workbench with custom components and functionality.
+
+## Topics to be covered:
+
+- Adding custom menu items and navigation
+- Creating custom dashboard components
+- Extending the SQL Lab interface
+- Adding custom sidebar panels
+- Creating floating panels and modals
+- Integrating with the command palette
+- Custom toolbar buttons and actions
+- Workspace state management
+- Plugin-specific keyboard shortcuts
+- Context menu extensions
+
+## Extension Points
+
+- **Main navigation** - Top-level menu items
+- **Dashboard builder** - Custom components and layouts
+- **SQL Lab** - Query editor extensions
+- **Chart explorer** - Visualization building tools
+- **Settings panels** - Configuration interfaces
+- **Data source explorer** - Database navigation
+
+## UI Integration Patterns
+
+- React component composition
+- Portal-based rendering
+- Event-driven UI updates
+- Responsive layout adaptation
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/capabilities/overview.md

@@ -0,0 +1,53 @@
+---
+title: Plugin Capabilities Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Plugin Capabilities Overview
+
+🚧 **Coming Soon** 🚧
+
+This section provides a comprehensive overview of what Superset plugins can do and how they integrate with the core platform.
+
+## Topics to be covered:
+
+- Plugin architecture and lifecycle
+- Available extension points
+- Core APIs and services
+- Plugin communication patterns
+- Configuration and settings management
+- Plugin permissions and security
+- Performance considerations
+- Best practices for plugin development
+
+## Plugin Types
+
+Superset supports several types of plugins:
+- **Visualization plugins** - Custom chart types and data visualizations
+- **Database connectors** - New data source integrations
+- **UI extensions** - Custom dashboard components and interfaces
+- **Theme plugins** - Custom styling and branding
+- **Filter plugins** - Custom filter components
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/capabilities/theming.md

@@ -0,0 +1,61 @@
+---
+title: Theming and Styling
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Theming and Styling
+
+🚧 **Coming Soon** 🚧
+
+Learn how to create custom themes and style your plugins to match Superset's design system.
+
+## Topics to be covered:
+
+- Understanding Superset's theme architecture
+- Using the theme provider in plugins
+- Creating custom color palettes
+- Responsive design considerations
+- Dark mode and light mode support
+- Customizing chart colors and styling
+- Brand customization and white-labeling
+- CSS-in-JS best practices
+- Working with Ant Design components
+- Accessibility in custom themes
+
+## Theme Structure
+
+- **Color tokens** - Primary, secondary, and semantic colors
+- **Typography** - Font families, sizes, and weights
+- **Spacing** - Grid system and layout tokens
+- **Component styles** - Default component appearances
+- **Chart themes** - Color schemes for visualizations
+
+## Supported Theming APIs
+
+- Theme provider context
+- CSS custom properties
+- Emotion/styled-components integration
+- Chart color palette API
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/cli/overview.md

@@ -1,466 +1,578 @@
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
 ---
-title: CLI Documentation
+title: Extension CLI
 sidebar_position: 1
-hide_title: true
 ---
 
-# Superset Extensions CLI
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
 
-The `apache-superset-extensions-cli` provides command-line tools for creating, developing, and packaging Superset extensions.
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Superset Extension CLI
+
+The `apache-superset-extensions-cli` package provides command-line tools for creating, developing, and packaging Apache Superset extensions. It streamlines the entire extension development workflow from initialization to deployment.
 
 ## Installation
 
+Install the CLI globally using pip:
+
 ```bash
 pip install apache-superset-extensions-cli
 ```
 
-## Commands
+Or install locally in your project:
+
+```bash
+pip install --user apache-superset-extensions-cli
+```
+
+Verify installation:
+
+```bash
+superset-extensions --version
+# Output: apache-superset-extensions-cli version 1.0.0
+```
+
+## Commands Overview
+
+| Command | Description |
+|---------|-------------|
+| `init` | Create a new extension project |
+| `dev` | Start development mode with hot reload |
+| `build` | Build extension assets for production |
+| `bundle` | Package extension into a .supx file |
+| `validate` | Validate extension metadata and structure |
+| `publish` | Publish extension to registry (future) |
+
+## Command Reference
 
 ### init
 
-Creates a new extension project with the standard folder structure.
+Creates a new extension project with the standard structure and boilerplate code.
 
 ```bash
-superset-extensions init <extension-name> [options]
+superset-extensions init [options] <extension-name>
 ```
 
-**Options:**
-- `--template <template>`: Use a specific template (default: basic)
-- `--author <name>`: Set the author name
-- `--description <text>`: Set the extension description
-- `--with-backend`: Include backend code structure
+#### Options
+
+- `--type, -t <type>` - Extension type: `full` (default), `frontend-only`, `backend-only`
+- `--template <template>` - Project template: `default`, `sql-lab`, `dashboard`, `chart`
+- `--author <name>` - Extension author name
+- `--description <desc>` - Extension description
+- `--license <license>` - License identifier (default: Apache-2.0)
+- `--superset-version <version>` - Minimum Superset version (default: 4.0.0)
+- `--skip-install` - Skip installing dependencies
+- `--use-typescript` - Use TypeScript for frontend (default: true)
+- `--use-npm` - Use npm instead of yarn
+
+#### Examples
 
-**Example:**
 ```bash
-superset-extensions init my-extension \
-  --author "John Doe" \
-  --description "Adds custom analytics to SQL Lab" \
-  --with-backend
+# Create a basic extension
+superset-extensions init my-extension
+
+# Create a SQL Lab focused extension
+superset-extensions init query-optimizer --template sql-lab
+
+# Create frontend-only extension
+superset-extensions init custom-viz --type frontend-only
+
+# Create with metadata
+superset-extensions init data-quality \
+  --author "Jane Doe" \
+  --description "Data quality monitoring for SQL Lab"
 ```
 
-**Generated Structure:**
+#### Generated Structure
+
 ```
 my-extension/
-├── extension.json
-├── frontend/
+├── extension.json          # Extension metadata
+├── frontend/              # Frontend source code
 │   ├── src/
-│   │   └── index.tsx
+│   │   ├── index.tsx     # Main entry point
+│   │   └── components/   # React components
 │   ├── package.json
 │   ├── tsconfig.json
 │   └── webpack.config.js
-├── backend/
+├── backend/               # Backend source code
 │   ├── src/
 │   │   └── my_extension/
 │   │       ├── __init__.py
-│   │       └── entrypoint.py
+│   │       └── api.py
 │   ├── tests/
-│   ├── pyproject.toml
 │   └── requirements.txt
-└── README.md
+├── README.md
+└── .gitignore
 ```
 
 ### dev
 
-Starts the development server with hot reloading.
+Starts development mode with automatic rebuilding and hot reload.
 
 ```bash
 superset-extensions dev [options]
 ```
 
-**Options:**
-- `--port <port>`: Development server port (default: 9001)
-- `--host <host>`: Development server host (default: localhost)
-- `--no-watch`: Disable file watching
-- `--verbose`: Show detailed output
+#### Options
+
+- `--port, -p <port>` - Development server port (default: 9001)
+- `--host <host>` - Development server host (default: localhost)
+- `--watch-backend` - Also watch backend files (default: true)
+- `--watch-frontend` - Also watch frontend files (default: true)
+- `--no-open` - Don't open browser automatically
+- `--superset-url <url>` - Superset instance URL (default: http://localhost:8088)
+- `--verbose` - Enable verbose logging
+
+#### Examples
 
-**Example:**
 ```bash
-# Start development server
+# Start development mode
 superset-extensions dev
 
-# Output:
-⚙️  Building frontend assets...
-✅ Frontend rebuilt
-✅ Backend files synced
-✅ Manifest updated
-👀 Watching for changes...
+# Use custom port
+superset-extensions dev --port 9002
+
+# Connect to remote Superset
+superset-extensions dev --superset-url https://superset.example.com
 ```
 
+#### Development Workflow
+
+1. **Start the dev server:**
+```bash
+superset-extensions dev
+```
+
+2. **Configure Superset** (`superset_config.py`):
+```python
+LOCAL_EXTENSIONS = [
+    "/path/to/your/extension"
+]
+ENABLE_EXTENSIONS = True
+```
+
+3. **Start Superset:**
+```bash
+superset run -p 8088 --with-threads --reload
+```
+
+The extension will automatically reload when you make changes.
+
 ### build
 
-Builds the extension for production.
+Builds extension assets for production deployment.
 
 ```bash
 superset-extensions build [options]
 ```
 
-**Options:**
-- `--mode <mode>`: Build mode (development | production)
-- `--analyze`: Generate bundle analysis
-- `--source-maps`: Include source maps
+#### Options
+
+- `--mode <mode>` - Build mode: `production` (default), `development`
+- `--analyze` - Generate bundle analysis report
+- `--source-maps` - Generate source maps
+- `--minify` - Minify output (default: true in production)
+- `--output, -o <dir>` - Output directory (default: dist)
+- `--clean` - Clean output directory before build
+- `--parallel` - Build frontend and backend in parallel
+
+#### Examples
 
-**Example:**
 ```bash
 # Production build
-superset-extensions build --mode production
+superset-extensions build
 
-# With analysis
+# Development build with source maps
+superset-extensions build --mode development --source-maps
+
+# Analyze bundle size
 superset-extensions build --analyze
+
+# Custom output directory
+superset-extensions build --output build
+```
+
+#### Build Output
+
+```
+dist/
+├── manifest.json          # Build manifest
+├── frontend/
+│   ├── remoteEntry.[hash].js
+│   ├── [name].[hash].js
+│   └── assets/
+└── backend/
+    └── my_extension/
+        ├── __init__.py
+        └── *.py
 ```
 
 ### bundle
 
-Creates a `.supx` package for distribution.
+Packages the built extension into a distributable `.supx` file.
 
 ```bash
 superset-extensions bundle [options]
 ```
 
-**Options:**
-- `--output <path>`: Output directory (default: current)
-- `--sign`: Sign the package (requires certificate)
-- `--compress`: Compression level (0-9, default: 6)
+#### Options
+
+- `--output, -o <file>` - Output filename (default: `{name}-{version}.supx`)
+- `--sign` - Sign the bundle (requires configured keys)
+- `--compression <level>` - Compression level 0-9 (default: 6)
+- `--exclude <patterns>` - Files to exclude (comma-separated)
+- `--include-dev-deps` - Include development dependencies
+
+#### Examples
 
-**Example:**
 ```bash
 # Create bundle
 superset-extensions bundle
 
-# Creates: my-extension-1.0.0.supx
+# Custom output name
+superset-extensions bundle --output my-extension-latest.supx
+
+# Signed bundle
+superset-extensions bundle --sign
+
+# Exclude test files
+superset-extensions bundle --exclude "**/*.test.js,**/*.spec.ts"
+```
+
+#### Bundle Structure
+
+The `.supx` file is a ZIP archive containing:
+
+```
+my-extension-1.0.0.supx
+├── manifest.json
+├── extension.json
+├── frontend/
+│   └── dist/
+└── backend/
+    └── src/
 ```
 
 ### validate
 
-Validates extension configuration and structure.
+Validates extension structure, metadata, and compatibility.
 
 ```bash
 superset-extensions validate [options]
 ```
 
-**Options:**
-- `--fix`: Auto-fix common issues
-- `--strict`: Enable strict validation
+#### Options
 
-**Checks:**
-- Valid extension.json syntax
-- Required files present
-- Dependency versions
-- Module exports
-- TypeScript configuration
+- `--strict` - Enable strict validation
+- `--fix` - Auto-fix correctable issues
+- `--check-deps` - Validate dependencies
+- `--check-security` - Run security checks
 
-**Example:**
-```bash
-superset-extensions validate --strict
-
-# Output:
-✅ extension.json valid
-✅ Frontend structure valid
-✅ Backend structure valid
-⚠️  Warning: Missing LICENSE file
-✅ Validation passed with warnings
-```
-
-### test
-
-Runs extension tests.
+#### Examples
 
 ```bash
-superset-extensions test [options]
+# Basic validation
+superset-extensions validate
+
+# Strict mode with auto-fix
+superset-extensions validate --strict --fix
+
+# Full validation
+superset-extensions validate --check-deps --check-security
 ```
 
-**Options:**
-- `--coverage`: Generate coverage report
-- `--watch`: Run in watch mode
-- `--frontend-only`: Run only frontend tests
-- `--backend-only`: Run only backend tests
+#### Validation Checks
 
-**Example:**
-```bash
-# Run all tests
-superset-extensions test --coverage
+- Extension metadata completeness
+- File structure conformity
+- API version compatibility
+- Dependency security vulnerabilities
+- Code quality standards
+- Bundle size limits
 
-# Watch mode for frontend
-superset-extensions test --frontend-only --watch
-```
+## Configuration File
 
-### publish
-
-Publishes extension to a registry (future feature).
-
-```bash
-superset-extensions publish [options]
-```
-
-**Options:**
-- `--registry <url>`: Registry URL
-- `--token <token>`: Authentication token
-- `--dry-run`: Simulate publish
-
-## Configuration
-
-### Project Configuration
-
-The CLI reads configuration from multiple sources:
-
-1. **extension.json** - Extension metadata
-2. **package.json** - Frontend dependencies
-3. **pyproject.toml** - Backend configuration
-4. **.extensionrc** - CLI-specific settings
-
-### .extensionrc Example
+Create `.superset-extension.json` for project-specific settings:
 
 ```json
 {
+  "build": {
+    "mode": "production",
+    "sourceMaps": true,
+    "analyze": false,
+    "parallel": true
+  },
   "dev": {
     "port": 9001,
     "host": "localhost",
-    "autoReload": true
+    "autoOpen": true
   },
-  "build": {
-    "mode": "production",
-    "sourceMaps": false,
-    "optimization": true
+  "bundle": {
+    "compression": 6,
+    "sign": false,
+    "exclude": [
+      "**/*.test.*",
+      "**/*.spec.*",
+      "**/tests/**"
+    ]
   },
-  "test": {
-    "coverage": true,
-    "threshold": {
-      "statements": 80,
-      "branches": 70,
-      "functions": 80,
-      "lines": 80
-    }
+  "validation": {
+    "strict": true,
+    "autoFix": true
   }
 }
 ```
 
-## Templates
-
-### Available Templates
-
-- **basic**: Simple extension with frontend only
-- **full-stack**: Frontend and backend components
-- **sql-panel**: SQL Lab panel extension
-- **api-only**: Backend API extension
-- **chart-plugin**: Custom chart visualization
-
-### Using Templates
-
-```bash
-# Use specific template
-superset-extensions init my-chart --template chart-plugin
-
-# List available templates
-superset-extensions init --list-templates
-```
-
-### Custom Templates
-
-Create custom templates in `~/.superset-extensions/templates/`:
-
-```
-~/.superset-extensions/templates/
-└── my-template/
-    ├── template.json
-    └── files/
-        └── ... template files ...
-```
-
-## Development Workflow
-
-### 1. Create Extension
-
-```bash
-superset-extensions init awesome-feature
-cd awesome-feature
-```
-
-### 2. Install Dependencies
-
-```bash
-# Frontend
-cd frontend && npm install
-
-# Backend (if applicable)
-cd ../backend && pip install -r requirements.txt
-```
-
-### 3. Configure Superset
-
-```python
-# superset_config.py
-ENABLE_EXTENSIONS = True
-LOCAL_EXTENSIONS = [
-    "/path/to/awesome-feature"
-]
-```
-
-### 4. Start Development
-
-```bash
-# Terminal 1: Extension dev server
-superset-extensions dev
-
-# Terminal 2: Superset
-superset run -p 8088 --reload
-```
-
-### 5. Test Changes
-
-Make changes to your code and see them reflected immediately in Superset.
-
-### 6. Build and Package
-
-```bash
-# Validate
-superset-extensions validate
-
-# Test
-superset-extensions test
-
-# Build
-superset-extensions build --mode production
-
-# Bundle
-superset-extensions bundle
-```
-
-### 7. Deploy
-
-Upload the `.supx` file to your Superset instance.
-
 ## Environment Variables
 
-The CLI respects these environment variables:
-
-- `SUPERSET_EXTENSIONS_DEV_PORT`: Development server port
-- `SUPERSET_EXTENSIONS_DEV_HOST`: Development server host
-- `SUPERSET_BASE_URL`: Superset instance URL
-- `NODE_ENV`: Node environment (development/production)
-- `PYTHONPATH`: Python module search path
-
-## Troubleshooting
-
-### Common Issues
-
-#### Port Already in Use
+Configure CLI behavior using environment variables:
 
 ```bash
-# Use different port
-superset-extensions dev --port 9002
+# Superset connection
+export SUPERSET_URL=http://localhost:8088
+export SUPERSET_USERNAME=admin
+export SUPERSET_PASSWORD=admin
+
+# Development settings
+export EXTENSION_DEV_PORT=9001
+export EXTENSION_DEV_HOST=localhost
+
+# Build settings
+export EXTENSION_BUILD_MODE=production
+export EXTENSION_SOURCE_MAPS=true
+
+# Registry settings (future)
+export EXTENSION_REGISTRY_URL=https://registry.superset.apache.org
+export EXTENSION_REGISTRY_TOKEN=your-token
 ```
 
-#### Module Federation Errors
-
-```bash
-# Rebuild with clean cache
-rm -rf dist/ node_modules/.cache
-superset-extensions build
-```
-
-#### Python Import Errors
-
-```bash
-# Ensure virtual environment is activated
-source venv/bin/activate
-superset-extensions dev
-```
-
-### Debug Mode
-
-Enable verbose output for troubleshooting:
-
-```bash
-# Verbose output
-superset-extensions dev --verbose
-
-# Debug webpack
-DEBUG=webpack:* superset-extensions build
-```
-
-## Best Practices
-
-1. **Version Control**: Commit `extension.json` but not `dist/`
-2. **Dependencies**: Pin versions in package.json
-3. **Testing**: Write tests for critical functionality
-4. **Documentation**: Keep README.md updated
-5. **Validation**: Run validate before bundling
-6. **Semantic Versioning**: Follow semver for releases
-
 ## Advanced Usage
 
-### Custom Webpack Configuration
+### Custom Templates
 
-Extend the default webpack config:
+Create custom project templates:
 
-```javascript
-// webpack.config.js
-const baseConfig = require('./webpack.base.config');
+```bash
+# Use custom template
+superset-extensions init my-ext --template https://github.com/user/template
 
-module.exports = {
-  ...baseConfig,
-  // Custom modifications
-  resolve: {
-    ...baseConfig.resolve,
-    alias: {
-      '@': path.resolve(__dirname, 'src'),
-    },
-  },
-};
+# Use local template
+superset-extensions init my-ext --template ./my-template
 ```
 
 ### CI/CD Integration
 
+#### GitHub Actions
+
 ```yaml
-# .github/workflows/extension.yml
-name: Extension CI
+name: Build Extension
 
 on: [push, pull_request]
 
 jobs:
-  test:
+  build:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
-      - uses: actions/setup-node@v2
-      - uses: actions/setup-python@v2
+
+      - name: Setup Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: '3.9'
+
+      - name: Setup Node
+        uses: actions/setup-node@v2
+        with:
+          node-version: '16'
 
       - name: Install CLI
         run: pip install apache-superset-extensions-cli
 
+      - name: Install dependencies
+        run: |
+          npm install --prefix frontend
+          pip install -r backend/requirements.txt
+
       - name: Validate
         run: superset-extensions validate --strict
 
-      - name: Test
-        run: superset-extensions test --coverage
-
       - name: Build
         run: superset-extensions build --mode production
 
       - name: Bundle
         run: superset-extensions bundle
+
+      - name: Upload artifact
+        uses: actions/upload-artifact@v2
+        with:
+          name: extension-bundle
+          path: '*.supx'
 ```
 
-## Getting Help
+### Automated Deployment
 
-- **Documentation**: [Developer Portal](../)
-- **Examples**: [GitHub Repository](https://github.com/apache/superset/tree/master/extensions)
-- **Issues**: [GitHub Issues](https://github.com/apache/superset/issues)
-- **Community**: [Slack Channel](https://apache-superset.slack.com)
+Deploy extensions automatically:
+
+```bash
+#!/bin/bash
+# deploy.sh
+
+# Build and bundle
+superset-extensions build --mode production
+superset-extensions bundle --sign
+
+# Upload to Superset instance
+BUNDLE=$(ls *.supx | head -1)
+curl -X POST "$SUPERSET_URL/api/v1/extensions/import/" \
+  -H "Authorization: Bearer $SUPERSET_TOKEN" \
+  -F "bundle=@$BUNDLE"
+
+# Verify deployment
+curl "$SUPERSET_URL/api/v1/extensions/" \
+  -H "Authorization: Bearer $SUPERSET_TOKEN"
+```
+
+### Multi-Extension Projects
+
+Manage multiple extensions in one repository:
+
+```bash
+# Initialize multiple extensions
+superset-extensions init extensions/viz-plugin --type frontend-only
+superset-extensions init extensions/sql-optimizer --template sql-lab
+superset-extensions init extensions/auth-provider --type backend-only
+
+# Build all extensions
+for dir in extensions/*/; do
+  (cd "$dir" && superset-extensions build)
+done
+
+# Bundle all extensions
+for dir in extensions/*/; do
+  (cd "$dir" && superset-extensions bundle)
+done
+```
+
+## Troubleshooting
+
+### Common Issues
+
+#### Port already in use
+
+```bash
+# Error: Port 9001 is already in use
+
+# Solution: Use a different port
+superset-extensions dev --port 9002
+```
+
+#### Module not found
+
+```bash
+# Error: Cannot find module '@apache-superset/core'
+
+# Solution: Ensure dependencies are installed
+npm install --prefix frontend
+```
+
+#### Build failures
+
+```bash
+# Check Node and Python versions
+node --version  # Should be 16+
+python --version  # Should be 3.9+
+
+# Clear cache and rebuild
+rm -rf dist node_modules frontend/node_modules
+npm install --prefix frontend
+superset-extensions build --clean
+```
+
+#### Bundle too large
+
+```bash
+# Warning: Bundle size exceeds recommended limit
+
+# Solution: Analyze and optimize
+superset-extensions build --analyze
+
+# Exclude unnecessary files
+superset-extensions bundle --exclude "**/*.map,**/*.test.*"
+```
+
+### Debug Mode
+
+Enable debug logging:
+
+```bash
+# Set debug environment variable
+export DEBUG=superset-extensions:*
+
+# Or use verbose flag
+superset-extensions dev --verbose
+superset-extensions build --verbose
+```
+
+### Getting Help
+
+```bash
+# General help
+superset-extensions --help
+
+# Command-specific help
+superset-extensions init --help
+superset-extensions dev --help
+
+# Version information
+superset-extensions --version
+```
+
+## Best Practices
+
+### Development
+
+1. **Use TypeScript** for type safety
+2. **Follow the style guide** for consistency
+3. **Write tests** for critical functionality
+4. **Document your code** with JSDoc/docstrings
+5. **Use development mode** for rapid iteration
+
+### Building
+
+1. **Optimize bundle size** - analyze and tree-shake
+2. **Generate source maps** for debugging
+3. **Validate before building** to catch issues early
+4. **Use production mode** for final builds
+5. **Clean build directory** to avoid stale files
+
+### Deployment
+
+1. **Sign your bundles** for security
+2. **Version properly** using semantic versioning
+3. **Test in staging** before production deployment
+4. **Document breaking changes** in CHANGELOG
+5. **Provide migration guides** for major updates
+
+## Resources
+
+- [Extension Architecture](/developer_portal/architecture/overview)
+- [API Reference](/developer_portal/api/frontend)
+- [Frontend Contribution Types](/developer_portal/extensions/frontend-contribution-types)
+- [GitHub Repository](https://github.com/apache/superset)
+- [Community Forum](https://github.com/apache/superset/discussions)

docs/developer_portal/coding-guidelines/overview.md

@@ -0,0 +1,44 @@
+---
+title: Coding Guidelines Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Coding Guidelines Overview
+
+🚧 **Coming Soon** 🚧
+
+Best practices and coding standards for Apache Superset development.
+
+## Topics to be covered:
+
+- General coding principles
+- Code organization
+- Error handling
+- Performance considerations
+- Security best practices
+- Testing requirements
+- Documentation standards
+- Commit message conventions
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/contributing/code-review.md

@@ -0,0 +1,339 @@
+---
+title: Code Review Process
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Code Review Process
+
+Understand how code reviews work in Apache Superset and how to participate effectively.
+
+## Overview
+
+Code review is a critical part of maintaining code quality and sharing knowledge across the team. Every change to Superset goes through peer review before merging.
+
+## For Authors
+
+### Preparing for Review
+
+#### Before Requesting Review
+- [ ] Self-review your changes
+- [ ] Ensure CI checks pass
+- [ ] Add comprehensive tests
+- [ ] Update documentation
+- [ ] Fill out PR template completely
+- [ ] Add screenshots for UI changes
+
+#### Self-Review Checklist
+```bash
+# View your changes
+git diff upstream/master
+
+# Check for common issues:
+# - Commented out code
+# - Debug statements (console.log, print)
+# - TODO comments that should be addressed
+# - Hardcoded values that should be configurable
+# - Missing error handling
+# - Performance implications
+```
+
+### Requesting Review
+
+#### Auto-Assignment
+GitHub will automatically request reviews based on CODEOWNERS file.
+
+#### Manual Assignment
+For specific expertise, request additional reviewers:
+- Frontend changes: Tag frontend experts
+- Backend changes: Tag backend experts
+- Security changes: Tag security team
+- Database changes: Tag database experts
+
+#### Review Request Message
+```markdown
+@reviewer This PR implements [feature]. Could you please review:
+1. The approach taken in [file]
+2. Performance implications of [change]
+3. Security considerations for [feature]
+
+Thanks!
+```
+
+### Responding to Feedback
+
+#### Best Practices
+- **Be receptive**: Reviews improve code quality
+- **Ask questions**: Clarify if feedback is unclear
+- **Explain decisions**: Share context for your choices
+- **Update promptly**: Address feedback in timely manner
+
+#### Comment Responses
+```markdown
+# Acknowledging
+"Good catch! Fixed in [commit hash]"
+
+# Explaining
+"I chose this approach because [reason]. Would you prefer [alternative]?"
+
+# Questioning
+"Could you elaborate on [concern]? I'm not sure I understand the issue."
+
+# Disagreeing respectfully
+"I see your point, but I think [current approach] because [reason]. What do you think?"
+```
+
+## For Reviewers
+
+### Review Responsibilities
+
+#### What to Review
+1. **Correctness**: Does the code do what it claims?
+2. **Design**: Is the approach appropriate?
+3. **Clarity**: Is the code readable and maintainable?
+4. **Testing**: Are tests comprehensive?
+5. **Performance**: Any performance concerns?
+6. **Security**: Any security issues?
+7. **Documentation**: Is it well documented?
+
+### Review Checklist
+
+#### Functionality
+- [ ] Feature works as described
+- [ ] Edge cases are handled
+- [ ] Error handling is appropriate
+- [ ] Backwards compatibility maintained
+
+#### Code Quality
+- [ ] Follows project conventions
+- [ ] No code duplication
+- [ ] Clear variable/function names
+- [ ] Appropriate abstraction levels
+- [ ] SOLID principles followed
+
+#### Testing
+- [ ] Unit tests for business logic
+- [ ] Integration tests for APIs
+- [ ] E2E tests for critical paths
+- [ ] Tests are maintainable
+- [ ] Good test coverage
+
+#### Security
+- [ ] Input validation
+- [ ] SQL injection prevention
+- [ ] XSS prevention
+- [ ] CSRF protection
+- [ ] Authentication/authorization checks
+- [ ] No sensitive data in logs
+
+#### Performance
+- [ ] Database queries optimized
+- [ ] No N+1 queries
+- [ ] Appropriate caching
+- [ ] Frontend bundle size impact
+- [ ] Memory usage considerations
+
+### Providing Feedback
+
+#### Effective Comments
+
+```python
+# ✅ Good: Specific and actionable
+"This query could cause N+1 problems. Consider using
+`select_related('user')` to fetch users in a single query."
+
+# ❌ Bad: Vague
+"This doesn't look right."
+```
+
+```typescript
+// ✅ Good: Suggests improvement
+"Consider using useMemo here to prevent unnecessary
+re-renders when dependencies haven't changed."
+
+// ❌ Bad: Just criticism
+"This is inefficient."
+```
+
+#### Comment Types
+
+**Use GitHub's comment types:**
+- **Comment**: General feedback or questions
+- **Approve**: Changes look good
+- **Request Changes**: Must be addressed before merge
+
+**Prefix conventions:**
+- `nit:` Minor issue (non-blocking)
+- `suggestion:` Recommended improvement
+- `question:` Seeking clarification
+- `blocker:` Must be fixed
+- `praise:` Highlighting good work
+
+#### Examples
+
+```markdown
+nit: Consider renaming `getData` to `fetchUserData` for clarity
+
+suggestion: This could be simplified using Array.reduce()
+
+question: Is this intentionally not handling the error case?
+
+blocker: This SQL is vulnerable to injection. Please use parameterized queries.
+
+praise: Excellent test coverage! 👍
+```
+
+## Review Process
+
+### Timeline
+
+#### Expected Response Times
+- **Initial review**: Within 2-3 business days
+- **Follow-up review**: Within 1-2 business days
+- **Critical fixes**: ASAP (tag in Slack)
+
+#### Escalation
+If no response after 3 days:
+1. Ping reviewer in PR comments
+2. Ask in #development Slack channel
+3. Tag @apache/superset-committers
+
+### Approval Requirements
+
+#### Minimum Requirements
+- **1 approval** from a committer for minor changes
+- **2 approvals** for significant features
+- **3 approvals** for breaking changes
+
+#### Special Cases
+- **Security changes**: Require security team review
+- **API changes**: Require API team review
+- **Database migrations**: Require database expert review
+- **UI/UX changes**: Require design review
+
+### Merge Process
+
+#### Who Can Merge
+- Committers with write access
+- After all requirements met
+- CI checks must pass
+
+#### Merge Methods
+- **Squash and merge**: Default for feature PRs
+- **Rebase and merge**: For clean history
+- **Create merge commit**: Rarely used
+
+#### Merge Checklist
+- [ ] All CI checks green
+- [ ] Required approvals obtained
+- [ ] No unresolved conversations
+- [ ] PR title follows conventions
+- [ ] Milestone set (if applicable)
+
+## Review Etiquette
+
+### Do's
+- ✅ Be kind and constructive
+- ✅ Acknowledge time and effort
+- ✅ Provide specific examples
+- ✅ Suggest solutions
+- ✅ Praise good work
+- ✅ Consider cultural differences
+- ✅ Focus on the code, not the person
+
+### Don'ts
+- ❌ Use harsh or dismissive language
+- ❌ Bikeshed on minor preferences
+- ❌ Review when tired or frustrated
+- ❌ Make personal attacks
+- ❌ Ignore the PR description
+- ❌ Demand perfection
+
+## Becoming a Reviewer
+
+### Path to Reviewer
+1. **Contribute regularly**: Submit quality PRs
+2. **Participate in discussions**: Share knowledge
+3. **Review others' code**: Start with comments
+4. **Build expertise**: Focus on specific areas
+5. **Get nominated**: By existing committers
+
+### Reviewer Expectations
+- Review PRs in your area of expertise
+- Respond within reasonable time
+- Mentor new contributors
+- Maintain high standards
+- Stay current with best practices
+
+## Advanced Topics
+
+### Reviewing Large PRs
+
+#### Strategy
+1. **Request splitting**: Ask to break into smaller PRs
+2. **Review in phases**:
+   - Architecture/approach first
+   - Implementation details second
+   - Tests and docs last
+3. **Use draft reviews**: Save comments and submit together
+
+### Cross-Team Reviews
+
+#### When Needed
+- Changes affecting multiple teams
+- Shared components/libraries
+- API contract changes
+- Database schema changes
+
+### Performance Reviews
+
+#### Tools
+```python
+# Backend performance
+import cProfile
+import pstats
+
+# Profile the code
+cProfile.run('function_to_profile()', 'stats.prof')
+stats = pstats.Stats('stats.prof')
+stats.sort_stats('cumulative').print_stats(10)
+```
+
+```typescript
+// Frontend performance
+// Use React DevTools Profiler
+// Chrome DevTools Performance tab
+// Lighthouse audits
+```
+
+## Resources
+
+### Internal
+- [Coding Guidelines](../coding-guidelines/overview)
+- [Testing Guide](../testing/overview)
+- [Architecture Overview](../architecture/overview)
+
+### External
+- [Google's Code Review Guide](https://google.github.io/eng-practices/review/)
+- [Best Practices for Code Review](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/)
+- [The Art of Readable Code](https://www.oreilly.com/library/view/the-art-of/9781449318482/)
+
+Next: [Reporting issues effectively](./issue-reporting)

docs/developer_portal/contributing/guidelines.md

@@ -0,0 +1,415 @@
+---
+title: Contribution Guidelines
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Contribution Guidelines
+
+## Pull Request Guidelines
+
+A philosophy we would like to strongly encourage is
+
+> Before creating a PR, create an issue.
+
+The purpose is to separate problem from possible solutions.
+
+**Bug fixes:** If you're only fixing a small bug, it's fine to submit a pull request right away but we highly recommend filing an issue detailing what you're fixing. This is helpful in case we don't accept that specific fix but want to keep track of the issue. Please keep in mind that the project maintainers reserve the rights to accept or reject incoming PRs, so it is better to separate the issue and the code to fix it from each other. In some cases, project maintainers may request you to create a separate issue from PR before proceeding.
+
+**Refactor:** For small refactors, it can be a standalone PR itself detailing what you are refactoring and why. If there are concerns, project maintainers may request you to create a `#SIP` for the PR before proceeding.
+
+**Feature/Large changes:** If you intend to change the public API, or make any non-trivial changes to the implementation, we require you to file a new issue as `#SIP` (Superset Improvement Proposal). This lets us reach an agreement on your proposal before you put significant effort into it. You are welcome to submit a PR along with the SIP (sometimes necessary for demonstration), but we will not review/merge the code until the SIP is approved.
+
+In general, small PRs are always easier to review than large PRs. The best practice is to break your work into smaller independent PRs and refer to the same issue. This will greatly reduce turnaround time.
+
+If you wish to share your work which is not ready to merge yet, create a [Draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/). This will enable maintainers and the CI runner to prioritize mature PR's.
+
+Finally, never submit a PR that will put master branch in broken state. If the PR is part of multiple PRs to complete a large feature and cannot work on its own, you can create a feature branch and merge all related PRs into the feature branch before creating a PR from feature branch to master.
+
+### Protocol
+
+#### Authoring
+
+- Fill in all sections of the PR template.
+- Title the PR with one of the following semantic prefixes (inspired by [Karma](http://karma-runner.github.io/0.10/dev/git-commit-msg.html])):
+
+  - `feat` (new feature)
+  - `fix` (bug fix)
+  - `docs` (changes to the documentation)
+  - `style` (formatting, missing semi colons, etc; no application logic change)
+  - `refactor` (refactoring code)
+  - `test` (adding missing tests, refactoring tests; no application logic change)
+  - `chore` (updating tasks etc; no application logic change)
+  - `perf` (performance-related change)
+  - `build` (build tooling, Docker configuration change)
+  - `ci` (test runner, GitHub Actions workflow changes)
+  - `other` (changes that don't correspond to the above -- should be rare!)
+  - Examples:
+    - `feat: export charts as ZIP files`
+    - `perf(api): improve API info performance`
+    - `fix(chart-api): cached-indicator always shows value is cached`
+
+- Add prefix `[WIP]` to title if not ready for review (WIP = work-in-progress). We recommend creating a PR with `[WIP]` first and remove it once you have passed CI test and read through your code changes at least once.
+- If you believe your PR contributes a potentially breaking change, put a `!` after the semantic prefix but before the colon in the PR title, like so: `feat!: Added foo functionality to bar`
+- **Screenshots/GIFs:** Changes to user interface require before/after screenshots, or GIF for interactions
+  - Recommended capture tools ([Kap](https://getkap.co/), [LICEcap](https://www.cockos.com/licecap/), [Skitch](https://download.cnet.com/Skitch/3000-13455_4-189876.html))
+  - If no screenshot is provided, the committers will mark the PR with `need:screenshot` label and will not review until screenshot is provided.
+- **Dependencies:** Be careful about adding new dependency and avoid unnecessary dependencies.
+  - For Python, include it in `pyproject.toml` denoting any specific restrictions and
+    in `requirements.txt` pinned to a specific version which ensures that the application
+    build is deterministic.
+  - For TypeScript/JavaScript, include new libraries in `package.json`
+- **Tests:** The pull request should include tests, either as doctests, unit tests, or both. Make sure to resolve all errors and test failures. See [Testing](./howtos#testing) for how to run tests.
+- **Documentation:** If the pull request adds functionality, the docs should be updated as part of the same PR.
+- **CI:** Reviewers will not review the code until all CI tests are passed. Sometimes there can be flaky tests. You can close and open PR to re-run CI test. Please report if the issue persists. After the CI fix has been deployed to `master`, please rebase your PR.
+- **Code coverage:** Please ensure that code coverage does not decrease.
+- Remove `[WIP]` when ready for review. Please note that it may be merged soon after approved so please make sure the PR is ready to merge and do not expect more time for post-approval edits.
+- If the PR was not ready for review and inactive for > 30 days, we will close it due to inactivity. The author is welcome to re-open and update.
+
+#### Reviewing
+
+- Use constructive tone when writing reviews.
+- If there are changes required, state clearly what needs to be done before the PR can be approved.
+- If you are asked to update your pull request with some changes there's no need to create a new one. Push your changes to the same branch.
+- The committers reserve the right to reject any PR and in some cases may request the author to file an issue.
+
+#### Test Environments
+
+- Members of the Apache GitHub org can launch an ephemeral test environment directly on a pull request by creating a comment containing (only) the command `/testenv up`.
+  - Note that org membership must be public in order for this validation to function properly.
+- Feature flags may be set for a test environment by specifying the flag name (prefixed with `FEATURE_`) and value after the command.
+  - Format: `/testenv up FEATURE_<feature flag name>=true|false`
+  - Example: `/testenv up FEATURE_DASHBOARD_NATIVE_FILTERS=true`
+  - Multiple feature flags may be set in single command, separated by whitespace
+- A comment will be created by the workflow script with the address and login information for the ephemeral environment.
+- Test environments may be created once the Docker build CI workflow for the PR has completed successfully.
+- Test environments do not currently update automatically when new commits are added to a pull request.
+- Test environments do not currently support async workers, though this is planned.
+- Running test environments will be shutdown upon closing the pull request.
+
+You can also access per-PR ephemeral environment directly using the following URL pattern:
+`https://pr-{PR_NUMBER}.superset.apache.org`
+
+#### Merging
+
+- At least one approval is required for merging a PR.
+- PR is usually left open for at least 24 hours before merging.
+- After the PR is merged, [close the corresponding issue(s)](https://help.github.com/articles/closing-issues-using-keywords/).
+
+#### Post-merge Responsibility
+
+- Project maintainers may contact the PR author if new issues are introduced by the PR.
+- Project maintainers may revert your changes if a critical issue is found, such as breaking master branch CI.
+
+## Managing Issues and PRs
+
+To handle issues and PRs that are coming in, committers read issues/PRs and flag them with labels to categorize and help contributors spot where to take actions, as contributors usually have different expertises.
+
+Triaging goals
+
+- **For issues:** Categorize, screen issues, flag required actions from authors.
+- **For PRs:** Categorize, flag required actions from authors. If PR is ready for review, flag required actions from reviewers.
+
+First, add **Category labels (a.k.a. hash labels)**. Every issue/PR must have one hash label (except spam entry). Labels that begin with `#` defines issue/PR type:
+
+| Label           | for Issue                                                                                                               | for PR                                                                                                                                            |
+| --------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `#bug`          | Bug report                                                                                                              | Bug fix                                                                                                                           |
+| `#code-quality` | Describe problem with code, architecture or productivity                                                                | Refactor, tests, tooling                                                                                                          |
+| `#feature`      | New feature request                                                                                                     | New feature implementation                                                                                                        |
+| `#refine`       | Propose improvement such as adjusting padding or refining UI style, excluding new features, bug fixes, and refactoring. | Implementation of improvement such as adjusting padding or refining UI style, excluding new features, bug fixes, and refactoring. |
+| `#doc`          | Documentation                                                                                                           | Documentation                                                                                                                     |
+| `#question`     | Troubleshooting: Installation, Running locally, Ask how to do something. Can be changed to `#bug` later.                | N/A                                                                                                                               |
+| `#SIP`          | Superset Improvement Proposal                                                                                           | N/A                                                                                                                               |
+| `#ASF`          | Tasks related to Apache Software Foundation policy                                                                      | Tasks related to Apache Software Foundation policy                                                                                |
+
+Then add other types of labels as appropriate.
+
+- **Descriptive labels (a.k.a. dot labels):** These labels that begin with `.` describe the details of the issue/PR, such as `.ui`, `.js`, `.install`, `.backend`, etc. Each issue/PR can have zero or more dot labels.
+- **Need labels:** These labels have pattern `need:xxx`, which describe the work required to progress, such as `need:rebase`, `need:update`, `need:screenshot`.
+- **Risk labels:** These labels have pattern `risk:xxx`, which describe the potential risk on adopting the work, such as `risk:db-migration`. The intention was to better understand the impact and create awareness for PRs that need more rigorous testing.
+- **Status labels:** These labels describe the status (`abandoned`, `wontfix`, `cant-reproduce`, etc.) Issue/PRs that are rejected or closed without completion should have one or more status labels.
+- **Version labels:** These have the pattern `vx.x` such as `v0.28`. Version labels on issues describe the version the bug was reported on. Version labels on PR describe the first release that will include the PR.
+
+Committers may also update title to reflect the issue/PR content if the author-provided title is not descriptive enough.
+
+If the PR passes CI tests and does not have any `need:` labels, it is ready for review, add label `review` and/or `design-review`.
+
+If an issue/PR has been inactive for at least 30 days, it will be closed. If it does not have any status label, add `inactive`.
+
+When creating a PR, if you're aiming to have it included in a specific release, please tag it with the version label. For example, to have a PR considered for inclusion in Superset 1.1 use the label `v1.1`.
+
+## Revert Guidelines
+
+Reverting changes that are causing issues in the master branch is a normal and expected part of the development process. In an open source community, the ramifications of a change cannot always be fully understood. With that in mind, here are some considerations to keep in mind when considering a revert:
+
+- **Availability of the PR author:** If the original PR author or the engineer who merged the code is highly available and can provide a fix in a reasonable time frame, this would counter-indicate reverting.
+- **Severity of the issue:** How severe is the problem on master? Is it keeping the project from moving forward? Is there user impact? What percentage of users will experience a problem?
+- **Size of the change being reverted:** Reverting a single small PR is a much lower-risk proposition than reverting a massive, multi-PR change.
+- **Age of the change being reverted:** Reverting a recently-merged PR will be more acceptable than reverting an older PR. A bug discovered in an older PR is unlikely to be causing widespread serious issues.
+- **Risk inherent in reverting:** Will the reversion break critical functionality? Is the medicine more dangerous than the disease?
+- **Difficulty of crafting a fix:** In the case of issues with a clear solution, it may be preferable to implement and merge a fix rather than a revert.
+
+Should you decide that reverting is desirable, it is the responsibility of the Contributor performing the revert to:
+
+- **Contact the interested parties:** The PR's author and the engineer who merged the work should both be contacted and informed of the revert.
+- **Provide concise reproduction steps:** Ensure that the issue can be clearly understood and duplicated by the original author of the PR.
+- **Put the revert through code review:** The revert must be approved by another committer.
+
+**Revert liberally to keep `master` stable**:
+- Build failures
+- Test failures
+- Critical bugs in production
+- Security vulnerabilities
+
+**How to revert**:
+1. Use GitHub's revert button when possible
+2. Create a PR with clear explanation
+3. Tag the original author
+4. Work with them on a fix
+
+## Design Guidelines
+
+### Capitalization Guidelines
+
+#### Sentence case
+
+Use sentence-case capitalization for everything in the UI (except these **).
+
+Sentence case is predominantly lowercase. Capitalize only the initial character of the first word, and other words that require capitalization, like:
+
+- **Proper nouns.** Objects in the product _are not_ considered proper nouns e.g. dashboards, charts, saved queries etc. Proprietary feature names eg. SQL Lab, Preset Manager _are_ considered proper nouns
+- **Acronyms** (e.g. CSS, HTML)
+- When referring to **UI labels that are themselves capitalized** from sentence case (e.g. page titles - Dashboards page, Charts page, Saved queries page, etc.)
+- User input that is reflected in the UI. E.g. a user-named a dashboard tab
+
+**Sentence case vs. Title case:**
+Title case: "A Dog Takes a Walk in Paris"
+Sentence case: "A dog takes a walk in Paris"
+
+**Why sentence case?**
+
+- It's generally accepted as the quickest to read
+- It's the easiest form to distinguish between common and proper nouns
+
+**Good examples:**
+- "Select a database"
+- "Create new chart"
+- "View all dashboards"
+
+**Bad examples:**
+- "Select a Database"
+- "Create New Chart"
+- "View All Dashboards"
+
+#### How to refer to UI elements
+
+When writing about a UI element, use the same capitalization as used in the UI.
+
+For example, if an input field is labeled "Name" then you refer to this as the "Name input field". Similarly, if a button has the label "Save" in it, then it is correct to refer to the "Save button".
+
+Where a product page is titled "Settings", you refer to this in writing as follows:
+"Edit your personal information on the Settings page".
+
+Often a product page will have the same title as the objects it contains. In this case, refer to the page as it appears in the UI, and the objects as common nouns:
+
+- Upload a dashboard on the Dashboards page
+- Go to Dashboards
+- View dashboard
+- View all dashboards
+- Upload CSS templates on the CSS templates page
+- Queries that you save will appear on the Saved queries page
+- Create custom queries in SQL Lab then create dashboards
+
+When writing about UI elements:
+- Use **bold** for clickable elements: "Click **Save**"
+- Use quotes for text fields: 'Enter "My Dashboard" in the name field'
+- Be specific about element types: button, link, dropdown, etc.
+
+#### **Exceptions to sentence case
+
+Only use title case for:
+- Product names (Apache Superset)
+- Proper nouns
+- Acronyms (SQL, API, CSV)
+- Input labels, buttons and UI tabs are all caps
+- User input values (e.g. column names, SQL Lab tab names) should be in their original case
+
+## Programming Language Conventions
+
+### Python
+
+We use:
+- **[Ruff](https://docs.astral.sh/ruff/)** for linting and formatting
+- **[Mypy](http://mypy-lang.org/)** for type checking
+
+Python code should:
+- Follow PEP 8
+- Use type hints for all new code
+- Use descriptive variable names
+- Include docstrings for modules, classes, and functions
+- Handle exceptions appropriately
+- Avoid global variables
+
+Parameters in the `config.py` (which are accessible via the Flask app.config dictionary) are
+assumed to always be defined and thus should be accessed directly via,
+
+```python
+blueprints = app.config["BLUEPRINTS"]
+```
+
+rather than,
+
+```python
+blueprints = app.config.get("BLUEPRINTS")
+```
+
+or similar as the later will cause typing issues. The former is of type `List[Callable]`
+whereas the later is of type `Optional[List[Callable]]`.
+
+#### Typing / Type Hints
+
+All new Python code should include type hints:
+
+To ensure clarity, consistency, all readability, _all_ new functions should use
+[type hints](https://docs.python.org/3/library/typing.html) and include a
+docstring.
+
+Note per [PEP-484](https://www.python.org/dev/peps/pep-0484/#exceptions) no
+syntax for listing explicitly raised exceptions is proposed and thus the
+recommendation is to put this information in a docstring, i.e.,
+
+```python
+import math
+from typing import List, Optional, Dict, Any, Union
+
+
+def sqrt(x: Union[float, int]) -> Union[float, int]:
+    """
+    Return the square root of x.
+
+    :param x: A number
+    :returns: The square root of the given number
+    :raises ValueError: If the number is negative
+    """
+
+    return math.sqrt(x)
+
+
+def process_data(
+    data: List[Dict[str, Any]],
+    filter_empty: bool = True
+) -> Optional[Dict[str, Any]]:
+    """
+    Process a list of data dictionaries.
+
+    Args:
+        data: List of dictionaries containing data
+        filter_empty: Whether to filter empty entries
+
+    Returns:
+        Processed data dictionary or None if no valid data
+    """
+    if not data:
+        return None
+
+    # Process data...
+    return processed_data
+```
+
+Use `mypy` to check types:
+```bash
+mypy superset
+```
+
+### TypeScript
+
+We use:
+- **ESLint** for linting
+- **Prettier** for formatting  
+- **TypeScript** strict mode
+
+TypeScript is fully supported and is the recommended language for writing all new frontend
+components. When modifying existing functions/components, migrating to TypeScript is
+appreciated, but not required. Examples of migrating functions/components to TypeScript can be
+found in [#9162](https://github.com/apache/superset/pull/9162) and [#9180](https://github.com/apache/superset/pull/9180).
+
+TypeScript code should:
+- Avoid `any` types - use proper TypeScript types
+- Use functional components with hooks for React
+- Include JSDoc comments for complex functions
+- Use consistent naming conventions
+- Handle errors appropriately
+
+Example:
+```typescript
+interface User {
+  id: number;
+  name: string;
+  email?: string;
+}
+
+export function processUser(user: User): string {
+  // Avoid using 'any'
+  const { name, email } = user;
+  return email ? `${name} <${email}>` : name;
+}
+```
+
+## Additional Guidelines
+
+### Commit Messages
+
+- Use clear, descriptive commit messages
+- Start with a verb in imperative mood
+- Reference issue numbers when applicable
+
+Good: "Fix dashboard filter bug when dataset is deleted"
+Bad: "Fixed stuff"
+
+### Code Review Etiquette
+
+- Be respectful and constructive
+- Focus on the code, not the person
+- Provide specific suggestions for improvement
+- Acknowledge good work
+- Be open to different approaches
+
+### Documentation
+
+- Update docs for any user-facing changes
+- Include code examples where helpful
+- Keep language clear and concise
+- Test documentation changes locally
+
+### Security
+
+- Never commit secrets or credentials
+- Validate all user input
+- Use parameterized queries for SQL
+- Follow OWASP guidelines
+- Report security issues privately to private@superset.apache.org
+
+## Questions?
+
+If you have questions about these guidelines, ask in:
+- [Slack #development](https://apache-superset.slack.com)
+- [GitHub Discussions](https://github.com/apache/superset/discussions)

docs/developer_portal/contributing/howtos.md

@@ -0,0 +1,528 @@
+---
+title: Development How-tos
+sidebar_position: 7
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Development How-tos
+
+This guide contains specific instructions for common development tasks in Superset.
+
+## Contributing to Documentation
+
+The documentation site is built using [Docusaurus](https://docusaurus.io/). All documentation lives in the `docs` folder, written in Markdown format.
+
+### Local Development
+
+To set up your local environment for documentation development:
+
+```bash
+cd docs
+npm install
+npm run start
+```
+
+The site will be available at http://localhost:3000
+
+### Build
+
+To create a production build:
+
+```bash
+npm run build
+npm run serve  # Test the build locally
+```
+
+### Deployment
+
+Documentation is automatically deployed when changes are merged to master.
+
+## Creating Visualization Plugins
+
+Visualization plugins allow you to add custom chart types to Superset. They are built as npm packages that integrate with the Superset frontend.
+
+### Prerequisites
+
+- Node.js 18+
+- npm or yarn
+- A local Superset development environment
+
+### Creating a simple Hello World viz plugin
+
+1. **Install the Superset Yeoman generator**:
+```bash
+npm install -g @superset-ui/generator-superset
+```
+
+2. **Create a new plugin**:
+```bash
+mkdir superset-plugin-chart-hello-world
+cd superset-plugin-chart-hello-world
+yo @superset-ui/superset
+```
+
+3. **Follow the prompts**:
+- Package name: `superset-plugin-chart-hello-world`
+- Chart type: Choose your preferred type
+- Include storybook: Yes (recommended for development)
+
+4. **Develop your plugin**:
+The generator creates a complete plugin structure with TypeScript, React components, and build configuration.
+
+5. **Test your plugin locally**:
+```bash
+npm run dev
+```
+
+6. **Link to your local Superset**:
+```bash
+npm link
+# In your Superset frontend directory:
+npm link superset-plugin-chart-hello-world
+```
+
+7. **Import and register in Superset**:
+Edit `superset-frontend/src/visualizations/presets/MainPreset.js` to include your plugin.
+
+## Testing
+
+### Python Testing
+
+Run Python tests using pytest:
+
+```bash
+# Run all tests
+pytest
+
+# Run specific test file
+pytest tests/unit_tests/test_specific.py
+
+# Run with coverage
+pytest --cov=superset
+
+# Run only unit tests
+pytest tests/unit_tests
+
+# Run only integration tests  
+pytest tests/integration_tests
+```
+
+#### Testing with local Presto connections
+
+To test against Presto:
+
+```bash
+# Start Presto locally using Docker
+docker run -p 8080:8080 \
+  --name presto \
+  -d prestodb/presto
+
+# Configure in superset_config.py
+SQLALCHEMY_DATABASE_URI = 'presto://localhost:8080/hive/default'
+```
+
+### Frontend Testing
+
+Run frontend tests using Jest:
+
+```bash
+cd superset-frontend
+
+# Run all tests
+npm run test
+
+# Run with coverage
+npm run test -- --coverage
+
+# Run in watch mode
+npm run test -- --watch
+
+# Run specific test file
+npm run test -- MyComponent.test.tsx
+```
+
+### E2E Integration Testing
+
+We support both Playwright (recommended) and Cypress for end-to-end testing.
+
+#### Playwright (Recommended - NEW)
+
+Playwright is our new E2E testing framework, gradually replacing Cypress.
+
+```bash
+# Navigate to frontend directory
+cd superset-frontend
+
+# Run all Playwright tests
+npm run playwright:test
+# or: npx playwright test
+
+# Run with interactive UI for debugging
+npm run playwright:ui
+# or: npx playwright test --ui
+
+# Run in headed mode (see browser)
+npm run playwright:headed
+# or: npx playwright test --headed
+
+# Run specific test file
+npx playwright test tests/auth/login.spec.ts
+
+# Run with debug mode (step through tests)
+npm run playwright:debug tests/auth/login.spec.ts
+# or: npx playwright test --debug tests/auth/login.spec.ts
+
+# Generate test report
+npm run playwright:report
+```
+
+#### Cypress (DEPRECATED - will be removed)
+
+Cypress is being phased out in favor of Playwright but is still available:
+
+```bash
+# Set base URL for Cypress
+export CYPRESS_BASE_URL='http://localhost:8088'
+export CYPRESS_DATABASE=test
+export CYPRESS_USERNAME=admin
+export CYPRESS_PASSWORD=admin
+
+# Navigate to Cypress directory
+cd superset-frontend/cypress-base
+
+# Run interactively
+npm run cypress-debug
+
+# Run headless (like CI)
+npm run cypress-run-chrome
+
+# Run specific file
+npm run cypress-run-chrome -- --spec "cypress/e2e/dashboard/dashboard.test.ts"
+```
+
+### Debugging Server App
+
+For debugging the Flask backend:
+
+#### Using PyCharm/IntelliJ
+
+1. Create a new Python configuration
+2. Set script path to `superset/app.py`
+3. Set environment variables:
+   - `FLASK_ENV=development`
+   - `SUPERSET_CONFIG_PATH=/path/to/superset_config.py`
+4. Set breakpoints and run in debug mode
+
+#### Using VS Code
+
+1. Add to `.vscode/launch.json`:
+```json
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "name": "Python: Flask",
+      "type": "python",
+      "request": "launch",
+      "module": "flask",
+      "env": {
+        "FLASK_APP": "superset/app.py",
+        "FLASK_ENV": "development"
+      },
+      "args": ["run", "--no-debugger", "--no-reload"],
+      "jinja": true
+    }
+  ]
+}
+```
+
+2. Set breakpoints and press F5 to debug
+
+### Storybook
+
+Storybook is used for developing and testing UI components in isolation:
+
+```bash
+cd superset-frontend
+
+# Start Storybook
+npm run storybook
+
+# Build static Storybook
+npm run build-storybook
+```
+
+Access Storybook at http://localhost:6006
+
+## Contributing Translations
+
+Superset uses Flask-Babel for internationalization.
+
+### Enabling language selection
+
+Edit `superset_config.py`:
+
+```python
+LANGUAGES = {
+    'en': {'flag': 'us', 'name': 'English'},
+    'fr': {'flag': 'fr', 'name': 'French'},
+    'zh': {'flag': 'cn', 'name': 'Chinese'},
+}
+```
+
+### Creating a new language dictionary
+
+```bash
+# Initialize a new language
+pybabel init -i superset/translations/messages.pot -d superset/translations -l de
+```
+
+### Extracting new strings for translation
+
+```bash
+# Extract Python strings
+pybabel extract -F babel.cfg -o superset/translations/messages.pot -k lazy_gettext superset
+
+# Extract JavaScript strings
+npm run build-translation
+```
+
+### Updating language files
+
+```bash
+# Update all language files with new strings
+pybabel update -i superset/translations/messages.pot -d superset/translations
+```
+
+### Applying translations
+
+```bash
+# Frontend
+cd superset-frontend
+npm run build-translation
+
+# Backend
+pybabel compile -d superset/translations
+```
+
+## Linting
+
+### Python
+
+We use Ruff for Python linting and formatting:
+
+```bash
+# Auto-format using ruff
+ruff format .
+
+# Lint check with ruff
+ruff check .
+
+# Lint fix with ruff
+ruff check --fix .
+```
+
+Pre-commit hooks run automatically on `git commit` if installed.
+
+### TypeScript
+
+We use ESLint and Prettier for TypeScript:
+
+```bash
+cd superset-frontend
+
+# Run eslint checks
+npm run lint
+
+# Run tsc (typescript) checks
+npm run type
+
+# Fix lint issues
+npm run lint-fix
+
+# Format with Prettier
+npm run prettier
+```
+
+## GitHub Ephemeral Environments
+
+For every PR, an ephemeral environment is automatically deployed for testing.
+
+Access pattern: `https://pr-{PR_NUMBER}.superset.apache.org`
+
+Features:
+- Automatically deployed on PR creation/update
+- Includes sample data
+- Destroyed when PR is closed
+- Useful for UI/UX review
+
+## Tips and Tricks
+
+### Using Docker for Development
+
+```bash
+# Rebuild specific service
+docker compose build superset
+
+# View logs
+docker compose logs -f superset
+
+# Execute commands in container
+docker compose exec superset bash
+
+# Reset database
+docker compose down -v
+docker compose up
+```
+
+### Hot Reloading
+
+**Frontend**: Webpack dev server provides hot module replacement automatically.
+
+**Backend**: Use Flask debug mode:
+```bash
+FLASK_ENV=development superset run -p 8088 --with-threads --reload
+```
+
+### Performance Profiling
+
+For Python profiling:
+```python
+# In superset_config.py
+PROFILING = True
+```
+
+For React profiling:
+- Use React DevTools Profiler
+- Enable performance marks in Chrome DevTools
+
+### Database Migrations
+
+```bash
+# Create a new migration
+superset db migrate -m "Description of changes"
+
+# Apply migrations
+superset db upgrade
+
+# Downgrade
+superset db downgrade
+```
+
+### Useful Aliases
+
+Add to your shell profile:
+
+```bash
+alias sdev='FLASK_ENV=development superset run -p 8088 --with-threads --reload'
+alias stest='pytest tests/unit_tests'
+alias slint='pre-commit run --all-files'
+alias sfront='cd superset-frontend && npm run dev-server'
+```
+
+## Common Issues and Solutions
+
+### Node/npm Issues
+
+```bash
+# Clear npm cache
+npm cache clean --force
+
+# Reinstall dependencies
+rm -rf node_modules package-lock.json
+npm install
+```
+
+### Python Environment Issues
+
+```bash
+# Recreate virtual environment
+deactivate
+rm -rf venv
+python3 -m venv venv
+source venv/bin/activate
+pip install -r requirements/development.txt
+pip install -e .
+```
+
+### Database Issues
+
+```bash
+# Reset local database
+superset db downgrade -r base
+superset db upgrade
+superset init
+```
+
+### Port Already in Use
+
+```bash
+# Find process using port
+lsof -i :8088
+# Kill process
+kill -9 [PID]
+```
+
+## Reporting Security Vulnerabilities
+
+Please report security vulnerabilities to **private@superset.apache.org**.
+
+In the event a community member discovers a security flaw in Superset, it is important to follow the [Apache Security Guidelines](https://www.apache.org/security/committers.html) and release a fix as quickly as possible before public disclosure. Reporting security vulnerabilities through the usual GitHub Issues channel is not ideal as it will publicize the flaw before a fix can be applied.
+
+## SQL Lab Async Configuration
+
+It's possible to configure a local database to operate in `async` mode, to work on `async` related features.
+
+To do this, you'll need to:
+
+- Add an additional database entry. We recommend you copy the connection string from the database labeled `main`, and then enable `SQL Lab` and the features you want to use. Don't forget to check the `Async` box
+- Configure a results backend, here's a local `FileSystemCache` example, not recommended for production, but perfect for testing (stores cache in `/tmp`)
+
+  ```python
+  from flask_caching.backends.filesystemcache import FileSystemCache
+  RESULTS_BACKEND = FileSystemCache('/tmp/sqllab')
+  ```
+
+- Start up a celery worker
+
+  ```bash
+  celery --app=superset.tasks.celery_app:app worker -O fair
+  ```
+
+Note that:
+- for changes that affect the worker logic, you'll have to restart the `celery worker` process for the changes to be reflected.
+- The message queue used is a `sqlite` database using the `SQLAlchemy` experimental broker. Ok for testing, but not recommended in production
+- In some cases, you may want to create a context that is more aligned to your production environment, and use the similar broker as well as results backend configuration
+
+## Async Chart Queries
+
+It's possible to configure database queries for charts to operate in `async` mode. This is especially useful for dashboards with many charts that may otherwise be affected by browser connection limits. To enable async queries for dashboards and Explore, the following dependencies are required:
+
+- Redis 5.0+ (the feature utilizes [Redis Streams](https://redis.io/topics/streams-intro))
+- Cache backends enabled via the `CACHE_CONFIG` and `DATA_CACHE_CONFIG` config settings
+- Celery workers configured and running to process async tasks
+
+## Need Help?
+
+- Check the [FAQ](https://superset.apache.org/docs/frequently-asked-questions)
+- Ask in [Slack](https://apache-superset.slack.com)
+- Search [GitHub Issues](https://github.com/apache/superset/issues)
+- Post in [GitHub Discussions](https://github.com/apache/superset/discussions)

docs/developer_portal/contributing/issue-reporting.md

@@ -0,0 +1,418 @@
+---
+title: Issue Reporting
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Issue Reporting
+
+Learn how to effectively report bugs and request features for Apache Superset.
+
+## Before Opening an Issue
+
+### Pre-Issue Checklist
+
+1. **Search Existing Issues**
+   ```
+   Search: https://github.com/apache/superset/issues
+   - Use keywords from your error message
+   - Check both open and closed issues
+   - Look for similar problems
+   ```
+
+2. **Check Documentation**
+   - [User Documentation](https://superset.apache.org/docs/intro)
+   - [FAQ](https://superset.apache.org/docs/frequently-asked-questions)
+   - [Configuration Guide](https://superset.apache.org/docs/configuration/configuring-superset)
+
+3. **Verify Version**
+   ```bash
+   # Check Superset version
+   superset version
+
+   # Try latest version
+   pip install --upgrade apache-superset
+   ```
+
+4. **Reproduce Consistently**
+   - Can you reproduce the issue?
+   - Does it happen every time?
+   - What specific actions trigger it?
+
+## Bug Reports
+
+### Bug Report Template
+
+```markdown
+### Bug Description
+A clear and concise description of the bug.
+
+### How to Reproduce
+1. Go to '...'
+2. Click on '...'
+3. Scroll down to '...'
+4. See error
+
+### Expected Behavior
+What you expected to happen.
+
+### Actual Behavior
+What actually happened. Include error messages.
+
+### Screenshots/Videos
+If applicable, add screenshots or recordings.
+
+### Environment
+- Superset version: [e.g., 3.0.0]
+- Python version: [e.g., 3.9.7]
+- Node version: [e.g., 18.17.0]
+- Database: [e.g., PostgreSQL 14]
+- Browser: [e.g., Chrome 120]
+- OS: [e.g., Ubuntu 22.04]
+
+### Additional Context
+- Using Docker: Yes/No
+- Configuration overrides:
+- Feature flags enabled:
+- Authentication method:
+```
+
+### What Makes a Good Bug Report
+
+#### ✅ Good Example
+```markdown
+### Bug Description
+When filtering a dashboard with a date range filter, charts using
+SQL Lab datasets don't update, while charts using regular datasets do.
+
+### How to Reproduce
+1. Create a dashboard with 2 charts:
+   - Chart A: Uses a SQL Lab virtual dataset
+   - Chart B: Uses a regular table dataset
+2. Add a date range filter (last 30 days)
+3. Apply the filter
+4. Chart B updates, Chart A shows no change
+
+### Expected Behavior
+Both charts should filter to show last 30 days of data.
+
+### Actual Behavior
+Only Chart B updates. Chart A still shows all data.
+No error messages in browser console or server logs.
+
+### Screenshots
+[Dashboard before filter]: attachment1.png
+[Dashboard after filter]: attachment2.png
+[Network tab showing requests]: attachment3.png
+
+### Environment
+- Superset version: 3.0.0
+- Python version: 3.9.16
+- Database: PostgreSQL 14.9
+- Browser: Chrome 120.0.6099.71
+- OS: macOS 14.2
+```
+
+#### ❌ Poor Example
+```markdown
+Dashboard filters don't work. Please fix.
+```
+
+### Required Information
+
+#### Error Messages
+```python
+# Include full error traceback
+Traceback (most recent call last):
+  File "...", line X, in function
+    error details
+SupersetException: Detailed error message
+```
+
+#### Logs
+```bash
+# Backend logs
+docker logs superset_app 2>&1 | tail -100
+
+# Or from development
+tail -f ~/.superset/superset.log
+```
+
+#### Browser Console
+```javascript
+// Include JavaScript errors
+// Chrome: F12 → Console tab
+// Include network errors
+// Chrome: F12 → Network tab
+```
+
+#### Configuration
+```python
+# Relevant config from superset_config.py
+FEATURE_FLAGS = {
+    "ENABLE_TEMPLATE_PROCESSING": True,
+    # ... other flags
+}
+```
+
+## Feature Requests
+
+### Feature Request Template
+
+```markdown
+### Is your feature request related to a problem?
+A clear description of the problem you're trying to solve.
+
+### Describe the solution you'd like
+A clear description of what you want to happen.
+
+### Describe alternatives you've considered
+Other solutions or features you've considered.
+
+### Additional context
+Any other context, mockups, or examples.
+
+### Are you willing to contribute?
+- [ ] Yes, I can implement this feature
+- [ ] Yes, I can help test
+- [ ] No, but I can provide feedback
+```
+
+### Good Feature Requests Include
+
+1. **Clear Use Case**
+   ```markdown
+   As a [type of user], I want [feature] so that [benefit].
+
+   Example:
+   As a data analyst, I want to schedule dashboard screenshots
+   so that I can automatically send reports to stakeholders.
+   ```
+
+2. **Mockups/Designs**
+   - UI mockups
+   - Workflow diagrams
+   - API specifications
+
+3. **Impact Analysis**
+   - Who benefits?
+   - How many users affected?
+   - Performance implications?
+
+## Security Issues
+
+### 🔴 IMPORTANT: Security Vulnerabilities
+
+**DO NOT** create public issues for security vulnerabilities!
+
+Instead:
+1. Email: security@apache.org
+2. Subject: `[Superset] Security Vulnerability`
+3. Include:
+   - Description of vulnerability
+   - Steps to reproduce
+   - Potential impact
+   - Suggested fix (if any)
+
+### Security Issue Template
+
+```markdown
+Send to: security@apache.org
+
+### Vulnerability Description
+[Describe the security issue]
+
+### Type
+- [ ] SQL Injection
+- [ ] XSS
+- [ ] CSRF
+- [ ] Authentication Bypass
+- [ ] Information Disclosure
+- [ ] Other: [specify]
+
+### Affected Versions
+[List affected versions]
+
+### Steps to Reproduce
+[Detailed steps - be specific]
+
+### Impact
+[What can an attacker do?]
+
+### Suggested Fix
+[If you have suggestions]
+```
+
+## Issue Labels
+
+### Priority Labels
+- `P0`: Critical - System unusable
+- `P1`: High - Major feature broken
+- `P2`: Medium - Important but workaround exists
+- `P3`: Low - Nice to have
+
+### Type Labels
+- `bug`: Something isn't working
+- `feature`: New feature request
+- `enhancement`: Improvement to existing feature
+- `documentation`: Documentation improvements
+- `question`: Question about usage
+
+### Component Labels
+- `dashboard`: Dashboard functionality
+- `sqllab`: SQL Lab
+- `explore`: Chart builder
+- `visualization`: Chart types
+- `api`: REST API
+- `security`: Security related
+
+### Status Labels
+- `needs-triage`: Awaiting review
+- `confirmed`: Bug confirmed
+- `in-progress`: Being worked on
+- `blocked`: Blocked by dependency
+- `stale`: No activity for 30+ days
+
+## Issue Lifecycle
+
+### 1. Creation
+- User creates issue with template
+- Auto-labeled as `needs-triage`
+
+### 2. Triage
+- Maintainer reviews within 7 days
+- Labels applied (priority, type, component)
+- Questions asked if needed
+
+### 3. Confirmation
+- Bug reproduced or feature discussed
+- Label changed to `confirmed`
+- Assigned to milestone if applicable
+
+### 4. Development
+- Contributor claims issue
+- Label changed to `in-progress`
+- PR linked to issue
+
+### 5. Resolution
+- PR merged
+- Issue auto-closed
+- Or manually closed with explanation
+
+## Following Up
+
+### If No Response
+
+After 7 days without response:
+```markdown
+@apache/superset-committers This issue hasn't been triaged yet.
+Could someone please take a look?
+```
+
+### Providing Updates
+
+```markdown
+Update: I found that this only happens when [condition].
+Here's additional debugging information: [details]
+```
+
+### Issue Staleness
+
+- Bot marks stale after 30 days of inactivity
+- Closes after 7 more days without activity
+- To keep open: Comment with updates
+
+## Tips for Success
+
+### Do's
+- ✅ Search before creating
+- ✅ Use templates
+- ✅ Provide complete information
+- ✅ Include screenshots/videos
+- ✅ Be responsive to questions
+- ✅ Test with latest version
+- ✅ One issue per report
+
+### Don'ts
+- ❌ "+1" or "me too" comments (use reactions)
+- ❌ Multiple issues in one report
+- ❌ Vague descriptions
+- ❌ Screenshots of text (copy/paste instead)
+- ❌ Private/sensitive data in reports
+- ❌ Demanding immediate fixes
+
+## Useful Commands
+
+### Gathering System Info
+
+```bash
+# Full environment info
+python -c "
+import sys
+import superset
+import sqlalchemy
+import pandas
+import numpy
+
+print(f'Python: {sys.version}')
+print(f'Superset: {superset.__version__}')
+print(f'SQLAlchemy: {sqlalchemy.__version__}')
+print(f'Pandas: {pandas.__version__}')
+print(f'NumPy: {numpy.__version__}')
+"
+
+# Database versions
+superset shell
+>>> from superset import db
+>>> print(db.engine.dialect.server_version_info)
+```
+
+### Creating Minimal Reproductions
+
+```python
+# Create test script
+# minimal_repro.py
+from superset import create_app
+
+app = create_app()
+with app.app_context():
+    # Your reproduction code here
+    pass
+```
+
+## Getting Help
+
+### Before Creating an Issue
+
+1. **Slack**: Ask in #troubleshooting
+2. **GitHub Discussions**: Search/ask questions
+3. **Stack Overflow**: Tag `apache-superset`
+4. **Mailing List**: user@superset.apache.org
+
+### Issue Not a Bug?
+
+Consider:
+- **Feature Request**: Use feature request template
+- **Question**: Use GitHub Discussions
+- **Configuration Help**: Ask in Slack
+- **Development Help**: See [Contributing Guide](./overview)
+
+Next: [Understanding the release process](./release-process)

docs/developer_portal/contributing/overview.md

@@ -0,0 +1,166 @@
+---
+title: Contributing Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Contributing to Apache Superset
+
+Superset is an [Apache Software foundation](https://www.apache.org/theapacheway/index.html) project.
+The core contributors (or committers) to Superset communicate primarily in the following channels (which can be joined by anyone):
+
+- [Mailing list](https://lists.apache.org/list.html?dev@superset.apache.org)
+- [Apache Superset Slack community](http://bit.ly/join-superset-slack)
+- [GitHub issues](https://github.com/apache/superset/issues)
+- [GitHub pull requests](https://github.com/apache/superset/pulls)
+- [GitHub discussions](https://github.com/apache/superset/discussions)
+- [Superset Community Calendar](https://superset.apache.org/community)
+
+More references:
+
+- [Superset Wiki (code guidelines and additional resources)](https://github.com/apache/superset/wiki)
+
+## Orientation
+
+Here's a list of repositories that contain Superset-related packages:
+
+- [apache/superset](https://github.com/apache/superset)
+  is the main repository containing the `apache_superset` Python package
+  distributed on
+  [pypi](https://pypi.org/project/apache_superset/). This repository
+  also includes Superset's main TypeScript/JavaScript bundles and react apps under
+  the [superset-frontend](https://github.com/apache/superset/tree/master/superset-frontend)
+  folder.
+- [github.com/apache-superset](https://github.com/apache-superset) is the
+  GitHub organization under which we manage Superset-related
+  small tools, forks and Superset-related experimental ideas.
+
+## Types of Contributions
+
+### Report Bug
+
+The best way to report a bug is to file an issue on GitHub. Please include:
+
+- Your operating system name and version.
+- Superset version.
+- Detailed steps to reproduce the bug.
+- Any details about your local setup that might be helpful in troubleshooting.
+
+When posting Python stack traces, please quote them using
+[Markdown blocks](https://help.github.com/articles/creating-and-highlighting-code-blocks/).
+
+_Please note that feature requests opened as GitHub Issues will be moved to Discussions._
+
+### Submit Ideas or Feature Requests
+
+The best way is to start an ["Ideas" Discussion thread](https://github.com/apache/superset/discussions/categories/ideas) on GitHub:
+
+- Explain in detail how it would work.
+- Keep the scope as narrow as possible, to make it easier to implement.
+- Remember that this is a volunteer-driven project, and that your contributions are as welcome as anyone's :)
+
+To propose large features or major changes to codebase, and help usher in those changes, please create a **Superset Improvement Proposal (SIP)**. See template from [SIP-0](https://github.com/apache/superset/issues/5602)
+
+### Fix Bugs
+
+Look through the GitHub issues. Issues tagged with `#bug` are
+open to whoever wants to implement them.
+
+### Implement Features
+
+Look through the GitHub issues. Issues tagged with
+`#feature` are open to whoever wants to implement them.
+
+### Improve Documentation
+
+Superset could always use better documentation,
+whether as part of the official Superset docs,
+in docstrings, `docs/*.rst` or even on the web as blog posts or
+articles. See [Documentation](./howtos#contributing-to-documentation) for more details.
+
+### Add Translations
+
+If you are proficient in a non-English language, you can help translate
+text strings from Superset's UI. You can jump into the existing
+language dictionaries at
+`superset/translations/<language_code>/LC_MESSAGES/messages.po`, or
+even create a dictionary for a new language altogether.
+See [Translating](./howtos#contributing-translations) for more details.
+
+### Ask Questions
+
+There is a dedicated [`apache-superset` tag](https://stackoverflow.com/questions/tagged/apache-superset) on [StackOverflow](https://stackoverflow.com/). Please use it when asking questions.
+
+## Types of Contributors
+
+Following the project governance model of the Apache Software Foundation (ASF), Apache Superset has a specific set of contributor roles:
+
+### PMC Member
+
+A Project Management Committee (PMC) member is a person who has been elected by the PMC to help manage the project. PMC members are responsible for the overall health of the project, including community development, release management, and project governance. PMC members are also responsible for the technical direction of the project.
+
+For more information about Apache Project PMCs, please refer to https://www.apache.org/foundation/governance/pmcs.html
+
+### Committer
+
+A committer is a person who has been elected by the PMC to have write access (commit access) to the code repository. They can modify the code, documentation, and website and accept contributions from others.
+
+The official list of committers and PMC members can be found [here](https://projects.apache.org/committee.html?superset).
+
+### Contributor
+
+A contributor is a person who has contributed to the project in any way, including but not limited to code, tests, documentation, issues, and discussions.
+
+> You can also review the Superset project's guidelines for PMC member promotion here: https://github.com/apache/superset/wiki/Guidelines-for-promoting-Superset-Committers-to-the-Superset-PMC
+
+### Security Team
+
+The security team is a selected subset of PMC members, committers and non-committers who are responsible for handling security issues.
+
+New members of the security team are selected by the PMC members in a vote. You can request to be added to the team by sending a message to private@superset.apache.org. However, the team should be small and focused on solving security issues, so the requests will be evaluated on a case-by-case basis and the team size will be kept relatively small, limited to only actively security-focused contributors.
+
+This security team must follow the [ASF vulnerability handling process](https://apache.org/security/committers.html#asf-project-security-for-committers).
+
+Each new security issue is tracked as a JIRA ticket on the [ASF's JIRA Superset security project](https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=588&projectKey=SUPERSETSEC)
+
+Security team members must:
+
+- Have an [ICLA](https://www.apache.org/licenses/contributor-agreements.html) signed with Apache Software Foundation.
+- Not reveal information about pending and unfixed security issues to anyone (including their employers) unless specifically authorised by the security team members, e.g., if the security team agrees that diagnosing and solving an issue requires the involvement of external experts.
+
+A release manager, the contributor overseeing the release of a specific version of Apache Superset, is by default a member of the security team.  However, they are not expected to be active in assessing, discussing, and fixing security issues.
+
+Security team members should also follow these general expectations:
+
+- Actively participate in assessing, discussing, fixing, and releasing security issues in Superset.
+- Avoid discussing security fixes in public forums. Pull request (PR) descriptions should not contain any information about security issues. The corresponding JIRA ticket should contain a link to the PR.
+- Security team members who contribute to a fix may be listed as remediation developers in the CVE report, along with their job affiliation (if they choose to include it).
+
+## Getting Started
+
+Ready to contribute? Here's how to get started:
+
+1. **[Set up your environment](./development-setup)** - Get Superset running locally
+2. **[Find something to work on](#types-of-contributions)** - Pick an issue or feature
+3. **[Submit your contribution](./submitting-pr)** - Create a pull request
+4. **[Follow guidelines](./guidelines)** - Ensure code quality
+
+Welcome to the Apache Superset community! 🚀

docs/developer_portal/contributing/release-process.md

@@ -0,0 +1,469 @@
+---
+title: Release Process
+sidebar_position: 6
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Release Process
+
+Understand Apache Superset's release process, versioning strategy, and how to participate.
+
+## Release Cadence
+
+### Schedule
+- **Major releases (X.0.0)**: Annually (approximately)
+- **Minor releases (X.Y.0)**: Quarterly
+- **Patch releases (X.Y.Z)**: As needed for critical fixes
+
+### Version Numbering
+
+Superset follows [Semantic Versioning](https://semver.org/):
+
+```
+MAJOR.MINOR.PATCH
+  ↓      ↓     ↓
+  │      │     └── Bug fixes, security patches
+  │      └────── New features, backwards compatible
+  └──────────── Breaking changes
+```
+
+### Examples
+- `3.0.0`: Major release with breaking changes
+- `3.1.0`: Minor release with new features
+- `3.1.1`: Patch release with bug fixes
+
+## Release Types
+
+### Major Releases (X.0.0)
+
+#### Includes
+- Breaking API changes
+- Deprecated feature removals
+- Major architectural changes
+- Database migration requirements
+
+#### Process
+- 2-3 month preparation period
+- Multiple release candidates (RC)
+- Extensive testing period
+- Migration guides required
+
+### Minor Releases (X.Y.0)
+
+#### Includes
+- New features
+- Performance improvements
+- Non-breaking API additions
+- Minor UI/UX updates
+
+#### Process
+- 1 month preparation
+- 1-2 release candidates
+- Standard testing period
+
+### Patch Releases (X.Y.Z)
+
+#### Includes
+- Bug fixes
+- Security patches
+- Documentation fixes
+- Dependency updates (security)
+
+#### Process
+- Fast track for critical issues
+- May skip RC for urgent security fixes
+- Minimal testing requirements
+
+## Release Process (For Release Managers)
+
+### 1. Pre-Release Preparation
+
+#### Feature Freeze
+```bash
+# Create release branch
+git checkout -b release-X.Y
+git push upstream release-X.Y
+
+# Update version
+# Edit setup.py and package.json
+VERSION = "X.Y.0rc1"
+```
+
+#### Update Documentation
+- CHANGELOG.md
+- UPDATING.md (for breaking changes)
+- Documentation version
+
+#### Release Notes Template
+```markdown
+# Apache Superset X.Y.0
+
+## 🎉 Highlights
+- Major feature 1
+- Major feature 2
+
+## 🚀 New Features
+- Feature 1 (#PR)
+- Feature 2 (#PR)
+
+## 🐛 Bug Fixes
+- Fix 1 (#PR)
+- Fix 2 (#PR)
+
+## ⚠️ Breaking Changes
+- Breaking change 1
+- Migration required for X
+
+## 📝 Documentation
+- Doc update 1 (#PR)
+
+## 🙏 Thank You
+Thanks to all contributors!
+```
+
+### 2. Create Release Candidate
+
+#### Build RC
+```bash
+# Tag release candidate
+git tag -a vX.Y.Zrc1 -m "Apache Superset X.Y.Z RC1"
+git push upstream vX.Y.Zrc1
+
+# Build source distribution
+python setup.py sdist
+
+# Build wheel
+python setup.py bdist_wheel
+
+# Sign artifacts
+gpg --armor --detach-sig dist/apache-superset-X.Y.Zrc1.tar.gz
+```
+
+#### Upload to staging
+```bash
+# Upload to Apache staging
+svn co https://dist.apache.org/repos/dist/dev/superset
+cd superset
+mkdir X.Y.Zrc1
+cp /path/to/dist/* X.Y.Zrc1/
+svn add X.Y.Zrc1
+svn commit -m "Add Apache Superset X.Y.Z RC1"
+```
+
+### 3. Voting Process
+
+#### Call for Vote Email
+
+Send to dev@superset.apache.org:
+
+```
+Subject: [VOTE] Release Apache Superset X.Y.Z RC1
+
+Hi all,
+
+I'd like to call a vote to release Apache Superset version X.Y.Z RC1.
+
+The release candidate:
+- Git tag: vX.Y.Zrc1
+- Git hash: abc123def456
+- Source: https://dist.apache.org/repos/dist/dev/superset/X.Y.Zrc1/
+
+Resources:
+- Release notes: [link]
+- CHANGELOG: [link]
+- PR list: [link]
+
+The vote will be open for at least 72 hours.
+
+[ ] +1 approve
+[ ] +0 no opinion
+[ ] -1 disapprove (and reason why)
+
+Thanks,
+[Your name]
+```
+
+#### Voting Rules
+- **Duration**: Minimum 72 hours
+- **Required**: 3 +1 votes from PMC members
+- **Veto**: Any -1 vote must be addressed
+
+#### Testing Checklist
+```markdown
+- [ ] Source builds successfully
+- [ ] Docker image builds
+- [ ] Basic functionality works
+- [ ] No critical bugs
+- [ ] License check passes
+- [ ] Security scan clean
+```
+
+### 4. Release Approval
+
+#### Tally Votes
+```
+Subject: [RESULT][VOTE] Release Apache Superset X.Y.Z RC1
+
+The vote to release Apache Superset X.Y.Z RC1 has passed.
+
++1 votes (binding):
+- PMC Member 1
+- PMC Member 2
+- PMC Member 3
+
++1 votes (non-binding):
+- Contributor 1
+- Contributor 2
+
+0 votes:
+- None
+
+-1 votes:
+- None
+
+Thank you to everyone who tested and voted!
+```
+
+### 5. Perform Release
+
+#### Promote RC to Release
+```bash
+# Tag final release
+git tag -a vX.Y.Z -m "Apache Superset X.Y.Z"
+git push upstream vX.Y.Z
+
+# Move from dev to release
+svn mv https://dist.apache.org/repos/dist/dev/superset/X.Y.Zrc1 \
+       https://dist.apache.org/repos/dist/release/superset/X.Y.Z
+```
+
+#### Publish to PyPI
+```bash
+# Upload to PyPI
+python -m twine upload dist/*X.Y.Z*
+```
+
+#### Build Docker Images
+```bash
+# Build and push Docker images
+docker build -t apache/superset:X.Y.Z .
+docker push apache/superset:X.Y.Z
+docker tag apache/superset:X.Y.Z apache/superset:latest
+docker push apache/superset:latest
+```
+
+### 6. Post-Release Tasks
+
+#### Update Documentation
+```bash
+# Update docs version
+cd docs
+# Update docusaurus.config.js with new version
+npm run build
+```
+
+#### Announcement Email
+
+Send to announce@apache.org, dev@superset.apache.org:
+
+```
+Subject: [ANNOUNCE] Apache Superset X.Y.Z Released
+
+The Apache Superset team is pleased to announce the release of
+Apache Superset X.Y.Z.
+
+Apache Superset is a modern data exploration and visualization platform.
+
+This release includes [number] commits from [number] contributors.
+
+Highlights:
+- Feature 1
+- Feature 2
+- Bug fixes and improvements
+
+Download: https://superset.apache.org/docs/installation/
+Release Notes: https://github.com/apache/superset/releases/tag/vX.Y.Z
+PyPI: https://pypi.org/project/apache-superset/
+Docker: docker pull apache/superset:X.Y.Z
+
+Thanks to all contributors who made this release possible!
+
+The Apache Superset Team
+```
+
+#### Update GitHub Release
+```bash
+# Create GitHub release
+gh release create vX.Y.Z \
+  --title "Apache Superset X.Y.Z" \
+  --notes-file RELEASE_NOTES.md
+```
+
+## For Contributors
+
+### During Feature Freeze
+
+#### What's Allowed
+- ✅ Bug fixes
+- ✅ Documentation updates
+- ✅ Test improvements
+- ✅ Security fixes
+
+#### What's Not Allowed
+- ❌ New features
+- ❌ Major refactoring
+- ❌ Breaking changes
+- ❌ Risky changes
+
+### Testing RCs
+
+#### How to Test
+```bash
+# Install RC from staging
+pip install https://dist.apache.org/repos/dist/dev/superset/X.Y.Zrc1/apache-superset-X.Y.Zrc1.tar.gz
+
+# Or use Docker
+docker pull apache/superset:X.Y.Zrc1
+```
+
+#### What to Test
+- Your use cases
+- New features mentioned in release notes
+- Upgrade from previous version
+- Database migrations
+- Critical workflows
+
+#### Reporting Issues
+```markdown
+Found issue in RC1:
+- Description: [what's wrong]
+- Steps to reproduce: [how to trigger]
+- Impact: [blocker/major/minor]
+- Suggested fix: [if known]
+```
+
+### CHANGELOG Maintenance
+
+#### Format
+```markdown
+## X.Y.Z (YYYY-MM-DD)
+
+### Features
+- feat: Description (#PR_NUMBER)
+
+### Fixes
+- fix: Description (#PR_NUMBER)
+
+### Breaking Changes
+- BREAKING: Description (#PR_NUMBER)
+  Migration: Steps to migrate
+```
+
+#### Generating CHANGELOG
+```bash
+# Use git log to generate initial list
+git log --oneline vX.Y-1.Z..vX.Y.Z | grep -E "^[a-f0-9]+ (feat|fix|perf|refactor|docs)"
+
+# Group by type and format
+```
+
+## Breaking Changes Process
+
+### Documentation Required
+
+#### UPDATING.md Entry
+```markdown
+# X.Y.Z
+
+## Breaking Change: [Title]
+
+### Description
+What changed and why.
+
+### Before
+```python
+# Old way
+old_function(param1, param2)
+```
+
+### After
+```python
+# New way
+new_function(param1, param2, param3)
+```
+
+### Migration Steps
+1. Update your code to...
+2. Run migration script...
+3. Test that...
+```
+
+### Deprecation Process
+
+1. **Version N**: Mark as deprecated
+   ```python
+   @deprecated(version="3.0.0", remove_in="4.0.0")
+   def old_function():
+       warnings.warn("Use new_function instead", DeprecationWarning)
+   ```
+
+2. **Version N+1**: Keep deprecated with warnings
+
+3. **Version N+2**: Remove completely
+
+## Security Releases
+
+### Expedited Process
+- No RC required for critical security fixes
+- Coordinate with security@apache.org
+- Embargo period may apply
+- CVE assignment through ASF security team
+
+### Security Advisory Template
+```markdown
+CVE-YYYY-XXXXX: [Title]
+
+Severity: [Critical/High/Medium/Low]
+Affected Versions: < X.Y.Z
+Fixed Version: X.Y.Z
+
+Description:
+[Vulnerability description]
+
+Mitigation:
+[How to fix or work around]
+
+Credit:
+[Reporter name/organization]
+```
+
+## Resources
+
+### Internal
+- [Apache Release Policy](https://www.apache.org/legal/release-policy.html)
+- [Superset Release History](https://github.com/apache/superset/releases)
+- [Version Strategy Discussion](https://github.com/apache/superset/discussions)
+
+### Tools
+- [Release Scripts](https://github.com/apache/superset/tree/master/scripts/release)
+- [Superset Repository Scripts](https://github.com/apache/superset/tree/master/scripts)
+
+Next: Return to [Contributing Overview](./overview)

docs/developer_portal/contributing/resources.md

@@ -0,0 +1,133 @@
+---
+title: Resources
+sidebar_position: 8
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Resources
+
+## High Level Architecture
+
+```mermaid
+flowchart TD
+
+  %% Top Level
+  LB["<b>Load Balancer(s)</b><br/>(optional)"]
+  LB -.-> WebServers
+
+  %% Web Servers
+  subgraph WebServers ["<b>Web Server(s)</b>"]
+    WS1["<b>Frontend</b><br/>(React, AntD, ECharts, AGGrid)"]
+    WS2["<b>Backend</b><br/>(Python, Flask, SQLAlchemy, Pandas, ...)"]
+  end
+
+  %% Infra
+  subgraph InfraServices ["<b>Infra</b>"]
+    DB[("<b>Metadata Database</b><br/>(Postgres / MySQL)")]
+
+    subgraph Caching ["<b>Caching Subservices<br/></b>(Redis, memcache, S3, ...)"]
+      direction LR
+      DummySpace[" "]:::invisible
+      QueryCache["<b>Query Results Cache</b><br/>(Accelerated Dashboards)"]
+      CsvCache["<b>CSV Exports Cache</b>"]
+      ThumbnailCache["<b>Thumbnails Cache</b>"]
+      AlertImageCache["<b>Alert/Report Images Cache</b>"]
+	  QueryCache -- " " --> CsvCache
+	  linkStyle 1 stroke:transparent;
+      ThumbnailCache -- " " --> AlertImageCache
+	  linkStyle 2 stroke:transparent;
+    end
+
+    Broker(("<b>Message Queue</b><br/>(Redis / RabbitMQ / SQS)"))
+  end
+
+  AsyncBackend["<b>Async Workers (Celery)</b><br>required for Alerts & Reports, thumbnails, CSV exports, long-running workloads, ..."]
+
+  %% External DBs
+  subgraph ExternalDatabases ["<b>Analytics Databases</b>"]
+    direction LR
+    BigQuery[(BigQuery)]
+    Snowflake[(Snowflake)]
+    Redshift[(Redshift)]
+    Postgres[(Postgres)]
+    Postgres[(... any ...)]
+  end
+
+  %% Connections
+  LB -.-> WebServers
+  WebServers --> DB
+  WebServers -.-> Caching
+  WebServers -.-> Broker
+  WebServers -.-> ExternalDatabases
+
+  Broker -.-> AsyncBackend
+
+  AsyncBackend -.-> ExternalDatabases
+  AsyncBackend -.-> Caching
+
+
+
+  %% Legend styling
+  classDef requiredNode stroke-width:2px,stroke:black;
+  class Required requiredNode;
+  class Optional optionalNode;
+
+  %% Hide real arrow
+  linkStyle 0 stroke:transparent;
+
+  %% Styling
+  classDef optionalNode stroke-dasharray: 5 5, opacity:0.9;
+  class LB optionalNode;
+  class Caching optionalNode;
+  class AsyncBackend optionalNode;
+  class Broker optionalNode;
+  class QueryCache optionalNode;
+  class CsvCache optionalNode;
+  class ThumbnailCache optionalNode;
+  class AlertImageCache optionalNode;
+  class Celery optionalNode;
+
+  classDef invisible fill:transparent,stroke:transparent;
+```
+
+## Entity-Relationship Diagram
+
+For the full interactive Entity-Relationship Diagram, please visit the [main documentation](https://superset.apache.org/docs/contributing/resources).
+
+You can also [download the .svg](https://github.com/apache/superset/tree/master/docs/static/img/erd.svg) directly from GitHub.
+
+## Additional Resources
+
+### Official Documentation
+- [Apache Superset Documentation](https://superset.apache.org/docs/intro)
+- [API Documentation](https://superset.apache.org/docs/api)
+- [Configuration Guide](https://superset.apache.org/docs/installation/configuring-superset)
+
+### Community Resources
+- [Apache Superset Blog](https://preset.io/blog/)
+- [YouTube Channel](https://www.youtube.com/channel/UCMuwrvBsg_jjI2gLcm04R0g)
+- [Twitter/X](https://twitter.com/ApacheSuperset)
+
+### Development Tools
+- [GitHub Repository](https://github.com/apache/superset)
+- [PyPI Package](https://pypi.org/project/apache-superset/)
+- [Docker Hub](https://hub.docker.com/r/apache/superset)
+- [npm Packages](https://www.npmjs.com/search?q=%40superset-ui)

docs/developer_portal/contributing/submitting-pr.md

@@ -0,0 +1,321 @@
+---
+title: Submitting Pull Requests
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Submitting Pull Requests
+
+Learn how to create and submit high-quality pull requests to Apache Superset.
+
+## Before You Start
+
+### Prerequisites
+- [ ] Development environment is set up
+- [ ] You've forked and cloned the repository
+- [ ] You've read the [contributing overview](./overview)
+- [ ] You've found or created an issue to work on
+
+### PR Readiness Checklist
+- [ ] Code follows [coding guidelines](../coding-guidelines/overview)
+- [ ] Tests are passing locally
+- [ ] Linting passes (`pre-commit run --all-files`)
+- [ ] Documentation is updated if needed
+
+## Creating Your Pull Request
+
+### 1. Create a Feature Branch
+
+```bash
+# Update your fork
+git fetch upstream
+git checkout master
+git merge upstream/master
+git push origin master
+
+# Create feature branch
+git checkout -b feature/your-feature-name
+```
+
+### 2. Make Your Changes
+
+```bash
+# Make changes
+edit files...
+
+# Run tests
+pytest tests/unit_tests/
+cd superset-frontend && npm run test
+
+# Run linting
+pre-commit run --all-files
+
+# Commit with conventional format
+git add .
+git commit -m "feat(dashboard): add new filter component"
+```
+
+### 3. PR Title Format
+
+Follow [Conventional Commits](https://www.conventionalcommits.org/):
+
+```
+type(scope): description
+```
+
+**Types:**
+- `feat`: New feature
+- `fix`: Bug fix
+- `docs`: Documentation only
+- `style`: Code style (formatting, semicolons, etc.)
+- `refactor`: Code refactoring
+- `perf`: Performance improvement
+- `test`: Adding tests
+- `chore`: Maintenance tasks
+- `ci`: CI/CD changes
+- `build`: Build system changes
+- `revert`: Reverting changes
+
+**Scopes:**
+- `dashboard`: Dashboard functionality
+- `sqllab`: SQL Lab features
+- `explore`: Chart explorer
+- `chart`: Visualization components
+- `api`: REST API endpoints
+- `db`: Database connections
+- `security`: Security features
+- `config`: Configuration
+
+**Examples:**
+```
+feat(sqllab): add query cost estimation
+fix(dashboard): resolve filter cascading issue
+docs(api): update REST endpoint documentation
+refactor(explore): simplify chart controls logic
+perf(dashboard): optimize chart loading
+```
+
+### 4. PR Description Template
+
+Use the template from `.github/PULL_REQUEST_TEMPLATE.md`:
+
+```markdown
+### SUMMARY
+Brief description of changes and motivation.
+
+### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
+[Required for UI changes]
+
+### TESTING INSTRUCTIONS
+1. Step-by-step instructions
+2. How to verify the fix/feature
+3. Any specific test scenarios
+
+### ADDITIONAL INFORMATION
+- [ ] Has associated issue: #12345
+- [ ] Required feature flags:
+- [ ] API changes:
+- [ ] DB migration required:
+
+### CHECKLIST
+- [ ] CI checks pass
+- [ ] Tests added/updated
+- [ ] Documentation updated
+- [ ] PR title follows conventions
+```
+
+### 5. Submit the PR
+
+```bash
+# Push to your fork
+git push origin feature/your-feature-name
+
+# Create PR via GitHub CLI
+gh pr create --title "feat(sqllab): add query cost estimation" \
+  --body-file .github/PULL_REQUEST_TEMPLATE.md
+
+# Or use the GitHub web interface
+```
+
+## PR Best Practices
+
+### Keep PRs Focused
+- One feature/fix per PR
+- Break large changes into smaller PRs
+- Separate refactoring from feature changes
+
+### Write Good Commit Messages
+```bash
+# Good
+git commit -m "fix(dashboard): prevent duplicate API calls when filters change"
+
+# Bad
+git commit -m "fix bug"
+git commit -m "updates"
+```
+
+### Include Tests
+```python
+# Backend test example
+def test_new_feature():
+    """Test that new feature works correctly."""
+    result = new_feature_function()
+    assert result == expected_value
+```
+
+```typescript
+// Frontend test example
+test('renders new component', () => {
+  const { getByText } = render(<NewComponent />);
+  expect(getByText('Expected Text')).toBeInTheDocument();
+});
+```
+
+### Add Screenshots for UI Changes
+```markdown
+### Before
+![Before](link-to-before-screenshot)
+
+### After  
+![After](link-to-after-screenshot)
+```
+
+### Update Documentation
+- Update relevant docs in `/docs` directory
+- Add docstrings to new functions/classes
+- Update UPDATING.md for breaking changes
+
+## CI Checks
+
+### Required Checks
+All PRs must pass:
+- `Python Tests` - Backend unit/integration tests
+- `Frontend Tests` - JavaScript/TypeScript tests
+- `Linting` - Code style checks
+- `Type Checking` - MyPy and TypeScript
+- `License Check` - Apache license headers
+- `Documentation Build` - Docs compile successfully
+
+### Common CI Failures
+
+#### Python Test Failures
+```bash
+# Run locally to debug
+pytest tests/unit_tests/ -v
+pytest tests/integration_tests/ -v
+```
+
+#### Frontend Test Failures
+```bash
+cd superset-frontend
+npm run test -- --coverage
+```
+
+#### Linting Failures
+```bash
+# Auto-fix many issues
+pre-commit run --all-files
+
+# Manual fixes may be needed for:
+# - MyPy type errors
+# - Complex ESLint issues
+# - License headers
+```
+
+## Responding to Reviews
+
+### Address Feedback Promptly
+```bash
+# Make requested changes
+edit files...
+
+# Add commits (don't amend during review)
+git add .
+git commit -m "fix: address review feedback"
+git push origin feature/your-feature-name
+```
+
+### Request Re-review
+- Click "Re-request review" after addressing feedback
+- Comment on resolved discussions
+- Thank reviewers for their time
+
+### Handling Conflicts
+```bash
+# Update your branch
+git fetch upstream
+git rebase upstream/master
+
+# Resolve conflicts
+edit conflicted files...
+git add .
+git rebase --continue
+
+# Force push (only to your feature branch!)
+git push --force-with-lease origin feature/your-feature-name
+```
+
+## After Merge
+
+### Clean Up
+```bash
+# Delete local branch
+git checkout master
+git branch -d feature/your-feature-name
+
+# Delete remote branch
+git push origin --delete feature/your-feature-name
+
+# Update your fork
+git fetch upstream
+git merge upstream/master
+git push origin master
+```
+
+### Follow Up
+- Monitor for any issues reported
+- Help with documentation if needed
+- Consider related improvements
+
+## Tips for Success
+
+### Do
+- ✅ Keep PRs small and focused
+- ✅ Write descriptive PR titles and descriptions
+- ✅ Include tests for new functionality
+- ✅ Respond to feedback constructively
+- ✅ Update documentation
+- ✅ Be patient with the review process
+
+### Don't
+- ❌ Submit PRs with failing tests
+- ❌ Include unrelated changes
+- ❌ Force push to master
+- ❌ Ignore CI failures
+- ❌ Skip the PR template
+
+## Getting Help
+
+- **Slack**: Ask in #development or #beginners
+- **GitHub**: Tag @apache/superset-committers for attention
+- **Mailing List**: dev@superset.apache.org
+
+Next: [Understanding code review process](./code-review)

docs/developer_portal/examples/index.md

@@ -1,464 +0,0 @@
----
-title: Extension Examples
-sidebar_position: 1
-hide_title: true
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-# Extension Examples
-
-Learn from real-world extension implementations that showcase different capabilities of the Superset extension system.
-
-## Dataset References Panel
-
-A SQL Lab panel that analyzes queries and displays information about referenced tables.
-
-### Features
-- Parses SQL to extract table references
-- Shows table owners and permissions
-- Displays last partition information
-- Provides row count estimates
-
-### Key Implementation
-
-```typescript
-// Parse SQL and extract tables
-function extractTables(sql: string): TableReference[] {
-  const tables = [];
-  const tableRegex = /FROM\s+(\w+\.?\w+)/gi;
-  let match;
-
-  while ((match = tableRegex.exec(sql)) !== null) {
-    tables.push({
-      schema: match[1].split('.')[0],
-      table: match[1].split('.')[1] || match[1],
-    });
-  }
-
-  return tables;
-}
-
-// Register panel
-export function activate(context: ExtensionContext) {
-  const panel = context.core.registerView('dataset-references.panel', () => (
-    <DatasetReferencesPanel />
-  ));
-
-  // Listen for query changes
-  const listener = context.sqlLab.onDidChangeEditorContent((content) => {
-    const tables = extractTables(content);
-    updatePanelWithTables(tables);
-  });
-
-  context.subscriptions.push(panel, listener);
-}
-```
-
-### Manifest
-
-```json
-{
-  "name": "dataset-references",
-  "contributions": {
-    "views": {
-      "sqllab.panels": [{
-        "id": "dataset-references.panel",
-        "name": "Dataset References",
-        "icon": "DatabaseOutlined",
-        "location": "right"
-      }]
-    }
-  }
-}
-```
-
-## Query Optimizer
-
-Analyzes SQL queries and suggests optimizations.
-
-### Features
-- Detects missing indexes
-- Suggests query rewrites
-- Identifies expensive operations
-- Provides execution plan analysis
-
-### Implementation Highlights
-
-```typescript
-// Register optimization command
-const optimizeCommand = context.commands.registerCommand('query-optimizer.analyze', {
-  title: 'Analyze Query Performance',
-  icon: 'ThunderboltOutlined',
-  execute: async () => {
-    const query = context.sqlLab.getCurrentQuery();
-    const database = context.sqlLab.getCurrentDatabase();
-
-    // Get execution plan
-    const plan = await getExecutionPlan(database.id, query);
-
-    // Analyze and suggest improvements
-    const suggestions = analyzeExecutionPlan(plan);
-
-    // Show results in panel
-    showOptimizationResults(suggestions);
-  }
-});
-
-// Add to editor menu
-"menus": {
-  "sqllab.editor": {
-    "primary": [{
-      "command": "query-optimizer.analyze",
-      "when": "editorHasContent"
-    }]
-  }
-}
-```
-
-## Natural Language to SQL
-
-Converts natural language questions to SQL queries using LLM integration.
-
-### Features
-- Natural language input
-- Context-aware SQL generation
-- Query validation
-- History tracking
-
-### Key Components
-
-```typescript
-// Backend API endpoint
-@rest_api.route('/nl2sql/generate')
-def generate_sql(prompt: str, context: dict):
-    # Use LLM to generate SQL
-    sql = llm_client.generate(
-        prompt=prompt,
-        schema=context['schema'],
-        examples=context['examples']
-    )
-
-    # Validate generated SQL
-    validation = validate_sql(sql)
-
-    return {
-        'sql': sql,
-        'valid': validation.is_valid,
-        'errors': validation.errors
-    }
-```
-
-```typescript
-// Frontend integration
-function NL2SQLPanel() {
-  const [prompt, setPrompt] = useState('');
-  const [loading, setLoading] = useState(false);
-
-  const generateSQL = async () => {
-    setLoading(true);
-
-    const response = await context.network.api.post('/extensions/nl2sql/generate', {
-      prompt,
-      context: {
-        database: context.sqlLab.getCurrentDatabase(),
-        schema: await context.sqlLab.getCurrentSchema(),
-      }
-    });
-
-    if (response.valid) {
-      // Insert SQL into editor
-      context.sqlLab.insertText(response.sql);
-    }
-
-    setLoading(false);
-  };
-
-  return (
-    <div>
-      <Input.TextArea
-        value={prompt}
-        onChange={(e) => setPrompt(e.target.value)}
-        placeholder="Describe what data you want..."
-      />
-      <Button onClick={generateSQL} loading={loading}>
-        Generate SQL
-      </Button>
-    </div>
-  );
-}
-```
-
-## Schema Visualizer
-
-Interactive database schema visualization.
-
-### Features
-- Visual ERD diagram
-- Table relationships
-- Column details on hover
-- Export to image
-
-### Implementation
-
-```typescript
-import { Graph } from '@antv/g6';
-
-function SchemaVisualizer() {
-  const containerRef = useRef<HTMLDivElement>(null);
-  const [graph, setGraph] = useState<Graph>();
-
-  useEffect(() => {
-    if (!containerRef.current) return;
-
-    const g = new Graph({
-      container: containerRef.current,
-      layout: {
-        type: 'dagre',
-        rankdir: 'LR',
-      },
-      defaultNode: {
-        type: 'sql-table-node',
-      },
-      defaultEdge: {
-        type: 'sql-relation-edge',
-      },
-    });
-
-    setGraph(g);
-    loadSchemaData(g);
-
-    return () => g.destroy();
-  }, []);
-
-  const loadSchemaData = async (g: Graph) => {
-    const tables = await context.sqlLab.getTables();
-    const nodes = tables.map(table => ({
-      id: table.name,
-      label: table.name,
-      columns: table.columns,
-    }));
-
-    const edges = extractRelationships(tables);
-
-    g.data({ nodes, edges });
-    g.render();
-  };
-
-  return <div ref={containerRef} style={{ height: '100%' }} />;
-}
-```
-
-## SQL Formatter
-
-Formats and beautifies SQL code with customizable rules.
-
-### Features
-- Multiple formatting styles
-- Custom rule configuration
-- Batch formatting
-- Format on save
-
-### Simple Implementation
-
-```typescript
-import { format } from 'sql-formatter';
-
-const formatCommand = context.commands.registerCommand('sql-formatter.format', {
-  title: 'Format SQL',
-  execute: () => {
-    const sql = context.sqlLab.getCurrentQuery();
-
-    const formatted = format(sql, {
-      language: 'sql',
-      indent: '  ',
-      uppercase: true,
-      linesBetweenQueries: 2,
-    });
-
-    context.sqlLab.replaceQuery(formatted);
-  }
-});
-
-// Auto-format on save
-context.sqlLab.onWillSaveQuery((event) => {
-  if (context.storage.local.get('autoFormat')) {
-    const formatted = format(event.query);
-    event.waitUntil(Promise.resolve(formatted));
-  }
-});
-```
-
-## Query History Search
-
-Enhanced query history with advanced search and filtering.
-
-### Features
-- Full-text search
-- Filter by date, user, database
-- Query statistics
-- Export capabilities
-
-### UI Component
-
-```typescript
-function QueryHistoryPanel() {
-  const [queries, setQueries] = useState<Query[]>([]);
-  const [filters, setFilters] = useState<Filters>({});
-
-  useEffect(() => {
-    loadQueries();
-  }, [filters]);
-
-  const loadQueries = async () => {
-    const history = await context.network.api.get('/api/v1/query', {
-      params: {
-        ...filters,
-        page_size: 100,
-      }
-    });
-
-    setQueries(history.result);
-  };
-
-  return (
-    <div>
-      <SearchFilters onChange={setFilters} />
-      <Table
-        dataSource={queries}
-        columns={[
-          { title: 'Query', dataIndex: 'sql', ellipsis: true },
-          { title: 'Database', dataIndex: 'database' },
-          { title: 'Status', dataIndex: 'status' },
-          { title: 'Duration', dataIndex: 'duration' },
-          { title: 'User', dataIndex: 'user' },
-          {
-            title: 'Actions',
-            render: (query) => (
-              <Button
-                icon={<CopyOutlined />}
-                onClick={() => context.sqlLab.insertText(query.sql)}
-              />
-            ),
-          },
-        ]}
-      />
-    </div>
-  );
-}
-```
-
-## Git Integration
-
-Version control for SQL queries and dashboards.
-
-### Features
-- Save queries to Git
-- Track changes
-- Collaborative editing
-- Branch management
-
-### Backend Integration
-
-```python
-from git import Repo
-
-class GitExtension:
-    def __init__(self, repo_path):
-        self.repo = Repo(repo_path)
-
-    def save_query(self, query, message):
-        # Save query to file
-        path = f"queries/{query.name}.sql"
-        with open(path, 'w') as f:
-            f.write(query.sql)
-
-        # Commit to Git
-        self.repo.index.add([path])
-        self.repo.index.commit(message)
-
-        return {
-            'status': 'success',
-            'commit': self.repo.head.commit.hexsha
-        }
-```
-
-## Best Practices from Examples
-
-### 1. User Experience
-- Provide clear feedback for async operations
-- Handle errors gracefully
-- Include loading states
-- Add keyboard shortcuts
-
-### 2. Performance
-- Debounce expensive operations
-- Cache API responses
-- Use virtual scrolling for large lists
-- Lazy load heavy components
-
-### 3. Integration
-- Respect Superset's theme
-- Use provided UI components
-- Follow existing UX patterns
-- Integrate with existing menus
-
-### 4. Code Organization
-```
-extension/
-├── frontend/
-│   ├── src/
-│   │   ├── components/     # UI components
-│   │   ├── hooks/          # Custom hooks
-│   │   ├── services/       # API services
-│   │   ├── utils/          # Utilities
-│   │   └── index.tsx       # Entry point
-│   └── tests/
-├── backend/
-│   ├── src/
-│   │   ├── api/           # REST endpoints
-│   │   ├── models/        # Data models
-│   │   ├── services/      # Business logic
-│   │   └── entrypoint.py
-│   └── tests/
-```
-
-### 5. Testing
-```typescript
-// Test example
-describe('DatasetReferences', () => {
-  it('should extract tables from SQL', () => {
-    const sql = 'SELECT * FROM users JOIN orders ON users.id = orders.user_id';
-    const tables = extractTables(sql);
-
-    expect(tables).toEqual([
-      { schema: 'public', table: 'users' },
-      { schema: 'public', table: 'orders' },
-    ]);
-  });
-});
-```
-
-## Learn More
-
-- [API Reference](../api/frontend)
-- [Architecture Overview](../architecture/overview)
-- [Getting Started Guide](../getting-started)
-- [CLI Documentation](../cli/overview)

docs/developer_portal/extensions/architectural-principles.md

@@ -0,0 +1,36 @@
+---
+title: Architectural Principles
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Architectural Principles
+
+Realizing this vision requires a strong architectural foundation. To ensure the resulting system is robust, maintainable, and adaptable, we have defined a set of architectural principles that will guide the design and implementation of the changes. These principles serve as the basis for all technical decisions and help create an environment where extensions can be developed safely and predictably, while minimizing technical debt and fragmentation.
+
+The architectural principles guiding this proposal include:
+
+1. **Lean core**: Superset's core should remain as minimal as possible, with many features and capabilities delegated to extensions. Wherever possible, built-in features should be implemented using the same APIs and extension mechanisms available to external extension authors. This approach reduces maintenance burden and complexity in the core application, encourages modularity, and allows the community to innovate and iterate on features independently of the main codebase.
+2. **Explicit contribution points**: All extension points must be clearly defined and documented, so extension authors know exactly where and how they can interact with the host system. Each extension must also declare its capabilities in a metadata file, enabling the host to manage the extension lifecycle and provide a consistent user experience.
+3. **Versioned and stable APIs**: Public interfaces for extensions should be versioned and follow semantic versioning, allowing for safe evolution and backward compatibility.
+4. **Lazy loading and activation**: Extensions should be loaded and activated only when needed, minimizing performance overhead and resource consumption.
+5. **Composability and reuse**: The architecture should encourage the reuse of extension points and patterns across different modules, promoting consistency and reducing duplication.
+6. **Community-driven evolution**: The system should be designed to evolve based on real-world feedback and contributions, allowing new extension points and capabilities to be added as needs emerge.

docs/developer_portal/extensions/built-in-features.md

@@ -0,0 +1,36 @@
+---
+title: What This Means for Superset's Built-in Features
+sidebar_position: 13
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# What This Means for Superset's Built-in Features
+
+Transitioning to a well-defined, versioned API model has significant implications for Superset's built-in features. By exposing stable, public APIs for core functionality, we enable both extensions and internal modules to interact with the application in a consistent and predictable way. This approach brings several key benefits:
+
+- **Unified API Surface**: All important features of Superset will be accessible through documented, versioned APIs. This not only empowers extension authors but also ensures that built-in features use the same mechanisms, validating the APIs through real-world usage and making it easier to replace or enhance individual features over time.
+- **Dogfooding and Replaceability**: By building Superset's own features using the same APIs available to extensions, we ensure that these APIs are robust, flexible, and well-tested. This also means that any built-in feature can potentially be replaced or extended by a third-party extension, increasing modularity and adaptability.
+- **Versioned and Stable Contracts**: Public APIs will be versioned and follow semantic versioning, providing stability for both internal and external consumers. This stability is critical for long-term maintainability, but it also means that extra care must be taken to avoid breaking changes and to provide clear migration paths when changes are necessary.
+- **Improved Inter-Module Communication**: With clearly defined APIs and a command-based architecture, modules and extensions can communicate through explicit interfaces rather than relying on direct Redux store access or tightly coupled state management. This decouples modules, reduces the risk of unintended side effects, and makes the codebase easier to reason about and maintain.
+- **Facilitated Refactoring and Evolution**: As the application evolves, having a stable API layer allows for internal refactoring and optimization without breaking consumers. This makes it easier to modernize or optimize internal implementations while preserving compatibility.
+- **Clearer Documentation and Onboarding**: A public, versioned API surface makes it easier to document and onboard new contributors, both for core development and for extension authors.
+
+Overall, this shift represents a move toward a more modular, maintainable, and extensible architecture, where both built-in features and extensions are first-class citizens, and where the boundaries between core and community-driven innovation are minimized.

docs/developer_portal/extensions/deploying-extension.md

@@ -0,0 +1,45 @@
+---
+title: Deploying an Extension
+sidebar_position: 8
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Deploying an Extension
+
+Once an extension has been developed, the deployment process involves packaging and uploading it to the host application.
+
+Packaging is handled by the `superset-extensions bundle` command, which:
+
+1. Builds frontend assets using Webpack (with Module Federation configuration).
+2. Collects backend Python source files and all necessary resources.
+3. Generates a `manifest.json` with build-time metadata, including the contents of `extension.json` and references to built assets.
+4. Packages everything into a `.supx` file (a zip archive with a specific structure required by Superset).
+
+Uploading is accomplished through Superset's REST API at `/api/v1/extensions/import/`. The endpoint accepts the `.supx` file as form data and processes it by:
+
+1. Extracting and validating the extension metadata and manifest.
+2. Storing extension assets in the metadata database for dynamic loading.
+3. Registering the extension in the metadata database, including its name, version, author, and capabilities.
+4. Automatically activating the extension, making it immediately available for use and management via the Superset UI or API.
+
+This API-driven approach enables automated deployment workflows and simplifies extension management for administrators. Extensions can be uploaded through the Swagger UI, programmatically via scripts, or through the management interface:
+
+https://github.com/user-attachments/assets/98b16cdd-8ec5-4812-9d5e-9915badd8f0d

docs/developer_portal/extensions/development-mode.md

@@ -0,0 +1,48 @@
+---
+title: Development Mode
+sidebar_position: 10
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Development Mode
+
+Development mode accelerates extension development by letting developers see changes in Superset quickly, without the need for repeated packaging and uploading. To enable development mode, set the `LOCAL_EXTENSIONS` configuration in your `superset_config.py`:
+
+``` python
+LOCAL_EXTENSIONS = [
+    "/path/to/your/extension1",
+    "/path/to/your/extension2",
+]
+```
+
+This instructs Superset to load and serve extensions directly from disk, so you can iterate quickly. Running `superset-extensions dev` watches for file changes and rebuilds assets automatically, while the Webpack development server (started separately with `npm run dev-server`) serves updated files as soon as they're modified. This enables immediate feedback for React components, styles, and other frontend code. Changes to backend files are also detected automatically and immediately synced, ensuring that both frontend and backend updates are reflected in your development environment.
+
+Example output when running in development mode:
+
+```
+superset-extensions dev
+
+⚙️  Building frontend assets…
+✅ Frontend rebuilt
+✅ Backend files synced
+✅ Manifest updated
+👀 Watching for changes in: /dataset_references/frontend, /dataset_references/backend
+```

docs/developer_portal/extensions/dynamic-module-loading.md

@@ -0,0 +1,84 @@
+---
+title: Dynamic Module Loading
+sidebar_position: 7
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Dynamic Module Loading
+
+The extension architecture leverages Webpack's Module Federation to enable dynamic loading of frontend assets at runtime. This sophisticated mechanism involves several key concepts:
+
+**Module Federation** allows extensions to be built and deployed independently while sharing dependencies with the host application. Extensions expose their entry points through the federation configuration:
+
+``` typescript
+new ModuleFederationPlugin({
+  name: 'my_extension',
+  filename: 'remoteEntry.[contenthash].js',
+  exposes: {
+    './index': './src/index.tsx',
+  },
+  externalsType: 'window',
+  externals: {
+    '@apache-superset/core': 'superset',
+  },
+  shared: {
+    react: { singleton: true },
+    'react-dom': { singleton: true },
+    'antd-v5': { singleton: true }
+  }
+})
+```
+
+`externals` and `externalsType` ensure that extensions use the host's implementation of shared packages rather than bundling their own copies.
+
+`shared` dependencies prevent duplication of common libraries like React and Ant Design avoiding version conflicts and reducing bundle size.
+
+This configuration tells Webpack that when the extension imports from `@apache-superset/core`, it should resolve to `window.superset` at runtime, where the host application provides the actual implementation. The following diagram illustrates how this works in practice:
+
+<img width="913" height="558" alt="Image" src="https://github.com/user-attachments/assets/e5e4d2ae-e8b5-4d17-a2a1-3667c65f25ca" />
+
+During extension registration, the host application fetches the remote entry file and dynamically loads the extension's modules without requiring a rebuild or restart of Superset.
+
+On the host application side, the `@apache-superset/core` package will be mapped to the corresponding implementations during bootstrap in the `setupExtensionsAPI` function.
+
+``` typescript
+import * as supersetCore from '@apache-superset/core';
+import {
+  authentication,
+  core,
+  commands,
+  environment,
+  extensions,
+  sqlLab,
+} from 'src/extensions';
+
+export default function setupExtensionsAPI() {
+  window.superset = {
+    ...supersetCore,
+    authentication,
+    core,
+    commands,
+    environment,
+    extensions,
+    sqlLab,
+  };
+}
+```

docs/developer_portal/extensions/extension-metadata.md

@@ -0,0 +1,55 @@
+---
+title: Extension Metadata
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extension Metadata
+
+The `extension.json` file contains all metadata necessary for the host application to understand and manage the extension:
+
+``` json
+{
+  "name": "dataset_references",
+  "version": "1.0.0",
+  "frontend": {
+    "contributions": {
+      "views": {
+        "sqllab.panels": [
+          {
+            "id": "dataset_references.main",
+            "name": "Dataset references"
+          }
+        ]
+      }
+    },
+    "moduleFederation": {
+      "exposes": ["./index"]
+    }
+  },
+  "backend": {
+    "entryPoints": ["dataset_references.entrypoint"],
+    "files": ["backend/src/dataset_references/**/*.py"]
+  },
+}
+```
+
+The `contributions` section declares how the extension extends Superset's functionality through views, commands, menus, and other contribution types. The `backend` section specifies entry points and files to include in the bundle.

docs/developer_portal/extensions/extension-project-structure.md

@@ -0,0 +1,78 @@
+---
+title: Extension Project Structure
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extension Project Structure
+
+The `apache-superset-extensions-cli` package provides a command-line interface (CLI) that streamlines the extension development workflow. It offers the following commands:
+
+```
+superset-extensions init: Generates the initial folder structure and scaffolds a new extension project.
+
+superset-extensions build: Builds extension assets.
+
+superset-extensions bundle: Packages the extension into a .supx file.
+
+superset-extensions dev: Automatically rebuilds the extension as files change.
+```
+
+When creating a new extension with `superset-extensions init <extension-name>`, the CLI generates a standardized folder structure:
+
+```
+dataset_references/
+├── extension.json
+├── frontend/
+│   ├── src/
+│   ├── webpack.config.js
+│   ├── tsconfig.json
+│   └── package.json
+├── backend/
+│   ├── src/
+│        └── dataset_references/
+│   ├── tests/
+│   ├── pyproject.toml
+│   └── requirements.txt
+├── dist/
+│   ├── manifest.json
+│   ├── frontend
+│        └── dist/
+│             ├── remoteEntry.d7a9225d042e4ccb6354.js
+│             └── 900.038b20cdff6d49cfa8d9.js
+│   └── backend
+│        └── dataset_references/
+│             ├── __init__.py
+│             ├── api.py
+│             └── entrypoint.py
+├── dataset_references-1.0.0.supx
+└── README.md
+```
+
+The `extension.json` file serves as the declared metadata for the extension, containing the extension's name, version, author, description, and a list of capabilities. This file is essential for the host application to understand how to load and manage the extension.
+
+The `frontend` directory contains the source code for the frontend components of the extension, including React components, styles, and assets. The `webpack.config.js` file is used to configure Webpack for building the frontend code, while the `tsconfig.json` file defines the TypeScript configuration for the project. The `package.json` file specifies the dependencies and scripts for building and testing the frontend code.
+
+The `backend` directory contains the source code for the backend components of the extension, including Python modules, tests, and configuration files. The `pyproject.toml` file is used to define the Python package and its dependencies, while the r`equirements.txt` file lists the required Python packages for the extension. The `src` folder contains the functional backend source files, `tests` directory contains unit tests for the backend code, ensuring that the extension behaves as expected and meets the defined requirements.
+
+The `dist` directory is built when running the `build` or `dev` command, and contains the files that will be included in the bundle. The `manifest.json` file contains critical metadata about the extension, including the majority of the contents of the `extension.json` file, but also other build-time information, like the name of the built Webpack Module Federation remote entry file. The files in the `dist` directory will be zipped into the final `.supx` file. Although this file is technically a zip archive, the `.supx` extension makes it clear that it is a Superset extension package and follows a specific file layout. This packaged file can be distributed and installed in Superset instances.
+
+The `README.md` file provides documentation and instructions for using the extension, including how to install, configure, and use its functionality.

docs/developer_portal/extensions/frontend-contribution-types.md

@@ -0,0 +1,90 @@
+---
+title: Frontend Contribution Types
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Frontend Contribution Types
+
+To facilitate the development of extensions, we will define a set of well-defined contribution types that extensions can implement. These contribution types will serve as the building blocks for extensions, allowing them to interact with the host application and provide new functionality. The initial set of contribution types will include:
+
+## Views
+
+Extensions can add new views or panels to the host application, such as custom SQL Lab panels, dashboards, or other UI components. Each view is registered with a unique ID and can be activated or deactivated as needed. Contribution areas are uniquely identified (e.g., `sqllab.panels` for SQL Lab panels), enabling seamless integration into specific parts of the application.
+
+``` json
+"views": {
+  "sqllab.panels": [
+    {
+      "id": "dataset_references.main",
+      "name": "Table references"
+    }
+  ]
+},
+```
+
+## Commands
+
+Extensions can define custom commands that can be executed within the host application, such as context-aware actions or menu options. Each command can specify properties like a unique command identifier, an icon, a title, and a description. These commands can be invoked by users through menus, keyboard shortcuts, or other UI elements, enabling extensions to add rich, interactive functionality to Superset.
+
+``` json
+"commands": [
+  {
+    "command": "extension1.copy_query",
+    "icon": "CopyOutlined",
+    "title": "Copy Query",
+    "description": "Copy the current query to clipboard"
+  },
+]
+```
+
+## Menus
+
+Extensions can contribute new menu items or context menus to the host application, providing users with additional actions and options. Each menu item can specify properties such as the target view, the command to execute, its placement (primary, secondary, or context), and conditions for when it should be displayed. Menu contribution areas are uniquely identified (e.g., `sqllab.editor` for the SQL Lab editor), allowing extensions to seamlessly integrate their functionality into specific menus and workflows within Superset.
+
+``` json
+"menus": {
+  "sqllab.editor": {
+    "primary": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.copy_query"
+      }
+    ],
+    "secondary": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.prettify"
+      }
+    ],
+    "context": [
+      {
+        "view": "builtin.editor",
+        "command": "extension1.clear"
+      },
+      {
+        "view": "builtin.editor",
+     "command": "extension1.refresh"
+      }
+    ]
+  },
+}
+```

docs/developer_portal/extensions/high-level-architecture.md

@@ -0,0 +1,41 @@
+---
+title: High-level Architecture
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# High-level Architecture
+
+It is important to note that this SIP is not intended to address every aspect of the architecture in a single document. Rather, it should be seen as a chapter in an ongoing book: it establishes foundational concepts and direction, while recognizing that many important topics remain to be explored. Many topics not covered here are expected to be addressed in subsequent SIPs as the architecture and community needs evolve.
+
+The following diagram illustrates the overall architecture, emphasizing the relationships between the host application, extensions, and the supporting packages that will be developed to enable this ecosystem.
+
+<img width="955" height="586" alt="Image" src="https://github.com/user-attachments/assets/cc2a41df-55a4-48c8-b056-35f7a1e567c6" />
+
+On the frontend side, as a result of discussions in [[SIP-169] Proposal for Extracting and Publishing Superset Core UI Components](https://github.com/apache/superset/issues/33441), the `@apache-superset/core` package will be created to provide all the essential building blocks for both the host application and extensions, including shared UI components, utility functions, APIs, and type definitions. By centralizing these resources, extensions and built-in features can use the same APIs and components, ensuring consistency, type safety, and a seamless user experience across the Superset ecosystem. This package will be versioned to support safe evolution of the platform while maintaining compatibility for both internal and external features.
+
+On the backend side, the `apache-superset-core` package will expose key classes and APIs needed by extensions that provide backend functionality such as extending Superset's API, providing database connectors, or customizing the security manager. It will contain dependencies on critical libraries like FAB, SQLAlchemy, etc and like `@apache-superset/core`, it will be versioned to ensure compatibility and stability.
+
+The `apache-superset-extensions-cli` package will provide a comprehensive set of CLI commands for extension development, including tools for code generation, building, and packaging extensions. These commands streamline the development workflow, making it easier for developers to scaffold new projects, build and bundle their code, and distribute extensions efficiently. By standardizing these processes, the CLI helps ensure that extensions are built in a consistent manner, remain compatible with evolving versions of Superset, and adhere to best practices across the ecosystem.
+
+Extension projects might have references to all packages, depending on their specific needs. For example, an extension that provides a custom SQL editor might depend on the `apache-superset-core` package for backend functionality, while also using the `@apache-superset/core` package for UI components and type definitions. This modular approach allows extension authors to choose the dependencies that best suit their needs, while also promoting consistency and reusability across the ecosystem.
+
+The host application (Superset) will depend on core packages and is responsible for providing the implementation of the APIs defined in them. It will expose a new endpoint (`/api/v1/extensions`) for extension registration and management, and a dedicated UI for managing extensions. Registered extensions will be stored in the metadata database in a table called `extensions`, which will contain information such as the extension's name, version, author, contributed features, exposed modules, relevant metadata and the built frontend and/or backend code.

docs/developer_portal/extensions/interacting-with-host.md

@@ -0,0 +1,120 @@
+---
+title: Interacting with the Host
+sidebar_position: 6
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Interacting with the Host
+
+Extensions interact with Superset through well-defined, versioned APIs provided by the `@apache-superset/core` (frontend) and `apache-superset-core` (backend) packages. These APIs are designed to be stable, discoverable, and consistent for both built-in and external extensions.
+
+**Frontend APIs** (via `@apache-superset/core)`:
+
+The frontend extension APIs in Superset are organized into logical namespaces such as `authentication`, `commands`, `extensions`, `sqlLab`, and others. Each namespace groups related functionality, making it easy for extension authors to discover and use the APIs relevant to their needs. For example, the `sqlLab` namespace provides events and methods specific to SQL Lab, allowing extensions to react to user actions and interact with the SQL Lab environment:
+
+``` typescript
+export const getCurrentTab: () => Tab | undefined;
+
+export const getDatabases: () => Database[];
+
+export const getTabs: () => Tab[];
+
+export const onDidChangeEditorContent: Event<string>;
+
+export const onDidClosePanel: Event<Panel>;
+
+export const onDidChangeActivePanel: Event<Panel>;
+
+export const onDidChangeTabTitle: Event<string>;
+
+export const onDidQueryRun: Event<Editor>;
+
+export const onDidQueryStop: Event<Editor>;
+```
+
+The following code demonstrates more examples of the existing frontend APIs:
+
+``` typescript
+import { core, commands, sqlLab, authentication, Button } from '@apache-superset/core';
+import MyPanel from './MyPanel';
+
+export function activate(context) {
+  // Register a new panel (view) in SQL Lab and use shared UI components in your extension's React code
+  const panelDisposable = core.registerView('my_extension.panel', <MyPanel><Button/></MyPanel>);
+
+  // Register a custom command
+  const commandDisposable = commands.registerCommand('my_extension.copy_query', {
+    title: 'Copy Query',
+    execute: () => {
+      // Command logic here
+    },
+  });
+
+  // Listen for query run events in SQL Lab
+  const eventDisposable = sqlLab.onDidQueryRun(editor => {
+    // Handle query execution event
+  });
+
+  // Access a CSRF token for secure API requests
+  authentication.getCSRFToken().then(token => {
+    // Use token as needed
+  });
+
+  // Add all disposables for automatic cleanup on deactivation
+  context.subscriptions.push(panelDisposable, commandDisposable, eventDisposable);
+}
+```
+
+**Backend APIs** (via `apache-superset-core`):
+
+Backend APIs follow a similar pattern, providing access to Superset's models, sessions, and query capabilities. Extensions can register REST API endpoints, access the metadata database, and interact with Superset's core functionality.
+
+Extension endpoints are registered under a dedicated `/extensions` namespace to avoid conflicting with built-in endpoints and also because they don't share the same version constraints. By grouping all extension endpoints under `/extensions`, Superset establishes a clear boundary between core and extension functionality, making it easier to manage, document, and secure both types of APIs.
+
+``` python
+from superset_core.api import rest_api, models, query
+from .api import DatasetReferencesAPI
+
+# Register a new extension REST API
+rest_api.add_extension_api(DatasetReferencesAPI)
+
+# Access Superset models with simple queries that filter out entities that
+# the user doesn't have access to
+databases = models.get_databases(id=database_id)
+if not databases:
+    return self.response_404()
+
+database = databases[0]
+
+# Perform complex queries using SQLAlchemy BaseQuery, also filtering
+# out inaccessible entities
+session = models.get_session()
+db_model = models.get_database_model())
+database_query = session.query(db_model.database_name.ilike("%abc%")
+databases_containing_abc = models.get_databases(query)
+
+# Bypass security model for highly custom use cases
+session = models.get_session()
+db_model = models.get_database_model())
+all_databases_containg_abc = session.query(db_model.database_name.ilike("%abc%").all()
+```
+
+In the future, we plan to expand the backend APIs to support configuring security models, database engines, SQL Alchemy dialects, etc.

docs/developer_portal/extensions/lifecycle-management.md

@@ -0,0 +1,41 @@
+---
+title: Lifecycle and Management
+sidebar_position: 9
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Lifecycle and Management
+
+Superset will manage the full lifecycle of extensions, including activation, deactivation, and cleanup. The lifecycle is designed to ensure that extensions can safely register resources and reliably clean them up when no longer needed.
+
+## Frontend lifecycle
+
+- When an extension is activated, its `activate(context)` function is called. The extension should register all event listeners, commands, views, and other contributions using the provided context, and add any disposables to `context.disposables`.
+- When the extension is deactivated (e.g., disabled or uninstalled), Superset automatically calls `dispose()` on all items in `context.disposables`, ensuring that event listeners, commands, and UI contributions are removed and memory leaks are avoided.
+
+## Backend lifecycle
+
+- Backend entry points, which can add REST API endpoints or execute arbitrary backend code, are eagerly evaluated during startup. Other backend code is lazily loaded when needed, ensuring minimal startup latency.
+- In the future, we plan to leverage mechanisms like Redis pub/sub (already an optional dependency of Superset) to dynamically manage the lifecycle of extensions' backend functionality. This will ensure that all running instances of the Superset backend have the same available extensions without requiring a restart. This will be addressed in a follow-up SIP.
+
+The proof-of-concept (POC) code for this SIP already implements a management module where administrators can upload, delete, enable/disable, and inspect the manifest for installed extensions via the Superset UI, making extension operations straightforward. These operations are currently supported dynamically for frontend extensions. For backend extensions, dynamic upload, deletion, and enable/disable are planned for a future iteration; at present, changes to backend extensions (such as uploading, deleting, or enabling/disabling) still require a server restart.
+
+https://github.com/user-attachments/assets/4eb7064b-3290-4e4c-b88b-52d8d1c11245

docs/developer_portal/extensions/overview.md

@@ -0,0 +1,78 @@
+---
+title: Extensions Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extensions Overview
+
+Apache Superset's extension system allows developers to enhance and customize Superset's functionality through a modular, plugin-based architecture. Extensions can add new visualization types, custom UI components, data processing capabilities, and integration points.
+
+## What are Superset Extensions?
+
+Superset extensions are self-contained packages that extend the core platform's capabilities. They follow a standardized architecture that ensures compatibility, security, and maintainability while providing powerful customization options.
+
+## Extension Architecture
+
+- **[Architectural Principles](./architectural-principles)** - Core design principles guiding extension development
+- **[High-level Architecture](./high-level-architecture)** - System overview and component relationships
+- **[Extension Project Structure](./extension-project-structure)** - Standard project layout and organization
+- **[Extension Metadata](./extension-metadata)** - Configuration and manifest structure
+
+## Development Guide
+
+- **[Frontend Contribution Types](./frontend-contribution-types)** - Types of UI contributions available
+- **[Interacting with Host](./interacting-with-host)** - Communication patterns with Superset core
+- **[Dynamic Module Loading](./dynamic-module-loading)** - Runtime loading and dependency management
+- **[Development Mode](./development-mode)** - Tools and workflows for extension development
+
+## Deployment & Management
+
+- **[Deploying Extension](./deploying-extension)** - Packaging and distribution strategies
+- **[Lifecycle Management](./lifecycle-management)** - Installation, updates, and removal
+- **[Versioning](./versioning)** - Version management and compatibility
+- **[Security Implications](./security-implications)** - Security considerations and best practices
+
+## Hands-on Examples
+
+- **[Proof of Concept](./proof-of-concept)** - Complete Hello World extension walkthrough
+
+## Extension Capabilities
+
+Extensions can provide:
+
+- **Custom Visualizations**: New chart types and data visualization components
+- **UI Enhancements**: Custom dashboards, panels, and interactive elements  
+- **Data Connectors**: Integration with external data sources and APIs
+- **Workflow Automation**: Custom actions and batch processing capabilities
+- **Authentication Providers**: SSO and custom authentication mechanisms
+- **Theme Customization**: Custom styling and branding options
+
+## Getting Started
+
+1. **Learn the Architecture**: Start with [Architectural Principles](./architectural-principles) to understand the design philosophy
+2. **Set up Development**: Follow the [Development Mode](./development-mode) guide to configure your environment
+3. **Build Your First Extension**: Complete the [Proof of Concept](./proof-of-concept) tutorial
+4. **Deploy and Share**: Use the [Deploying Extension](./deploying-extension) guide to package your extension
+
+## Extension Ecosystem
+
+The extension system is designed to foster a vibrant ecosystem of community-contributed functionality. By following the established patterns and guidelines, developers can create extensions that seamlessly integrate with Superset while maintaining the platform's reliability and performance standards.

docs/developer_portal/extensions/proof-of-concept.md

@@ -0,0 +1,288 @@
+---
+title: "Example: Hello World"
+sidebar_position: 14
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Example: Hello World
+
+:::warning Work in Progress
+This documentation is under active development. Some features described may not be fully implemented yet.
+:::
+
+This guide walks you through creating your first Superset extension - a simple "Hello World" panel for SQL Lab. You'll learn how to create, build, package, install, and test a basic extension.
+
+## Prerequisites
+
+Before starting, ensure you have:
+- Node.js 18+ and npm installed
+- Python 3.9+ installed
+- A running Superset development environment with `ENABLE_EXTENSIONS = True` in your config
+- Basic knowledge of React and TypeScript
+
+## Step 1: Initialize Your Extension
+
+First, install the Superset extension CLI and create a new extension project:
+
+```bash
+# Install the CLI globally
+pip install apache-superset-extensions-cli
+
+# Create a new extension
+superset-extensions init hello-world
+cd hello-world
+```
+
+This creates the following structure:
+```
+hello-world/
+├── extension.json         # Extension metadata
+├── frontend/             # Frontend code
+│   ├── src/
+│   │   └── index.tsx    # Main entry point
+│   ├── package.json
+│   └── webpack.config.js
+├── backend/              # Backend code (optional)
+│   └── src/
+└── README.md
+```
+
+## Step 2: Configure Extension Metadata
+
+Edit `extension.json` to define your extension's capabilities:
+
+```json
+{
+  "name": "hello_world",
+  "displayName": "Hello World Extension",
+  "version": "1.0.0",
+  "description": "A simple Hello World panel for SQL Lab",
+  "author": "Your Name",
+  "license": "Apache-2.0",
+  "superset": {
+    "minVersion": "4.0.0"
+  },
+  "frontend": {
+    "contributions": {
+      "views": {
+        "sqllab.panels": [
+          {
+            "id": "hello_world.main",
+            "name": "Hello World",
+            "icon": "SmileOutlined"
+          }
+        ]
+      },
+      "commands": [
+        {
+          "command": "hello_world.greet",
+          "title": "Say Hello",
+          "description": "Display a greeting message"
+        }
+      ]
+    }
+  }
+}
+```
+
+## Step 3: Create the Frontend Component
+
+Create `frontend/src/HelloWorldPanel.tsx`:
+
+```tsx
+import React, { useState, useEffect } from 'react';
+import { Card, Button, Alert } from '@apache-superset/core';
+
+export const HelloWorldPanel: React.FC = () => {
+  const [greeting, setGreeting] = useState('Hello, Superset!');
+  const [queryCount, setQueryCount] = useState(0);
+
+  // Listen for query executions
+  useEffect(() => {
+    const handleQueryRun = () => {
+      setQueryCount(prev => prev + 1);
+      setGreeting(`Hello! You've run ${queryCount + 1} queries.`);
+    };
+
+    // Subscribe to SQL Lab events
+    const disposable = window.superset?.sqlLab?.onDidQueryRun?.(handleQueryRun);
+
+    return () => disposable?.dispose?.();
+  }, [queryCount]);
+
+  return (
+    <Card title="Hello World Extension">
+      <Alert
+        message={greeting}
+        type="success"
+        showIcon
+      />
+      <p style={{ marginTop: 16 }}>
+        This is your first Superset extension! 🎉
+      </p>
+      <p>
+        Queries executed this session: <strong>{queryCount}</strong>
+      </p>
+      <Button
+        onClick={() => setGreeting('Hello from the button!')}
+        style={{ marginTop: 16 }}
+      >
+        Click Me
+      </Button>
+    </Card>
+  );
+};
+```
+
+## Step 4: Set Up the Entry Point
+
+Update `frontend/src/index.tsx`:
+
+```tsx
+import { ExtensionContext } from '@apache-superset/core';
+import { HelloWorldPanel } from './HelloWorldPanel';
+
+export function activate(context: ExtensionContext) {
+  console.log('Hello World extension is activating!');
+
+  // Register the panel
+  const panel = context.registerView(
+    'hello_world.main',
+    <HelloWorldPanel />
+  );
+
+  // Register the command
+  const command = context.registerCommand('hello_world.greet', {
+    execute: () => {
+      console.log('Hello from the command!');
+      // You could trigger panel updates or show notifications here
+    }
+  });
+
+  // Add disposables for cleanup
+  context.subscriptions.push(panel, command);
+}
+
+export function deactivate() {
+  console.log('Hello World extension is deactivating!');
+}
+```
+
+## Step 5: Build the Extension
+
+Build your extension assets:
+
+```bash
+# Install dependencies
+cd frontend
+npm install
+
+# Build the extension
+cd ..
+superset-extensions build
+
+# This creates a dist/ folder with your built assets
+```
+
+> **Note:** The `superset-extensions` CLI handles webpack configuration automatically. Superset already has Module Federation configured, so you don't need to set up webpack yourself unless you have specific advanced requirements.
+
+## Step 6: Package the Extension
+
+Create the distributable `.supx` file:
+
+```bash
+superset-extensions bundle
+
+# This creates hello_world-1.0.0.supx
+```
+
+## Step 7: Install in Superset
+
+Upload your extension to a running Superset instance:
+
+### Option A: Via API
+```bash
+curl -X POST http://localhost:8088/api/v1/extensions/import/ \
+  -H "Authorization: Bearer YOUR_TOKEN" \
+  -F "bundle=@hello_world-1.0.0.supx"
+```
+
+### Option B: Via UI
+1. Navigate to Settings → Extensions
+2. Click "Upload Extension"
+3. Select your `hello_world-1.0.0.supx` file
+4. Click "Install"
+
+## Step 9: Test Your Extension
+
+1. Open SQL Lab in Superset
+2. Look for the "Hello World" panel in the panels dropdown or sidebar
+3. The panel should display your greeting message
+4. Run a SQL query and watch the query counter increment
+5. Click the button to see the greeting change
+
+## Step 10: Development Mode (Optional)
+
+For faster development iteration, use local development mode:
+
+1. Add to your `superset_config.py`:
+```python
+LOCAL_EXTENSIONS = [
+    "/path/to/hello-world"
+]
+ENABLE_EXTENSIONS = True
+```
+
+2. Run the extension in watch mode:
+```bash
+superset-extensions dev
+```
+
+3. Changes will be reflected immediately without rebuilding
+
+## Troubleshooting
+
+### Extension Not Loading
+- Check that `ENABLE_EXTENSIONS = True` in your Superset config
+- Verify the extension is listed in Settings → Extensions
+- Check browser console for errors
+- Ensure all dependencies are installed
+
+### Build Errors
+- Make sure you have the correct Node.js version (18+)
+- Clear node_modules and reinstall: `rm -rf node_modules && npm install`
+- Check that webpack.config.js is properly configured
+
+### Panel Not Visible
+- Verify the contribution point in extension.json matches `sqllab.panels`
+- Check that the panel ID is unique
+- Restart Superset after installing the extension
+
+## Next Steps
+
+Now that you have a working Hello World extension, you can:
+- Add more complex UI components
+- Integrate with Superset's API to fetch data
+- Add backend functionality for data processing
+- Create custom commands and menu items
+- Listen to more SQL Lab events
+
+For more advanced examples, explore the other pages in this documentation section.

docs/developer_portal/extensions/security-implications.md

@@ -0,0 +1,33 @@
+---
+title: Security Implications and Responsibilities
+sidebar_position: 12
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Security Implications and Responsibilities
+
+By default, extensions are disabled and must be explicitly enabled by setting the `ENABLE_EXTENSIONS` feature flag. Built-in extensions are included as part of the Superset codebase and are held to the same security standards and review processes as the rest of the application.
+
+For external extensions, administrators are responsible for evaluating and verifying the security of any extensions they choose to install, just as they would when installing third-party NPM or PyPI packages. At this stage, all extensions run in the same context as the host application, without additional sandboxing. This means that external extensions can impact the security and performance of a Superset environment in the same way as any other installed dependency.
+
+We plan to introduce an optional sandboxed execution model for extensions in the future (as part of an additional SIP). Until then, administrators should exercise caution and follow best practices when selecting and deploying third-party extensions. A directory of known Superset extensions may be maintained in a means similar to [this page](https://github.com/apache/superset/wiki/Superset-Third%E2%80%90Party-Plugins-Directory) on the wiki. We also discussed the possibility of introducing a shared registry for vetted extensions but decided to leave it out of the initial scope of the project. We might introduce a registry at a later stage depending on the evolution of extensions created by the community.
+
+Any performance or security vulnerabilities introduced by external extensions should be reported directly to the extension author, not as Superset vulnerabilities. Any security concerns regarding built-in extensions (included in Superset's monorepo) should be reported to the Superset Security mailing list for triage and resolution by maintainers.

docs/developer_portal/extensions/versioning.md

@@ -0,0 +1,31 @@
+---
+title: Versioning
+sidebar_position: 11
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Versioning
+
+All core packages published to NPM and PyPI—including `@apache-superset/core`, `apache-superset-core`, and `apache-superset-extensions-cli`—will follow semantic versioning ([semver](https://semver.org/)). This means that any breaking changes to public APIs, interfaces, or extension points will result in a major version bump, while new features and non-breaking changes will be released as minor or patch updates.
+
+During the initial development phase, packages will remain under version 0.x, allowing for rapid iteration and the introduction of breaking changes as the architecture evolves based on real-world feedback. Once the APIs and extension points are considered stable, we will release version 1.0.0 and begin enforcing strict server practices.
+
+To minimize disruption, breaking changes will be carefully planned and communicated in advance. We will provide clear migration guides and changelogs to help extension authors and core contributors adapt to new versions. Where possible, we will deprecate APIs before removing them, giving developers time to transition to newer interfaces.

docs/developer_portal/getting-started/index.md

@@ -1,248 +0,0 @@
----
-title: Getting Started
-sidebar_position: 2
-hide_title: true
----
-
-<!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
--->
-
-# Getting Started with Extensions
-
-This guide will walk you through creating, developing, and deploying your first Superset extension.
-
-## Prerequisites
-
-Before you begin, make sure you have:
-
-- **Node.js 16+** and npm/yarn installed
-- **Python 3.9+** and pip installed  
-- **Superset** running locally or access to a Superset instance
-- **Git** for version control
-- Basic knowledge of React and TypeScript
-
-## Quick Start
-
-### 1. Install the CLI
-
-First, install the Superset Extensions CLI globally:
-
-```bash
-pip install apache-superset-extensions-cli
-```
-
-### 2. Create Your First Extension
-
-Use the CLI to scaffold a new extension project:
-
-```bash
-superset-extensions init my-first-extension
-cd my-first-extension
-```
-
-This creates the following structure:
-
-```
-my-first-extension/
-├── extension.json          # Extension metadata
-├── frontend/              # Frontend code
-│   ├── src/
-│   │   └── index.tsx     # Main entry point
-│   ├── package.json
-│   └── webpack.config.js
-├── backend/              # Backend code (optional)
-│   ├── src/
-│   └── requirements.txt
-└── README.md
-```
-
-### 3. Configure Your Extension
-
-Edit `extension.json` to define your extension's capabilities:
-
-```json
-{
-  "name": "my-first-extension",
-  "version": "1.0.0",
-  "description": "My first Superset extension",
-  "author": "Your Name",
-  "frontend": {
-    "contributions": {
-      "views": {
-        "sqllab.panels": [
-          {
-            "id": "my-extension.main",
-            "name": "My Panel",
-            "icon": "ToolOutlined"
-          }
-        ]
-      }
-    }
-  }
-}
-```
-
-### 4. Develop Your Extension
-
-Edit `frontend/src/index.tsx` to implement your extension:
-
-```typescript
-import React from 'react';
-import { ExtensionContext } from '@apache-superset/core';
-
-export function activate(context: ExtensionContext) {
-  // Register your panel component
-  const panel = context.core.registerView('my-extension.main', () => (
-    <div style={{ padding: 20 }}>
-      <h2>Hello from My Extension!</h2>
-      <p>This is my first Superset extension.</p>
-    </div>
-  ));
-
-  // Clean up on deactivation
-  context.subscriptions.push(panel);
-}
-
-export function deactivate() {
-  // Cleanup code if needed
-}
-```
-
-### 5. Test Locally
-
-Enable development mode in your Superset configuration:
-
-```python
-# superset_config.py
-ENABLE_EXTENSIONS = True
-LOCAL_EXTENSIONS = [
-    "/path/to/my-first-extension"
-]
-```
-
-Run the development server:
-
-```bash
-# In your extension directory
-superset-extensions dev
-
-# In a separate terminal, start Superset
-superset run -p 8088 --with-threads --reload
-```
-
-Your extension will now appear in SQL Lab!
-
-### 6. Build and Package
-
-When ready to distribute your extension:
-
-```bash
-superset-extensions build
-superset-extensions bundle
-```
-
-This creates a `my-first-extension-1.0.0.supx` file that can be uploaded to any Superset instance.
-
-### 7. Deploy
-
-Upload your extension via the Superset UI or API:
-
-```bash
-curl -X POST http://localhost:8088/api/v1/extensions/import/ \
-  -H "Authorization: Bearer YOUR_TOKEN" \
-  -F "file=@my-first-extension-1.0.0.supx"
-```
-
-## What's Next?
-
-Now that you have a basic extension working, explore:
-
-- [Extension Architecture](../architecture/overview) - Understand how extensions work
-- [API Reference](../api/frontend) - Learn about available APIs
-- [Examples](../examples) - See more complex extension examples
-- [Best Practices](./best-practices) - Learn extension development best practices
-
-## Common Patterns
-
-### Adding a SQL Lab Panel
-
-```typescript
-const panel = context.core.registerView('my-extension.panel', () => (
-  <MyPanelComponent />
-));
-```
-
-### Registering Commands
-
-```typescript
-const command = context.commands.registerCommand('my-extension.run', {
-  title: 'Run My Command',
-  execute: () => {
-    // Command logic
-  }
-});
-```
-
-### Listening to Events
-
-```typescript
-const listener = context.sqlLab.onDidQueryRun((query) => {
-  console.log('Query executed:', query);
-});
-```
-
-### Adding Menu Items
-
-```json
-{
-  "menus": {
-    "sqllab.editor": {
-      "primary": [{
-        "command": "my-extension.run",
-        "when": "editorHasSelection"
-      }]
-    }
-  }
-}
-```
-
-## Troubleshooting
-
-### Extension Not Loading
-
-- Ensure `ENABLE_EXTENSIONS = True` in your config
-- Check the browser console for errors
-- Verify the extension path in `LOCAL_EXTENSIONS`
-
-### Module Not Found Errors
-
-- Run `npm install` in the frontend directory
-- Check that `@apache-superset/core` is properly externalized
-
-### Build Failures
-
-- Ensure all dependencies are installed
-- Check webpack.config.js for proper Module Federation setup
-- Verify extension.json is valid JSON
-
-## Get Help
-
-- Join the [Superset Slack](https://join.slack.com/t/apache-superset/shared_invite/zt-16jvzmoi8-sI1TY1Pm~y_RnSiUAN0jqQ)
-- Ask questions on [GitHub Discussions](https://github.com/apache/superset/discussions)
-- Report issues on [GitHub Issues](https://github.com/apache/superset/issues)

docs/developer_portal/guidelines/backend-style-guidelines.md

@@ -0,0 +1,318 @@
+---
+title: Backend Style Guidelines
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Backend Style Guidelines
+
+This is a list of statements that describe how we do backend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for backend quality and style.
+
+* We use a monolithic Python/Flask/Flask-AppBuilder backend, with small single-responsibility satellite services where necessary.
+* Files are generally organized by feature or object type. Within each domain, we can have api controllers, models, schemas, commands, and data access objects (dao).
+    * See: [Proposal for Improving Superset's Python Code Organization](https://github.com/apache/superset/issues/9077)
+* API controllers use Marshmallow Schemas to serialize/deserialize data.
+* Authentication and authorization are controlled by the [security manager](https://github.com/apache/superset/blob/master/superset/security/manager).
+* We use Pytest for unit and integration tests. These live in the `tests` directory.
+* We add tests for every new piece of functionality added to the backend.
+* We use pytest fixtures to share setup between tests.
+* We use sqlalchemy to access both Superset's application database, and users' analytics databases.
+* We make changes backwards compatible whenever possible.
+    * If a change cannot be made backwards compatible, it goes into a major release.
+    * See: [Proposal For Semantic Versioning](https://github.com/apache/superset/issues/12566)
+* We use Swagger for API documentation, with docs written inline on the API endpoint code.
+* We prefer thin ORM models, putting shared functionality in other utilities.
+* Several linters/checkers are used to maintain consistent code style and type safety: pylint, pypy, black, isort.
+* `__init__.py` files are kept empty to avoid implicit dependencies.
+
+## Code Organization
+
+### Domain-Driven Structure
+
+Organize code by business domain rather than technical layers:
+
+```
+superset/
+├── dashboards/
+│   ├── api.py          # API endpoints
+│   ├── commands/       # Business logic
+│   ├── dao.py          # Data access layer
+│   ├── models.py       # Database models
+│   └── schemas.py      # Serialization schemas
+├── charts/
+│   ├── api.py
+│   ├── commands/
+│   ├── dao.py
+│   ├── models.py
+│   └── schemas.py
+```
+
+### API Controllers
+
+Use Flask-AppBuilder with Marshmallow schemas:
+
+```python
+from flask_appbuilder.api import BaseApi
+from marshmallow import Schema, fields
+
+class DashboardSchema(Schema):
+    id = fields.Integer()
+    dashboard_title = fields.String(required=True)
+    created_on = fields.DateTime(dump_only=True)
+
+class DashboardApi(BaseApi):
+    resource_name = "dashboard"
+    openapi_spec_tag = "Dashboards"
+
+    @expose("/", methods=["GET"])
+    @protect()
+    @safe
+    def get_list(self) -> Response:
+        """Get a list of dashboards"""
+        # Implementation
+```
+
+### Commands Pattern
+
+Use commands for business logic:
+
+```python
+from typing import Optional
+from superset.commands.base import BaseCommand
+from superset.dashboards.dao import DashboardDAO
+
+class CreateDashboardCommand(BaseCommand):
+    def __init__(self, properties: Dict[str, Any]):
+        self._properties = properties
+
+    def run(self) -> Dashboard:
+        self.validate()
+        return DashboardDAO.create(self._properties)
+
+    def validate(self) -> None:
+        if not self._properties.get("dashboard_title"):
+            raise ValidationError("Title is required")
+```
+
+### Data Access Objects (DAOs)
+
+See: [DAO Style Guidelines and Best Practices](./backend/dao-style-guidelines)
+
+## Testing
+
+### Unit Tests
+
+```python
+import pytest
+from unittest.mock import patch
+from superset.dashboards.commands.create import CreateDashboardCommand
+
+def test_create_dashboard_success():
+    properties = {
+        "dashboard_title": "Test Dashboard",
+        "owners": [1]
+    }
+
+    command = CreateDashboardCommand(properties)
+    dashboard = command.run()
+
+    assert dashboard.dashboard_title == "Test Dashboard"
+
+def test_create_dashboard_validation_error():
+    properties = {}  # Missing required title
+
+    command = CreateDashboardCommand(properties)
+
+    with pytest.raises(ValidationError):
+        command.run()
+```
+
+### Integration Tests
+
+```python
+import pytest
+from superset.app import create_app
+from superset.extensions import db
+
+@pytest.fixture
+def app():
+    app = create_app()
+    app.config["TESTING"] = True
+    with app.app_context():
+        db.create_all()
+        yield app
+        db.drop_all()
+
+def test_dashboard_api_create(app, auth_headers):
+    with app.test_client() as client:
+        response = client.post(
+            "/api/v1/dashboard/",
+            json={"dashboard_title": "Test Dashboard"},
+            headers=auth_headers
+        )
+        assert response.status_code == 201
+```
+
+## Security
+
+### Authorization Decorators
+
+```python
+from flask_appbuilder.security.decorators import has_access
+
+class DashboardApi(BaseApi):
+    @expose("/", methods=["POST"])
+    @protect()
+    @has_access("can_write", "Dashboard")
+    def post(self) -> Response:
+        """Create a new dashboard"""
+        # Implementation
+```
+
+### Input Validation
+
+```python
+from marshmallow import Schema, fields, validate
+
+class DashboardSchema(Schema):
+    dashboard_title = fields.String(
+        required=True,
+        validate=validate.Length(min=1, max=500)
+    )
+    slug = fields.String(
+        validate=validate.Regexp(r'^[a-z0-9-]+$')
+    )
+```
+
+## Database Operations
+
+### Use SQLAlchemy ORM
+
+```python
+from sqlalchemy import Column, Integer, String, Text
+from superset.models.helpers import AuditMixinNullable
+
+class Dashboard(Model, AuditMixinNullable):
+    __tablename__ = "dashboards"
+
+    id = Column(Integer, primary_key=True)
+    dashboard_title = Column(String(500))
+    position_json = Column(Text)
+
+    def __repr__(self) -> str:
+        return f"<Dashboard {self.dashboard_title}>"
+```
+
+### Database Migrations
+
+```python
+# migration file
+def upgrade():
+    op.add_column(
+        "dashboards",
+        sa.Column("new_column", sa.String(255), nullable=True)
+    )
+
+def downgrade():
+    op.drop_column("dashboards", "new_column")
+```
+
+## Error Handling
+
+### Custom Exceptions
+
+```python
+class SupersetException(Exception):
+    """Base exception for Superset"""
+    pass
+
+class ValidationError(SupersetException):
+    """Raised when validation fails"""
+    pass
+
+class SecurityException(SupersetException):
+    """Raised when security check fails"""
+    pass
+```
+
+### Error Responses
+
+```python
+from flask import jsonify
+from werkzeug.exceptions import BadRequest
+
+@app.errorhandler(ValidationError)
+def handle_validation_error(error):
+    return jsonify({
+        "message": str(error),
+        "error_type": "VALIDATION_ERROR"
+    }), 400
+```
+
+## Type Hints and Documentation
+
+### Use Type Hints
+
+```python
+from typing import List, Optional, Dict, Any
+from superset.models.dashboard import Dashboard
+
+def get_dashboards_by_owner(owner_id: int) -> List[Dashboard]:
+    """Get all dashboards owned by a specific user"""
+    return db.session.query(Dashboard).filter_by(owner_id=owner_id).all()
+
+def create_dashboard(properties: Dict[str, Any]) -> Optional[Dashboard]:
+    """Create a new dashboard with the given properties"""
+    # Implementation
+```
+
+### API Documentation
+
+```python
+from flask_appbuilder.api import BaseApi
+from flask_appbuilder.api.schemas import get_list_schema
+
+class DashboardApi(BaseApi):
+    @expose("/", methods=["GET"])
+    @protect()
+    @safe
+    def get_list(self) -> Response:
+        """Get a list of dashboards
+        ---
+        get:
+          description: >-
+            Get a list of dashboards
+          parameters:
+          - in: query
+            schema:
+              type: integer
+            name: page_size
+            description: Number of results per page
+          responses:
+            200:
+              description: Success
+              content:
+                application/json:
+                  schema:
+                    $ref: '#/components/schemas/DashboardListResponse'
+        """
+        # Implementation
+```

docs/developer_portal/guidelines/backend/dao-style-guidelines.md

@@ -0,0 +1,365 @@
+---
+title: DAO Style Guidelines and Best Practices
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# DAO Style Guidelines and Best Practices
+
+A Data Access Object (DAO) is a pattern that provides an abstract interface to the SQLAlchemy Object Relational Mapper (ORM). The DAOs are critical as they form the building block of the application which are wrapped by the associated commands and RESTful API endpoints.
+
+Currently there are numerous inconsistencies and violation of the DRY principal within the codebase as it relates to DAOs and ORMs—unnecessary commits, non-ACID transactions, etc.—which makes the code unnecessarily complex and convoluted. Addressing the underlying issues with the DAOs _should_ help simplify the downstream operations and improve the developer experience.
+
+To ensure consistency the following rules should be adhered to:
+
+1. All database operations (including testing) should be defined within a DAO, i.e., there should not be any explicit `db.session.add`, `db.session.merge`, etc. calls outside of a DAO.
+
+2. A DAO should use `create`, `update`, `delete`, `upsert` terms—typical database operations which ensure consistency with commands—rather than action based terms like `save`, `saveas`, `override`, etc.
+
+3. Sessions should be managed via a [context manager](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#begin-once) which auto-commits on success and rolls back on failure, i.e., there should be no explicit `db.session.commit` or `db.session.rollback` calls within the DAO.
+
+4. There should be a single atomic transaction representing the entirety of the operation, i.e., when creating a dataset with associated columns and metrics either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back. SQLAlchemy supports [nested transactions](https://docs.sqlalchemy.org/en/20/orm/session_transaction.html#nested-transaction) via the `begin_nested` method which can be nested—inline with how DAOs are invoked.
+
+5. The database layer should adopt a "shift left" mentality i.e., uniqueness/foreign key constraints, relationships, cascades, etc. should all be defined in the database layer rather than being enforced in the application layer.
+
+## DAO Implementation Examples
+
+### Basic DAO Structure
+
+```python
+from typing import List, Optional, Dict, Any
+from sqlalchemy.orm import Session
+from superset.extensions import db
+from superset.models.dashboard import Dashboard
+
+class DashboardDAO:
+    """Data Access Object for Dashboard operations"""
+
+    @classmethod
+    def find_by_id(cls, dashboard_id: int) -> Optional[Dashboard]:
+        """Find dashboard by ID"""
+        return db.session.query(Dashboard).filter_by(id=dashboard_id).first()
+
+    @classmethod
+    def find_by_ids(cls, dashboard_ids: List[int]) -> List[Dashboard]:
+        """Find dashboards by list of IDs"""
+        return db.session.query(Dashboard).filter(
+            Dashboard.id.in_(dashboard_ids)
+        ).all()
+
+    @classmethod
+    def create(cls, properties: Dict[str, Any]) -> Dashboard:
+        """Create a new dashboard"""
+        with db.session.begin():
+            dashboard = Dashboard(**properties)
+            db.session.add(dashboard)
+            db.session.flush()  # Get the ID
+            return dashboard
+
+    @classmethod
+    def update(cls, dashboard: Dashboard, properties: Dict[str, Any]) -> Dashboard:
+        """Update an existing dashboard"""
+        with db.session.begin():
+            for key, value in properties.items():
+                setattr(dashboard, key, value)
+            return dashboard
+
+    @classmethod
+    def delete(cls, dashboard: Dashboard) -> None:
+        """Delete a dashboard"""
+        with db.session.begin():
+            db.session.delete(dashboard)
+```
+
+### Complex DAO Operations
+
+```python
+class DatasetDAO:
+    """Data Access Object for Dataset operations"""
+
+    @classmethod
+    def create_with_columns_and_metrics(
+        cls,
+        dataset_properties: Dict[str, Any],
+        columns: List[Dict[str, Any]],
+        metrics: List[Dict[str, Any]]
+    ) -> Dataset:
+        """Create dataset with associated columns and metrics atomically"""
+        with db.session.begin():
+            # Create the dataset
+            dataset = Dataset(**dataset_properties)
+            db.session.add(dataset)
+            db.session.flush()  # Get the dataset ID
+
+            # Create columns
+            for column_props in columns:
+                column_props['dataset_id'] = dataset.id
+                column = TableColumn(**column_props)
+                db.session.add(column)
+
+            # Create metrics
+            for metric_props in metrics:
+                metric_props['dataset_id'] = dataset.id
+                metric = SqlMetric(**metric_props)
+                db.session.add(metric)
+
+            return dataset
+
+    @classmethod
+    def bulk_delete(cls, dataset_ids: List[int]) -> int:
+        """Delete multiple datasets and return count"""
+        with db.session.begin():
+            count = db.session.query(Dataset).filter(
+                Dataset.id.in_(dataset_ids)
+            ).delete(synchronize_session=False)
+            return count
+```
+
+### Query Methods
+
+```python
+class DashboardDAO:
+    @classmethod
+    def find_by_slug(cls, slug: str) -> Optional[Dashboard]:
+        """Find dashboard by slug"""
+        return db.session.query(Dashboard).filter_by(slug=slug).first()
+
+    @classmethod
+    def find_by_owner(cls, owner_id: int) -> List[Dashboard]:
+        """Find all dashboards owned by a user"""
+        return db.session.query(Dashboard).filter_by(
+            created_by_fk=owner_id
+        ).all()
+
+    @classmethod
+    def search(
+        cls,
+        query: str,
+        page: int = 0,
+        page_size: int = 25
+    ) -> Tuple[List[Dashboard], int]:
+        """Search dashboards with pagination"""
+        base_query = db.session.query(Dashboard).filter(
+            Dashboard.dashboard_title.ilike(f"%{query}%")
+        )
+
+        total_count = base_query.count()
+        dashboards = base_query.offset(page * page_size).limit(page_size).all()
+
+        return dashboards, total_count
+```
+
+### Error Handling in DAOs
+
+```python
+from sqlalchemy.exc import IntegrityError
+from superset.exceptions import DAOCreateFailedError, DAODeleteFailedError
+
+class DashboardDAO:
+    @classmethod
+    def create(cls, properties: Dict[str, Any]) -> Dashboard:
+        """Create a new dashboard with error handling"""
+        try:
+            with db.session.begin():
+                dashboard = Dashboard(**properties)
+                db.session.add(dashboard)
+                db.session.flush()
+                return dashboard
+        except IntegrityError as ex:
+            raise DAOCreateFailedError(str(ex)) from ex
+
+    @classmethod
+    def delete(cls, dashboard: Dashboard) -> None:
+        """Delete a dashboard with error handling"""
+        try:
+            with db.session.begin():
+                db.session.delete(dashboard)
+        except IntegrityError as ex:
+            raise DAODeleteFailedError(
+                f"Cannot delete dashboard {dashboard.id}: {str(ex)}"
+            ) from ex
+```
+
+## Best Practices
+
+### 1. Use Class Methods
+
+All DAO methods should be class methods (`@classmethod`) rather than instance methods:
+
+```python
+# ✅ Good
+class DashboardDAO:
+    @classmethod
+    def find_by_id(cls, dashboard_id: int) -> Optional[Dashboard]:
+        return db.session.query(Dashboard).filter_by(id=dashboard_id).first()
+
+# ❌ Avoid
+class DashboardDAO:
+    def find_by_id(self, dashboard_id: int) -> Optional[Dashboard]:
+        return db.session.query(Dashboard).filter_by(id=dashboard_id).first()
+```
+
+### 2. Use Context Managers for Transactions
+
+Always use context managers to ensure proper transaction handling:
+
+```python
+# ✅ Good - automatic commit/rollback
+@classmethod
+def create(cls, properties: Dict[str, Any]) -> Dashboard:
+    with db.session.begin():
+        dashboard = Dashboard(**properties)
+        db.session.add(dashboard)
+        return dashboard
+
+# ❌ Avoid - manual commit/rollback
+@classmethod
+def create(cls, properties: Dict[str, Any]) -> Dashboard:
+    try:
+        dashboard = Dashboard(**properties)
+        db.session.add(dashboard)
+        db.session.commit()
+        return dashboard
+    except Exception:
+        db.session.rollback()
+        raise
+```
+
+### 3. Use Descriptive Method Names
+
+Method names should clearly indicate the operation:
+
+```python
+# ✅ Good - clear CRUD operations
+create()
+update()
+delete()
+find_by_id()
+find_by_slug()
+
+# ❌ Avoid - ambiguous names
+save()
+remove()
+get()
+```
+
+### 4. Type Hints
+
+Always include type hints for parameters and return values:
+
+```python
+@classmethod
+def find_by_ids(cls, dashboard_ids: List[int]) -> List[Dashboard]:
+    """Find dashboards by list of IDs"""
+    return db.session.query(Dashboard).filter(
+        Dashboard.id.in_(dashboard_ids)
+    ).all()
+```
+
+### 5. Batch Operations
+
+Provide efficient batch operations when needed:
+
+```python
+@classmethod
+def bulk_update_published_status(
+    cls,
+    dashboard_ids: List[int],
+    published: bool
+) -> int:
+    """Update published status for multiple dashboards"""
+    with db.session.begin():
+        count = db.session.query(Dashboard).filter(
+            Dashboard.id.in_(dashboard_ids)
+        ).update(
+            {Dashboard.published: published},
+            synchronize_session=False
+        )
+        return count
+```
+
+## Testing DAOs
+
+### Unit Tests for DAOs
+
+```python
+import pytest
+from superset.dashboards.dao import DashboardDAO
+from superset.models.dashboard import Dashboard
+
+def test_dashboard_create(session):
+    """Test creating a dashboard"""
+    properties = {
+        "dashboard_title": "Test Dashboard",
+        "slug": "test-dashboard"
+    }
+
+    dashboard = DashboardDAO.create(properties)
+
+    assert dashboard.id is not None
+    assert dashboard.dashboard_title == "Test Dashboard"
+    assert dashboard.slug == "test-dashboard"
+
+def test_dashboard_find_by_slug(session):
+    """Test finding dashboard by slug"""
+    # Create test data
+    dashboard = Dashboard(
+        dashboard_title="Test Dashboard",
+        slug="test-dashboard"
+    )
+    session.add(dashboard)
+    session.commit()
+
+    # Test the DAO method
+    found_dashboard = DashboardDAO.find_by_slug("test-dashboard")
+
+    assert found_dashboard is not None
+    assert found_dashboard.dashboard_title == "Test Dashboard"
+
+def test_dashboard_delete(session):
+    """Test deleting a dashboard"""
+    dashboard = Dashboard(dashboard_title="Test Dashboard")
+    session.add(dashboard)
+    session.commit()
+    dashboard_id = dashboard.id
+
+    DashboardDAO.delete(dashboard)
+
+    deleted_dashboard = DashboardDAO.find_by_id(dashboard_id)
+    assert deleted_dashboard is None
+```
+
+### Integration Tests
+
+```python
+def test_create_dataset_with_columns_atomic(app_context):
+    """Test that creating dataset with columns is atomic"""
+    dataset_properties = {"table_name": "test_table"}
+    columns = [{"column_name": "col1"}, {"column_name": "col2"}]
+
+    # This should succeed completely or fail completely
+    dataset = DatasetDAO.create_with_columns_and_metrics(
+        dataset_properties, columns, []
+    )
+
+    assert dataset.id is not None
+    assert len(dataset.columns) == 2
+```

docs/developer_portal/guidelines/design-guidelines.md

@@ -0,0 +1,148 @@
+---
+title: Design Guidelines
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Design Guidelines
+
+This is an area to host resources and documentation supporting the evolution and proper use of Superset design system elements. If content is to be added to this section or requires revisiting, a proposal should be submitted to the `dev@superset.apache.org` email list with either a text proposal or a link to a GitHub issue providing the markdown that will be added to this wiki. The Dev list will have the chance to review the proposal and arrive at lazy consensus. A committer may then copy/paste the markdown to this wiki, and make it public.
+
+## Capitalization Guidelines
+
+### Sentence case
+
+Use sentence-case capitalization for everything in the UI (except these **).
+
+Sentence case is predominantly lowercase. Capitalize only the initial character of the first word, and other words that require capitalization, like:
+
+* **Proper nouns.** Objects in the product _are not_ considered proper nouns e.g. dashboards, charts, saved queries etc. Proprietary feature names eg. SQL Lab, Preset Manager _are_ considered proper nouns
+* **Acronyms** (e.g. CSS, HTML)
+* When referring to **UI labels that are themselves capitalized** from sentence case (e.g. page titles - Dashboards page, Charts page, Saved queries page, etc.)
+* User input that is reflected in the UI. E.g. a user-named a dashboard tab
+
+**Sentence case vs. Title case:** Title case: "A Dog Takes a Walk in Paris" Sentence case: "A dog takes a walk in Paris"
+
+**Why sentence case?**
+
+* It's generally accepted as the quickest to read
+* It's the easiest form to distinguish between common and proper nouns
+
+### How to refer to UI elements
+
+When writing about a UI element, use the same capitalization as used in the UI.
+
+For example, if an input field is labeled "Name" then you refer to this as the "Name input field". Similarly, if a button has the label "Save" in it, then it is correct to refer to the "Save button".
+
+Where a product page is titled "Settings", you refer to this in writing as follows: "Edit your personal information on the Settings page".
+
+Often a product page will have the same title as the objects it contains. In this case, refer to the page as it appears in the UI, and the objects as common nouns:
+
+* Upload a dashboard on the Dashboards page
+* Go to Dashboards
+* View dashboard
+* View all dashboards
+* Upload CSS templates on the CSS templates page
+* Queries that you save will appear on the Saved queries page
+* Create custom queries in SQL Lab then create dashboards
+
+### **Exceptions to sentence case:**
+
+1. Acronyms and abbreviations. Examples: URL, CSV, XML
+
+## Button Design Guidelines
+
+### Overview
+
+**Button variants:**
+
+1. Primary
+2. Secondary
+3. Tertiary
+4. Destructive
+
+**Button styles:** Each button variant has three styles:
+
+1. Text
+2. Icon+text
+3. Icon only
+
+Primary buttons have a fourth style: dropdown.
+
+**Usage:** Buttons communicate actions that users can take. Do not use for navigations, instead use links.
+
+**Purpose:**
+
+| Button Type | Description |
+|------------|-------------|
+| Primary | Main call to action, just 1 per page not including modals or main headers |
+| Secondary | Secondary actions, always in conjunction with a primary |
+| Tertiary | For less prominent actions; can be used in isolation or paired with a primary button |
+| Destructive | For actions that could have destructive effects on the user's data |
+
+## Error Message Design Guidelines
+
+### Definition
+
+Interface errors appear when the application can't do what the user wants, typically because:
+
+- The app technically fails to complete the request
+- The app can't understand the user input
+- The user tries to combine operations that can't work together
+
+In all cases, encountering errors increases user friction and frustration while trying to use the application. Providing an error experience that helps the user understand what happened and their next steps is key to building user confidence and increasing engagement.
+
+### General best practices
+
+**The best error experience is no error at all.** Before implementing error patterns, consider what you might do in the interface before the user would encounter an error to prevent it from happening at all. This might look like:
+
+- Providing tooltips or microcopy to help users understand how to interact with the interface
+- Disabling parts of the UI until desired conditions are met (e.g. disabling a Save button until mandatory fields in a form are completed)
+- Correcting an error automatically (e.g. autocorrecting spelling errors)
+
+**Only report errors users care about.** The only errors that should appear in the interface are errors that require user acknowledgement and action (even if that action is "try again later" or "contact support").
+
+**Do not start the user in an error state.** If user inputs are required to display an initial interface (e.g. a chart in Explore), use empty states or field highlighting to drive users to the required action.
+
+### Patterns
+
+#### Pattern selection
+
+Select one pattern per error (e.g. do not implement an inline and banner pattern for the same error).
+
+When the error... | Use...
+---------------- | ------
+Is directly related to a UI control | Inline error
+Is not directly related to a UI control | Banner error
+
+#### Inline
+
+Inline errors are used when the source of the error is directly related to a UI control (text input, selector, etc.) such as the user not populating a required field or entering a number in a text field.
+
+##### Anatomy
+
+Use the `LabeledErrorBoundInput` component for this error pattern.
+
+1. **Message** Provides direction on how to populate the input correctly.
+
+##### Implementation details
+
+- Where and when relevant, scroll the screen to the UI control with the error

docs/developer_portal/guidelines/frontend-style-guidelines.md

@@ -0,0 +1,44 @@
+---
+title: Frontend Style Guidelines
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Frontend Style Guidelines
+
+This is a list of statements that describe how we do frontend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for frontend quality and style.
+
+*   We develop using TypeScript.
+*   We use React for building components, and Redux to manage app/global state.
+    *   See: [Component Style Guidelines and Best Practices](./frontend/component-style-guidelines)
+*   We prefer functional components to class components and use hooks for local component state.
+*   We use [Ant Design](https://ant.design/) components from our component library whenever possible, only building our own custom components when it's required.
+*   We use [@emotion](https://emotion.sh/docs/introduction) to provide styling for our components, co-locating styling within component files.
+    *   See: [Emotion Styling Guidelines and Best Practices](./frontend/emotion-styling-guidelines)
+*   We use Jest for unit tests, React Testing Library for component tests, and Cypress for end-to-end tests.
+    *   See: [Testing Guidelines and Best Practices](./frontend/testing-guidelines)
+*   We add tests for every new component or file added to the frontend.
+*   We organize our repo so similar files live near each other, and tests are co-located with the files they test.
+*   We prefer small, easily testable files and components.
+*   We use ESLint and Prettier to automatically fix lint errors and format the code.
+    *   We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
+    *   If there's not a linting rule, we don't have a rule!
+*   We use [React Storybook](https://storybook.js.org/) and [Applitools](https://applitools.com/) to help preview/test and stabilize our components

docs/developer_portal/guidelines/frontend/component-style-guidelines.md

@@ -0,0 +1,258 @@
+---
+title: Component Style Guidelines and Best Practices
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Component Style Guidelines and Best Practices
+
+This documentation illustrates how we approach component development in Superset and provides examples to help you in writing new components or updating existing ones by following our community-approved standards.
+
+This guide is intended primarily for reusable components. Whenever possible, all new components should be designed with reusability in mind.
+
+## General Guidelines
+
+- We use [Ant Design](https://ant.design/) as our component library. Do not build a new component if Ant Design provides one but rather instead extend or customize what the library provides
+- Always style your component using Emotion and always prefer the theme variables whenever applicable. See: [Emotion Styling Guidelines and Best Practices](./emotion-styling-guidelines)
+- All components should be made to be reusable whenever possible
+- All components should follow the structure and best practices as detailed below
+
+## Directory and component structure
+
+```
+superset-frontend/src/components
+   {ComponentName}/
+      index.tsx
+      {ComponentName}.test.tsx
+      {ComponentName}.stories.tsx
+```
+
+**Components root directory:** Components that are meant to be re-used across different parts of the application should go in the `superset-frontend/src/components` directory. Components that are meant to be specific for a single part of the application should be located in the nearest directory where the component is used, for example, `superset-frontend/src/Explore/components`
+
+**Exporting the component:** All components within the `superset-frontend/src/components` directory should be exported from `superset-frontend/src/components/index.ts` to facilitate their imports by other components
+
+**Component directory name:** Use `PascalCase` for the component directory name
+
+**Storybook:** Components should come with a storybook file whenever applicable, with the following naming convention `{ComponentName}.stories.tsx`. More details about Storybook below
+
+**Unit and end-to-end tests:** All components should come with unit tests using Jest and React Testing Library. The file name should follow this naming convention `{ComponentName}.test.tsx.` Read the [Testing Guidelines and Best Practices](./testing-guidelines) for more details about tests
+
+## Component Development Best Practices
+
+### Use TypeScript
+
+All new components should be written in TypeScript. This helps catch errors early and provides better development experience with IDE support.
+
+```tsx
+interface ComponentProps {
+  title: string;
+  isVisible?: boolean;
+  onClose?: () => void;
+}
+
+export const MyComponent: React.FC<ComponentProps> = ({
+  title,
+  isVisible = true,
+  onClose
+}) => {
+  // Component implementation
+};
+```
+
+### Prefer Functional Components
+
+Use functional components with hooks instead of class components:
+
+```tsx
+// ✅ Good - Functional component with hooks
+export const MyComponent: React.FC<Props> = ({ data }) => {
+  const [loading, setLoading] = useState(false);
+
+  useEffect(() => {
+    // Effect logic
+  }, []);
+
+  return <div>{/* Component JSX */}</div>;
+};
+
+// ❌ Avoid - Class component
+class MyComponent extends React.Component {
+  // Class implementation
+}
+```
+
+### Follow Ant Design Patterns
+
+Extend Ant Design components rather than building from scratch:
+
+```tsx
+import { Button } from 'antd';
+import styled from '@emotion/styled';
+
+const StyledButton = styled(Button)`
+  // Custom styling using emotion
+`;
+```
+
+### Reusability and Props Design
+
+Design components with reusability in mind:
+
+```tsx
+interface ButtonProps {
+  variant?: 'primary' | 'secondary' | 'tertiary';
+  size?: 'small' | 'medium' | 'large';
+  loading?: boolean;
+  disabled?: boolean;
+  children: React.ReactNode;
+  onClick?: () => void;
+}
+
+export const CustomButton: React.FC<ButtonProps> = ({
+  variant = 'primary',
+  size = 'medium',
+  ...props
+}) => {
+  // Implementation
+};
+```
+
+## Testing Components
+
+Every component should include comprehensive tests:
+
+```tsx
+// MyComponent.test.tsx
+import { render, screen, fireEvent } from '@testing-library/react';
+import { MyComponent } from './MyComponent';
+
+test('renders component with title', () => {
+  render(<MyComponent title="Test Title" />);
+  expect(screen.getByText('Test Title')).toBeInTheDocument();
+});
+
+test('calls onClose when close button is clicked', () => {
+  const mockOnClose = jest.fn();
+  render(<MyComponent title="Test" onClose={mockOnClose} />);
+
+  fireEvent.click(screen.getByRole('button', { name: /close/i }));
+  expect(mockOnClose).toHaveBeenCalledTimes(1);
+});
+```
+
+## Storybook Stories
+
+Create stories for visual testing and documentation:
+
+```tsx
+// MyComponent.stories.tsx
+import type { Meta, StoryObj } from '@storybook/react';
+import { MyComponent } from './MyComponent';
+
+const meta: Meta<typeof MyComponent> = {
+  title: 'Components/MyComponent',
+  component: MyComponent,
+  parameters: {
+    layout: 'centered',
+  },
+  tags: ['autodocs'],
+};
+
+export default meta;
+type Story = StoryObj<typeof meta>;
+
+export const Default: Story = {
+  args: {
+    title: 'Default Component',
+    isVisible: true,
+  },
+};
+
+export const Hidden: Story = {
+  args: {
+    title: 'Hidden Component',
+    isVisible: false,
+  },
+};
+```
+
+## Performance Considerations
+
+### Use React.memo for Expensive Components
+
+```tsx
+import React, { memo } from 'react';
+
+export const ExpensiveComponent = memo<Props>(({ data }) => {
+  // Expensive rendering logic
+  return <div>{/* Component content */}</div>;
+});
+```
+
+### Optimize Re-renders
+
+Use `useCallback` and `useMemo` appropriately:
+
+```tsx
+export const OptimizedComponent: React.FC<Props> = ({ items, onSelect }) => {
+  const expensiveValue = useMemo(() => {
+    return items.reduce((acc, item) => acc + item.value, 0);
+  }, [items]);
+
+  const handleSelect = useCallback((id: string) => {
+    onSelect(id);
+  }, [onSelect]);
+
+  return <div>{/* Component content */}</div>;
+};
+```
+
+## Accessibility
+
+Ensure components are accessible:
+
+```tsx
+export const AccessibleButton: React.FC<Props> = ({ children, onClick }) => {
+  return (
+    <button
+      type="button"
+      aria-label="Descriptive label"
+      onClick={onClick}
+    >
+      {children}
+    </button>
+  );
+};
+```
+
+## Error Boundaries
+
+For components that might fail, consider error boundaries:
+
+```tsx
+export const SafeComponent: React.FC<Props> = ({ children }) => {
+  return (
+    <ErrorBoundary fallback={<div>Something went wrong</div>}>
+      {children}
+    </ErrorBoundary>
+  );
+};
+```

docs/developer_portal/guidelines/frontend/emotion-styling-guidelines.md

@@ -0,0 +1,346 @@
+---
+title: Emotion Styling Guidelines and Best Practices
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Emotion Styling Guidelines and Best Practices
+
+## Emotion Styling Guidelines
+
+### DO these things:
+
+- **DO** use `styled` when you want to include additional (nested) class selectors in your styles
+- **DO** use `styled` components when you intend to export a styled component for re-use elsewhere
+- **DO** use `css` when you want to amend/merge sets of styles compositionally
+- **DO** use `css` when you're making a small, or single-use set of styles for a component
+- **DO** move your style definitions from direct usage in the `css` prop to an external variable when they get long
+- **DO** prefer tagged template literals (`css={css\`...\`}`) over style objects wherever possible for maximum style portability/consistency
+- **DO** use `useTheme` to get theme variables
+
+### DON'T do these things:
+
+- **DON'T** use `styled` for small, single-use style tweaks that would be easier to read/review if they were inline
+- **DON'T** export incomplete Ant Design components
+
+## When to use `css` or `styled`
+
+### Use `css` for:
+
+1. **Small, single-use styles**
+```tsx
+import { css } from '@emotion/react';
+
+const MyComponent = () => (
+  <div
+    css={css`
+      margin: 8px;
+      padding: 16px;
+    `}
+  >
+    Content
+  </div>
+);
+```
+
+2. **Composing styles**
+```tsx
+const baseStyles = css`
+  padding: 16px;
+  border-radius: 4px;
+`;
+
+const primaryStyles = css`
+  ${baseStyles}
+  background-color: blue;
+  color: white;
+`;
+
+const secondaryStyles = css`
+  ${baseStyles}
+  background-color: gray;
+  color: black;
+`;
+```
+
+3. **Conditional styling**
+```tsx
+const MyComponent = ({ isActive }: { isActive: boolean }) => (
+  <div
+    css={[
+      baseStyles,
+      isActive && activeStyles,
+    ]}
+  >
+    Content
+  </div>
+);
+```
+
+### Use `styled` for:
+
+1. **Reusable components**
+```tsx
+import styled from '@emotion/styled';
+
+const StyledButton = styled.button`
+  padding: 12px 24px;
+  border: none;
+  border-radius: 4px;
+  background-color: ${({ theme }) => theme.colors.primary};
+  color: white;
+
+  &:hover {
+    background-color: ${({ theme }) => theme.colors.primaryDark};
+  }
+`;
+```
+
+2. **Components with complex nested selectors**
+```tsx
+const StyledCard = styled.div`
+  padding: 16px;
+  border: 1px solid ${({ theme }) => theme.colors.border};
+
+  .card-header {
+    font-weight: bold;
+    margin-bottom: 8px;
+  }
+
+  .card-content {
+    color: ${({ theme }) => theme.colors.text};
+
+    p {
+      margin-bottom: 12px;
+    }
+  }
+`;
+```
+
+3. **Extending Ant Design components**
+```tsx
+import { Button } from 'antd';
+import styled from '@emotion/styled';
+
+const CustomButton = styled(Button)`
+  border-radius: 8px;
+  font-weight: 600;
+
+  &.ant-btn-primary {
+    background: linear-gradient(45deg, #1890ff, #722ed1);
+  }
+`;
+```
+
+## Using Theme Variables
+
+Always use theme variables for consistent styling:
+
+```tsx
+import { useTheme } from '@emotion/react';
+
+const MyComponent = () => {
+  const theme = useTheme();
+
+  return (
+    <div
+      css={css`
+        background-color: ${theme.colors.grayscale.light5};
+        color: ${theme.colors.grayscale.dark2};
+        padding: ${theme.gridUnit * 4}px;
+        border-radius: ${theme.borderRadius}px;
+      `}
+    >
+      Content
+    </div>
+  );
+};
+```
+
+## Common Patterns
+
+### Responsive Design
+```tsx
+const ResponsiveContainer = styled.div`
+  display: flex;
+  flex-direction: column;
+
+  ${({ theme }) => theme.breakpoints.up('md')} {
+    flex-direction: row;
+  }
+`;
+```
+
+### Animation
+```tsx
+const FadeInComponent = styled.div`
+  opacity: 0;
+  transition: opacity 0.3s ease-in-out;
+
+  &.visible {
+    opacity: 1;
+  }
+`;
+```
+
+### Conditional Props
+```tsx
+interface StyledDivProps {
+  isHighlighted?: boolean;
+  size?: 'small' | 'medium' | 'large';
+}
+
+const StyledDiv = styled.div<StyledDivProps>`
+  padding: 16px;
+  background-color: ${({ isHighlighted, theme }) =>
+    isHighlighted ? theme.colors.primary : theme.colors.grayscale.light5};
+
+  ${({ size }) => {
+    switch (size) {
+      case 'small':
+        return css`font-size: 12px;`;
+      case 'large':
+        return css`font-size: 18px;`;
+      default:
+        return css`font-size: 14px;`;
+    }
+  }}
+`;
+```
+
+## Best Practices
+
+### 1. Use Semantic CSS Properties
+```tsx
+// ✅ Good - semantic property names
+const Header = styled.h1`
+  font-size: ${({ theme }) => theme.typography.sizes.xl};
+  margin-bottom: ${({ theme }) => theme.gridUnit * 4}px;
+`;
+
+// ❌ Avoid - magic numbers
+const Header = styled.h1`
+  font-size: 24px;
+  margin-bottom: 16px;
+`;
+```
+
+### 2. Group Related Styles
+```tsx
+// ✅ Good - grouped styles
+const Card = styled.div`
+  /* Layout */
+  display: flex;
+  flex-direction: column;
+  padding: ${({ theme }) => theme.gridUnit * 4}px;
+
+  /* Appearance */
+  background-color: ${({ theme }) => theme.colors.grayscale.light5};
+  border: 1px solid ${({ theme }) => theme.colors.grayscale.light2};
+  border-radius: ${({ theme }) => theme.borderRadius}px;
+
+  /* Typography */
+  font-family: ${({ theme }) => theme.typography.families.sansSerif};
+  color: ${({ theme }) => theme.colors.grayscale.dark2};
+`;
+```
+
+### 3. Extract Complex Styles
+```tsx
+// ✅ Good - extract complex styles to variables
+const complexGradient = css`
+  background: linear-gradient(
+    135deg,
+    ${({ theme }) => theme.colors.primary} 0%,
+    ${({ theme }) => theme.colors.secondary} 100%
+  );
+`;
+
+const GradientButton = styled.button`
+  ${complexGradient}
+  padding: 12px 24px;
+  border: none;
+  color: white;
+`;
+```
+
+### 4. Avoid Deep Nesting
+```tsx
+// ✅ Good - shallow nesting
+const Navigation = styled.nav`
+  .nav-item {
+    padding: 8px 16px;
+  }
+
+  .nav-link {
+    color: ${({ theme }) => theme.colors.text};
+    text-decoration: none;
+  }
+`;
+
+// ❌ Avoid - deep nesting
+const Navigation = styled.nav`
+  ul {
+    li {
+      a {
+        span {
+          color: blue; /* Too nested */
+        }
+      }
+    }
+  }
+`;
+```
+
+## Performance Tips
+
+### 1. Avoid Inline Functions in CSS
+```tsx
+// ✅ Good - external function
+const getBackgroundColor = (isActive: boolean, theme: any) =>
+  isActive ? theme.colors.primary : theme.colors.secondary;
+
+const Button = styled.button<{ isActive: boolean }>`
+  background-color: ${({ isActive, theme }) => getBackgroundColor(isActive, theme)};
+`;
+
+// ❌ Avoid - inline function (creates new function on each render)
+const Button = styled.button<{ isActive: boolean }>`
+  background-color: ${({ isActive, theme }) =>
+    isActive ? theme.colors.primary : theme.colors.secondary};
+`;
+```
+
+### 2. Use CSS Objects for Dynamic Styles
+```tsx
+// For highly dynamic styles, consider CSS objects
+const dynamicStyles = (props: Props) => ({
+  backgroundColor: props.color,
+  fontSize: `${props.size}px`,
+  // ... other dynamic properties
+});
+
+const DynamicComponent = (props: Props) => (
+  <div css={dynamicStyles(props)}>
+    Content
+  </div>
+);
+```

docs/developer_portal/guidelines/frontend/testing-guidelines.md

@@ -0,0 +1,297 @@
+---
+title: Testing Guidelines and Best Practices
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Testing Guidelines and Best Practices
+
+We feel that tests are an important part of a feature and not an additional or optional effort. That's why we colocate test files with functionality and sometimes write tests upfront to help validate requirements and shape the API of our components. Every new component or file added should have an associated test file with the `.test` extension.
+
+We use Jest, React Testing Library (RTL), and Cypress to write our unit, integration, and end-to-end tests. For each type, we have a set of best practices/tips described below:
+
+## Jest
+
+### Write simple, standalone tests
+
+The importance of simplicity is often overlooked in test cases. Clear, dumb code should always be preferred over complex ones. The test cases should be pretty much standalone and should not involve any external logic if not absolutely necessary. That's because you want the corpus of the tests to be easy to read and understandable at first sight.
+
+### Avoid nesting when you're testing
+
+Avoid the use of `describe` blocks in favor of inlined tests. If your tests start to grow and you feel the need to group tests, prefer to break them into multiple test files. Check this awesome [article](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing) written by [Kent C. Dodds](https://kentcdodds.com/) about this topic.
+
+### No warnings!
+
+Your tests shouldn't trigger warnings. This is really common when testing async functionality. It's really difficult to read test results when we have a bunch of warnings.
+
+## React Testing Library (RTL)
+
+### Keep accessibility in mind when writing your tests
+
+One of the most important points of RTL is accessibility and this is also a very important point for us. We should try our best to follow the RTL [Priority](https://testing-library.com/docs/queries/about/#priority) when querying for elements in our tests. `getByTestId` is not viewable by the user and should only be used when the element isn't accessible in any other way.
+
+### Don't use `act` unnecessarily
+
+`render` and `fireEvent` are already wrapped in `act`, so wrapping them in `act` again is a common mistake. Some solutions to the warnings related to async testing can be found in the RTL docs.
+
+## Example Test Structure
+
+```tsx
+// MyComponent.test.tsx
+import { render, screen, fireEvent, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { MyComponent } from './MyComponent';
+
+// ✅ Good - Simple, standalone test
+test('renders loading state initially', () => {
+  render(<MyComponent />);
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+});
+
+// ✅ Good - Tests user interaction
+test('calls onSubmit when form is submitted', async () => {
+  const user = userEvent.setup();
+  const mockOnSubmit = jest.fn();
+
+  render(<MyComponent onSubmit={mockOnSubmit} />);
+
+  await user.type(screen.getByLabelText('Username'), 'testuser');
+  await user.click(screen.getByRole('button', { name: 'Submit' }));
+
+  expect(mockOnSubmit).toHaveBeenCalledWith({ username: 'testuser' });
+});
+
+// ✅ Good - Tests async behavior
+test('displays error message when API call fails', async () => {
+  const mockFetch = jest.fn().mockRejectedValue(new Error('API Error'));
+  global.fetch = mockFetch;
+
+  render(<MyComponent />);
+
+  await waitFor(() => {
+    expect(screen.getByText('Error: API Error')).toBeInTheDocument();
+  });
+});
+```
+
+## Testing Best Practices
+
+### Use appropriate queries in priority order
+
+1. **Accessible to everyone**: `getByRole`, `getByLabelText`, `getByPlaceholderText`, `getByText`
+2. **Semantic queries**: `getByAltText`, `getByTitle`
+3. **Test IDs**: `getByTestId` (last resort)
+
+```tsx
+// ✅ Good - using accessible queries
+test('user can submit form', () => {
+  render(<LoginForm />);
+
+  const usernameInput = screen.getByLabelText('Username');
+  const passwordInput = screen.getByLabelText('Password');
+  const submitButton = screen.getByRole('button', { name: 'Log in' });
+
+  // Test implementation
+});
+
+// ❌ Avoid - using test IDs when better options exist
+test('user can submit form', () => {
+  render(<LoginForm />);
+
+  const usernameInput = screen.getByTestId('username-input');
+  const passwordInput = screen.getByTestId('password-input');
+  const submitButton = screen.getByTestId('submit-button');
+
+  // Test implementation
+});
+```
+
+### Test behavior, not implementation details
+
+```tsx
+// ✅ Good - tests what the user experiences
+test('shows success message after successful form submission', async () => {
+  render(<ContactForm />);
+
+  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com');
+  await userEvent.click(screen.getByRole('button', { name: 'Submit' }));
+
+  await waitFor(() => {
+    expect(screen.getByText('Message sent successfully!')).toBeInTheDocument();
+  });
+});
+
+// ❌ Avoid - testing implementation details
+test('calls setState when form is submitted', () => {
+  const component = shallow(<ContactForm />);
+  const instance = component.instance();
+  const spy = jest.spyOn(instance, 'setState');
+
+  instance.handleSubmit();
+  expect(spy).toHaveBeenCalled();
+});
+```
+
+### Mock external dependencies appropriately
+
+```tsx
+// Mock API calls
+jest.mock('../api/userService', () => ({
+  getUser: jest.fn(),
+  createUser: jest.fn(),
+}));
+
+// Mock components that aren't relevant to the test
+jest.mock('../Chart/Chart', () => {
+  return function MockChart() {
+    return <div data-testid="mock-chart">Chart Component</div>;
+  };
+});
+```
+
+## Async Testing Patterns
+
+### Testing async operations
+
+```tsx
+test('loads and displays user data', async () => {
+  const mockUser = { id: 1, name: 'John Doe' };
+  const mockGetUser = jest.fn().mockResolvedValue(mockUser);
+
+  render(<UserProfile getUserData={mockGetUser} />);
+
+  // Wait for the async operation to complete
+  await waitFor(() => {
+    expect(screen.getByText('John Doe')).toBeInTheDocument();
+  });
+
+  expect(mockGetUser).toHaveBeenCalledTimes(1);
+});
+```
+
+### Testing loading states
+
+```tsx
+test('shows loading spinner while fetching data', async () => {
+  const mockGetUser = jest.fn().mockImplementation(
+    () => new Promise(resolve => setTimeout(resolve, 100))
+  );
+
+  render(<UserProfile getUserData={mockGetUser} />);
+
+  expect(screen.getByText('Loading...')).toBeInTheDocument();
+
+  await waitFor(() => {
+    expect(screen.queryByText('Loading...')).not.toBeInTheDocument();
+  });
+});
+```
+
+## Component-Specific Testing
+
+### Testing form components
+
+```tsx
+test('validates required fields', async () => {
+  render(<RegistrationForm />);
+
+  const submitButton = screen.getByRole('button', { name: 'Register' });
+  await userEvent.click(submitButton);
+
+  expect(screen.getByText('Username is required')).toBeInTheDocument();
+  expect(screen.getByText('Email is required')).toBeInTheDocument();
+});
+```
+
+### Testing modals and overlays
+
+```tsx
+test('opens and closes modal', async () => {
+  render(<ModalContainer />);
+
+  const openButton = screen.getByRole('button', { name: 'Open Modal' });
+  await userEvent.click(openButton);
+
+  expect(screen.getByRole('dialog')).toBeInTheDocument();
+
+  const closeButton = screen.getByRole('button', { name: 'Close' });
+  await userEvent.click(closeButton);
+
+  expect(screen.queryByRole('dialog')).not.toBeInTheDocument();
+});
+```
+
+### Testing with context providers
+
+```tsx
+const renderWithTheme = (component: React.ReactElement) => {
+  return render(
+    <ThemeProvider theme={mockTheme}>
+      {component}
+    </ThemeProvider>
+  );
+};
+
+test('applies theme colors correctly', () => {
+  renderWithTheme(<ThemedButton />);
+
+  const button = screen.getByRole('button');
+  expect(button).toHaveStyle({
+    backgroundColor: mockTheme.colors.primary,
+  });
+});
+```
+
+## Performance Testing
+
+### Testing with large datasets
+
+```tsx
+test('handles large lists efficiently', () => {
+  const largeDataset = Array.from({ length: 10000 }, (_, i) => ({
+    id: i,
+    name: `Item ${i}`,
+  }));
+
+  const { container } = render(<VirtualizedList items={largeDataset} />);
+
+  // Should only render visible items
+  const renderedItems = container.querySelectorAll('[data-testid="list-item"]');
+  expect(renderedItems.length).toBeLessThan(100);
+});
+```
+
+## Testing Accessibility
+
+```tsx
+test('is accessible to screen readers', () => {
+  render(<AccessibleForm />);
+
+  const form = screen.getByRole('form');
+  const inputs = screen.getAllByRole('textbox');
+
+  inputs.forEach(input => {
+    expect(input).toHaveAttribute('aria-label');
+  });
+
+  expect(form).toHaveAttribute('aria-describedby');
+});
+```

docs/developer_portal/guides/command-palette.md

@@ -0,0 +1,61 @@
+---
+title: Command Palette Integration
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Command Palette Integration
+
+🚧 **Coming Soon** 🚧
+
+Learn how to integrate your plugin with Superset's command palette to provide quick access to plugin functionality.
+
+## Topics to be covered:
+
+- Understanding the command palette architecture
+- Registering custom commands
+- Command categories and organization
+- Keyboard shortcuts and hotkeys
+- Dynamic command generation
+- Command context and availability
+- Icon and description customization
+- Command execution and callbacks
+- Search and filtering integration
+- Command palette theming
+
+## Command Types
+
+- **Navigation commands** - Quick navigation to plugin views
+- **Action commands** - Execute plugin-specific actions
+- **Creation commands** - Create new charts, dashboards, or data sources
+- **Configuration commands** - Quick access to settings
+- **Help commands** - Documentation and support links
+
+## Implementation Patterns
+
+- Command registration lifecycle
+- Async command execution
+- Context-aware command availability
+- Command result handling
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/guides/custom-editors.md

@@ -0,0 +1,64 @@
+---
+title: Custom Editors
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Custom Editors
+
+🚧 **Coming Soon** 🚧
+
+Build specialized editing interfaces for data manipulation, query building, and configuration management.
+
+## Topics to be covered:
+
+- Editor component architecture
+- Syntax highlighting and code completion
+- Real-time validation and error detection
+- Undo/redo functionality
+- Collaborative editing features
+- Custom language support
+- Editor extensions and plugins
+- Integration with Superset's SQL Lab
+- File and document management
+- Export and import capabilities
+
+## Editor Types
+
+- **SQL query editors** - Enhanced database query interfaces
+- **Configuration editors** - JSON, YAML, and custom config formats
+- **Formula editors** - Mathematical and business logic expressions
+- **Chart configuration** - Visual chart property editors
+- **Data transformation** - ETL pipeline builders
+- **Dashboard layout editors** - Drag-and-drop interface builders
+
+## Advanced Features
+
+- Monaco Editor integration
+- CodeMirror customization
+- Custom language definitions
+- Intelligent autocomplete
+- Syntax error highlighting
+- Multi-cursor editing
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/guides/overview.md

@@ -0,0 +1,58 @@
+---
+title: Development Guides Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Development Guides Overview
+
+🚧 **Coming Soon** 🚧
+
+This section contains practical guides and tutorials for common plugin development scenarios and advanced techniques.
+
+## Topics to be covered:
+
+- Step-by-step development tutorials
+- Common development patterns and solutions
+- Integration with Superset's core features
+- Advanced plugin architectures
+- Performance optimization techniques
+- Debugging and troubleshooting guides
+- Migration guides for plugin updates
+- Best practices and coding standards
+
+## Available Guides
+
+- **Command Palette Integration** - Add custom commands and shortcuts
+- **WebViews and Embedded Content** - Display external content in Superset
+- **Custom Editors** - Build specialized data editing interfaces
+- **Virtual Documents** - Handle dynamic content and data sources
+
+## Guide Categories
+
+- **Beginner** - Getting started with basic concepts
+- **Intermediate** - Common patterns and integrations
+- **Advanced** - Complex architectures and performance optimization
+- **Troubleshooting** - Debugging and problem-solving
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/guides/virtual-documents.md

@@ -0,0 +1,63 @@
+---
+title: Virtual Documents
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Virtual Documents
+
+🚧 **Coming Soon** 🚧
+
+Learn how to create and manage virtual documents that represent dynamic content and data sources within Superset.
+
+## Topics to be covered:
+
+- Virtual document concepts and architecture
+- Dynamic content generation
+- Document lifecycle management
+- Data source abstraction
+- Real-time document updates
+- Document caching and performance
+- Version control and history
+- Collaborative document editing
+- Document search and indexing
+- Export and sharing capabilities
+
+## Virtual Document Types
+
+- **Dynamic reports** - Auto-updating analytical reports
+- **Data lineage documents** - Interactive data flow visualization
+- **Configuration schemas** - Dynamic form generation
+- **API documentation** - Auto-generated from code
+- **Data dictionaries** - Searchable metadata catalogs
+- **Query libraries** - Shared SQL query collections
+
+## Implementation Patterns
+
+- Document provider interfaces
+- Content resolution strategies
+- Change detection and synchronization
+- Document serialization formats
+- Access control and permissions
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/guides/webviews.md

@@ -0,0 +1,61 @@
+---
+title: WebViews and Embedded Content
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# WebViews and Embedded Content
+
+🚧 **Coming Soon** 🚧
+
+Explore how to embed external web content, iframes, and interactive applications within your Superset plugins.
+
+## Topics to be covered:
+
+- Creating secure WebView components
+- iframe integration and sandboxing
+- Cross-origin communication patterns
+- Authentication and session management
+- WebView lifecycle and memory management
+- Event handling between parent and child
+- Responsive WebView sizing
+- Loading states and error handling
+- Performance optimization for embedded content
+- Security considerations and CSP compliance
+
+## WebView Use Cases
+
+- **External dashboards** - Embed third-party analytics tools
+- **Interactive documentation** - Live code examples and tutorials
+- **Configuration panels** - External admin interfaces
+- **Data exploration tools** - Specialized analysis applications
+- **Custom visualizations** - Complex D3.js or other web-based charts
+
+## Security Features
+
+- Content Security Policy (CSP) integration
+- Cross-origin resource sharing (CORS) handling
+- Secure message passing
+- Domain allowlisting
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/index.md

@@ -1,126 +1,136 @@
 ---
-title: Developer Portal
+title: Overview
 sidebar_position: 1
-hide_title: true
 ---
 
 <!--
-    Licensed to the Apache Software Foundation (ASF) under one
-    or more contributor license agreements.  See the NOTICE file
-    distributed with this work for additional information
-    regarding copyright ownership.  The ASF licenses this file
-    to you under the Apache License, Version 2.0 (the
-    "License"); you may not use this file except in compliance
-    with the License.  You may obtain a copy of the License at
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
 
-      http://www.apache.org/licenses/LICENSE-2.0
+  http://www.apache.org/licenses/LICENSE-2.0
 
-    Unless required by applicable law or agreed to in writing,
-    software distributed under the License is distributed on an
-    "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-    KIND, either express or implied.  See the License for the
-    specific language governing permissions and limitations
-    under the License.
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
 -->
 
-# Superset Developer Portal
+# Apache Superset Developer Portal
 
-Welcome to the Apache Superset Developer Portal! This is your comprehensive guide to extending and customizing Superset through our new extension architecture.
+Welcome to the Apache Superset Developer Portal - your comprehensive resource for contributing to and extending Apache Superset.
 
-## What are Superset Extensions?
+## 🚀 Quick Start
 
-Superset Extensions provide a powerful way to enhance and customize Apache Superset without modifying the core codebase. Following the successful model pioneered by VS Code, our extension architecture enables developers to:
+### New Contributors
+- [Contributing Overview](/developer_portal/contributing/overview)
+- [Development Setup](/developer_portal/contributing/development-setup)
+- [Your First PR](/developer_portal/contributing/submitting-pr)
 
-- **Add custom features** to SQL Lab and other Superset modules
-- **Create reusable components** that can be shared across organizations
-- **Integrate external tools** and services seamlessly
-- **Customize workflows** to match your team's specific needs
+### Extension Development
+- [Extension Project Structure](/developer_portal/extensions/extension-project-structure)
+- [Extension Architecture](/developer_portal/architecture/overview)
+- [Extension Architecture](/developer_portal/extensions/high-level-architecture)
 
-## Why Extensions?
+## 📚 Documentation Sections
 
-As Superset has grown, we've recognized the need for a more modular architecture that allows:
+### Extensions
+Learn how to build powerful extensions that enhance Superset's capabilities. This section covers the extension architecture, development patterns, and deployment strategies. You'll find comprehensive guides on creating frontend contributions, managing extension lifecycles, and understanding security implications.
 
-- **Innovation without fragmentation** - Build features without forking the codebase
-- **Community-driven development** - Share and reuse extensions across organizations
-- **Stable APIs** - Develop against versioned, well-documented interfaces
-- **Rapid iteration** - Deploy custom features without waiting for core releases
+### Testing
+Comprehensive testing strategies for Superset development. This section covers frontend testing with Jest and React Testing Library, backend testing with pytest, end-to-end testing with Playwright, and CI/CD pipeline best practices.
 
-## Key Features
+### Contributing to Superset
+Everything you need to contribute to the Apache Superset project. This section includes community guidelines, development environment setup, pull request processes, code review workflows, issue reporting guidelines, and Apache release procedures. You'll also find style guidelines for both frontend and backend development.
 
-### 🎯 Well-Defined Extension Points
+## 🛠️ Development Resources
 
-Extensions can contribute to specific areas of Superset:
-- SQL Lab panels (left, right, bottom, editor)
-- Custom commands and menu items
-- Status bar components
-- API endpoints and backend functionality
+### Prerequisites
+- **Python**: 3.9, 3.10, or 3.11
+- **Node.js**: 18.x or 20.x
+- **npm**: 9.x or 10.x
+- **Git**: Basic understanding
+- **React/TypeScript**: For frontend development
+- **Flask/SQLAlchemy**: For backend development
 
-### 🔧 Modern Development Experience
+### Key Technologies
+- **Frontend**: React, TypeScript, Ant Design, Redux
+- **Backend**: Flask, SQLAlchemy, Celery, Redis
+- **Build Tools**: Webpack, Babel, npm/yarn
+- **Testing**: Jest, Pytest, Playwright
+- **CI/CD**: GitHub Actions, pre-commit
 
-- **CLI tools** for scaffolding, building, and packaging
-- **Hot reloading** during development
-- **TypeScript support** with full type safety
-- **Module Federation** for dynamic loading
+## 🤝 Community
 
-### 📦 Simple Distribution
+### Get Help
+- **[Slack](https://apache-superset.slack.com)** - Join #development, #troubleshooting, or #beginners
+- **[GitHub Discussions](https://github.com/apache/superset/discussions)** - Ask questions and share ideas
+- **[Mailing Lists](https://lists.apache.org/list.html?dev@superset.apache.org)** - Development discussions
 
-- Package extensions as `.supx` files
-- Upload via REST API or UI
-- Automatic activation and lifecycle management
-- Version compatibility checking
+### Contribute
+- **[Good First Issues](https://github.com/apache/superset/labels/good%20first%20issue)** - Start here!
+- **[Help Wanted](https://github.com/apache/superset/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22)** - Issues needing help
+- **[Roadmap](https://github.com/orgs/apache/projects/180)** - See what's planned
 
-## Getting Started
+## 📖 Additional Resources
 
-Ready to build your first extension? Check out our [Getting Started Guide](./getting-started) to:
+### External Documentation
+- **[User Documentation](https://superset.apache.org/docs/intro)** - Using Superset
+- **[API Documentation](https://superset.apache.org/docs/api)** - REST API reference
+- **[Configuration Guide](https://superset.apache.org/docs/configuration/configuring-superset)** - Setup and configuration
 
-1. Set up your development environment
-2. Create your first extension
-3. Test it locally
-4. Package and deploy it
+### Important Files
+- **[CONTRIBUTING.md](https://github.com/apache/superset/blob/master/CONTRIBUTING.md)** - Contribution guidelines
+- **[CLAUDE.md](https://github.com/apache/superset/blob/master/CLAUDE.md)** - LLM development guide
+- **[UPDATING.md](https://github.com/apache/superset/blob/master/UPDATING.md)** - Breaking changes log
 
-## Architecture Overview
+## 🎯 Where to Start?
 
-Our extension architecture is built on several key principles:
+<table>
+<tr>
+<td width="50%">
 
-- **Lean Core**: Keep Superset's core minimal and delegate features to extensions
-- **Explicit APIs**: Clear, versioned interfaces for extension interactions
-- **Lazy Loading**: Extensions load only when needed for optimal performance
-- **Security First**: Extensions run with appropriate permissions and sandboxing
+**I want to contribute code**
+1. [Set up development environment](/developer_portal/contributing/development-setup)
+2. [Find a good first issue](https://github.com/apache/superset/labels/good%20first%20issue)
+3. [Submit your first PR](/developer_portal/contributing/submitting-pr)
 
-Learn more in our [Architecture Documentation](./architecture/overview).
+</td>
+<td width="50%">
 
-## Current Status
+**I want to build an extension**
+1. [Learn the architecture](/developer_portal/architecture/overview)
+2. [Learn extension structure](/developer_portal/extensions/extension-project-structure)
+3. [Explore architecture](/developer_portal/extensions/high-level-architecture)
 
-The extension architecture is currently in active development. The initial focus is on SQL Lab extensions, with plans to expand to:
+</td>
+</tr>
+<tr>
+<td>
 
-- Dashboard extensions
-- Chart plugins (enhanced from current system)
-- Database connectors
-- Security providers
+**I found a bug**
+1. [Search existing issues](https://github.com/apache/superset/issues)
+2. [Report the bug](/developer_portal/contributing/issue-reporting)
+3. [Submit a fix](/developer_portal/contributing/submitting-pr)
 
-## Example: Dataset References Extension
+</td>
+<td>
 
-See the extension system in action with our Dataset References example, which adds a SQL Lab panel showing:
+**I need help**
+1. [Check the FAQ](https://superset.apache.org/docs/frequently-asked-questions)
+2. [Ask in Slack](https://apache-superset.slack.com)
+3. [Start a discussion](https://github.com/apache/superset/discussions)
 
-- Tables referenced in queries
-- Table owners for permission requests  
-- Last available partitions
-- Estimated row counts
-
-## Join the Community
-
-- **Contribute**: Help shape the future of Superset extensions
-- **Share**: Publish your extensions for others to use
-- **Learn**: Explore extensions built by the community
-
-## Quick Links
-
-- [Getting Started Guide](./getting-started)
-- [Extension Architecture](./architecture/overview)
-- [API Reference](./api/frontend)
-- [CLI Documentation](./cli/overview)
-- [Examples](./examples)
+</td>
+</tr>
+</table>
 
 ---
 
-*The Superset extension architecture is inspired by the successful model of VS Code Extensions, bringing similar flexibility and power to the data exploration domain.*
+Welcome to the Apache Superset community! We're excited to have you contribute. 🎉

docs/developer_portal/references/activation-events.md

@@ -0,0 +1,549 @@
+---
+title: Activation Events
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Activation Events
+
+Activation events control when your extension is loaded and activated. Extensions should specify activation events to ensure they're only loaded when needed, improving Superset's startup performance.
+
+## Overview
+
+Extensions are activated lazily - they're loaded only when certain conditions are met. This is controlled by the `activationEvents` field in your `extension.json`:
+
+```json
+{
+  "activationEvents": [
+    "onCommand:myExtension.start",
+    "onView:sqllab.panels",
+    "onLanguage:sql"
+  ]
+}
+```
+
+## Activation Event Types
+
+### onCommand
+
+Activated when a specific command is invoked:
+
+```json
+"activationEvents": [
+  "onCommand:myExtension.analyze",
+  "onCommand:myExtension.export"
+]
+```
+
+The extension activates when any of its commands are executed, either through:
+- Command palette
+- Menu items
+- Keyboard shortcuts
+- API calls
+
+### onView
+
+Activated when a specific view becomes visible:
+
+```json
+"activationEvents": [
+  "onView:sqllab.panels",
+  "onView:dashboard.widgets"
+]
+```
+
+**Available Views**:
+- `sqllab.panels` - SQL Lab side panels
+- `sqllab.bottomPanels` - SQL Lab bottom panels
+
+**TODO: Future Views**:
+- `dashboard.widgets` - Dashboard widget areas
+- `chart.toolbar` - Chart toolbar views
+- `explore.panels` - Explore view panels
+
+### onLanguage
+
+Activated when a file of a specific language is opened:
+
+```json
+"activationEvents": [
+  "onLanguage:sql",
+  "onLanguage:python"
+]
+```
+
+Useful for extensions that provide:
+- Language-specific features
+- Syntax highlighting
+- Code completion
+- Linting
+
+### workspaceContains
+
+Activated when the workspace contains files matching a pattern:
+
+```json
+"activationEvents": [
+  "workspaceContains:**/*.sql",
+  "workspaceContains:**/.supersetrc",
+  "workspaceContains:**/superset_config.py"
+]
+```
+
+Uses glob patterns to detect:
+- Configuration files
+- Project types
+- Specific file structures
+
+### onStartupFinished
+
+Activated after Superset has fully started:
+
+```json
+"activationEvents": [
+  "onStartupFinished"
+]
+```
+
+Use for extensions that:
+- Don't need immediate activation
+- Provide background services
+- Monitor system events
+
+### Star Activation (*)
+
+Always activate (not recommended):
+
+```json
+"activationEvents": ["*"]
+```
+
+⚠️ **Warning**: This impacts startup performance. Only use when absolutely necessary.
+
+## Extension Lifecycle
+
+### 1. Registration
+
+When Superset starts or an extension is installed:
+
+```typescript
+// Extension is registered but not loaded
+{
+  id: 'myExtension',
+  state: 'unloaded',
+  activationEvents: ['onCommand:myExtension.start']
+}
+```
+
+### 2. Activation Trigger
+
+When an activation event occurs:
+
+```typescript
+// Event triggered
+eventBus.emit('command:myExtension.start');
+
+// Extension manager checks activation events
+if (extension.activationEvents.includes('onCommand:myExtension.start')) {
+  activateExtension(extensionId);
+}
+```
+
+### 3. Loading
+
+Extension assets are loaded:
+
+```typescript
+async function loadExtension(extensionId: string) {
+  // Load frontend assets
+  await loadRemoteEntry(extension.remoteEntry);
+
+  // Load backend modules (if applicable)
+  await loadBackendModules(extension.backendModules);
+
+  return extension;
+}
+```
+
+### 4. Activation
+
+The `activate` function is called:
+
+```typescript
+export async function activate(context: ExtensionContext) {
+  console.log('Extension activating');
+
+  // Register contributions
+  const view = context.registerView(...);
+  const command = context.registerCommand(...);
+
+  // Store disposables for cleanup
+  context.subscriptions.push(view, command);
+
+  // Perform initialization
+  await initialize();
+
+  console.log('Extension activated');
+}
+```
+
+### 5. Active State
+
+Extension is fully operational:
+
+```typescript
+{
+  id: 'myExtension',
+  state: 'activated',
+  exports: { /* exposed APIs */ }
+}
+```
+
+### 6. Deactivation
+
+When extension is disabled or Superset shuts down:
+
+```typescript
+export async function deactivate() {
+  console.log('Extension deactivating');
+
+  // Cleanup resources
+  await cleanup();
+
+  // Subscriptions are automatically disposed
+  console.log('Extension deactivated');
+}
+```
+
+## Activation Strategies
+
+### Lazy Activation (Recommended)
+
+Activate only when needed:
+
+```json
+{
+  "activationEvents": [
+    "onCommand:myExtension.start",
+    "onView:myExtension.panel"
+  ]
+}
+```
+
+Benefits:
+- ✅ Fast startup
+- ✅ Lower memory usage
+- ✅ Better performance
+
+### Eager Activation
+
+Activate on startup for critical features:
+
+```json
+{
+  "activationEvents": [
+    "onStartupFinished"
+  ]
+}
+```
+
+Use cases:
+- Authentication providers
+- Security extensions
+- Core infrastructure
+
+### Conditional Activation
+
+Activate based on workspace:
+
+```json
+{
+  "activationEvents": [
+    "workspaceContains:**/superset_config.py",
+    "workspaceContains:**/*.sql"
+  ]
+}
+```
+
+Benefits:
+- Context-aware activation
+- Project-specific features
+- Automatic detection
+
+## Multiple Activation Events
+
+Extensions can specify multiple events (OR logic):
+
+```json
+{
+  "activationEvents": [
+    "onCommand:myExtension.start",
+    "onCommand:myExtension.configure",
+    "onView:sqllab.panels",
+    "onLanguage:sql",
+    "workspaceContains:**/*.myext"
+  ]
+}
+```
+
+The extension activates when **any** event occurs.
+
+## Performance Considerations
+
+### Do's ✅
+
+1. **Use specific activation events**
+```json
+"activationEvents": ["onCommand:myExtension.specific"]
+```
+
+2. **Defer heavy initialization**
+```typescript
+export async function activate(context) {
+  // Quick registration
+  context.registerCommand('myExtension.heavy', async () => {
+    // Heavy work only when command is used
+    await doHeavyWork();
+  });
+}
+```
+
+3. **Load resources on demand**
+```typescript
+let heavyModule;
+
+export async function activate(context) {
+  context.registerCommand('myExtension.feature', async () => {
+    // Lazy load when needed
+    heavyModule = heavyModule || await import('./heavy');
+    heavyModule.execute();
+  });
+}
+```
+
+### Don'ts ❌
+
+1. **Avoid star activation**
+```json
+// Bad - activates always
+"activationEvents": ["*"]
+```
+
+2. **Don't block activation**
+```typescript
+// Bad - blocks activation
+export async function activate(context) {
+  await longRunningOperation(); // Blocks
+}
+
+// Good - defer work
+export async function activate(context) {
+  setImmediate(() => longRunningOperation());
+}
+```
+
+3. **Avoid unnecessary events**
+```json
+// Bad - too many events
+"activationEvents": [
+  "onStartupFinished",
+  "onCommand:*",
+  "onView:*"
+]
+```
+
+## Testing Activation Events
+
+### Manual Testing
+
+1. **Check activation timing**:
+```typescript
+export async function activate(context) {
+  console.time('activation');
+  // ... activation code
+  console.timeEnd('activation');
+}
+```
+
+2. **Verify event triggers**:
+```typescript
+// In browser console
+superset.extensions.getExtension('myExtension').state
+// Should be 'unloaded' before event
+
+// Trigger event
+superset.commands.executeCommand('myExtension.start');
+
+// Check again
+superset.extensions.getExtension('myExtension').state
+// Should be 'activated' after event
+```
+
+### Automated Testing
+
+```typescript
+describe('Extension Activation', () => {
+  it('should activate on command', async () => {
+    const extension = await loadExtension('myExtension');
+
+    expect(extension.state).toBe('unloaded');
+
+    await commands.executeCommand('myExtension.start');
+
+    expect(extension.state).toBe('activated');
+  });
+
+  it('should not activate on unrelated event', async () => {
+    const extension = await loadExtension('myExtension');
+
+    await commands.executeCommand('unrelated.command');
+
+    expect(extension.state).toBe('unloaded');
+  });
+});
+```
+
+## Debugging Activation
+
+### Enable Debug Logging
+
+```typescript
+// In extension
+const DEBUG = true;
+
+export async function activate(context) {
+  if (DEBUG) {
+    console.log('[MyExtension] Activating', {
+      extensionId: context.extensionId,
+      timestamp: new Date().toISOString()
+    });
+  }
+}
+```
+
+### Monitor Activation Events
+
+```typescript
+// In browser console
+superset.events.on('extension:activating', (e) => {
+  console.log('Extension activating:', e.extensionId);
+});
+
+superset.events.on('extension:activated', (e) => {
+  console.log('Extension activated:', e.extensionId);
+});
+```
+
+### Common Issues
+
+**Extension not activating:**
+- Check activation events are correct
+- Verify event is being triggered
+- Check browser console for errors
+- Ensure extension is enabled
+
+**Extension activating too early:**
+- Review activation events
+- Consider using more specific events
+- Check for star activation
+
+**Extension activating multiple times:**
+- Check for duplicate event registrations
+- Verify deactivation cleanup
+- Review activation logic
+
+## Best Practices
+
+1. **Choose minimal activation events** - Only what's necessary
+2. **Defer expensive operations** - Don't block activation
+3. **Use specific events** - Avoid broad patterns
+4. **Test activation timing** - Ensure good performance
+5. **Document activation requirements** - Help users understand
+6. **Handle activation failures** - Graceful error handling
+7. **Clean up on deactivation** - Prevent memory leaks
+8. **Log activation in debug mode** - Aid troubleshooting
+9. **Consider user experience** - Balance performance and features
+10. **Version activation events** - Plan for changes
+
+## Future Activation Events
+
+These activation events are planned for future releases:
+
+- `onUri` - Custom URI schemes
+- `onWebviewPanel` - Webview visibility
+- `onFileSystem` - File system providers
+- `onDebug` - Debug sessions
+- `onTaskType` - Task providers
+- `onNotebook` - Notebook documents
+- `onAuthentication` - Auth providers
+- `onCustomEditor` - Custom editors
+- `onTerminalProfile` - Terminal profiles
+
+## Migration Guide
+
+### From Always Active to Lazy
+
+Before (always active):
+```json
+{
+  "activationEvents": ["*"]
+}
+```
+
+After (lazy activation):
+```json
+{
+  "activationEvents": [
+    "onCommand:myExtension.command1",
+    "onCommand:myExtension.command2",
+    "onView:myExtension.view"
+  ]
+}
+```
+
+### Adding New Activation Events
+
+When adding features:
+```json
+{
+  "version": "1.0.0",
+  "activationEvents": [
+    "onCommand:myExtension.oldCommand"
+  ]
+}
+
+// Version 1.1.0 - Added new feature
+{
+  "version": "1.1.0",
+  "activationEvents": [
+    "onCommand:myExtension.oldCommand",
+    "onCommand:myExtension.newCommand",  // New
+    "onView:myExtension.panel"            // New
+  ]
+}
+```
+
+## Related Documentation
+
+- [Extension Manifest](/developer_portal/references/manifest)
+- [Lifecycle Management](/developer_portal/extensions/lifecycle-management)
+- [Contribution Points](/developer_portal/references/contribution-points)
+- [Architecture Overview](/developer_portal/architecture/overview)

docs/developer_portal/references/api.md

@@ -0,0 +1,101 @@
+---
+title: API Reference
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# API Reference
+
+🚧 **Coming Soon** 🚧
+
+Complete API documentation for all Superset plugin development interfaces and services.
+
+## Topics to be covered:
+
+- Core plugin development APIs
+- Chart and visualization APIs
+- Data transformation and query APIs
+- UI component and theming APIs
+- Event handling and lifecycle APIs
+- Configuration and settings APIs
+- Security and authentication APIs
+- Performance and monitoring APIs
+- Utility functions and helpers
+- TypeScript type definitions
+
+## API Categories
+
+### Core Plugin APIs
+
+#### Plugin Registration
+```typescript
+// Plugin registration interface
+interface PluginConfig {
+  name: string;
+  version: string;
+  components: ComponentRegistry;
+  metadata: PluginMetadata;
+}
+
+// registerPlugin function
+function registerPlugin(config: PluginConfig): void;
+```
+
+#### Plugin Lifecycle
+- `onActivate()` - Plugin activation hook
+- `onDeactivate()` - Plugin deactivation hook
+- `onUpdate()` - Plugin update hook
+- `onConfigChange()` - Configuration change hook
+
+### Chart Development APIs
+
+#### Chart Component Interface
+```typescript
+interface ChartComponent {
+  render(props: ChartProps): JSX.Element;
+  transformProps(chartProps: ChartProps): TransformedProps;
+  buildQuery(formData: FormData): Query;
+}
+```
+
+#### Data Transformation
+- `transformProps()` - Data transformation function
+- `buildQuery()` - Query building function
+- `formatData()` - Data formatting utilities
+- `validateData()` - Data validation helpers
+
+### UI and Theming APIs
+
+#### Theme Provider
+- `useTheme()` - Theme context hook
+- `ThemeProvider` - Theme provider component
+- `createTheme()` - Theme creation utility
+- `mergeThemes()` - Theme composition function
+
+#### Component Library
+- Button components and variants
+- Form controls and inputs
+- Layout and grid components
+- Data display components
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/references/contribution-points.md

@@ -0,0 +1,475 @@
+---
+title: Contribution Points
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Contribution Points Reference
+
+Contribution points define where and how extensions can add functionality to Apache Superset. Extensions declare their contributions in the `extension.json` manifest file.
+
+## Views
+
+Views are UI components that appear in designated areas of Superset.
+
+### SQL Lab Panels
+
+Extensions can contribute panels to SQL Lab:
+
+```json
+"contributions": {
+  "views": {
+    "sqllab.panels": [
+      {
+        "id": "myExtension.dataPanel",
+        "name": "Data Explorer",
+        "icon": "DatabaseOutlined",
+        "when": "sqllab.connected"
+      }
+    ]
+  }
+}
+```
+
+**Properties**:
+- `id` - Unique view identifier
+- `name` - Display name in UI
+- `icon` - Ant Design icon name
+- `when` - Conditional visibility
+
+**Available Locations**:
+- `sqllab.panels` - Side panels in SQL Lab
+- `sqllab.bottomPanels` - Bottom panels below editor
+
+**TODO: Future Locations**:
+- `dashboard.widgets` - Dashboard widget areas
+- `chart.panels` - Chart editor panels
+- `explore.sections` - Explore view sections
+
+### View Registration
+
+In your extension code:
+
+```typescript
+export function activate(context: ExtensionContext) {
+  const view = context.registerView(
+    'myExtension.dataPanel',
+    <DataExplorerPanel />
+  );
+
+  context.subscriptions.push(view);
+}
+```
+
+## Commands
+
+Commands are actions that can be invoked by users or other extensions.
+
+### Command Definition
+
+```json
+"commands": [
+  {
+    "command": "myExtension.runAnalysis",
+    "title": "Run Analysis",
+    "category": "Data Tools",
+    "icon": "PlayCircleOutlined",
+    "enablement": "sqllab.hasQuery && !sqllab.running"
+  }
+]
+```
+
+**Properties**:
+- `command` - Unique command identifier
+- `title` - Display name
+- `category` - Command palette category
+- `icon` - Optional icon
+- `enablement` - Condition for enabling
+
+### Command Registration
+
+```typescript
+commands.registerCommand('myExtension.runAnalysis', {
+  execute: async (...args) => {
+    const query = sqlLab.getCurrentQuery();
+    const result = await analyzeQuery(query);
+    return result;
+  },
+
+  isEnabled: () => {
+    return sqlLab.hasQuery() && !sqlLab.isRunning();
+  }
+});
+```
+
+### Built-in Commands
+
+Extensions can invoke these built-in commands:
+
+```typescript
+// SQL Lab commands
+await commands.executeCommand('sqllab.executeQuery');
+await commands.executeCommand('sqllab.formatQuery');
+await commands.executeCommand('sqllab.saveQuery');
+await commands.executeCommand('sqllab.exportResults');
+
+// Editor commands  
+await commands.executeCommand('editor.action.formatDocument');
+await commands.executeCommand('editor.action.commentLine');
+
+// System commands
+await commands.executeCommand('workbench.action.openSettings');
+await commands.executeCommand('workbench.action.showCommands');
+```
+
+## Menus
+
+Add items to existing Superset menus.
+
+### Menu Contributions
+
+```json
+"menus": {
+  "sqllab.editor": {
+    "primary": [
+      {
+        "command": "myExtension.analyze",
+        "group": "navigation",
+        "order": 1,
+        "when": "editorFocus"
+      }
+    ],
+    "secondary": [
+      {
+        "command": "myExtension.settings",
+        "group": "settings"
+      }
+    ],
+    "context": [
+      {
+        "command": "myExtension.explain",
+        "group": "1_modification",
+        "when": "editorTextFocus && editorHasSelection"
+      }
+    ]
+  }
+}
+```
+
+**Menu Locations**:
+- `sqllab.editor.primary` - Main toolbar
+- `sqllab.editor.secondary` - Secondary toolbar
+- `sqllab.editor.context` - Right-click menu
+
+**Groups** (for organization):
+- `navigation` - Primary navigation items
+- `1_modification` - Edit operations
+- `2_workspace` - Workspace management
+- `9_cutcopypaste` - Clipboard operations
+- `z_commands` - Other commands
+
+**TODO: Future Menu Locations**:
+- `explorer.context` - Data explorer context menu
+- `dashboard.toolbar` - Dashboard toolbar
+- `chart.context` - Chart context menu
+
+## Configuration
+
+Define user-configurable settings.
+
+### Configuration Schema
+
+```json
+"configuration": {
+  "title": "My Extension Settings",
+  "order": 10,
+  "properties": {
+    "myExtension.enableFeature": {
+      "type": "boolean",
+      "default": true,
+      "description": "Enable the main feature",
+      "order": 1
+    },
+    "myExtension.apiEndpoint": {
+      "type": "string",
+      "default": "https://api.example.com",
+      "description": "API endpoint URL",
+      "pattern": "^https?://",
+      "order": 2
+    },
+    "myExtension.refreshInterval": {
+      "type": "number",
+      "default": 5000,
+      "minimum": 1000,
+      "maximum": 60000,
+      "description": "Refresh interval in milliseconds",
+      "order": 3
+    },
+    "myExtension.theme": {
+      "type": "string",
+      "enum": ["light", "dark", "auto"],
+      "enumDescriptions": [
+        "Light theme",
+        "Dark theme",
+        "Follow system"
+      ],
+      "default": "auto",
+      "description": "Color theme",
+      "order": 4
+    },
+    "myExtension.advanced": {
+      "type": "object",
+      "properties": {
+        "cacheSize": {
+          "type": "number",
+          "default": 100
+        },
+        "debug": {
+          "type": "boolean",
+          "default": false
+        }
+      },
+      "description": "Advanced settings",
+      "order": 5
+    }
+  }
+}
+```
+
+### Accessing Configuration
+
+```typescript
+// Get configuration value
+const isEnabled = workspace.getConfiguration('myExtension')
+  .get<boolean>('enableFeature');
+
+// Update configuration
+await workspace.getConfiguration('myExtension')
+  .update('refreshInterval', 10000);
+
+// Listen for changes
+workspace.onDidChangeConfiguration(e => {
+  if (e.affectsConfiguration('myExtension.theme')) {
+    updateTheme();
+  }
+});
+```
+
+## Keybindings
+
+Register keyboard shortcuts for commands.
+
+### TODO: Keybinding Definition (Future)
+
+```json
+"keybindings": [
+  {
+    "command": "myExtension.runQuery",
+    "key": "ctrl+shift+r",
+    "mac": "cmd+shift+r",
+    "when": "editorTextFocus"
+  }
+]
+```
+
+## Language Support
+
+### TODO: Language Contributions (Future)
+
+```json
+"languages": [
+  {
+    "id": "supersql",
+    "extensions": [".ssql"],
+    "aliases": ["SuperSQL", "ssql"],
+    "configuration": "./language-configuration.json"
+  }
+]
+```
+
+## Themes
+
+### TODO: Theme Contributions (Future)
+
+```json
+"themes": [
+  {
+    "label": "My Dark Theme",
+    "uiTheme": "vs-dark",
+    "path": "./themes/my-dark-theme.json"
+  }
+]
+```
+
+## Status Bar
+
+Add items to the status bar.
+
+### TODO: Status Bar Contributions (Future)
+
+```json
+"statusBar": [
+  {
+    "id": "myExtension.status",
+    "alignment": "left",
+    "priority": 100,
+    "text": "$(database) Connected",
+    "tooltip": "Database connection status",
+    "command": "myExtension.showStatus"
+  }
+]
+```
+
+## Activity Bar
+
+### TODO: Activity Bar Contributions (Future)
+
+```json
+"activityBar": [
+  {
+    "id": "myExtension.explorer",
+    "title": "Data Explorer",
+    "icon": "./icons/explorer.svg"
+  }
+]
+```
+
+## Context Variables
+
+Extensions can use these context variables in `when` clauses:
+
+### SQL Lab Context
+
+- `sqllab.connected` - Database connection established
+- `sqllab.hasQuery` - Query text present
+- `sqllab.querySelected` - Query text selected
+- `sqllab.running` - Query executing
+- `sqllab.hasResults` - Results available
+- `sqllab.queryExecuted` - Query has been run
+- `sqllab.panelVisible` - Specific panel visible
+- `sqllab.tabActive` - Specific tab active
+
+### Editor Context
+
+- `editorFocus` - Editor has focus
+- `editorTextFocus` - Text area focused
+- `editorHasSelection` - Text selected
+- `editorHasMultipleSelections` - Multiple selections
+- `editorReadonly` - Editor is read-only
+- `editorLangId` - Language ID matches
+
+### Workspace Context
+
+- `workspaceFolderCount` - Number of workspace folders
+- `workspaceState` - Workspace state value
+- `config.*` - Configuration values
+
+### Resource Context
+
+- `resourceScheme` - URI scheme matches
+- `resourceFilename` - Filename matches pattern
+- `resourceExtname` - File extension matches
+- `resourceLangId` - Resource language ID
+
+## Activation Events
+
+Control when your extension activates:
+
+```json
+"activationEvents": [
+  "onCommand:myExtension.start",
+  "onView:myExtension.explorer",
+  "onLanguage:sql",
+  "workspaceContains:**/*.ssql",
+  "onStartupFinished"
+]
+```
+
+See [Activation Events](/developer_portal/references/activation-events) for details.
+
+## API Access Declaration
+
+Declare which APIs your extension uses:
+
+```json
+"capabilities": {
+  "apis": [
+    "sqllab.*",
+    "authentication.getUser",
+    "workspace.getConfiguration",
+    "commands.executeCommand"
+  ]
+}
+```
+
+## Contribution Validation
+
+Contributions are validated:
+
+1. **At build time** - Schema validation
+2. **At registration** - Conflict detection
+3. **At runtime** - Permission checks
+
+Common validation errors:
+- Duplicate command IDs
+- Invalid menu locations
+- Missing required properties
+- Circular dependencies
+- Invalid context expressions
+
+## Best Practices
+
+1. **Use namespaced IDs** - Prefix with extension name
+2. **Declare minimal capabilities** - Only request needed APIs
+3. **Provide meaningful descriptions** - Help users understand
+4. **Use appropriate icons** - Follow Ant Design guidelines
+5. **Group related items** - Organize menus logically
+6. **Test context conditions** - Ensure `when` clauses work
+7. **Handle missing permissions** - Graceful degradation
+8. **Document commands** - Explain what they do
+9. **Version your APIs** - Plan for changes
+10. **Validate user input** - For configuration values
+
+## Future Contribution Points
+
+These contribution points are planned for future releases:
+
+- **Debuggers** - Custom debugging adapters
+- **Tasks** - Background task providers  
+- **Snippets** - Code snippets
+- **Color Themes** - Complete color themes
+- **Icon Themes** - Icon set definitions
+- **Product Icons** - Custom product icons
+- **Walkthroughs** - Getting started guides
+- **Authentication** - Auth providers
+- **Views Containers** - Custom view containers
+- **Terminal** - Terminal profiles
+- **Comments** - Comment providers
+- **Code Actions** - Quick fixes
+- **Code Lens** - Inline commands
+- **Semantic Tokens** - Syntax highlighting
+
+## Related Documentation
+
+- [Extension Manifest](/developer_portal/references/manifest)
+- [Activation Events](/developer_portal/references/activation-events)
+- [API Reference](/developer_portal/api/frontend)
+- [Frontend Contribution Types](/developer_portal/extensions/frontend-contribution-types)

docs/developer_portal/references/manifest.md

@@ -0,0 +1,526 @@
+---
+title: Extension Manifest
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Extension Manifest Reference
+
+The `extension.json` file defines metadata, capabilities, and configuration for a Superset extension. This file is required at the root of every extension project.
+
+## Complete Example
+
+```json
+{
+  "name": "dataset_references",
+  "displayName": "Dataset References",
+  "version": "1.0.0",
+  "description": "Display metadata about tables referenced in SQL queries",
+  "author": "Apache Superset Contributors",
+  "license": "Apache-2.0",
+  "homepage": "https://github.com/apache/superset",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/apache/superset.git"
+  },
+  "bugs": {
+    "url": "https://github.com/apache/superset/issues"
+  },
+  "engines": {
+    "superset": ">=4.0.0"
+  },
+  "categories": ["SQL Lab", "Analytics"],
+  "keywords": ["sql", "metadata", "tables", "references"],
+  "icon": "database",
+  "galleryBanner": {
+    "color": "#1890ff",
+    "theme": "dark"
+  },
+  "frontend": {
+    "main": "./dist/index.js",
+    "contributions": {
+      "views": {
+        "sqllab.panels": [
+          {
+            "id": "dataset_references.main",
+            "name": "Dataset References",
+            "icon": "TableOutlined",
+            "when": "sqllab.queryExecuted"
+          }
+        ]
+      },
+      "commands": [
+        {
+          "command": "dataset_references.refresh",
+          "title": "Refresh Dataset Metadata",
+          "category": "Dataset References",
+          "icon": "ReloadOutlined"
+        }
+      ],
+      "menus": {
+        "sqllab.editor": {
+          "primary": [
+            {
+              "command": "dataset_references.refresh",
+              "group": "navigation",
+              "when": "dataset_references.panelVisible"
+            }
+          ]
+        }
+      },
+      "configuration": {
+        "title": "Dataset References",
+        "properties": {
+          "dataset_references.autoRefresh": {
+            "type": "boolean",
+            "default": true,
+            "description": "Automatically refresh metadata on query execution"
+          },
+          "dataset_references.showPartitions": {
+            "type": "boolean",
+            "default": true,
+            "description": "Display partition information"
+          },
+          "dataset_references.cacheTimeout": {
+            "type": "number",
+            "default": 300,
+            "description": "Cache timeout in seconds"
+          }
+        }
+      }
+    },
+    "moduleFederation": {
+      "name": "dataset_references",
+      "exposes": {
+        "./index": "./src/index"
+      },
+      "shared": {
+        "react": { "singleton": true },
+        "react-dom": { "singleton": true }
+      }
+    }
+  },
+  "backend": {
+    "main": "dataset_references.entrypoint",
+    "entryPoints": ["dataset_references.entrypoint"],
+    "files": ["backend/src/dataset_references/**/*.py"],
+    "requirements": [
+      "sqlparse>=0.4.0",
+      "pandas>=1.3.0"
+    ]
+  },
+  "activationEvents": [
+    "onView:sqllab.panels",
+    "onCommand:dataset_references.refresh",
+    "workspaceContains:**/*.sql"
+  ]
+}
+```
+
+## Required Fields
+
+### name
+- **Type**: `string`
+- **Pattern**: `^[a-z0-9_]+$`
+- **Description**: Unique identifier for the extension. Must be lowercase with underscores.
+
+```json
+"name": "my_extension"
+```
+
+### version
+- **Type**: `string`
+- **Format**: [Semantic Versioning](https://semver.org/)
+- **Description**: Extension version following semver format.
+
+```json
+"version": "1.2.3"
+```
+
+### engines
+- **Type**: `object`
+- **Description**: Specifies compatible Superset versions.
+
+```json
+"engines": {
+  "superset": ">=4.0.0 <5.0.0"
+}
+```
+
+## Metadata Fields
+
+### displayName
+- **Type**: `string`
+- **Description**: Human-readable name shown in UI.
+
+### description
+- **Type**: `string`
+- **Description**: Short description of extension functionality.
+
+### author
+- **Type**: `string` | `object`
+- **Description**: Extension author information.
+
+```json
+"author": {
+  "name": "Jane Doe",
+  "email": "jane@example.com",
+  "url": "https://example.com"
+}
+```
+
+### license
+- **Type**: `string`
+- **Description**: SPDX license identifier.
+- **Common values**: `Apache-2.0`, `MIT`, `BSD-3-Clause`
+
+### categories
+- **Type**: `string[]`
+- **Description**: Extension categories for marketplace organization.
+- **Valid values**:
+  - `"SQL Lab"`
+  - `"Dashboard"`
+  - `"Charts"`
+  - `"Data Sources"`
+  - `"Analytics"`
+  - `"Security"`
+  - `"Theming"`
+  - `"Developer Tools"`
+
+### keywords
+- **Type**: `string[]`
+- **Description**: Search keywords for extension discovery.
+
+### icon
+- **Type**: `string`
+- **Description**: Icon identifier or path to icon file.
+
+## Frontend Configuration
+
+### frontend.main
+- **Type**: `string`
+- **Description**: Entry point for frontend code.
+
+### frontend.contributions
+
+Defines how the extension extends Superset's UI.
+
+#### views
+Register custom views and panels:
+
+```json
+"views": {
+  "sqllab.panels": [
+    {
+      "id": "extension.panel",
+      "name": "My Panel",
+      "icon": "icon-name",
+      "when": "condition"
+    }
+  ]
+}
+```
+
+**View Locations**:
+- `sqllab.panels` - SQL Lab side panels
+- `sqllab.bottomPanels` - SQL Lab bottom panels
+- `dashboard.widgets` - Dashboard widgets (TODO: future)
+- `chart.toolbar` - Chart toolbar items (TODO: future)
+
+#### commands
+Register executable commands:
+
+```json
+"commands": [
+  {
+    "command": "extension.doSomething",
+    "title": "Do Something",
+    "category": "My Extension",
+    "icon": "PlayCircleOutlined",
+    "enablement": "resourceIsSelected"
+  }
+]
+```
+
+#### menus
+Add items to existing menus:
+
+```json
+"menus": {
+  "sqllab.editor": {
+    "primary": [
+      {
+        "command": "extension.command",
+        "group": "navigation",
+        "when": "editorFocus"
+      }
+    ],
+    "context": [
+      {
+        "command": "extension.contextAction",
+        "group": "1_modification"
+      }
+    ]
+  }
+}
+```
+
+**Menu Locations**:
+- `sqllab.editor.primary` - Main SQL Lab toolbar
+- `sqllab.editor.secondary` - Secondary actions
+- `sqllab.editor.context` - Right-click context menu
+- `explorer.context` - Data explorer context menu (TODO: future)
+
+#### configuration
+Define extension settings:
+
+```json
+"configuration": {
+  "title": "My Extension",
+  "properties": {
+    "myExtension.setting1": {
+      "type": "boolean",
+      "default": true,
+      "description": "Enable feature X"
+    },
+    "myExtension.setting2": {
+      "type": "string",
+      "enum": ["option1", "option2"],
+      "default": "option1",
+      "description": "Choose option"
+    }
+  }
+}
+```
+
+**Property Types**:
+- `boolean` - True/false toggle
+- `string` - Text input
+- `number` - Numeric input
+- `array` - List of values
+- `object` - Complex configuration
+
+### frontend.moduleFederation
+
+Webpack Module Federation configuration:
+
+```json
+"moduleFederation": {
+  "name": "extension_name",
+  "exposes": {
+    "./index": "./src/index"
+  },
+  "shared": {
+    "react": { "singleton": true },
+    "react-dom": { "singleton": true },
+    "@apache-superset/core": { "singleton": true }
+  }
+}
+```
+
+## Backend Configuration
+
+### backend.main
+- **Type**: `string`
+- **Description**: Main Python module entry point.
+
+### backend.entryPoints
+- **Type**: `string[]`
+- **Description**: Python modules to load on startup.
+
+```json
+"entryPoints": [
+  "my_extension.api",
+  "my_extension.security",
+  "my_extension.models"
+]
+```
+
+### backend.files
+- **Type**: `string[]`
+- **Description**: Glob patterns for backend files to include.
+
+```json
+"files": [
+  "backend/src/**/*.py",
+  "backend/config/*.yaml"
+]
+```
+
+### backend.requirements
+- **Type**: `string[]`
+- **Description**: Python package dependencies.
+
+```json
+"requirements": [
+  "requests>=2.28.0",
+  "pandas>=1.3.0,<2.0.0"
+]
+```
+
+## Activation Events
+
+Controls when the extension is activated:
+
+```json
+"activationEvents": [
+  "onView:sqllab.panels",
+  "onCommand:myExtension.start",
+  "onLanguage:sql",
+  "workspaceContains:**/*.sql",
+  "*"
+]
+```
+
+**Event Types**:
+- `onView:<viewId>` - When specific view is opened
+- `onCommand:<commandId>` - When command is executed
+- `onLanguage:<language>` - When file type is opened
+- `workspaceContains:<pattern>` - When workspace contains matching files
+- `onStartupFinished` - After Superset fully starts
+- `*` - Always activate (not recommended)
+
+## Conditional Activation ("when" clauses)
+
+Control when UI elements are visible/enabled:
+
+```json
+"when": "sqllab.queryExecuted && config.myExtension.enabled"
+```
+
+**Context Keys**:
+- `sqllab.queryExecuted` - Query has been run
+- `sqllab.hasResults` - Query returned results
+- `editorFocus` - Editor is focused
+- `resourceIsSelected` - Resource selected in explorer
+- `config.<setting>` - Configuration value check
+
+**Operators**:
+- `&&` - AND
+- `||` - OR
+- `!` - NOT
+- `==` - Equals
+- `!=` - Not equals
+- `=~` - Regex match
+
+## Capabilities Declaration
+
+Declare required permissions and capabilities:
+
+```json
+"capabilities": {
+  "permissions": [
+    "database.read",
+    "query.execute",
+    "cache.write"
+  ],
+  "apis": [
+    "sqllab.*",
+    "authentication.getUser"
+  ]
+}
+```
+
+## Build Configuration
+
+### TODO: Future Fields
+
+These fields are planned for future implementation:
+
+```json
+{
+  "publisher": "organization-name",
+  "preview": false,
+  "contributes": {
+    "themes": [],
+    "languages": [],
+    "debuggers": [],
+    "jsonValidation": []
+  },
+  "extensionDependencies": [
+    "other-extension@^1.0.0"
+  ],
+  "extensionPack": [
+    "extension1",
+    "extension2"
+  ],
+  "scripts": {
+    "compile": "webpack",
+    "test": "jest",
+    "lint": "eslint"
+  }
+}
+```
+
+## Validation
+
+The manifest is validated against a JSON schema during:
+- Development (`superset-extensions dev`)
+- Build (`superset-extensions build`)
+- Installation (API upload)
+
+Common validation errors:
+- Missing required fields
+- Invalid version format
+- Incompatible engine version
+- Duplicate command IDs
+- Invalid activation events
+
+## Best Practices
+
+1. **Use semantic versioning** for the version field
+2. **Declare minimum Superset version** accurately
+3. **Use specific activation events** to improve performance
+4. **Provide clear descriptions** for configuration options
+5. **Include all required Python dependencies** in requirements
+6. **Use unique IDs** for commands and views
+7. **Follow naming conventions** (snake_case for name, camelCase for settings)
+8. **Include complete author information** for support
+9. **Specify appropriate categories** for discovery
+10. **Test manifest changes** before deployment
+
+## Migration from Legacy Format
+
+If migrating from older extension formats:
+
+```javascript
+// Legacy format (deprecated)
+{
+  "plugin_name": "MyPlugin",
+  "plugin_version": "1.0"
+}
+
+// New format
+{
+  "name": "my_plugin",
+  "version": "1.0.0",
+  "engines": {
+    "superset": ">=4.0.0"
+  }
+}
+```
+
+## Related Documentation
+
+- [Extension Project Structure](/developer_portal/extensions/extension-project-structure)
+- [Contribution Points](/developer_portal/references/contribution-points)
+- [Activation Events](/developer_portal/references/activation-events)
+- [API Reference](/developer_portal/api/frontend)

docs/developer_portal/references/overview.md

@@ -0,0 +1,74 @@
+---
+title: References Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# References Overview
+
+🚧 **Coming Soon** 🚧
+
+Comprehensive reference documentation for all Superset plugin APIs, configuration options, and development resources.
+
+## Topics to be covered:
+
+- Complete API reference documentation
+- Plugin configuration schemas
+- Event and hook reference
+- Component library documentation
+- TypeScript type definitions
+- Extension point catalog
+- Error code reference
+- Performance metrics documentation
+- Migration guides and changelogs
+- Troubleshooting and FAQ
+
+## Reference Sections
+
+### API Documentation
+- **Plugin APIs** - Core plugin development interfaces
+- **Chart APIs** - Visualization component interfaces
+- **Data APIs** - Query and transformation interfaces
+- **UI APIs** - User interface and theming interfaces
+- **Utility APIs** - Helper functions and utilities
+
+### Configuration References
+- **Plugin Manifests** - Plugin.json schema and options
+- **Contribution Points** - Available extension points
+- **Activation Events** - Plugin lifecycle triggers
+- **Settings Schema** - Configuration option definitions
+
+### Development Resources
+- **TypeScript Definitions** - Complete type reference
+- **Component Library** - Reusable UI components
+- **Testing Utilities** - Testing helpers and mocks
+- **Build Tools** - Webpack and bundling configuration
+
+## Documentation Format
+
+- **Interactive examples** - Live code demonstrations
+- **Type annotations** - Complete TypeScript signatures
+- **Usage patterns** - Common implementation examples
+- **Migration notes** - Version upgrade guidance
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/sidebars.js

@@ -34,6 +34,33 @@ module.exports = {
         'architecture/overview',
       ],
     },
+    {
+      type: 'category',
+      label: 'Extensions',
+      collapsed: true,
+      items: [
+        'extensions/architectural-principles',
+        'extensions/high-level-architecture',
+        'extensions/extension-project-structure',
+        'extensions/extension-metadata',
+        'extensions/frontend-contribution-types',
+        'extensions/interacting-with-host',
+        'extensions/dynamic-module-loading',
+        'extensions/deploying-extension',
+        'extensions/lifecycle-management',
+        'extensions/development-mode',
+        'extensions/versioning',
+        'extensions/security-implications',
+        {
+          type: 'doc',
+          id: 'extensions/built-in-features',
+          customProps: {
+            disabled: true,
+          },
+        },
+        'extensions/proof-of-concept',
+      ],
+    },
     {
       type: 'category',
       label: 'API Reference',

docs/developer_portal/testing/backend-testing.md

@@ -0,0 +1,68 @@
+---
+title: Backend Testing
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Backend Testing
+
+🚧 **Coming Soon** 🚧
+
+Complete guide for testing Superset's Python backend, APIs, and database interactions.
+
+## Topics to be covered:
+
+- Pytest configuration and fixtures
+- Unit testing best practices
+- Integration testing with databases
+- API endpoint testing
+- Mocking strategies and patterns
+- Testing async operations with Celery
+- Security testing guidelines
+- Performance and load testing
+- Test database setup and teardown
+- Coverage requirements
+
+## Quick Commands
+
+```bash
+# Run all backend tests
+pytest
+
+# Run specific test file
+pytest tests/unit_tests/specific_test.py
+
+# Run with coverage
+pytest --cov=superset
+
+# Run tests in parallel
+pytest -n auto
+
+# Run only unit tests
+pytest tests/unit_tests/
+
+# Run only integration tests
+pytest tests/integration_tests/
+```
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/testing/ci-cd.md

@@ -0,0 +1,70 @@
+---
+title: CI/CD and Automation
+sidebar_position: 5
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# CI/CD and Automation
+
+🚧 **Coming Soon** 🚧
+
+Understanding Superset's continuous integration and deployment pipelines.
+
+## Topics to be covered:
+
+- GitHub Actions workflows
+- Pre-commit hooks configuration
+- Automated testing pipelines
+- Code quality checks (ESLint, Prettier, Black, MyPy)
+- Security scanning (Dependabot, CodeQL)
+- Docker image building and publishing
+- Release automation
+- Performance benchmarking
+- Coverage reporting and tracking
+
+## Pre-commit Hooks
+
+```bash
+# Install pre-commit hooks
+pre-commit install
+
+# Run all hooks on staged files
+pre-commit run
+
+# Run specific hook
+pre-commit run mypy
+
+# Run on all files (not just staged)
+pre-commit run --all-files
+```
+
+## GitHub Actions
+
+Key workflows:
+- `test-frontend.yml` - Frontend tests
+- `test-backend.yml` - Backend tests
+- `docker.yml` - Docker image builds
+- `codeql.yml` - Security analysis
+- `release.yml` - Release automation
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/testing/e2e-testing.md

@@ -0,0 +1,80 @@
+---
+title: End-to-End Testing
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# End-to-End Testing
+
+🚧 **Coming Soon** 🚧
+
+Guide for writing and running end-to-end tests using Playwright and Cypress.
+
+## Topics to be covered:
+
+### Playwright (Recommended)
+- Setting up Playwright environment
+- Writing reliable E2E tests
+- Page Object Model pattern
+- Handling async operations
+- Cross-browser testing
+- Visual regression testing
+- Debugging with Playwright Inspector
+- CI/CD integration
+
+### Cypress (Deprecated)
+- Legacy Cypress test maintenance
+- Migration to Playwright
+- Running existing Cypress tests
+
+## Quick Commands
+
+### Playwright
+```bash
+# Run all Playwright tests
+npm run playwright:test
+
+# Run in headed mode (see browser)
+npm run playwright:headed
+
+# Run specific test file
+npx playwright test tests/auth/login.spec.ts
+
+# Debug specific test
+npm run playwright:debug tests/auth/login.spec.ts
+
+# Open Playwright UI
+npm run playwright:ui
+```
+
+### Cypress (Deprecated)
+```bash
+# Run Cypress tests
+cd superset-frontend/cypress-base
+npm run cypress-run-chrome
+
+# Open Cypress UI
+npm run cypress-debug
+```
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/testing/frontend-testing.md

@@ -0,0 +1,61 @@
+---
+title: Frontend Testing
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Frontend Testing
+
+🚧 **Coming Soon** 🚧
+
+Comprehensive guide for testing Superset's frontend components and features.
+
+## Topics to be covered:
+
+- Jest configuration and setup
+- React Testing Library best practices
+- Component testing strategies
+- Redux store testing
+- Async operations and API mocking
+- Snapshot testing guidelines
+- Coverage requirements and reporting
+- Debugging test failures
+- Performance testing for UI components
+
+## Quick Commands
+
+```bash
+# Run all frontend tests
+npm run test
+
+# Run tests in watch mode
+npm run test -- --watch
+
+# Run tests with coverage
+npm run test -- --coverage
+
+# Run specific test file
+npm run test -- MyComponent.test.tsx
+```
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/testing/overview.md

@@ -0,0 +1,164 @@
+---
+title: Testing Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Testing Overview
+
+Apache Superset follows a comprehensive testing strategy that ensures code quality, reliability, and maintainability. This section covers all aspects of testing in the Superset ecosystem, from unit tests to end-to-end testing workflows.
+
+## Testing Philosophy
+
+Superset embraces a testing pyramid approach:
+
+- **Unit Tests**: Fast, isolated tests for individual components and functions
+- **Integration Tests**: Tests that verify component interactions and API endpoints
+- **End-to-End Tests**: Full user journey testing in browser environments
+
+## Testing Documentation
+
+### Frontend Testing
+- **[Frontend Testing](./frontend-testing)** - Jest, React Testing Library, and component testing strategies
+
+### Backend Testing  
+- **[Backend Testing](./backend-testing)** - pytest, database testing, and API testing patterns
+
+### End-to-End Testing
+- **[E2E Testing](./e2e-testing)** - Playwright testing for complete user workflows
+
+### CI/CD Integration
+- **[CI/CD](./ci-cd)** - Continuous integration, automated testing, and deployment pipelines
+
+## Testing Tools & Frameworks
+
+### Frontend
+- **Jest**: JavaScript testing framework for unit and integration tests
+- **React Testing Library**: Component testing utilities focused on user behavior
+- **Playwright**: Modern end-to-end testing for web applications
+- **Storybook**: Component development and visual testing environment
+
+### Backend
+- **pytest**: Python testing framework with powerful fixtures and plugins
+- **SQLAlchemy Test Utilities**: Database testing and transaction management
+- **Flask Test Client**: API endpoint testing and request simulation
+- **Factory Boy**: Test data generation and model factories
+
+## Best Practices
+
+### Writing Effective Tests
+1. **Test Behavior, Not Implementation**: Focus on what the code should do, not how it does it
+2. **Keep Tests Independent**: Each test should be able to run in isolation
+3. **Use Descriptive Names**: Test names should clearly describe what is being tested
+4. **Arrange, Act, Assert**: Structure tests with clear setup, execution, and verification phases
+
+### Test Organization
+- **Colocation**: Place test files near the code they test
+- **Naming Conventions**: Use consistent naming patterns for test files and functions
+- **Test Categories**: Organize tests by type (unit, integration, e2e)
+- **Test Data Management**: Use factories and fixtures for consistent test data
+
+## Running Tests
+
+### Quick Commands
+```bash
+# Frontend unit tests
+npm run test
+
+# Backend unit tests  
+pytest tests/unit_tests/
+
+# End-to-end tests
+npm run playwright:test
+
+# All tests with coverage
+npm run test:coverage
+```
+
+### Test Development Workflow
+1. **Write Failing Test**: Start with a test that describes the desired behavior
+2. **Implement Feature**: Write the minimum code to make the test pass
+3. **Refactor**: Improve code quality while keeping tests green
+4. **Verify Coverage**: Ensure adequate test coverage for new code
+
+## Testing in Development
+
+### Test-Driven Development (TDD)
+- Write tests before implementation
+- Use tests to guide design decisions
+- Maintain fast feedback loops
+
+### Continuous Testing
+- Run tests automatically on code changes
+- Integrate testing into development workflow
+- Use pre-commit hooks for test validation
+
+## Getting Started
+
+1. **Set up Testing Environment**: Follow the development setup guide
+2. **Run Existing Tests**: Familiarize yourself with the test suite
+3. **Write Your First Test**: Start with a simple unit test
+4. **Learn Testing Patterns**: Study existing tests for patterns and conventions
+
+## Topics to be covered:
+
+- Testing strategy and pyramid
+- Test-driven development (TDD) for plugins
+- Continuous integration and automated testing
+- Code coverage and quality metrics
+- Testing tools and frameworks overview
+- Mock data and test fixtures
+- Performance testing and benchmarking
+- Accessibility testing automation
+- Cross-browser and device testing
+- Regression testing strategies
+
+## Testing Levels
+
+### Unit Testing
+- **Component testing** - Individual React components
+- **Function testing** - Data transformation and utility functions
+- **Hook testing** - Custom React hooks
+- **Service testing** - API clients and business logic
+
+### Integration Testing
+- **API integration** - Backend service communication
+- **Component integration** - Multi-component workflows
+- **Data flow testing** - End-to-end data processing
+- **Plugin lifecycle testing** - Installation and activation
+
+### End-to-End Testing
+- **User workflow testing** - Complete user journeys
+- **Cross-browser testing** - Browser compatibility
+- **Performance testing** - Load and stress testing
+- **Accessibility testing** - Screen reader and keyboard navigation
+
+## Testing Tools
+
+- **Jest** - Unit and integration testing framework
+- **React Testing Library** - Component testing utilities
+- **Playwright** - End-to-end testing (replacing Cypress)
+- **Storybook** - Component development and testing
+- **MSW** - API mocking for testing
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/ux/accessibility.md

@@ -0,0 +1,70 @@
+---
+title: Accessibility Guidelines
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Accessibility Guidelines
+
+🚧 **Coming Soon** 🚧
+
+Ensure your Superset plugins are accessible to users with disabilities and comply with modern accessibility standards.
+
+## Topics to be covered:
+
+- WCAG 2.1 compliance requirements
+- Keyboard navigation and focus management
+- Screen reader compatibility
+- Color contrast and visual accessibility
+- Alternative text for images and charts
+- Accessible form design and validation
+- ARIA labels and semantic markup
+- Accessibility testing tools and techniques
+- Voice control and assistive technology support
+- Internationalization and right-to-left languages
+
+## Accessibility Standards
+
+### WCAG 2.1 Level AA Compliance
+- **Perceivable** - Information presented in ways users can perceive
+- **Operable** - Interface components must be operable by all users
+- **Understandable** - Information and UI operation must be understandable
+- **Robust** - Content must be robust enough for various assistive technologies
+
+### Key Requirements
+
+- **Color contrast** - Minimum 4.5:1 ratio for normal text
+- **Keyboard navigation** - All functionality accessible via keyboard
+- **Focus indicators** - Clear visual focus indicators
+- **Alternative text** - Meaningful descriptions for non-text content
+- **Error identification** - Clear error messages and instructions
+
+## Testing Tools
+
+- axe-core accessibility testing
+- Lighthouse accessibility audits
+- Screen reader testing (NVDA, JAWS, VoiceOver)
+- Keyboard navigation testing
+- Color contrast analyzers
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/ux/best-practices.md

@@ -0,0 +1,73 @@
+---
+title: UX Best Practices
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# UX Best Practices
+
+🚧 **Coming Soon** 🚧
+
+Practical guidelines and proven patterns for creating exceptional user experiences in Superset plugins.
+
+## Topics to be covered:
+
+- User research and persona development
+- Usability testing and feedback collection
+- Information architecture and navigation design
+- Interaction design patterns
+- Visual design and branding consistency
+- Performance optimization for user experience
+- Mobile and responsive design strategies
+- User onboarding and feature discovery
+- Error handling and graceful degradation
+- Analytics and user behavior tracking
+
+## Common UX Patterns
+
+### Data Visualization
+- **Progressive disclosure** - Show summary first, details on demand
+- **Contextual actions** - Relevant controls near data points
+- **Consistent legends** - Standardized color coding and symbols
+- **Responsive charts** - Adapt to different screen sizes
+
+### Navigation and Discovery
+- **Breadcrumb navigation** - Clear path indicators
+- **Search and filtering** - Quick content discovery
+- **Contextual menus** - Right-click and hover actions
+- **Keyboard shortcuts** - Power user efficiency
+
+### Form Design
+- **Smart defaults** - Pre-populate based on context
+- **Inline validation** - Real-time feedback
+- **Progressive enhancement** - Advanced features for power users
+- **Clear error states** - Helpful error messages and recovery
+
+## Performance Considerations
+
+- Loading state management
+- Perceived performance optimization
+- Data streaming and pagination
+- Client-side caching strategies
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/ux/design-principles.md

@@ -0,0 +1,68 @@
+---
+title: Design Principles
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Design Principles
+
+🚧 **Coming Soon** 🚧
+
+Core design principles that guide the development of effective and user-friendly Superset plugins.
+
+## Topics to be covered:
+
+- Data-first design philosophy
+- Progressive disclosure principles
+- Cognitive load reduction strategies
+- Visual hierarchy and information architecture
+- Feedback and affordance design
+- Error prevention and recovery
+- Performance and perceived performance
+- Cross-platform consistency
+- Internationalization considerations
+- Mobile and responsive design principles
+
+## Fundamental Principles
+
+### Data Transparency
+- Make data sources and transformations visible
+- Provide clear data lineage and provenance
+- Show confidence levels and data quality indicators
+
+### User Empowerment
+- Enable self-service analytics
+- Provide multiple paths to accomplish goals
+- Support both novice and expert workflows
+
+### Contextual Relevance
+- Show relevant information at the right time
+- Minimize context switching
+- Provide smart defaults based on user behavior
+
+### Collaborative Design
+- Support sharing and collaboration features
+- Enable team workflows and permissions
+- Provide commenting and annotation capabilities
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/ux/overview.md

@@ -0,0 +1,62 @@
+---
+title: User Experience Guidelines
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# User Experience Guidelines
+
+🚧 **Coming Soon** 🚧
+
+Comprehensive guidelines for creating intuitive and accessible user experiences in Superset plugins.
+
+## Topics to be covered:
+
+- Superset design system principles
+- User interface consistency standards
+- Interaction patterns and behaviors
+- Visual hierarchy and layout guidelines
+- Color usage and accessibility compliance
+- Typography and content guidelines
+- Responsive design principles
+- Error handling and user feedback
+- Loading states and performance indicators
+- User onboarding and help systems
+
+## UX Principles
+
+- **Consistency** - Follow established patterns and conventions
+- **Clarity** - Make interfaces intuitive and self-explanatory
+- **Efficiency** - Optimize for user productivity and speed
+- **Accessibility** - Ensure inclusive design for all users
+- **Flexibility** - Support different workflows and preferences
+
+## Design Resources
+
+- Component library and style guide
+- Design tokens and theme variables
+- Icon library and usage guidelines
+- Layout templates and grid systems
+- Accessibility testing tools
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/viz-plugins/controls.md

@@ -0,0 +1,77 @@
+---
+title: Controls and Configuration
+sidebar_position: 3
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Controls and Configuration
+
+🚧 **Coming Soon** 🚧
+
+Learn how to create intuitive control panels and configuration interfaces for your visualization plugins.
+
+## Topics to be covered:
+
+- Control panel architecture and layout
+- Built-in control types and components
+- Creating custom control components
+- Control validation and error handling
+- Conditional control visibility
+- Control grouping and sections
+- Advanced control patterns
+- Form state management
+- Control panel theming
+- Accessibility in control design
+
+## Available Control Types
+
+### Basic Controls
+- **Text Input** - String values and labels
+- **Number Input** - Numeric values with validation
+- **Checkbox** - Boolean toggles
+- **Radio Buttons** - Single selection from options
+- **Select Dropdown** - Single or multi-select
+- **Slider** - Numeric range selection
+
+### Advanced Controls
+- **Color Picker** - Color selection with palette
+- **Date Picker** - Date and time selection
+- **Code Editor** - SQL, JSON, or custom syntax
+- **File Upload** - Asset and data file handling
+- **Metrics Selector** - Data column selection
+- **Filter Controls** - Dynamic filtering options
+
+### Custom Controls
+- Building reusable control components
+- Control component API and props
+- Integration with form validation
+- Custom control styling and theming
+
+## Control Configuration Patterns
+
+- Section organization and collapsible groups
+- Conditional control display logic
+- Dynamic control generation
+- Control dependencies and relationships
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/viz-plugins/creating-viz-plugin.md

@@ -0,0 +1,80 @@
+---
+title: Creating a Visualization Plugin
+sidebar_position: 2
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Creating a Visualization Plugin
+
+🚧 **Coming Soon** 🚧
+
+Step-by-step guide to building your first custom visualization plugin for Apache Superset.
+
+## Topics to be covered:
+
+- Setting up the plugin development environment
+- Using the visualization plugin generator
+- Understanding the plugin file structure
+- Implementing the chart component
+- Creating the control panel interface
+- Adding data transformation logic
+- Testing your visualization locally
+- Debugging common issues
+- Packaging for distribution
+- Publishing to npm registry
+
+## Development Steps
+
+### 1. Project Setup
+- Clone the superset-ui repository
+- Install dependencies and development tools
+- Create a new plugin directory
+- Configure build and development scripts
+
+### 2. Chart Implementation
+- Define the main chart component
+- Handle data props and rendering
+- Implement responsive design
+- Add interactive features
+
+### 3. Configuration Interface
+- Design the control panel layout
+- Add form controls and validation
+- Implement conditional controls
+- Handle control state management
+
+### 4. Testing and Validation
+- Unit testing with Jest
+- Integration testing with Storybook
+- Visual regression testing
+- Performance benchmarking
+
+## Code Examples
+
+Examples will include:
+- Basic chart component structure
+- Control panel configuration
+- Data transformation functions
+- Event handling patterns
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/viz-plugins/overview.md

@@ -0,0 +1,67 @@
+---
+title: Visualization Plugins Overview
+sidebar_position: 1
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Visualization Plugins Overview
+
+🚧 **Coming Soon** 🚧
+
+Learn how to create custom visualization plugins to extend Superset's charting capabilities with new chart types and data representations.
+
+## Topics to be covered:
+
+- Visualization plugin architecture
+- Chart component development
+- Data transformation and processing
+- Control panel configuration
+- Chart rendering lifecycle
+- Interactive features and event handling
+- Performance optimization for large datasets
+- Chart theming and customization
+- Export and sharing capabilities
+- Plugin packaging and distribution
+
+## Plugin Components
+
+### Core Components
+- **Chart Component** - Main visualization renderer
+- **Control Panel** - Configuration interface
+- **Transform Props** - Data processing logic
+- **Metadata** - Plugin registration and configuration
+
+### Optional Components
+- **Thumbnail** - Chart preview image
+- **Build Query** - Custom query generation
+- **Control Panel Sections** - Advanced configuration grouping
+
+## Supported Chart Libraries
+
+- **D3.js** - Custom SVG-based visualizations
+- **ECharts** - Rich interactive charts
+- **Deck.gl** - Geospatial and 3D visualizations
+- **React** - Custom React-based components
+- **Canvas/WebGL** - High-performance rendering
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/developer_portal/viz-plugins/transforming-data.md

@@ -0,0 +1,76 @@
+---
+title: Transforming Data
+sidebar_position: 4
+---
+
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Transforming Data
+
+🚧 **Coming Soon** 🚧
+
+Master data transformation techniques to prepare and optimize data for your visualization plugins.
+
+## Topics to be covered:
+
+- Data transformation pipeline architecture
+- Understanding query results structure
+- Implementing transform props functions
+- Data aggregation and grouping
+- Filtering and sorting operations
+- Data type conversion and validation
+- Handling missing and null values
+- Performance optimization for large datasets
+- Caching and memoization strategies
+- Error handling in data transformations
+
+## Transformation Patterns
+
+### Data Preparation
+- **Normalization** - Converting data to consistent formats
+- **Aggregation** - Grouping and summarizing data
+- **Pivoting** - Reshaping data for different chart types
+- **Joining** - Combining multiple data sources
+- **Filtering** - Removing irrelevant data points
+
+### Chart-Specific Transformations
+- **Time series** - Date parsing and time-based grouping
+- **Geographic data** - Coordinate conversion and mapping
+- **Hierarchical data** - Tree and nested structure handling
+- **Network data** - Node and edge relationship processing
+- **Statistical data** - Distribution and correlation analysis
+
+### Performance Considerations
+- Lazy evaluation and streaming
+- Incremental data processing
+- Client-side vs server-side transformations
+- Memory management for large datasets
+- Parallel processing techniques
+
+## API Reference
+
+- Transform props function signature
+- Available utility functions
+- Data structure interfaces
+- Error handling patterns
+
+---
+
+*This documentation is under active development. Check back soon for updates!*

docs/docs/configuration/alerts-reports.mdx

@@ -40,7 +40,7 @@ You'll need to extend the Superset image to include a headless browser. Your opt
 - Use Firefox: you'll need to install geckodriver and Firefox.
 - Use Chrome without Playwright: you'll need to install Chrome and set the value of `WEBDRIVER_TYPE` to `"chrome"` in your `superset_config.py`.
 
-In Superset versions prior to 4.1, users installed Firefox or Chrome and that was documented here.
+In Superset versions <=4.0x, users installed Firefox or Chrome and that was documented here.
 
 Only the worker container needs the browser.
 

docs/docs/configuration/databases.mdx

@@ -49,6 +49,7 @@ are compatible with Superset.
 | [Apache Pinot](/docs/configuration/databases#apache-pinot)                     | `pip install pinotdb`                                                              | `pinot://BROKER:5436/query?server=http://CONTROLLER:5983/`                                                                                             |
 | [Apache Solr](/docs/configuration/databases#apache-solr)                       | `pip install sqlalchemy-solr`                                                      | `solr://{username}:{password}@{hostname}:{port}/{server_path}/{collection}`                                                                            |
 | [Apache Spark SQL](/docs/configuration/databases#apache-spark-sql)             | `pip install pyhive`                                                               | `hive://hive@{hostname}:{port}/{database}`                                                                                                             |
+| [Arc (Basekick Labs)](/docs/configuration/databases#arc)                       | `pip install arc-superset-dialect`                                                | `arc://{api_key}@{hostname}:{port}/{database}`                                                                                                         |
 | [Ascend.io](/docs/configuration/databases#ascendio)                       | `pip install impyla`                                                               | `ascend://{username}:{password}@{hostname}:{port}/{database}?auth_mechanism=PLAIN;use_ssl=true`                                                        |
 | [Azure MS SQL](/docs/configuration/databases#sql-server)                | `pip install pymssql`                                                              | `mssql+pymssql://UserName@presetSQL:TestPassword@presetSQL.database.windows.net:1433/TestSchema`                                                       |
 | [ClickHouse](/docs/configuration/databases#clickhouse)                  | `pip install clickhouse-connect`                                                   | `clickhousedb://{username}:{password}@{hostname}:{port}/{database}`                                                                                    |
@@ -1256,6 +1257,20 @@ The expected connection string is formatted as follows:
 hive://hive@{hostname}:{port}/{database}
 ```
 
+#### Arc
+
+The recommended connector library is [arc-superset-dialect](https://pypi.org/project/arc-superset-dialect/). Install with `pip install arc-superset-dialect`.
+
+The connection string looks like:
+
+```
+arc://{api_key}@{hostname}:{port}/{database}
+```
+
+##### Multi-Database Support
+
+Arc supports multiple databases (schemas) within a single instance. In Superset, each Arc database appears as a schema in the SQL Lab, and cross-database queries are supported using `database.table` syntax.
+
 #### SQL Server
 
 The recommended connector library for SQL Server is [pymssql](https://github.com/pymssql/pymssql).
@@ -1769,6 +1784,48 @@ You can use the `Extra` field in the **Edit Databases** form to configure SSL:
      }
 }
 ```
+##### Custom Error Messages
+You can use the `CUSTOM_DATABASE_ERRORS` in the `superset/custom_database_errors.py` file or overwrite it in your config file to configure custom error messages for database exceptions.
+
+This feature lets you transform raw database errors into user-friendly messages, optionally including documentation links and hiding default error codes.
+
+Provide an empty string as the first value to keep the original error message. This way, you can add just a link to the documentation
+**Example usage:**
+```Python
+CUSTOM_DATABASE_ERRORS = {
+    "database_name": {
+        re.compile('permission denied for view'): (
+            __(
+                'Permission denied'
+            ),
+            SupersetErrorType.GENERIC_DB_ENGINE_ERROR,
+            {
+                "custom_doc_links": [
+                    {
+                        "url": "https://example.com/docs/1",
+                        "label": "Check documentation"
+                    },
+                ],
+                "show_issue_info": False,
+            }
+        )
+    },
+    "examples": {
+        re.compile(r'message="(?P<message>[^"]*)"'): (
+            __(
+                'Unexpected error: "%(message)s"'
+            ),
+            SupersetErrorType.GENERIC_DB_ENGINE_ERROR,
+            {}
+        )
+    }
+}
+```
+
+**Options:**
+
+- ``custom_doc_links``: List of documentation links to display with the error.
+- ``show_issue_info``: Set to ``False`` to hide default error codes.
 
 ## Misc
 

docs/docs/configuration/sql-templating.mdx

@@ -12,11 +12,13 @@ version: 1
 SQL Lab and Explore supports [Jinja templating](https://jinja.palletsprojects.com/en/2.11.x/) in queries.
 To enable templating, the `ENABLE_TEMPLATE_PROCESSING` [feature flag](/docs/configuration/configuring-superset#feature-flags) needs to be enabled in `superset_config.py`.
 
-> #### ⚠️ Security Warning
->
-> While powerful, this feature executes template code on the server. Within the Superset security model, this is **intended functionality**, as users with permissions to edit charts and virtual datasets are considered **trusted users**.
->
-> If you grant these permissions to untrusted users, this feature can be exploited as a **Server-Side Template Injection (SSTI)** vulnerability. Do not enable `ENABLE_TEMPLATE_PROCESSING` unless you fully understand and accept the associated security risks.
+:::warning[Security Warning]
+
+While powerful, this feature executes template code on the server. Within the Superset security model, this is **intended functionality**, as users with permissions to edit charts and virtual datasets are considered **trusted users**.
+
+If you grant these permissions to untrusted users, this feature can be exploited as a **Server-Side Template Injection (SSTI)** vulnerability. Do not enable `ENABLE_TEMPLATE_PROCESSING` unless you fully understand and accept the associated security risks.
+
+:::
 
 When templating is enabled, python code can be embedded in virtual datasets and
 in Custom SQL in the filter and metric controls in Explore. By default, the following variables are
@@ -182,7 +184,7 @@ The available validators and names can be found in
 
 In this section, we'll walkthrough the pre-defined Jinja macros in Superset.
 
-**Current Username**
+### Current Username
 
 The `{{ current_username() }}` macro returns the `username` of the currently logged in user.
 
@@ -197,7 +199,7 @@ cache key by adding the following parameter to your Jinja code:
 {{ current_username(add_to_cache_keys=False) }}
 ```
 
-**Current User ID**
+### Current User ID
 
 The `{{ current_user_id() }}` macro returns the account ID of the currently logged in user.
 
@@ -212,7 +214,7 @@ cache key by adding the following parameter to your Jinja code:
 {{ current_user_id(add_to_cache_keys=False) }}
 ```
 
-**Current User Email**
+### Current User Email
 
 The `{{ current_user_email() }}` macro returns the email address of the currently logged in user.
 
@@ -227,7 +229,7 @@ cache key by adding the following parameter to your Jinja code:
 {{ current_user_email(add_to_cache_keys=False) }}
 ```
 
-**Current User Roles**
+### Current User Roles
 
 The `{{ current_user_roles() }}` macro returns an array of roles for the logged in user.
 
@@ -257,7 +259,7 @@ Will be rendered as:
 SELECT * FROM users WHERE role IN ('admin', 'viewer')
 ```
 
-**Current User RLS Rules**
+### Current User RLS Rules
 
 The `{{ current_user_rls_rules() }}` macro returns an array of RLS rules applied to the current dataset for the logged in user.
 
@@ -265,7 +267,7 @@ If you have caching enabled in your Superset configuration, then the list of RLS
 by Superset when calculating the cache key. A cache key is a unique identifier that determines if there's a
 cache hit in the future and Superset can retrieve cached data.
 
-**Custom URL Parameters**
+### Custom URL Parameters
 
 The `{{ url_param('custom_variable') }}` macro lets you define arbitrary URL
 parameters and reference them in your SQL code.
@@ -299,7 +301,7 @@ Here's a concrete example:
   WHERE country_code = 'US'
   ```
 
-**Explicitly Including Values in Cache Key**
+### Explicitly Including Values in Cache Key
 
 The `{{ cache_key_wrapper() }}` function explicitly instructs Superset to add a value to the
 accumulated list of values used in the calculation of the cache key.
@@ -311,7 +313,7 @@ in the cache key. You can gain more context
 Note that this function powers the caching of the `user_id` and `username` values
 in the `current_user_id()` and `current_username()` function calls (if you have caching enabled).
 
-**Filter Values**
+### Filter Values
 
 You can retrieve the value for a specific filter as a list using `{{ filter_values() }}`.
 
@@ -332,7 +334,7 @@ GROUP BY action
 
 There `where_in` filter converts the list of values from `filter_values('action_type')` into a string suitable for an `IN` expression.
 
-**Filters for a Specific Column**
+### Filters for a Specific Column
 
 The `{{ get_filters() }}` macro returns the filters applied to a given column. In addition to
 returning the values (similar to how `filter_values()` does), the `get_filters()` macro
@@ -394,7 +396,7 @@ Here's a concrete example:
     order by lineage, level
 ```
 
-**Time Filter**
+### Time Filter
 
 The `{{ get_time_filter() }}` macro returns the time filter applied to a specific column. This is useful if you want
 to handle time filters inside the virtual dataset, as by default the time filter is placed on the outer query. This can
@@ -469,7 +471,7 @@ WHERE
   AND dttm < {{ time_filter.to_expr }}
 ```
 
-**Datasets**
+### Datasets
 
 It's possible to query physical and virtual datasets using the `dataset` macro. This is useful if you've defined computed columns and metrics on your datasets, and want to reuse the definition in adhoc SQL Lab queries.
 
@@ -493,7 +495,7 @@ Since metrics are aggregations, the resulting SQL expression will be grouped by
 SELECT * FROM {{ dataset(42, include_metrics=True, columns=["ds", "category"]) }} LIMIT 10
 ```
 
-**Metrics**
+### Metrics
 
 The `{{ metric('metric_key', dataset_id) }}` macro can be used to retrieve the metric SQL syntax from a dataset. This can be useful for different purposes:
 
@@ -511,7 +513,7 @@ The parameter can be used in SQL Lab, or when fetching a metric from another dat
 
 Superset supports [builtin filters from the Jinja2 templating package](https://jinja.palletsprojects.com/en/stable/templates/#builtin-filters). Custom filters have also been implemented:
 
-**Where In**
+### Where In
 Parses a list into a SQL-compatible statement. This is useful with macros that return an array (for example the `filter_values` macro):
 
 ```
@@ -528,7 +530,7 @@ Dashboard filter without any value applied
 {{ filter_values('column')|where_in(default_to_none=True) }} => None
 ```
 
-**To Datetime**
+### To Datetime
 
 Loads a string as a `datetime` object. This is useful when performing date operations. For example:
 ```