feat(build): migrate from Prettier to Oxfmt for docs

Signed-off-by: hainenber <dotronghai96@gmail.com>
2026-08-04 04:52:32 +00:00 · 2026-07-28 21:38:39 +07:00
parent af9729a861
commit 1bbc63099b
2163 changed files with 89307 additions and 32009 deletions
--- a/docs/developer_docs/contributing/code-review.md
+++ b/docs/developer_docs/contributing/code-review.md
@@ -35,6 +35,7 @@ Code review is a critical part of maintaining code quality and sharing knowledge
 ### Preparing for Review

 #### Before Requesting Review
+
 - [ ] Self-review your changes
 - [ ] Ensure CI checks pass
 - [ ] Add comprehensive tests
@@ -43,6 +44,7 @@ Code review is a critical part of maintaining code quality and sharing knowledge
 - [ ] Add screenshots for UI changes

 #### Self-Review Checklist
+
 ```bash
 # View your changes
 git diff upstream/master
@@ -59,18 +61,23 @@ git diff upstream/master
 ### 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]
@@ -81,23 +88,29 @@ 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?"
 ```

@@ -106,6 +119,7 @@ Thanks!
 ### 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?
@@ -117,12 +131,14 @@ Thanks!
 ### 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
@@ -130,6 +146,7 @@ Thanks!
 - [ ] SOLID principles followed

 #### Testing
+
 - [ ] Unit tests for business logic
 - [ ] Integration tests for APIs
 - [ ] E2E tests for critical paths
@@ -137,6 +154,7 @@ Thanks!
 - [ ] Good test coverage

 #### Security
+
 - [ ] Input validation
 - [ ] SQL injection prevention
 - [ ] XSS prevention
@@ -145,6 +163,7 @@ Thanks!
 - [ ] No sensitive data in logs

 #### Performance
+
 - [ ] Database queries optimized
 - [ ] No N+1 queries
 - [ ] Appropriate caching
@@ -176,11 +195,13 @@ re-renders when dependencies haven't changed."
 #### 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
@@ -206,12 +227,15 @@ praise: Excellent test coverage! 👍
 ### 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
@@ -219,11 +243,13 @@ If no response after 3 days:
 ### 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
@@ -232,16 +258,19 @@ If no response after 3 days:
 ### 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
@@ -251,6 +280,7 @@ If no response after 3 days:
 ## Review Etiquette

 ### Do's
+
 - ✅ Be kind and constructive
 - ✅ Acknowledge time and effort
 - ✅ Provide specific examples
@@ -260,6 +290,7 @@ If no response after 3 days:
 - ✅ Focus on the code, not the person

 ### Don'ts
+
 - ❌ Use harsh or dismissive language
 - ❌ Bikeshed on minor preferences
 - ❌ Review when tired or frustrated
@@ -270,6 +301,7 @@ If no response after 3 days:
 ## 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
@@ -277,6 +309,7 @@ If no response after 3 days:
 5. **Get nominated**: By existing committers

 ### Reviewer Expectations
+
 - Review PRs in your area of expertise
 - Respond within reasonable time
 - Mentor new contributors
@@ -288,6 +321,7 @@ If no response after 3 days:
 ### Reviewing Large PRs

 #### Strategy
+
 1. **Request splitting**: Ask to break into smaller PRs
 2. **Review in phases**:
   - Architecture/approach first
@@ -298,6 +332,7 @@ If no response after 3 days:
 ### Cross-Team Reviews

 #### When Needed
+
 - Changes affecting multiple teams
 - Shared components/libraries
 - API contract changes
@@ -306,6 +341,7 @@ If no response after 3 days:
 ### Performance Reviews

 #### Tools
+
 ```python
 # Backend performance
 import cProfile
@@ -327,11 +363,13 @@ stats.sort_stats('cumulative').print_stats(10)
 ## Resources

 ### Internal
+
 - [Coding Guidelines](../guidelines/design-guidelines.md)
 - [Testing Guide](../testing/overview.md)
 - [Extension Architecture](../extensions/architecture.md)

 ### 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/)
--- a/docs/developer_docs/contributing/development-setup.md
+++ b/docs/developer_docs/contributing/development-setup.md
@@ -150,6 +150,7 @@ make up
 ```

 This automatically:
+
 - Generates a unique project name from your directory name
 - Finds available ports (incrementing from 8088, 9000, etc. if already in use)
 - Displays the assigned URLs before starting
@@ -158,16 +159,16 @@ Each clone gets isolated containers and volumes, so you can run them side-by-sid

 Available commands (run from repo root):

-| Command | Description |
-|---------|-------------|
-| `make up` | Start services (foreground) |
-| `make up-detached` | Start services (background) |
-| `make down` | Stop all services |
-| `make ps` | Show running containers |
-| `make logs` | Follow container logs |
-| `make ports` | Show assigned URLs and ports |
-| `make open` | Open browser to dev server |
-| `make nuke` | Stop, remove volumes & local images |
+| Command            | Description                         |
+| ------------------ | ----------------------------------- |
+| `make up`          | Start services (foreground)         |
+| `make up-detached` | Start services (background)         |
+| `make down`        | Stop all services                   |
+| `make ps`          | Show running containers             |
+| `make logs`        | Follow container logs               |
+| `make ports`       | Show assigned URLs and ports        |
+| `make open`        | Open browser to dev server          |
+| `make nuke`        | Stop, remove volumes & local images |

 From a subdirectory, use: `make -C $(git rev-parse --show-toplevel) up`

@@ -178,6 +179,7 @@ Always use these commands instead of plain `docker compose down`, which won't kn
 ## GitHub Codespaces (Cloud Development)

 GitHub Codespaces provides a complete, pre-configured development environment in the cloud. This is ideal for:
+
 - Quick contributions without local setup
 - Consistent development environments across team members
 - Working from devices that can't run Docker locally
@@ -324,17 +326,21 @@ You can also run the pre-commit checks manually in various ways:
 ## Working with LLMs

 ### Environment Setup
+
 Ensure Docker Compose is running before starting LLM sessions:
+
 ```bash
 docker compose up
 ```

 Validate your environment:
+
 ```bash
 curl -f http://localhost:8088/health && echo "✅ Superset ready"
 ```

 ### LLM Session Best Practices
+
 - Always validate environment setup first using the health checks above
 - Use focused validation commands: `pre-commit run` (not `--all-files`)
 - **Read [LLMS.md](https://github.com/apache/superset/blob/master/LLMS.md) first** - Contains comprehensive development guidelines, coding standards, and critical refactor information
@@ -346,6 +352,7 @@ curl -f http://localhost:8088/health && echo "✅ Superset ready"
 - Follow the TypeScript migration guidelines and avoid deprecated patterns listed in LLMS.md

 ### Key Development Commands
+
 ```bash
 # Frontend development
 cd superset-frontend
@@ -646,7 +653,7 @@ If you want to use the same flag in the client code, also add it to the FeatureF

 ```typescript
 export enum FeatureFlag {
-  SCOPED_FILTER = "SCOPED_FILTER",
+  SCOPED_FILTER = 'SCOPED_FILTER',
 }
 ```

@@ -815,6 +822,7 @@ If Jest tests hang with "Jest did not exit one second after the test run has com
 **To verify if still needed**: Remove the MessageChannel mocking lines and run `npm test -- --shard=4/8`. If tests hang, the workaround is still required.

 **Future removal conditions**: This workaround can be removed when:
+
 - rc-overflow updates to properly clean up MessagePorts in test environments
 - Jest updates to handle MessageChannel/MessagePort cleanup better
 - Ant Design switches away from rc-overflow
@@ -959,9 +967,9 @@ VSCode will not stop on breakpoints right away. We've attached to PID 6 however
 To debug Flask running in POD inside a kubernetes cluster, you'll need to make sure the pod runs as root and is granted the SYS_TRACE capability.These settings should not be used in production environments.

 ```yaml
-  securityContext:
-    capabilities:
-      add: ["SYS_PTRACE"]
+securityContext:
+  capabilities:
+    add: ['SYS_PTRACE']
 ```

 See [set capabilities for a container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) for more details.
--- a/docs/developer_docs/contributing/guidelines.md
+++ b/docs/developer_docs/contributing/guidelines.md
@@ -130,8 +130,8 @@ Triaging goals

 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                                                                                                                                            |
-| --------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| 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                                                                                                        |
@@ -175,12 +175,14 @@ Should you decide that reverting is desirable, it is the responsibility of the C
 - **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
@@ -211,11 +213,13 @@ Sentence case: "A dog takes a walk in Paris"
 - 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"
@@ -240,6 +244,7 @@ Often a product page will have the same title as the objects it contains. In thi
 - 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.
@@ -247,6 +252,7 @@ When writing about UI elements:
 #### **Exceptions to sentence case

 Only use title case for:
+
 - Product names (Apache Superset)
 - Proper nouns
 - Acronyms (SQL, API, CSV)
@@ -258,10 +264,12 @@ Only use title case for:
 ### 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
@@ -336,6 +344,7 @@ def process_data(
 ```

 Use `mypy` to check types:
+
 ```bash
 mypy superset
 ```
@@ -343,8 +352,9 @@ mypy superset
 ### TypeScript

 We use:
+
 - **ESLint** for linting
- **Prettier** for formatting  
+- **Oxfmt** for formatting
 - **TypeScript** strict mode

 TypeScript is fully supported and is the recommended language for writing all new frontend
@@ -353,6 +363,7 @@ appreciated, but not required. Examples of migrating functions/components to Typ
 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
@@ -360,6 +371,7 @@ TypeScript code should:
 - Handle errors appropriately

 Example:
+
 ```typescript
 interface User {
  id: number;
@@ -411,5 +423,6 @@ Bad: "Fixed stuff"
 ## 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)
--- a/docs/developer_docs/contributing/howtos.md
+++ b/docs/developer_docs/contributing/howtos.md
@@ -68,11 +68,13 @@ Visualization plugins allow you to add custom chart types to Superset. They are
 ### 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
@@ -80,19 +82,22 @@ 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.
+   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:
@@ -100,7 +105,7 @@ npm link superset-plugin-chart-hello-world
 ```

 7. **Import and register in Superset**:
-Edit `superset-frontend/src/visualizations/presets/MainPreset.ts` to include your plugin.
+   Edit `superset-frontend/src/visualizations/presets/MainPreset.ts` to include your plugin.

 ## Testing

@@ -121,7 +126,7 @@ pytest --cov=superset
 # Run only unit tests
 pytest tests/unit_tests

-# Run only integration tests  
+# Run only integration tests
 pytest tests/integration_tests
 ```

@@ -234,6 +239,7 @@ For debugging the Flask backend:
 #### Using VS Code

 1. Add to `.vscode/launch.json`:
+
 ```json
 {
  "version": "0.2.0",
@@ -261,9 +267,9 @@ For debugging the Flask backend:
 To debug Flask running in a POD inside a kubernetes cluster, you'll need to make sure the pod runs as root and is granted the `SYS_PTRACE` capability. These settings should not be used in production environments.

 ```yaml
-  securityContext:
-    capabilities:
-      add: ["SYS_PTRACE"]
+securityContext:
+  capabilities:
+    add: ['SYS_PTRACE']
 ```

 See [set capabilities for a container](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) for more details.
@@ -349,7 +355,7 @@ uses Claude AI to generate draft translations for any missing entries. All
 AI-generated strings are marked `#, fuzzy` and tagged with an attribution
 comment so that human reviewers know they need to be checked.

-Note that `#, fuzzy` marks a translation as *needing review*, not as *withheld*:
+Note that `#, fuzzy` marks a translation as _needing review_, not as _withheld_:
 both the frontend and backend builds serve fuzzy entries (see [Applying
 translations](#applying-translations) above), so an AI-generated string is shown
 in the UI as soon as it is built and deployed. Reviewers should verify each
@@ -395,6 +401,7 @@ python scripts/translations/backfill_po.py --lang fr --limit 20 --dry-run
 ```

 Output shows each string, its translation, and a context tag:
+
 - No tag — 3+ reference languages available (high confidence)
 - `[ctx:N]` — only N other languages have this string (lower confidence)
 - `[ctx:0]` — no other language has this string yet; English alone used
@@ -407,15 +414,15 @@ python scripts/translations/backfill_po.py --lang fr

 Options:

-| Flag | Default | Description |
-|------|---------|-------------|
-| `--lang LANG` | required | ISO language code (`fr`, `de`, `ja`, …) |
-| `--batch-size N` | 50 | Strings per Claude request |
-| `--limit N` | unlimited | Stop after N entries |
-| `--min-context N` | 0 | Skip entries with fewer than N reference translations |
-| `--model MODEL` | `claude-sonnet-4-6` | Claude model to use |
-| `--dry-run` | off | Print without writing |
-| `--no-fuzzy` | off | Don't mark entries as fuzzy |
+| Flag              | Default             | Description                                           |
+| ----------------- | ------------------- | ----------------------------------------------------- |
+| `--lang LANG`     | required            | ISO language code (`fr`, `de`, `ja`, …)               |
+| `--batch-size N`  | 50                  | Strings per Claude request                            |
+| `--limit N`       | unlimited           | Stop after N entries                                  |
+| `--min-context N` | 0                   | Skip entries with fewer than N reference translations |
+| `--model MODEL`   | `claude-sonnet-4-6` | Claude model to use                                   |
+| `--dry-run`       | off                 | Print without writing                                 |
+| `--no-fuzzy`      | off                 | Don't mark entries as fuzzy                           |

 Use `--min-context 2` to skip strings that have fewer than 2 reference
 translations in other languages. Those strings are more likely to be ambiguous
@@ -488,8 +495,8 @@ npm run check:custom-rules
 # Run tsc (typescript) checks
 npm run type

-# Format with Prettier
-npm run prettier
+# Format with Oxfmt
+npm run format
 ```

 #### Architecture
@@ -519,6 +526,7 @@ The linting system consists of two components:
 **"Plugin 'basic-custom-plugin' not found" Error**

 Ensure you're using the explicit config:
+
 ```bash
 npx oxlint --config oxlint.json
 ```
@@ -526,6 +534,7 @@ npx oxlint --config oxlint.json
 **Custom Rules Not Running**

 Verify the AST parsing dependencies are installed:
+
 ```bash
 npm ls @babel/parser @babel/traverse glob
 ```
@@ -544,6 +553,7 @@ 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
@@ -573,6 +583,7 @@ docker compose up
 **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
 ```
@@ -580,12 +591,14 @@ 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

@@ -683,6 +696,7 @@ To do this, you'll need to:
  ```

 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
--- a/docs/developer_docs/contributing/issue-reporting.md
+++ b/docs/developer_docs/contributing/issue-reporting.md
@@ -31,6 +31,7 @@ Learn how to effectively report bugs and request features for Apache Superset.
 ### Pre-Issue Checklist

 1. **Search Existing Issues**
+
   ```
   Search: https://github.com/apache/superset/issues
   - Use keywords from your error message
@@ -44,6 +45,7 @@ Learn how to effectively report bugs and request features for Apache Superset.
   - [Configuration Guide](https://superset.apache.org/docs/configuration/configuring-superset)

 3. **Verify Version**
+
   ```bash
   # Check Superset version
   superset version
@@ -63,24 +65,30 @@ Learn how to effectively report bugs and request features for Apache Superset.

 ```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.11.7]
 - Node version: [e.g., 18.17.0]
@@ -89,6 +97,7 @@ If applicable, add screenshots or recordings.
 - OS: [e.g., Ubuntu 22.04]

 ### Additional Context
+
 - Using Docker: Yes/No
 - Configuration overrides:
 - Feature flags enabled:
@@ -98,12 +107,15 @@ If applicable, add screenshots or recordings.
 ### 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
@@ -112,18 +124,22 @@ SQL Lab datasets don't update, while charts using regular datasets do.
 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.11.16
 - Database: PostgreSQL 14.9
@@ -132,6 +148,7 @@ No error messages in browser console or server logs.
 ```

 #### ❌ Poor Example
+
 ```markdown
 Dashboard filters don't work. Please fix.
 ```
@@ -139,6 +156,7 @@ Dashboard filters don't work. Please fix.
 ### Required Information

 #### Error Messages
+
 ```python
 # Include full error traceback
 Traceback (most recent call last):
@@ -148,6 +166,7 @@ SupersetException: Detailed error message
 ```

 #### Logs
+
 ```bash
 # Backend logs
 docker logs superset_app 2>&1 | tail -100
@@ -157,6 +176,7 @@ tail -f ~/.superset/superset.log
 ```

 #### Browser Console
+
 ```javascript
 // Include JavaScript errors
 // Chrome: F12 → Console tab
@@ -165,6 +185,7 @@ tail -f ~/.superset/superset.log
 ```

 #### Configuration
+
 ```python
 # Relevant config from superset_config.py
 FEATURE_FLAGS = {
@@ -179,18 +200,23 @@ FEATURE_FLAGS = {

 ```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
@@ -199,6 +225,7 @@ Any other context, mockups, or examples.
 ### Good Feature Requests Include

 1. **Clear Use Case**
+
   ```markdown
   As a [type of user], I want [feature] so that [benefit].

@@ -224,6 +251,7 @@ Any other context, mockups, or examples.
 **DO NOT** create public issues for security vulnerabilities!

 Instead:
+
 1. Email: security@apache.org
 2. Subject: `[Superset] Security Vulnerability`
 3. Include:
@@ -238,9 +266,11 @@ Instead:
 Send to: security@apache.org

 ### Vulnerability Description
+
 [Describe the security issue]

 ### Type
+
 - [ ] SQL Injection
 - [ ] XSS
 - [ ] CSRF
@@ -249,27 +279,33 @@ Send to: security@apache.org
 - [ ] 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
@@ -277,6 +313,7 @@ Send to: security@apache.org
 - `question`: Question about usage

 ### Component Labels
+
 - `dashboard`: Dashboard functionality
 - `sqllab`: SQL Lab
 - `explore`: Chart builder
@@ -285,6 +322,7 @@ Send to: security@apache.org
 - `security`: Security related

 ### Status Labels
+
 - `needs-triage`: Awaiting review
 - `confirmed`: Bug confirmed
 - `in-progress`: Being worked on
@@ -294,25 +332,30 @@ Send to: security@apache.org
 ## 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
@@ -322,6 +365,7 @@ Send to: security@apache.org
 ### 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?
@@ -343,6 +387,7 @@ Here's additional debugging information: [details]
 ## Tips for Success

 ### Do's
+
 - ✅ Search before creating
 - ✅ Use templates
 - ✅ Provide complete information
@@ -352,6 +397,7 @@ Here's additional debugging information: [details]
 - ✅ One issue per report

 ### Don'ts
+
 - ❌ "+1" or "me too" comments (use reactions)
 - ❌ Multiple issues in one report
 - ❌ Vague descriptions
@@ -410,6 +456,7 @@ with app.app_context():
 ### Issue Not a Bug?

 Consider:
+
 - **Feature Request**: Use feature request template
 - **Question**: Use GitHub Discussions
 - **Configuration Help**: Ask in Slack
--- a/docs/developer_docs/contributing/overview.md
+++ b/docs/developer_docs/contributing/overview.md
@@ -146,7 +146,7 @@ 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.
+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:

--- a/docs/developer_docs/contributing/pkg-resources-migration.md
+++ b/docs/developer_docs/contributing/pkg-resources-migration.md
@@ -61,6 +61,7 @@ Update all dependencies to use `importlib.metadata` instead of `pkg_resources`:
 #### Migration Example

 **Old (deprecated):**
+
 ```python
 import pkg_resources

@@ -69,6 +70,7 @@ entry_points = pkg_resources.iter_entry_points("group_name")
 ```

 **New (recommended):**
+
 ```python
 from importlib.metadata import version, entry_points

@@ -79,11 +81,13 @@ eps = entry_points(group="group_name")
 ## Action Items

 ### For Superset Maintainers
+
 1. The Superset codebase already uses `importlib.metadata`
 2. Monitor third-party dependencies for updates
 3. Update setuptools pin once the ecosystem is ready

 ### For Extension Developers
+
 1. **Update your packages** to use `importlib.metadata` instead of `pkg_resources`
 2. **Test with setuptools >= 81.0.0** once all packages are migrated

--- a/docs/developer_docs/contributing/release-process.md
+++ b/docs/developer_docs/contributing/release-process.md
@@ -29,6 +29,7 @@ Understand Apache Superset's release process, versioning strategy, and how to pa
 ## 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
@@ -46,6 +47,7 @@ MAJOR.MINOR.PATCH
 ```

 ### 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
@@ -55,12 +57,14 @@ MAJOR.MINOR.PATCH
 ### 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
@@ -69,12 +73,14 @@ MAJOR.MINOR.PATCH
 ### 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
@@ -82,12 +88,14 @@ MAJOR.MINOR.PATCH
 ### 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
@@ -97,6 +105,7 @@ MAJOR.MINOR.PATCH
 ### 1. Pre-Release Preparation

 #### Feature Freeze
+
 ```bash
 # Create release branch
 git checkout -b release-X.Y
@@ -108,40 +117,49 @@ 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"
@@ -158,6 +176,7 @@ 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
@@ -202,11 +221,13 @@ Thanks,
 ```

 #### 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
@@ -219,6 +240,7 @@ Thanks,
 ### 4. Release Approval

 #### Tally Votes
+
 ```
 Subject: [RESULT][VOTE] Release Apache Superset X.Y.Z RC1

@@ -245,6 +267,7 @@ 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"
@@ -256,12 +279,14 @@ svn mv https://dist.apache.org/repos/dist/dev/superset/X.Y.Zrc1 \
 ```

 #### 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 .
@@ -273,6 +298,7 @@ docker push apache/superset:latest
 ### 6. Post-Release Tasks

 #### Update Documentation
+
 ```bash
 # Update docs version
 cd docs
@@ -310,6 +336,7 @@ The Apache Superset Team
 ```

 #### Update GitHub Release
+
 ```bash
 # Create GitHub release
 gh release create vX.Y.Z \
@@ -322,12 +349,14 @@ gh release create vX.Y.Z \
 ### During Feature Freeze

 #### What's Allowed
+
 - ✅ Bug fixes
 - ✅ Documentation updates
 - ✅ Test improvements
 - ✅ Security fixes

 #### What's Not Allowed
+
 - ❌ New features
 - ❌ Major refactoring
 - ❌ Breaking changes
@@ -336,6 +365,7 @@ gh release create vX.Y.Z \
 ### 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
@@ -345,6 +375,7 @@ docker pull apache/superset:X.Y.Zrc1
 ```

 #### What to Test
+
 - Your use cases
 - New features mentioned in release notes
 - Upgrade from previous version
@@ -352,8 +383,10 @@ docker pull apache/superset:X.Y.Zrc1
 - Critical workflows

 #### Reporting Issues
+
 ```markdown
 Found issue in RC1:
+
 - Description: [what's wrong]
 - Steps to reproduce: [how to trigger]
 - Impact: [blocker/major/minor]
@@ -363,21 +396,26 @@ Found issue in RC1:
 ### 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)"
@@ -390,31 +428,38 @@ git log --oneline vX.Y-1.Z..vX.Y.Z | grep -E "^[a-f0-9]+ (feat|fix|perf|refactor
 ### Documentation Required

 #### UPDATING.md Entry
-```markdown
+
+````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

@@ -423,7 +468,7 @@ new_function(param1, param2, param3)
   @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

@@ -432,12 +477,14 @@ new_function(param1, param2, param3)
 ## 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]

@@ -458,11 +505,13 @@ Credit:
 ## 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)

--- a/docs/developer_docs/contributing/resources.md
+++ b/docs/developer_docs/contributing/resources.md
@@ -117,16 +117,19 @@ You can also [download the .svg](https://github.com/apache/superset/tree/master/
 ## 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/admin-docs/configuration/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)
--- a/docs/developer_docs/contributing/submitting-pr.md
+++ b/docs/developer_docs/contributing/submitting-pr.md
@@ -29,12 +29,14 @@ 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.md)
 - [ ] You've found or created an issue to work on

 ### PR Readiness Checklist
+
 - [ ] Code follows [coding guidelines](../guidelines/design-guidelines.md)
 - [ ] Tests are passing locally
 - [ ] Linting passes (`pre-commit run --all-files`)
@@ -82,6 +84,7 @@ type(scope): description
 ```

 **Types:**
+
 - `feat`: New feature
 - `fix`: Bug fix
 - `docs`: Documentation only
@@ -95,6 +98,7 @@ type(scope): description
 - `revert`: Reverting changes

 **Scopes:**
+
 - `dashboard`: Dashboard functionality
 - `sqllab`: SQL Lab features
 - `explore`: Chart explorer
@@ -105,6 +109,7 @@ type(scope): description
 - `config`: Configuration

 **Examples:**
+
 ```
 feat(sqllab): add query cost estimation
 fix(dashboard): resolve filter cascading issue
@@ -119,23 +124,28 @@ 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
@@ -158,11 +168,13 @@ gh pr create --title "feat(sqllab): add query cost estimation" \
 ## 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"
@@ -173,6 +185,7 @@ git commit -m "updates"
 ```

 ### Include Tests
+
 ```python
 # Backend test example
 def test_new_feature():
@@ -190,15 +203,19 @@ test('renders new component', () => {
 ```

 ### Add Screenshots for UI Changes
+
 ```markdown
 ### Before
+
 ![Before](link-to-before-screenshot)

-### After  
+### 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
@@ -206,7 +223,9 @@ test('renders new component', () => {
 ## CI Checks

 ### Required Checks
+
 All PRs must pass:
+
 - `Python Tests` - Backend unit/integration tests
 - `Frontend Tests` - JavaScript/TypeScript tests
 - `Linting` - Code style checks
@@ -217,6 +236,7 @@ All PRs must pass:
 ### Common CI Failures

 #### Python Test Failures
+
 ```bash
 # Run locally to debug
 pytest tests/unit_tests/ -v
@@ -224,12 +244,14 @@ 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
@@ -243,6 +265,7 @@ pre-commit run --all-files
 ## Responding to Reviews

 ### Address Feedback Promptly
+
 ```bash
 # Make requested changes
 edit files...
@@ -254,11 +277,13 @@ 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
@@ -276,6 +301,7 @@ git push --force-with-lease origin feature/your-feature-name
 ## After Merge

 ### Clean Up
+
 ```bash
 # Delete local branch
 git checkout master
@@ -291,6 +317,7 @@ git push origin master
 ```

 ### Follow Up
+
 - Monitor for any issues reported
 - Help with documentation if needed
 - Consider related improvements
@@ -298,6 +325,7 @@ git push origin master
 ## Tips for Success

 ### Do
+
 - ✅ Keep PRs small and focused
 - ✅ Write descriptive PR titles and descriptions
 - ✅ Include tests for new functionality
@@ -306,6 +334,7 @@ git push origin master
 - ✅ Be patient with the review process

 ### Don't
+
 - ❌ Submit PRs with failing tests
 - ❌ Include unrelated changes
 - ❌ Force push to master