Skip to main content

Contributing to Liteset

Liteset is an academic, asynchronous port of Apache Superset 6.0.0. Contributions are welcome — but please keep in mind that the product Liteset implements is upstream Apache Superset. If your change is about Superset's product behaviour (UX, charts, dashboards, SQL Lab, dataset model, RBAC semantics), it almost always belongs upstream first; Liteset will pick it up by re-syncing.

Where to discuss​

For broader Superset community channels (Slack, dev mailing list, monthly meetups, Stack Overflow tag), see the upstream community page. Liteset re-uses the Superset product, so most product-level questions are best asked there.

Orientation​

Liteset lives in a single repository:

  • happykust/liteset — the async backend (superset/), the React frontend (superset-frontend/, identical to Apache Superset), tests and infra. The Python package is published to PyPI as liteset.

Upstream reference:

  • apache/superset — Liteset tracks Apache Superset 6.0.0. Most documentation, FAB-isms and configuration semantics flow from here.

Types of contribution​

Report a bug​

File a GitHub issue including:

  • Operating system + version.
  • Liteset version (liteset --version or git SHA).
  • Detailed reproduction steps.
  • Anything special about your setup (reverse proxy, custom superset_config.py, RBAC overrides).

If the bug is a regression vs Apache Superset 6.0.0, please say so explicitly and link the equivalent Apache Superset behaviour — those are the highest-priority fixes for Liteset.

When posting stack traces, quote them with Markdown code blocks.

Feature requests opened as issues will be moved to Discussions.

Suggest a feature​

Open an Ideas discussion:

  • Explain how the feature should behave.
  • Keep the scope narrow.
  • Note whether the same feature already exists or has been requested in upstream Apache Superset (link the upstream issue).

If the feature is product-level Superset behaviour, please file it upstream first — Liteset will not diverge from upstream on product semantics.

Fix a bug or build a feature​

The basic workflow:

  1. Fork happykust/liteset on GitHub.
  2. Branch off main (git checkout -b fix/some-description).
  3. Set up the dev environment as described in Setting up a Development Environment.
  4. Write code + tests. Liteset is async — handlers are async def, DAOs return awaitables, tests use pytest-asyncio.
  5. Run pre-commit and tests locally.
  6. Open a pull request against main. Reference the issue / discussion. Describe what changed and why.
  7. Address review feedback (commit further changes; do not force-push unless the reviewer asks).

There is no heavy Apache-style governance. Non-trivial architectural changes (new layer, new dependency, breaking config change) go through a lightweight LIP (Liteset Improvement Proposal) — open a discussion first so we can agree on direction before code is written.

Improve the documentation​

The site you're reading lives under docs/. It uses Docusaurus 3 and supports English + Russian. To build it locally:

cd docs
yarn install
yarn build
yarn serve --port 3000

Each documentation page has an "Edit this page" link — clicking it opens the source MDX in the GitHub editor. Translations live under docs/i18n/<locale>/.

Code of conduct​

Be respectful and collaborative. Disrespect, harassment or discrimination of any kind will not be tolerated. As an academic project Liteset does not run a separate CoC committee — the project maintainer reserves the right to close issues, lock discussions and ban participants who violate this norm.

Licensing​

Liteset is distributed under the Apache License 2.0, inherited from Apache Superset 6.0.0. By submitting a pull request you agree that your contribution is licensed under the same terms. There is no separate ICLA — the GitHub PR + DCO-style "sign-off" on each commit (git commit -s) is sufficient.