* request to add kcp-edge-devs group changes to ownership and strategy for kcp is requiring kcp-edge to change strategy and establish our own slack channel, mailing list, and etc. We would like to continue working within the kubernetes ecosystem as we are expanding our support to work with a variety of different kubernetes distributions, not just kcp. * Update usergroups.yaml corrected indent on line 294 * updated user names to match GH * Update usergroups.yaml name of project has changed * Update communication/slack-config/usergroups.yaml Co-authored-by: Madhav Jivrajani <12381034+MadhavJivrajani@users.noreply.github.com> * Update usergroups.yaml converted to lowercase * Update usergroups.yaml I had names from PROW in here - they are now kubernetes slack org IDs. Sorry about that. --------- Co-authored-by: Madhav Jivrajani <12381034+MadhavJivrajani@users.noreply.github.com> |
||
---|---|---|
.github | ||
archive | ||
committee-code-of-conduct | ||
committee-security-response | ||
committee-steering | ||
communication | ||
contributors | ||
elections | ||
events | ||
generator | ||
github-management | ||
hack | ||
icons | ||
mentoring | ||
sig-api-machinery | ||
sig-apps | ||
sig-architecture | ||
sig-auth | ||
sig-autoscaling | ||
sig-cli | ||
sig-cloud-provider | ||
sig-cluster-lifecycle | ||
sig-contributor-experience | ||
sig-docs | ||
sig-instrumentation | ||
sig-k8s-infra | ||
sig-multicluster | ||
sig-network | ||
sig-node | ||
sig-release | ||
sig-scalability | ||
sig-scheduling | ||
sig-security | ||
sig-storage | ||
sig-testing | ||
sig-ui | ||
sig-usability | ||
sig-windows | ||
ug-vmware-users | ||
wg-api-expression | ||
wg-batch | ||
wg-data-protection | ||
wg-iot-edge | ||
wg-multitenancy | ||
wg-policy | ||
wg-structured-logging | ||
.generated_files | ||
.gitignore | ||
CLA.md | ||
CONTRIBUTING.md | ||
LICENSE | ||
Makefile | ||
OWNERS | ||
OWNERS_ALIASES | ||
README.md | ||
SECURITY.md | ||
SECURITY_CONTACTS | ||
SIG-diagram.png | ||
SIG-diagram.svg | ||
code-of-conduct.md | ||
community-membership.md | ||
go.mod | ||
go.sum | ||
governance.md | ||
kubernetes_governance_diagram.png | ||
liaisons.md | ||
sig-list.md | ||
sig-wg-lifecycle.md | ||
sigs.yaml | ||
values.md |
README.md
Kubernetes Community
Welcome to the Kubernetes community!
This is the starting point for joining and contributing to the Kubernetes community - improving docs, improving code, giving talks etc.
To learn more about the project structure and organization, please refer to Project Governance information.
Communicating
The communication page lists communication channels like chat, issues, mailing lists, conferences, etc.
For more specific topics, try a SIG.
Governance
Kubernetes has the following types of groups that are officially supported:
- Committees are named sets of people that are chartered to take on sensitive topics. This group is encouraged to be as open as possible while achieving its mission but, because of the nature of the topics discussed, private communications are allowed. Examples of committees include the steering committee and things like security or code of conduct.
- Special Interest Groups (SIGs) are persistent open groups that focus on a part of the project.
SIGs must have open and transparent proceedings.
Anyone is welcome to participate and contribute provided they follow the Kubernetes Code of Conduct.
The purpose of a SIG is to own and develop a set of subprojects.
- Subprojects Each SIG can have a set of subprojects.
These are smaller groups that can work independently.
Some subprojects will be part of the main Kubernetes deliverables while others will be more speculative and live in the
kubernetes-sigs
github org.
- Subprojects Each SIG can have a set of subprojects.
These are smaller groups that can work independently.
Some subprojects will be part of the main Kubernetes deliverables while others will be more speculative and live in the
- Working Groups are temporary groups that are formed to address issues that cross SIG boundaries. Working groups do not own any code or other long term artifacts. Working groups can report back and act through involved SIGs.
- User Groups are groups for facilitating communication and discovery of information related to topics that have long term relevance to large groups of Kubernetes users. They do not have ownership of parts of the Kubernetes code base.
See the full governance doc for more details on these groups.
A SIG can have its own policy for contribution, described in a README
or CONTRIBUTING
file in the SIG folder in this repo (e.g. sig-cli/CONTRIBUTING.md), and its own mailing list, slack channel, etc.
If you want to edit details about a SIG (e.g. its weekly meeting time or its leads), please follow these instructions that detail how our docs are auto-generated.
Learn to Build
Links in contributors/devel/README.md lead to many relevant technical topics.
Contribute
A first step to contributing is to pick from the list of kubernetes SIGs. Start attending SIG meetings, join the slack channel and subscribe to the mailing list. SIGs will often have a set of "help wanted" issues that can help new contributors get involved.
The Contributor Guide provides detailed instruction on how to get your ideas and bug fixes seen and accepted, including:
- How to file an issue
- How to find something to work on
- How to open a pull request
Membership
We encourage all contributors to become members. We aim to grow an active, healthy community of contributors, reviewers, and code owners. Learn more about requirements and responsibilities of membership in our Community Membership page.