Kubernetes New Contributor Workshop - KubeCon EU 2018

Special Interest Groups (SIGs)

Types of SIGs:

Master list can be found here

• Feature areas:

  A specific portion of K8s functionality. Ex. sig-auth, sig-apps, sig-big-data, sig-cli, sig-ui...

• Plumbing:

  In charge of aspects that cross all other SIGs. Ex. sig-cluster-lifecycle, sig-api-machinery, sig-instrumentation

• Cloud providers:

  One for each cloud provider that is supported. Ex. sig-aws, sig-gcp, sig-openstack, ...

• Meta:

  Aspects of running the k8s project. Ex. sig-architecture, sif-release, sig-product-management, ...

• Documentation & website: Contributing to other SIGs requires also contributing to documentation. sig-docs

Working Groups (WG) and Subprojects:

• Working groups => old way; Subprojects => new way

• For specific tools (ex. Helm), goals (ex. Resource Management) or areas (ex. Machine Learning).

• Examples: wg-app-def, wg-apply, wg-cluster-api, ...

• Groups change around more frequently than SIGs, some might be temporary.

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)

Repositories for k8s:

Disclaimer: Currently cleaning up / refactoring repos. This might change soon!

• Core repository (where the core code is).

  kubernetes/kubernetes (also known as: k/k)

• Project

  Repos for running and organising the project k/Community, k/Features, k/Steering, ...

  k/Community: has one folder for every SIG, and for most of WGs, CoC, ... k/Features: you file an issue when preparing a new feature k/Test-Infra and k/Perf-Tests: separate repos for performance tests and other tests

• Docs / Website

  k/website, k/kubernetes-docs-cn, k/kubernetes-docs-ko

• Developer Tools

  k/sample-controller, k/k8s.io, ...

• Staging Repos

  Mirror specific directories api, code-generator, client-go, metrics, ...

• SIG repos

  Some SIGs have their own dedicated repos release, federation, autoscaler

• Cloud Providers

  cloud-provider-azure, cloud-provider-gcp, ...

• Products & Tools

  kubeadm, kubectl, kops, helm, ...

Contributing

Bug Reports

Reporting bugs by filing a detailed bug report (including labels).

Issues as specifications

Issues are used as specs:

• Feature or API change proposals
• New tests
• Docs.

You start with creating a new issue, with all the relevant labels, and raise it on a SIG meeting or on the list, then when "lazy consensus" is achieved you submit a PR.

Required labels

List of labels can be found here

We use a prefix with a -:

• sig/label defines which SIG the issue belongs to
• kind/label defines what type the issue is (bug, feature, documentation, ...)
• triage/label for issues that need to be closed (duplicate, needs-information, support, unreproduceable, unresolved, ...)
• priority/label are assigned by SIG leads, signal how critical the issue is (critical-urgent, important-soon, backlog, ...)
• area/label is an optional label, there is no cannonical list (kubectl, api, dns, platform/gce, ...)
• help-wanted does not signal that this is a good first issue (dedicated label for this coming soon for "good first issue")