title | weight | aliases | description | |
---|---|---|---|---|
Getting Started |
1 |
|
A small list of things that you should read and be familiar with before you get started with contributing. This includes such things as signing the Contributor License Agreement, familiarizing yourself with our Code of Conduct, and more. |
Have you ever wanted to contribute to the coolest cloud technology? This guide will help you understand the overall organization of the Kubernetes project, and direct you to the best places to get started contributing. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged.
This document is the single source of truth for how to contribute to the code base. Feel free to browse the open issues and file new ones, all feedback is welcome!
Welcome to Kubernetes! This guide is broken up into the following sections. It is recommended that you follow these steps in order:
- Welcome - this page
- Prerequisites - tasks you need to complete before you can start contributing to Kubernetes
- Your First Contribution - things you'll need to know before making your first contribution
- Contributing - the main reference guide to contributing to Kubernetes
Before submitting code to Kubernetes, you should first complete the following prerequisites. These steps are checked automatically by a bot during your first submission. Completing these steps will make your first contribution easier:
Before you get started, you will need to sign up for a GitHub user account.
Before you can contribute to Kubernetes, you will need to sign the Contributor License Agreement. The easiest way to do so is to open a PR against the contributor playground repo, you can find an example PR here.
Note: kubernetes-sigs/contributor-playground is a repository for practicing submitting your first PR, not just for CLA registration. When creating and submitting a new PR, please write the PR description according to the provided template. Check the above example PR for reference.
Please make sure to read and observe the Code of Conduct and Community Values
It is not required to set up a developer environment in order to contribute to Kubernetes.
If you plan to contribute code changes, review the developer resources page for how to set up your environment.
Kubernetes is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly, and collaborative environment.
- Read and review the Community Expectations for an understanding of code and review expectations.
- See Community Membership for a list of the various responsibilities of contributor roles.
- You are encouraged to move up this contributor ladder as you gain experience.
If you are looking for a safe place, where you can familiarize yourself with the pull request and issue review process in Kubernetes, then the Kubernetes Contributor Playground is the right place for you.
A Youtube playlist of the New Contributor workshop has been posted. An outline of the video content can be found here.
Kubernetes is a large, lively, friendly open-source community. As many open source projects often do, it depends on new people becoming members and regular code contributors. The Community Membership Document covers membership processes and roles. Please consider joining Kubernetes, and making your way up the contributor ladder!
- General Information relating to Kubernetes communication policies
Kubernetes participates in KubeCon + CloudNativeCon, held three times per year in China, Europe, and North America. Information about these and other community events is available on the CNCF Events pages.
All Kubernetes meetups follow the general Cloud Native Computing Foundation Guidelines You may also contact CNCF Staff driving the Community Groups (previously known as Meetups) program by email ([email protected])
Learn more about the Kubernetes mentoring initiatives.
This section includes things that need to be documented, but typical contributors do not need to interact with regularly.
- OWNERS files - The Kubernetes organizations are managed with OWNERS files, which outline which parts of the code are owned by what groups.