ProProgrammer · October 7, 2018 13:51
diff --git a/new-contributor-workshop-part1.txt b/new-contributor-workshop-part1.txt
 Watch - 2018 Kubernetes Contributor Summit EU New Contributor Workshop Part 1 - https://www.youtube.com/watch?v=obyAKf39H38
 	CLA Signing: https://git.k8s.io/community/CLA.md
 		Actual URL: https://github.com/kubernetes/community/blob/master/CLA.md

 	SIG == Special Interest Group
 		Project humans organized in SIGs

 	Docs and Website
 		Frontend development
 		SIGs:
 			SIG-docs
 			SIG-contributor-experience

 	Testing
 		test-infra repository
 		Most of the code written in Golang
 		SIGs:
 			SIG-testing

 	Code
 		kubernetes/kubernetes
 			Big repo - lots of open issues
 			Sub repos and related projects abound:
 				E.g. charts, minikube, kops
 			Command line: CLI

 			SIGs:
 				Depends on your area of interest

 	Finding your First Topic - aka - Welcome to open source:
 		Notice a bug
 		Would like a feature
 		Trying to learn a technology
 		Work involves developing community contributions
 		Want better documentation

 	Find your topic exercise
 		At your table, go around the table in a circle and explain (or speculate) on what part of Kubernetes you might want to contribute to

 		Also, explain what in your background, job, or interest motivates you

 		Self Exercise:
 			I have over 5 years of experience in Software Testing - Automation and Manual however I am really really interested in getting into software development.

 			I want to work on being able to identify reported bugs, reproduce them confidently, and then triage the issue in terms of what code is responsible for it.
 			Once triaged, start working on resolving the issue.

 			On side, I would like to contribute to documentation since I will be going through a lot of documentation myself to gain understanding.

 	Communication - Let's talk communication in the Kubernetes Community
 		Mutual respect is a prerequisite for healthy collaboration
 		https://git.k8s.io/community/code-of-conduct.md
 		Actual URL: https://github.com/kubernetes/community/blob/master/code-of-conduct.md

 		Unspoken rules that exist in any community:
 			Technical questions go to SO and Slack - NOT Github

 			Github issues / PRs often entail discussion related to the topic at hand. Stay courteous and follow up.

 			Stay patient as people may address your questions / contributions from all over the world.

 		When in doubt, ask:
 			slack.k8s.io
 			Good channels to start with:
 				#kubernetes-users
 				#kubernetes-novice
 				#sig-contribex

 				Definitely join #sig-contribex because It is literally the SIG's job to help you out if you are confused.

 				Every SIG has their own channel

 			Other avenues of communication:
 				Community Meetings
 				@pinging someone on GitHub
 					Some reviewers/contributors get a lot of noise - don't take it personally if they do not respond / react to your mention.
 				Meetups
 					If you want to start a meetup in your city/area - ask here for help:
 						Slack - #sig-contribex
 				Office Hours
 					K8s community Meetings - calendar URL:
 						https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles

 						Initially you won't understand anything - but give it time and slowly and gradually things will start making sense.

 				Twitter: twitter.com/kubernetesio

 				Google Groups - Mailing Lists
 					[email protected]
 						Thats for developers
 					[email protected]
 						For Users - lot of questions are answered here.

 	The SIG system - How work is organized
 	Youtube video: Starting 33:47
 		Special Interest Group (SIG)
 			Inspired by SIGs in IETF

 		Actively creating new SIGs and some SIGs are shutting down about once every kubernetes release cycle (roughly 3 months)

 		People working with Kubernetes end up being identified with particular SIG.
 			Even if you are involved in multiple SIGs, you end up spending most of your time in one SIG - simply because there's too much to do as a major contributor in more than a SIG unless YOU DON'T LIKE SLEEPING!

 		Semi-autonomous team
 			Own leaders & charter
 			Responsible for code
 			Own repo(s) (sometimes)
 			Slack channel & mailing list
 			Meetings (usually Zoom)
 			Subprojects (& WGs)

 		Types of SIGs
 			1. Feature Areas
 				These are fairly defined based on modules within Kubernetes that they are incharge of.
 				Some of these are a little bit deceptive.
 					Eg: sig-auth is not just responsible for authentication but for everything involving security
 					This is due to the way the project was structured originally
 					sig-network also has some security responsibilities for obvious reasons
 				sig-auth
 				sig-apps
 				sig-autoscaling
 				sig-big-data
 				sig-cli
 					kubectl and kubectl API
 				sig-multicluster
 				sig-network
 				sig-node
 				sig-scalability
 				sig-scheduling
 					Responsible for core kubernetes scheduler and the scheduling API
 					Some other things related to schedulding
 				sig-service-catalog
 				sig-ui
 					Care about dashboard and APIs that the dashboard consumes
 			2. Plumbing
 				These are SIGs that are incharge of kubernetes code that kind of cuts across all of the feature SIGs.
 				Particularly the three listed below:
 					sig-cluster-lifecycle
 						kube admin
 						everything to do with upgrade and downgrade
 							e.g.: File upgrade and downgrade related bugs.
 					sig-api-machinery
 						in charge of implementation of kubernetes API
 					sig-instrumentation
 			3. Cloud Providers
 				Every public cloud that has the official kubernetes support, they use these official cloud provider SIGs
 					sig-aws
 					sig-azure
 					sig-gcp
 					sig-ibmcloud
 					sig-openstack

 				These are super busy right now since we are in the process of taking the cloud provider code out of the core kubernetes code and getting it to use the new cloud provider API
 			4. Meta
 				Devoted to aspects of running the project
 					sig-architecture
 						How things within the kubernetes architecture interact with each other.
 						E.g. communication between scheduler and the controller
 					sig-contributor-experience
 					sig-product-management
 						Kubernetes long term management.
 					sig-release
 						Josh Berkus (speaker) is primarily a part of this sig
 							Lead for 1.11 release team
 					sig-testing
 						Incharge of everything related to testing for kubernetes

 				Good to get involved in if you are trying to get an idea of how the whole project works.

 			5. Docs
 				sig-docs
 					Numerically - this has the biggest number of contributors.
 				As a developer - you always end up being contributor to this SIG since all features need to have documentation up to date all the time.

 			For complete list - checkout master list of SIGs here: https://github.com/kubernetes/community/blob/master/sig-list.md

 			Every sig maintains a page on community repo (link above) - access it by clicking on sig name in the master list above.

 			Meeting recordings available on the SIG page for those contributing from opposite to popular time zones in which SIGs operate usually.

 			Every SIG needs to have a lead. Details of Leads on the SIG page.

 			A few SIGs have chairs who are responsible to ensure that they have meetings and all things are being taken care off and Technical Leads who are incharge of the actual code.
 				This is what the division between chairs and technical leads means.

 		WGs and Subprojects
 			Little bit of chaos simply because things are changing.

 			In addition to the SIGs we have WGs - moving from WGs as a concept to Subprojects as a concept.

 			Working Groups == Old Way
 			Subprojects == New Way

 			For specific:
 				Tools (e.g. helm)
 				Goals (e.g. Resource Management)
 				Areas (e.g. Machine Learning)

 			Current list of WGs - expected to change
 				wg-app-def
 				wg-apply
 				wg-cloud-provider
 				wg-cluster-api
 				wg-container-identity
 				wg-kubeadm-adoption
 				wg-machine-learning
 				wg-multitenancy
 				wg-policy
 				wg-resource-management
 				wg-cluster-ops

 			Unlike SIGs, WGs change rather more frequently
 				For e.g: WGs that are goal oriented achieve their goal (e.g. - a WG that was responsible to develop 6 features is done developing the final (6th) feature) then the WG dissolves.

 		Picking the right SIG
 			This is one of the most difficult things to get started in kubernetes

 			Often a trial/error process.

 			1. Figure out what specific projects/areas you want to work on
 			2. Find out which SIG/WG/subproject covers that
 				a. Ask on #sig-contribex
 				b. Go to SIG intros at the conference
 			3. Join that SIG/subproject
 				a. If joining a WG/subproject, also join a SIG

 	Repositories are being refactored
 		Core Repository
 			kubernetes/kubernetes
 				aka k/k
 			Roughly 2 million lines of code
 			May get broken into multiple repositories

 		Project
 			k/Community
 				Community Events
 				Specification Proposals
 				Has folder for everyone of the sigs
 				Information about how whole project runs
 			k/Features
 				Serves special propose
 				If you are proposing a feature - you file it against the Features repository

 			k/Steering
 				Steering committee
 			k/Test-Infra
 				Most of the code for our automated testing lives.
 				Except that the performance tests have their own repo
 			k/Perf-Tests
 				Performance tests - separate repo since they run different than rest of the tests (in test-infra)

 		Docs/Website
 			k/website
 				Primary one - called website despite the fact that it actually contains documentation.
 			k/kubernetes-docs-cn
 				Translating the documentation in chinese
 				Josh - not quite sure why there's a separate repository
 			k/kubernetes-docs-ko
 				Similarly for Korean as in case of Chinese 

 		Developer Tools
 			These are repositories devoted to developer tools.
 			k/sample-controller*
 			k/sample-apiserver*
 			k/code-generator*
 			k/k8s-io
 				Sites that supply developer information
 				E.g.: Testing dashboards, current issue dashboards, etc.
 			k/kubernetes-template-object
 				Template project for what a new repository should look like should you in case need to create a new repository in the first place for whatever it is you are working on.

 		Staging Repos
 			Because the main kubernetes/kubernetes is a gigantic monolithic repository, we have a bunch of mirror repositories called staging repositories that mirror specific subdirectories that are kind of detachable components.
 			They are complete mirrors
 				Same PRs get applied to both
 			They exist for building test of those components - because you are hacking only those things.
 			And particularly because there are a number of vendors who fork these things.
 			api
 			apiextensions-apiserver
 			apimachinery
 			apiserver
 			client-go
 			code-generator
 			kube-aggregator
 			metrics
 			sample-apiserver

 		SIG repos
 			A few of the SIGs have their own separate repository for a thing

 			release
 				Release team has their own repository for all release related stuff
 			federation
 				multi-cluster has a repository called federation because that was the original name for multi-cluster
 			autoscaler
 				Autoscaler has their own repository

 			Why only three of them have their own repos?

 		Cloud Providers
 			Some of the cloud providers have their own repos

 			cloud-provider-azure
 			cloud-provider-gcp
 			cloud-provider-openstack

 			Where's AWS?

 		Product & Tools
 			- WHole set of tools - specific that are not core kubernetes components - some are core k8s components, some are not
 			- But things you build against/with k8s that are sort of separate executables

 			kubeadm
 			kubectl
 			kops
 			helm
 			charts
 			kompose
 			ingress-nginx
 			minikube
 			dashboard
 			heapster
 			kubernetes-anywhere
 			kube-openapi

 		A namepsace called kube-incubator
 			- Thera are 22 projects on it
 			- Do not assume that any of these are maintained code because most of them aren't

 			A Historical Accumulation:
 				- Random stuff in kubernetes/
 				- Random stuff in kube-incubator/
 				- Random stuff in kubernetes/contrib/

 				and no clear path for promotion/deprecation

 			Historically, kube-incubator for a place for projects that might not go anywhere.
 				But the problem with kube-incubator is - no written procedures about how something got into incubator and importantly - no written procedure about how anything got out of kube-incubator.

 				Same thing for this accumulation place called kubernetes/contrib

 		How it will be:
 			1. All accessory projects start in kubernetes-sigs/ namespace
 				And each under kubernetes-sigs/ are repos which belong to specific sigs
 					E.g.: belonging to sig-aws - there are couple of repos which have specific AWS code.
 			2. SIGs determine when/how they graduate to kubernetes/ or k/k.
 				The advantage of this approach is that someone is clearly responsible for what happens to that repository.

 		My repository, my rules
 			Repos can have different:
 				Ownership
 				Approval Workflows
 				Merge Workflows
 				Release cycles

 		Membership / Ownership
 			Moving to but not yet completed:
 				Within directories there's a file called OWNERS
 				That files defines who owns any code document, etc in that directory or sub-directory

 				OWNERS files govern who approves code
 					Approval is then controlled by GitHub bots

 					They're recursive to parent directories
 					... but some repos still use GitHub groups
 					... and some OWNERS files refer to groups
	Watch - 2018 Kubernetes Contributor Summit EU New Contributor Workshop Part 1 - https://www.youtube.com/watch?v=obyAKf39H38
	CLA Signing: https://git.k8s.io/community/CLA.md
	Actual URL: https://github.com/kubernetes/community/blob/master/CLA.md

	SIG == Special Interest Group
	Project humans organized in SIGs

	Docs and Website
	Frontend development
	SIGs:
	SIG-docs
	SIG-contributor-experience

	Testing
	test-infra repository
	Most of the code written in Golang
	SIGs:
	SIG-testing

	Code
	kubernetes/kubernetes
	Big repo - lots of open issues
	Sub repos and related projects abound:
	E.g. charts, minikube, kops
	Command line: CLI

	SIGs:
	Depends on your area of interest

	Finding your First Topic - aka - Welcome to open source:
	Notice a bug
	Would like a feature
	Trying to learn a technology
	Work involves developing community contributions
	Want better documentation

	Find your topic exercise
	At your table, go around the table in a circle and explain (or speculate) on what part of Kubernetes you might want to contribute to

	Also, explain what in your background, job, or interest motivates you

	Self Exercise:
	I have over 5 years of experience in Software Testing - Automation and Manual however I am really really interested in getting into software development.

	I want to work on being able to identify reported bugs, reproduce them confidently, and then triage the issue in terms of what code is responsible for it.
	Once triaged, start working on resolving the issue.

	On side, I would like to contribute to documentation since I will be going through a lot of documentation myself to gain understanding.

	Communication - Let's talk communication in the Kubernetes Community
	Mutual respect is a prerequisite for healthy collaboration
	https://git.k8s.io/community/code-of-conduct.md
	Actual URL: https://github.com/kubernetes/community/blob/master/code-of-conduct.md

	Unspoken rules that exist in any community:
	Technical questions go to SO and Slack - NOT Github

	Github issues / PRs often entail discussion related to the topic at hand. Stay courteous and follow up.

	Stay patient as people may address your questions / contributions from all over the world.

	When in doubt, ask:
	slack.k8s.io
	Good channels to start with:
	#kubernetes-users
	#kubernetes-novice
	#sig-contribex

	Definitely join #sig-contribex because It is literally the SIG's job to help you out if you are confused.

	Every SIG has their own channel

	Other avenues of communication:
	Community Meetings
	@pinging someone on GitHub
	Some reviewers/contributors get a lot of noise - don't take it personally if they do not respond / react to your mention.
	Meetups
	If you want to start a meetup in your city/area - ask here for help:
	Slack - #sig-contribex
	Office Hours
	K8s community Meetings - calendar URL:
	https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles

	Initially you won't understand anything - but give it time and slowly and gradually things will start making sense.

	Twitter: twitter.com/kubernetesio

	Google Groups - Mailing Lists
	[email protected]
	Thats for developers
	[email protected]
	For Users - lot of questions are answered here.

	The SIG system - How work is organized
	Youtube video: Starting 33:47
	Special Interest Group (SIG)
	Inspired by SIGs in IETF

	Actively creating new SIGs and some SIGs are shutting down about once every kubernetes release cycle (roughly 3 months)

	People working with Kubernetes end up being identified with particular SIG.
	Even if you are involved in multiple SIGs, you end up spending most of your time in one SIG - simply because there's too much to do as a major contributor in more than a SIG unless YOU DON'T LIKE SLEEPING!

	Semi-autonomous team
	Own leaders & charter
	Responsible for code
	Own repo(s) (sometimes)
	Slack channel & mailing list
	Meetings (usually Zoom)
	Subprojects (& WGs)

	Types of SIGs
	1. Feature Areas
	These are fairly defined based on modules within Kubernetes that they are incharge of.
	Some of these are a little bit deceptive.
	Eg: sig-auth is not just responsible for authentication but for everything involving security
	This is due to the way the project was structured originally
	sig-network also has some security responsibilities for obvious reasons
	sig-auth
	sig-apps
	sig-autoscaling
	sig-big-data
	sig-cli
	kubectl and kubectl API
	sig-multicluster
	sig-network
	sig-node
	sig-scalability
	sig-scheduling
	Responsible for core kubernetes scheduler and the scheduling API
	Some other things related to schedulding
	sig-service-catalog
	sig-ui
	Care about dashboard and APIs that the dashboard consumes
	2. Plumbing
	These are SIGs that are incharge of kubernetes code that kind of cuts across all of the feature SIGs.
	Particularly the three listed below:
	sig-cluster-lifecycle
	kube admin
	everything to do with upgrade and downgrade
	e.g.: File upgrade and downgrade related bugs.
	sig-api-machinery
	in charge of implementation of kubernetes API
	sig-instrumentation
	3. Cloud Providers
	Every public cloud that has the official kubernetes support, they use these official cloud provider SIGs
	sig-aws
	sig-azure
	sig-gcp
	sig-ibmcloud
	sig-openstack

	These are super busy right now since we are in the process of taking the cloud provider code out of the core kubernetes code and getting it to use the new cloud provider API
	4. Meta
	Devoted to aspects of running the project
	sig-architecture
	How things within the kubernetes architecture interact with each other.
	E.g. communication between scheduler and the controller
	sig-contributor-experience
	sig-product-management
	Kubernetes long term management.
	sig-release
	Josh Berkus (speaker) is primarily a part of this sig
	Lead for 1.11 release team
	sig-testing
	Incharge of everything related to testing for kubernetes

	Good to get involved in if you are trying to get an idea of how the whole project works.

	5. Docs
	sig-docs
	Numerically - this has the biggest number of contributors.
	As a developer - you always end up being contributor to this SIG since all features need to have documentation up to date all the time.

	For complete list - checkout master list of SIGs here: https://github.com/kubernetes/community/blob/master/sig-list.md

	Every sig maintains a page on community repo (link above) - access it by clicking on sig name in the master list above.

	Meeting recordings available on the SIG page for those contributing from opposite to popular time zones in which SIGs operate usually.

	Every SIG needs to have a lead. Details of Leads on the SIG page.

	A few SIGs have chairs who are responsible to ensure that they have meetings and all things are being taken care off and Technical Leads who are incharge of the actual code.
	This is what the division between chairs and technical leads means.

	WGs and Subprojects
	Little bit of chaos simply because things are changing.

	In addition to the SIGs we have WGs - moving from WGs as a concept to Subprojects as a concept.

	Working Groups == Old Way
	Subprojects == New Way

	For specific:
	Tools (e.g. helm)
	Goals (e.g. Resource Management)
	Areas (e.g. Machine Learning)

	Current list of WGs - expected to change
	wg-app-def
	wg-apply
	wg-cloud-provider
	wg-cluster-api
	wg-container-identity
	wg-kubeadm-adoption
	wg-machine-learning
	wg-multitenancy
	wg-policy
	wg-resource-management
	wg-cluster-ops

	Unlike SIGs, WGs change rather more frequently
	For e.g: WGs that are goal oriented achieve their goal (e.g. - a WG that was responsible to develop 6 features is done developing the final (6th) feature) then the WG dissolves.

	Picking the right SIG
	This is one of the most difficult things to get started in kubernetes

	Often a trial/error process.

	1. Figure out what specific projects/areas you want to work on
	2. Find out which SIG/WG/subproject covers that
	a. Ask on #sig-contribex
	b. Go to SIG intros at the conference
	3. Join that SIG/subproject
	a. If joining a WG/subproject, also join a SIG

	Repositories are being refactored
	Core Repository
	kubernetes/kubernetes
	aka k/k
	Roughly 2 million lines of code
	May get broken into multiple repositories

	Project
	k/Community
	Community Events
	Specification Proposals
	Has folder for everyone of the sigs
	Information about how whole project runs
	k/Features
	Serves special propose
	If you are proposing a feature - you file it against the Features repository

	k/Steering
	Steering committee
	k/Test-Infra
	Most of the code for our automated testing lives.
	Except that the performance tests have their own repo
	k/Perf-Tests
	Performance tests - separate repo since they run different than rest of the tests (in test-infra)

	Docs/Website
	k/website
	Primary one - called website despite the fact that it actually contains documentation.
	k/kubernetes-docs-cn
	Translating the documentation in chinese
	Josh - not quite sure why there's a separate repository
	k/kubernetes-docs-ko
	Similarly for Korean as in case of Chinese

	Developer Tools
	These are repositories devoted to developer tools.
	k/sample-controller*
	k/sample-apiserver*
	k/code-generator*
	k/k8s-io
	Sites that supply developer information
	E.g.: Testing dashboards, current issue dashboards, etc.
	k/kubernetes-template-object
	Template project for what a new repository should look like should you in case need to create a new repository in the first place for whatever it is you are working on.

	Staging Repos
	Because the main kubernetes/kubernetes is a gigantic monolithic repository, we have a bunch of mirror repositories called staging repositories that mirror specific subdirectories that are kind of detachable components.
	They are complete mirrors
	Same PRs get applied to both
	They exist for building test of those components - because you are hacking only those things.
	And particularly because there are a number of vendors who fork these things.
	api
	apiextensions-apiserver
	apimachinery
	apiserver
	client-go
	code-generator
	kube-aggregator
	metrics
	sample-apiserver

	SIG repos
	A few of the SIGs have their own separate repository for a thing

	release
	Release team has their own repository for all release related stuff
	federation
	multi-cluster has a repository called federation because that was the original name for multi-cluster
	autoscaler
	Autoscaler has their own repository

	Why only three of them have their own repos?

	Cloud Providers
	Some of the cloud providers have their own repos

	cloud-provider-azure
	cloud-provider-gcp
	cloud-provider-openstack

	Where's AWS?

	Product & Tools
	- WHole set of tools - specific that are not core kubernetes components - some are core k8s components, some are not
	- But things you build against/with k8s that are sort of separate executables

	kubeadm
	kubectl
	kops
	helm
	charts
	kompose
	ingress-nginx
	minikube
	dashboard
	heapster
	kubernetes-anywhere
	kube-openapi

	A namepsace called kube-incubator
	- Thera are 22 projects on it
	- Do not assume that any of these are maintained code because most of them aren't

	A Historical Accumulation:
	- Random stuff in kubernetes/
	- Random stuff in kube-incubator/
	- Random stuff in kubernetes/contrib/

	and no clear path for promotion/deprecation

	Historically, kube-incubator for a place for projects that might not go anywhere.
	But the problem with kube-incubator is - no written procedures about how something got into incubator and importantly - no written procedure about how anything got out of kube-incubator.

	Same thing for this accumulation place called kubernetes/contrib

	How it will be:
	1. All accessory projects start in kubernetes-sigs/ namespace
	And each under kubernetes-sigs/ are repos which belong to specific sigs
	E.g.: belonging to sig-aws - there are couple of repos which have specific AWS code.
	2. SIGs determine when/how they graduate to kubernetes/ or k/k.
	The advantage of this approach is that someone is clearly responsible for what happens to that repository.

	My repository, my rules
	Repos can have different:
	Ownership
	Approval Workflows
	Merge Workflows
	Release cycles

	Membership / Ownership
	Moving to but not yet completed:
	Within directories there's a file called OWNERS
	That files defines who owns any code document, etc in that directory or sub-directory

	OWNERS files govern who approves code
	Approval is then controlled by GitHub bots

	They're recursive to parent directories
	... but some repos still use GitHub groups
	... and some OWNERS files refer to groups