Ways to Contribute
There are many ways you can contribute to kubectx and kubens:- Report bugs - Found an issue? Let us know!
- Suggest features - Have an idea for improvement? Share it!
- Fix bugs - Submit a pull request to fix an existing issue
- Add features - Implement new functionality
- Improve documentation - Help make the docs better
- Write tests - Increase test coverage
- Review pull requests - Help review community contributions
Before You Start
Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one. You generally only need to submit a CLA once, so if you’ve already submitted one (even if it was for a different project), you probably don’t need to do it again.The CLA process is quick and only needs to be completed once for all Google open source projects.
Development Setup
Prerequisites
To contribute to kubectx and kubens, you’ll need:- Go 1.21 or later (for the Go implementation)
- Git for version control
- Make for building the project
- kubectl for testing
- A Kubernetes cluster for testing (minikube, kind, or real cluster)
Clone the Repository
Build the Project
Run Tests
Making Changes
1. Create an Issue First
Before starting work on a major feature or change:- Check if an issue already exists for your idea
- If not, create a new issue describing:
- The problem you’re solving
- Your proposed solution
- Any alternatives you considered
2. Fork and Branch
feature/- for new featuresfix/- for bug fixesdocs/- for documentation changesrefactor/- for code refactoring
3. Make Your Changes
When writing code: Go Code Standards:- Follow Effective Go guidelines
- Use
go fmtto format your code - Run
go vetto check for common mistakes - Add tests for new functionality
- Update existing tests if behavior changes
- Use shellcheck to validate scripts
- Follow existing code style
- Add comments for complex logic
- Update README.md if adding new features
- Update help text in code
- Add code comments for complex logic
4. Write Tests
All new features and bug fixes should include tests:5. Commit Your Changes
Write clear, descriptive commit messages:- Use present tense (“Add feature” not “Added feature”)
- First line should be 50 characters or less
- Add detailed description after a blank line if needed
- Reference issue numbers (e.g., “Fixes #123”)
6. Push and Create Pull Request
- Clear title - Summarize the change
- Description - Explain what, why, and how
- Issue reference - Link to related issues
- Testing - Describe how you tested the change
- Screenshots - If applicable (for UI changes)
Code Review Process
What to Expect
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Review timeline:- Initial review: Usually within a few days
- Feedback iterations: Varies based on complexity
- Merge: After all feedback is addressed and tests pass
- Request changes to code style
- Ask for additional tests
- Suggest architectural improvements
- Request documentation updates
Responding to Feedback
When reviewers request changes:- Make the requested changes in your branch
- Commit and push the updates
- Reply to review comments explaining your changes
- Mark conversations as resolved when addressed
Getting Your PR Merged
Your pull request will be merged when:- All review feedback is addressed
- All tests pass (CI checks are green)
- The CLA is signed
- At least one maintainer approves
- No merge conflicts exist
Testing Guidelines
Manual Testing
Before submitting a PR, manually test your changes:Automated Testing
Ensure all automated tests pass:Documentation Contributions
Documentation improvements are highly valued!README Updates
If your change affects user-facing functionality:- Update the main README.md
- Update relevant examples
- Add new sections if introducing features
Code Documentation
For code changes:Help Text
Update help text if adding or modifying commands:Common Contribution Scenarios
Adding a New Command
- Add command parsing in
flags.go - Create operation struct and
Run()method - Add help text in
help.go - Write unit tests
- Update README.md
- Test manually
Fixing a Bug
- Write a test that reproduces the bug
- Verify the test fails
- Fix the bug
- Verify the test passes
- Submit PR with test and fix
Improving Error Messages
- Identify unclear error messages
- Update error text to be more descriptive
- Ensure errors include context
- Test error paths manually
Getting Help
If you need help with your contribution:- Ask in the issue - Comment on the related issue
- GitHub Discussions - Start a discussion for general questions
- Pull Request - Ask questions in your PR description or comments
- Review existing code - Look at similar features for guidance
Release Process
This section is informational for contributors. Releases are handled by maintainers.
- MAJOR - Incompatible API changes
- MINOR - New functionality (backward compatible)
- PATCH - Bug fixes (backward compatible)
Code of Conduct
We are committed to providing a welcoming and inclusive environment:- Be respectful and considerate
- Welcome newcomers and help them get started
- Focus on constructive feedback
- Assume good intentions
- Respect differing viewpoints and experiences
Recognition
Contributors are recognized in:- GitHub contributors list
- Release notes (for significant contributions)
- Project README (for major features)