Notes from 2018 Kubernetes Contributor Summit EU New Contributor Workshop Part 1 - https://www.youtube.com/watch?v=obyAKf39H38

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
					kubernetes-dev@googlegroups.com
						Thats for developers
					kubernetes-users@googlegroups.com
						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