8ede53fc27
The go-code.md file is mostly redundant relative to contributors/devel/development.md and godep.md, the contributors/guide/coding-conventions.md document and the various now standard and easily searchable k8s external sources of information about the Go language. The redundant links are simply dropped. The moovweg/gvm link is dropped as the project appears stale with no releases in years, many open issues, no commits in a year and shows a build failure in its CI badge. The emptied go-code.md file is retained, leaving a pointer to the new location in its place. Signed-off-by: Tim Pepper <tpepper@vmware.com> |
||
|---|---|---|
| .github | ||
| archive | ||
| committee-steering | ||
| communication | ||
| contributors | ||
| events | ||
| generator | ||
| hack | ||
| keps | ||
| mentoring | ||
| project-managers | ||
| sig-api-machinery | ||
| sig-apps | ||
| sig-architecture | ||
| sig-auth | ||
| sig-autoscaling | ||
| sig-aws | ||
| sig-azure | ||
| sig-big-data | ||
| sig-cli | ||
| sig-cluster-lifecycle | ||
| sig-cluster-ops | ||
| sig-contributor-experience | ||
| sig-docs | ||
| sig-gcp | ||
| sig-instrumentation | ||
| sig-multicluster | ||
| sig-network | ||
| sig-node | ||
| sig-on-premise | ||
| sig-openstack | ||
| sig-product-management | ||
| sig-release | ||
| sig-rktnetes | ||
| sig-scalability | ||
| sig-scheduling | ||
| sig-service-catalog | ||
| sig-storage | ||
| sig-testing | ||
| sig-ui | ||
| sig-windows | ||
| wg-app-def | ||
| wg-cloud-provider | ||
| wg-cluster-api | ||
| wg-container-identity | ||
| wg-kubeadm-adoption | ||
| wg-multitenancy | ||
| wg-resource-management | ||
| .generated_files | ||
| .gitignore | ||
| .travis.yml | ||
| CLA.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| Makefile | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| code-of-conduct.md | ||
| communication.md | ||
| community-membership.md | ||
| governance.md | ||
| incubator.md | ||
| org-owners-guide.md | ||
| setting-up-cla-check.md | ||
| sig-creation-procedure.md | ||
| sig-governance.md | ||
| sig-list.md | ||
| sigs.yaml | ||
| sysadmin.md | ||
README.md
Kubernetes Community
Welcome to the Kubernetes community!
This is the starting point for becoming a contributor - improving docs, improving code, giving talks etc.
Communicating
The communication page lists communication channels like chat, issues, mailing lists, conferences, etc.
For more specific topics, try a SIG.
SIGs
Kubernetes is a set of projects, each shepherded by a special interest group (SIG).
A first step to contributing is to pick from the list of kubernetes SIGs.
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),
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.
How Can I Help?
Documentation (like the text you are reading now) can always use improvement!
There's a semi-curated list of issues that should not need deep knowledge of the system.
To dig deeper, read a design doc, e.g. architecture.
Pick a SIG, peruse its associated cmd directory,
find a main() and read code until you find something you want to fix.
There's always code that can be clarified and variables or functions that can be renamed or commented.
There's always a need for more test coverage.
Learn to Build
Links in contributors/devel/README.md lead to many relevant topics, including
- Developer's Guide - how to start a build/test cycle
- Collaboration Guide - how to work together
- expectations - what the community expects
- pull request policy - how to prepare a pull request
Your First Contribution
We recommend that you work on an existing issue before attempting to develop a new feature.
Start by finding an existing issue with the help wanted label; these issues we've deemed are well suited for new contributors. Alternatively, if there is a specific area you are interested in, ask a SIG lead for suggestions), and respond on the issue thread expressing interest in working on it.
This helps other people know that the issue is active, and hopefully prevents duplicated efforts.
Before submitting a pull request, sign the CLA.
If you want to work on a new idea of relatively small scope:
- Submit an issue describing your proposed change to the repo in question.
- The repo owners will respond to your issue promptly.
- If your proposed change is accepted, sign the CLA, and start work in your fork.
- Submit a pull request containing a tested change.