Skip to main content

​
Welcome

Welcome to Kubernetes Dashboard! We’re excited about the prospect of you joining our community. The Kubernetes community abides by the CNCF code of conduct:
As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

​
Getting Started

Before contributing, familiarize yourself with the project:

Project Documentation

Read the project documentation

Kubernetes Dashboard Guide

Official Kubernetes documentation

​
Required Reading

Before contributing, please review:

​
Contributor License Agreement

Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests.

Sign the CLA

Review and sign the Contributor License Agreement

​
Contributor Guides

Kubernetes Contributor Guide

Main contributor documentation

Contributor Cheat Sheet

Common resources for developers

​
Contribution Workflow

​
1. Submit an Issue

Before starting work:
  1. Search existing issues to avoid duplicates
  2. Create a new issue describing your proposed change
  3. Wait for feedback from maintainers
For bug reports, include steps to reproduce, expected behavior, and actual behavior.

​
2. Fork and Clone

Once your proposal is approved: 
# Fork the repository on GitHub, then clone your fork
git clone https://github.com/YOUR_USERNAME/dashboard.git
cd dashboard

# Add upstream remote
git remote add upstream https://github.com/kubernetes/dashboard.git

​
3. Create a Branch

Create a feature branch for your changes: 
git checkout -b feature/my-feature

​
4. Make Changes

Make your changes following the project’s code conventions:

​
Go Code Conventions

​
Angular Code Conventions

​
5. Test Your Changes

Before submitting, ensure all tests pass: 
# Run all tests
make test

# Run all checks (linting, formatting, etc.)
make check

# Fix auto-fixable issues
make fix
See the Testing guide for detailed testing instructions.

​
6. Commit Your Changes

Write clear, descriptive commit messages: 
git add .
git commit -m "Add feature: brief description of changes"
Commit Message Guidelines:
  • Use present tense (“Add feature” not “Added feature”)
  • Use imperative mood (“Move cursor to…” not “Moves cursor to…”)
  • Limit first line to 72 characters
  • Reference issues and pull requests liberally

​
7. Push and Create Pull Request

# Push to your fork
git push origin feature/my-feature
Then create a pull request on GitHub.

​
Pull Request Process

​
Review Process

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. What to expect:
  1. Automated checks run on your PR
  2. Maintainers review your code
  3. Feedback is provided for improvements
  4. Approval required before merging

​
Pre-Submission Checklist

Before submitting your PR, ensure:
  • All tests pass locally (make test)
  • All checks pass locally (make check)
  • Code follows project conventions
  • License headers are present (make check-license)
  • Commit messages are clear and descriptive
  • PR description explains the change
  • Issue is referenced in PR description

​
Required Checks

Your PR must pass the following automated checks:
All unit tests must pass across all modules.Run locally:
make test
Code must pass all linting checks:
  • golangci-lint for Go
  • eslint for TypeScript/JavaScript
  • stylelint for CSS/SCSS
  • prettier for formatting
Run locally:
make check
All source files must have proper license headers.Check locally:
make check-license
Fix automatically:
make fix-license
The project must build successfully.Run locally:
make build

​
Development Best Practices

​
Dependency Management

​
Go Dependencies

  • Use only official releases
  • Avoid using specific commits or latest
  • Run go mod tidy before committing
  • Dependencies are managed with go mod

​
JavaScript Dependencies

  • Use Yarn for package management
  • Update package.json and commit yarn.lock
  • Avoid suspicious or unknown dependencies

​
Security

  • Never commit sensitive information (credentials, tokens, etc.)
  • Keep dependencies updated
  • Follow security best practices
  • Report security issues privately to maintainers

​
Code Quality Tools

The project uses several tools to maintain code quality:
ToolPurposeDocumentation
golangci-lintGo lintinggolangci-lint
eslintJS/TS lintingeslint
stylelintCSS/SCSS lintingstylelint
prettierCode formattingprettier

​
Communication Channels

Get in touch with the community:

Slack Channel

Join #sig-ui on Kubernetes Slack

Mailing List

Subscribe to kubernetes-sig-ui mailing list

​
Mentorship

New to Kubernetes or open source?

Mentoring Initiatives

We have diverse mentorship programs available that are always looking for volunteers!

​
Release Process

The project follows semver versioning scheme.

​
Module Releases

Each module has its own releases:
  • api/v1.0.0
  • web/v2.4.5
  • auth/v1.2.3
  • etc.

​
Application Releases

Application releases are created via Helm chart updates:
  • Tag format: v3.0.0
  • Includes detailed release notes
  • Includes compatibility matrix
  • Includes upgrade instructions

​
Making Your First Contribution

Look for issues labeled good first issue or help wanted: 
# Search for beginner-friendly issues
https://github.com/kubernetes/dashboard/labels/good%20first%20issue
Don’t hesitate to ask questions! The community is here to help.

​
Next Steps

Getting Started

Set up your development environment

Testing

Learn how to run tests

Build docs developers (and LLMs) love

Get started for freeTalk to us