Joining in the beginning was onboarding on a yacht Now is more onboarding a BIG cruise ship.
Will be a Hard schedule, and let’s hope we can achieve everything Sig-contributor-experience -> from Non-member contributors to Owner
=> Find your first topics: bug, feature, learning, community development and documentation
Table exercise: Introduce yourself and give a tip on where you want to contribute in Kubernetes
Kubernetes community is like a Capybara: community members are really cool with everyone and they are from a lot of different horizons.
When in doubt, ask on Slack
Other communication channels:
on https://kubernetes.io/community, there is the schedule for all the SIG/Working group meeting. If you want to join or create a meetup. Go to slack#sig-contribex
Semi-autonomous teams: - Own leaders & charteers - Code, Github repo, Slack, mailing, meeting responsibility
From working group to “subproject”.
For specific: tools (ex. Helm), goals (ex. Resource Management) or areas (ex. Machine Learning).
Working groups change around more frequently than SIGs, and some might be temporary.
Everything will be refactored (cleaning, move, merged,…)
Mirror of core part for easy vendoring
Too much places for Random/Incubation stuff. No working path for promotion/deprecation
In future: 1. start in Kubernetes-sigs 2. SIGs determine when and how the project will be promoted/deprecated
Those repositories can have their own rules: - Approval - Ownership - …
- Bug or Feature - What happened - How to reproduce
### Issues as specifications
Most of k8s change start with an issue:
sig/\*: the sig the issue belong too
Free for dedicated issue area
Currently mostly complicated things
We will go through the typical PR process on kubernetes repos.
When we contribute to any kubernetes repository, fork it
Do your modification in your fork ``` $ git clone firstname.lastname@example.org:jgsqware/community.git $GOPATH/src/github.com/kubernetes/community $ git remote add upstream https://github.com/kubernetes/community.git $ git remote -v origin email@example.com:jgsqware/community.git (fetch) origin firstname.lastname@example.org:jgsqware/community.git (push) upstream email@example.com:kubernetes/community.git (fetch) upstream firstname.lastname@example.org:kubernetes/community.git (push) $ git checkout -b kubecon Switched to a new branch ‘kubecon’
$ git add contributors/new-contributor-playground/new-contibutor-playground-xyz.md $ git commit
Adding a new contributors file We are currently experimenting PR process in the kubernetes repository.
$ git push -u origin kubecon ```
/assign @reviewerrecommended by the
LTGMlabel from one of the
k8s-ci-robotwill automatically merge the PR
needs-ok-to-test is used for non-member contributor to validate the pull request
How bot toll you when you mess up
At the end of a PR there is a bunch of test. 2 types: - required: Always run and needed to pass to validate the PR (eg. end-to-end test) - not required: Needed in specific condition (eg. modifying on ly specific part of code)
If something failed, click on
details and check the test failure logs to see what happened.
junit-XX.log with the list of test executed and
e2e-xxxxx folder with all the component logs.
To check if the test failed because of your PR or another one, you can click on the TOP
pull-request-xxx link and you will see the test-grid and check if your failing test is failing in other PR too.
If you want to retrigger the test manually, you can comment the PR with
k8s-ci-robot will retrigger the tests.
Anyone can contribute to docs.
k8s-ci-robot. Approval process is the same as for any k8s repo.
master branch is the current version of the docs. So always branch from
master. It’s continuous deployment
For a specific release docs, branch from
The code: [kubernetes/kubernetes] The process: [kubernetes/community]
You need: - Go - Docker
./build/run.sh maketil it works
KUBE_*_PLATFORM="linux/amd64" make WHAT "kubectl"
build documentation there: https://git.k8s.io/kubernetes/build
test documentation there: https://git.k8s.io/community/contributor/guide