kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2119 from jgsqware/contributor-notes 

Add New contributor summit notes
This commit is contained in:
k8s-ci-robot 2018-05-02 03:06:18 -07:00 committed by GitHub
parent e3fcf0db13 f4f5a2e8d9
commit d2d0cd10e0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 350 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

350
contributors/new-contributor-playground/new-contributor-notes.md Normal file
View File

@ -0,0 +1,350 @@
# Kubernetes New Contributor Workshop - KubeCon EU 2018 - Notes
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
## SIG presentation
- SIG-docs & SIG-contributor-experience: **Docs and website** contribution
- SIG-testing: **Testing** contribution
- SIG-\* (*depends on the area to contribute on*): **Code** contribution
**=> 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
## Communication in the community
Kubernetes community is like a Capybara: community members are really cool with everyone and they are from a lot of different horizons.
- Tech question on Slack and Stack Overflow, not on Github
- A lot of discussion will be involve when GH issues and PR are opened. Don't be frustrated
- Stay patient because there is a lot of contribution
When in doubt, **ask on Slack**
Other communication channels:
- Community meetings
- Mailing lists
- @ on Github
- Office Hour
- Kubernetes meetups https://www.meetup.com/topics/kubernetes
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**
## SIG - Special Interest Group
Semi-autonomous teams:
- Own leaders & charteers
- Code, Github repo, Slack, mailing, meeting responsibility
### Types
[SIG List](https://github.com/kubernetes/community/blob/master/sig-list.md)
1. Features Area
- sig-auth
- sig-apps
- sig-autoscaling
- sig-big-data
- sig-cli
- sig-multicluster
- sig-network
- sig-node
- sig-scalability
- sig-scheduling
- sig-service-catalog
- sig-storage
- sig-ui
2. Plumbing
- sig-cluster-lifecycle
- sig-api-machinary
- sig-instrumentation
3. Cloud Providers *(currently working on moving cloudprovider code out of Core)*
- sig-aws
- sig-azure
- sig-gcp
- sig-ibmcloud
- sig-openstack
4. Meta
- sig-architecture: For all general architectural decision
- sig-contributor-experience: Helping contributor and community experience
- sig-product-management: Long-term decision
- sig-release
- sig-testing: In charge of all the test for Kubernetes
5. Docs
- sig-docs: for documentation and website
## Working groups and "Subproject"
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.
- wg-app-def
- wg-apply
- wg-cloud-provider
- wg-cluster-api
- wg-container-identity
- ...
### Picking the right SIG:
1. Figure out which area you would like to contribute to
2. Find out which SIG / WG / subproject covers that (tip: ask on #sig-contribex Slack channel)
3. Join that SIG / WG / subproject (you should also join the main SIG when joining a WG / subproject)
## Tour des repositories
Everything will be refactored (cleaning, move, merged,...)
### Core repository
- [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)
### Project
- [kubernetes/Community](https://github.com/kubernetes/Community): Kubecon, proposition, Code of conduct and Contribution guideline, SIG-list
- [kubernetes/Features](https://github.com/kubernetes/Features): Features proposal for future release
- [kubernetes/Steering](https://github.com/kubernetes/Steering)
- [kubernetes/Test-Infra](https://github.com/kubernetes/Test-Infra): All related to test except Perf
- [kubernetes/Perf-Tests](https://github.com/kubernetes/Perf-Tests):
### Docs/Website
- website
- kubernetes-cn
- kubernetes-ko
### Developer Tools
- sample-controller*
- sample- apiserver*
- code-generator*
- k8s.io
- kubernetes-template-project: For new github repo
### Staging repositories
Mirror of core part for easy vendoring
### SIG repositories
- release
- federation
- autoscaler
### Cloud Providers
No AWS
### Tools & Products
- kubeadm
- kubectl
- kops
- helm
- charts
- kompose
- ingress-nginx
- minikube
- dashboard
- heapster
- kubernetes-anywhere
- kube-openapi
### 2nd Namespace: Kubernetes-sigs
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
- ...
## Contribution
### First Bug report
```
- Bug or Feature
- What happened
- How to reproduce
```
### Issues as specifications
Most of k8s change start with an issue:
- Feature proposal
- API changes proposal
- Specification
### From Issue to Code/Docs
1. Start with an issue
2. Apply all appropriate labels
3. cc SIG leads and concerned devs
4. Raise the issue at a SIG meeting or on mailing list
5. If *Lazy consensus*, submit a PR
### Required labels https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md
#### On creation
- `sig/\*`: the sig the issue belong too
- `kind/\*`:
- bug
- feature
- documentation
- design
- failing-test
#### For issue closed as port of **triage**
- `triage/duplicate`
- `triage/needs-information`
- `triage/support`
- `triage/unreproduceable`
- `triage/unresolved`
#### Prority
- `priority/critical-urgent`
- `priority/important-soon`
- `priority/important-longtem`
- `priority/backlog`
- `priority/awaiting-evidence`
#### Area
Free for dedicated issue area
- `area/kubectl`
- `area/api`
- `area/dns`
- `area/platform/gcp`
#### help-wanted
Currently mostly complicated things
#### SOON
`good-first-issue`
## Making a contribution by Pull Request
We will go through the typical PR process on kubernetes repos.
We will play there: [community/contributors/new-contributor-playground at master · kubernetes/community · GitHub](https://github.com/kubernetes/community/tree/master/contributors/new-contributor-playground)
1. When we contribute to any kubernetes repository, **fork it**
2. Do your modification in your fork
```
$ git clone git@github.com:jgsqware/community.git $GOPATH/src/github.com/kubernetes/community
$ git remote add upstream https://github.com/kubernetes/community.git
$ git remote -v
origin git@github.com:jgsqware/community.git (fetch)
origin git@github.com:jgsqware/community.git (push)
upstream git@github.com:kubernetes/community.git (fetch)
upstream git@github.com:kubernetes/community.git (push)
$ git checkout -b kubecon
Switched to a new branch 'kubecon'
## DO YOUR MODIFCATION IN THE CODE##
$ git add contributors/new-contributor-playground/new-contibutor-playground-xyz.md
$ git commit
### IN YOUR COMMIT EDITOR ###
Adding a new contributors file
We are currently experimenting PR process in the kubernetes repository.
$ git push -u origin kubecon
```
3. Create a Pull request via Github
4. If needed, sign the CLA to make valid your contribution
5. Read the `k8s-ci-robot` message and `/assign @reviewer` recommended by the `k8s-ci-robot`
6. wait for a `LTGM` label from one of the `OWNER/reviewers`
7. wait for approval from one of `OWNER/approvers`
8. `k8s-ci-robot` will automatically merge the PR
`needs-ok-to-test` is used for non-member contributor to validate the pull request
## Test infrastructure
> 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.
There is `junit-XX.log` with the list of test excuted 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 `/retest` and `k8s-ci-robot` will retrigger the tests.
## SIG-Docs contribution
Anyone can contribute to docs.
### Kubernetes docs
- Websites URL
- Github Repository
- k8s slack: #sig-docs
### Working with docs
Docs use `k8s-ci-robot`. Approval process is the same as for any k8s repo
In docs, `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 `release-1.X`.
## Local build and Test
The code: [kubernetes/kubernetes]
The process: [kubernetes/community]
### Dev Env
You need:
- Go
- Docker
- Lot of RAM and CPU and 10 GB of space
- best to use Linux
- place you k8s repo fork in:
- `$GOPATH/src/k8s.io/kubernetes`
- `cd $GOPATH/src/k8s.io/kubernetes`
- build: `./build/run.sh make`
- Build is incremental, keep running `./build/run.sh make` til it works
- To build variant: `make WHAT="kubectl"`
- Building kubectl on Mac for linux: `KUBE_*_PLATFORM="linux/amd64" make WHAT "kubectl"`
there is `build` documentation there: https://git.k8s.io/kubernetes/build
### Testing
there is `test` documentation there: https://git.k8s.io/community/contributor/guide