From Automation to Community:
A Deep Dive Into SIG Contributor Experience
Priyanka Saggu, SUSE
Madhav Jivrajani, VMware
Kaslin Fields, Google
Code of Conduct
Remember the Golden Rule: Treat others as you would want to be treated - with kindness and respect
Scan the QR code to access and
review the CNCF Code of Conduct:
Virtual Audience Closed Captioning
Closed captioning for the virtual audience is available during each session through Wordly. The Wordly functionality can be found under the “Translations” tab on the session page.
Wordly will default to English. If another language is needed, simply click the dropdown at the bottom of the “Translations” tab and choose from one of 26+ languages available so you don’t miss a beat from our presenters.
*Note: Closed captioning is ONLY available during the scheduled live sessions and will not be available for the recordings on-demand within the virtual conference platform.
Who Are We?
Madhav Jivrajani
@MadhavJivrajani
Kaslin Fields
@kaslinfields
Priyanka Saggu
@_psaggu
Before We Start…
�registry.k8s.io is GA!🎉
🚨❄️k8s.gcr.io is frozen❄️🚨
More info on
https://k8s.io/image-registry-redirect
How Does ContribEx… ContribEx?
How Does ContribEx… ContribEx?
Subprojects!
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Subprojects Overview
Mentoring Prereq - The Ladder
Subproject Owner
- Set priorities and approve proposals for subproject
- Responsibility and leadership for entire repository/directory
Approver
- Approve contributions for acceptance
- Highly experienced reviewer and contributor in subproject
Reviewer
- History of reviewing; reviews frequently
- Authorship in subproject
Member
- Active contributor to the project
- Sponsored by two Reviewers
Non-member Contributors
Mentoring
Mentoring
GitHub Management: Update
Changes In Lifecycle and Triage Flow of Issues
GitHub Management: Update
Previous Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
GitHub Management: Update
Previous Issue Triage and Lifecycle Flow
Issue
needs-triage
/triage accepted
triage/accepted
90 days
of inactivity
lifecycle/stale
30 more days
of inactivity
lifecycle/rotten
30 more days
of inactivity
/close not-planned
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
priority/important-longterm
Assuming issue has
triage/accepted
with
/remove-triage accepted
After 1 year of inactivity
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
Assuming issue has
triage/accepted
priority/important-soon
with
/remove-triage accepted
priority/important-longterm
with
/remove-triage accepted
After 90 days of inactivity
After 1 year of inactivity
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
Assuming issue has
triage/accepted
priority/critical-urgent
with
/remove-triage accepted
priority/important-soon
with
/remove-triage accepted
priority/important-longterm
with
/remove-triage accepted
After 30 days of inactivity
After 90 days of inactivity
After 1 year of inactivity
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
Assuming issue has
triage/accepted
priority/critical-urgent
with
After 30 days of inactivity
/remove-triage accepted
priority/important-soon
with
After 90 days of inactivity
/remove-triage accepted
priority/important-longterm
with
After 1 year of inactivity
/remove-triage accepted
priority/backlog
with
After 1 year of inactivity
/remove-triage accepted
GitHub Management: Update
New Issue Triage and Lifecycle Flow
needs-triage
/triage accepted
triage/accepted
Assuming issue has
triage/accepted
Don’t mark as stale/rotten
Hence, avoid auto-close.
Assuming issue has NO
triage/accepted
Previous lifecycle kicks in
Assuming issue has
triage/accepted
priority/critical-urgent
with
After 30 days of inactivity
/remove-triage accepted
priority/important-soon
with
After 90 days of inactivity
/remove-triage accepted
priority/important-longterm
with
After 1 year of inactivity
/remove-triage accepted
priority/backlog
with
After 1 year of inactivity
/remove-triage accepted
No auto-close
No auto-close
No auto-close
Auto-close
GitHub Management: Update
New Issue Triage and Lifecycle Flow
Note: Additionally, if issues have good first issue and/or help wanted labels, we exclude them from the entire lifecycle process.
GitHub Management: Update
Thank you @tallclair and @BenTheElder for these changes! ✨
Deep Dive: Annual Reports
What Are Annual Reports?
Deep Dive: Annual Reports
Why Are Annual Reports Important?
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
go run ./generator/app.go
...
Generating annual reports
Generating generator/generated/2022_sig-docs.md
...
Generating sig-api-machinery/annual-report-2022.md
...
Generating generator/generated/2022_sig-instrumentation.md
...�Generating wg-api-expression/annual-report-2022.md
...�Finished generation!
❯ make ANNUAL_REPORT=true
Generated Annual Report templates for SIG(s) and WG(s)
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
go run ./generator/app.go
...
Generating annual reports
Generating generator/generated/2022_sig-docs.md
...
Generating sig-api-machinery/annual-report-2022.md
...
Generating generator/generated/2022_sig-instrumentation.md
...�Generating wg-api-expression/annual-report-2022.md
...�Finished generation!
❯ make ANNUAL_REPORT=true
Generated GitHub Issue Templates for SIG(s) and WG(s)
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
❯ for i in $(ls -1 generator/generated/*.md); do hub issue create -F $i && rm $i; done
Deep Dive: Annual Reports
Current Process for Generating Annual Reports
❯ for i in $(ls -1 generator/generated/*.md); do hub issue create -F $i && rm $i; done
Deep Dive: Annual Reports
Sprinkling Some Automation On Annual Reports
Auto generating list of KEPs worked on by SIG(s) or WG(s) during the Annual Report year
Deep Dive: Annual Reports
Sprinkling Some Automation On Annual Reports
Auto generating list of KEPs worked on by SIG(s) or WG(s) during the Annual Report year
Deep Dive: Annual Reports
Sprinkling Some Automation On Annual Reports
Auto-generating new, retired & continuing subprojects & working groups during the Annual Report year
Deep Dive: Annual Reports
Sprinkling Some Automation On Annual Reports
Auto-generating new, retired & continuing subprojects & working groups during the Annual Report year
Deep Dive: Granular Approval
What is “Approval” and how does it work currently?
An OWNERS file:
reviewers:
approvers:
Deep Dive: Granular Approval
Current Approval Process
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
Deep Dive: Granular Approval
Current Approval Process
pkg
├── api
│ ├── first.go
│ └── first_test.go
└── registry
├── apps
│ ├── one.go
│ └── one_test.go
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
Deep Dive: Granular Approval
Current Approval Process
pkg
├── api
│ ├── first.go
│ └── first_test.go
└── registry
├── apps
│ ├── one.go
│ └── one_test.go
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
x comments: /approve
Deep Dive: Granular Approval
Current Approval Process
pkg
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry
├── apps
│ ├── one.go
│ └── one_test.go
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
x comments: /approve
Deep Dive: Granular Approval
Current Approval Process
pkg ✓
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry ✓
├── apps
│ ├── one.go ✓
│ └── one_test.go ✓
└── first.go ✓
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve
Deep Dive: Granular Approval
Current Approval Process: The Problem
pkg ✓
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry ✓
├── apps
│ ├── one.go ✓
│ └── one_test.go ✓
└── first.go ✓
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve
b only has expertise on testing, remaining expertise lies with c, a.
Deep Dive: Granular Approval
Current Approval Process: The Problem
The problem becomes more elaborate when changes like dependency bumps are made to Kubernetes
Deep Dive: Granular Approval
Granular Approval
This work allows approvers to approve files granularly:
This helps distribute approval privileges among approvers and approvers no longer have to (unavoidably) approve files they do not have confidence over.
Deep Dive: Granular Approval
Granular Approval Process
pkg
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry
├── apps
│ ├── one.go
│ └── one_test.go
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve *_test.go
Deep Dive: Granular Approval
Granular Approval Process
pkg
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry
├── apps
│ ├── one.go
│ └── one_test.go ✓
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve *_test.go
Deep Dive: Granular Approval
Granular Approval Process
pkg
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry
├── apps ✓
│ ├── one.go ✓
│ └── one_test.go ✓
└── first.go
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve *_test.go
c comments: /approve pkg/registry/apps/*
Deep Dive: Granular Approval
Granular Approval Process
pkg ✓
├── api ✓
│ ├── first.go ✓
│ └── first_test.go ✓
└── registry ✓
├── apps ✓
│ ├── one.go ✓
│ └── one_test.go ✓
└── first.go ✓
pkg/
├── api/
│ ├── OWNERS
└── registry/
├── OWNERS
├── apps/
pkg/api/OWNERS = x, y, z (approvers)
pkg/registry/OWNERS = a, b, c (approvers)
b comments: /approve *_test.go
c comments: /approve pkg/registry/apps/*
a comments: /approve
Deep Dive: Peribolos Team Management
What is “Peribolos”?
Kubernetes Reconciliation Loop
Declared State
Observed State
Observe State
Take actions
Deep Dive: Peribolos Team Management
What is “Peribolos”?
Org Reconciliation Loop
Declared Members
Observed Members
List Members
Invite, Promote, Remove Members
Deep Dive: Peribolos Team Management
What is “Peribolos”?
Org Reconciliation Loop
Declared Members
Observed Members
List Members
Invite, Promote, Remove Members
Repeat for metadata, teams, et. al.
Deep Dive: Peribolos Team Management
How Does Peribolos Work?
Deep Dive: Peribolos Team Management
orgs:
this-org:
company: foo
email: foo
name: foo
description: foo
has_organization_projects: true
has_repository_projects: true
default_repository_permission: read
members_can_create_repositories: false
members:
- anne
- bob
admins:
- carl
Top Level Key
Name of GitHub Organisation (“kubernetes”, “kubernetes-sigs”, etc)
Org Settings
Org Member Settings
How Does Peribolos Work?
Deep Dive: Peribolos Team Management
orgs:
this-org:
...
teams:
team-one:
description: people working on team-one
privacy: closed
previously:
- old-team-one
members:
- anne
maintainers:
- jane
repos:
some-repo: admin
other-repo: read
team-two:
...
that-org:
...
Teams Settings
Team Config
Team Members
Ensure Team has Listed Permissions Levels on Repos in Org
How Does Peribolos Work?
❯ go run ./prow/cmd/peribolos --dump kubernetes-sigs \
--github-token-path ~/github-token > org-config.yaml
Deep Dive: Peribolos Team Management
How Does Peribolos Work?
❯ go run ./prow/cmd/peribolos --dump kubernetes-sigs \
--github-token-path ~/github-token > org-config.yaml
Deep Dive: Peribolos Team Management
How Does Peribolos Work?
( use `org-config.yaml` for dry-run first! )
❯ go run ./prow/cmd/peribolos --config-path org.yaml \
--github-token-path ~/github-token # --confirm
Deep Dive: Peribolos Team Management
The Present State!
Deep Dive: Peribolos Team Management
The Present State!
Deep Dive: Peribolos Team Management
The Present State!
Deep Dive: Peribolos Team Management
(WIP) Solution!
Deep Dive: Peribolos Team Management
(WIP) Solution!
Deep Dive: Peribolos Team Management
(WIP) Solution!
Deep Dive: Peribolos Team Management
(WIP) Solution!
# restrictions.yaml
restrictions:
...
...
- path: "kubernetes/sigs-docs/teams.yaml"
allowedRepos:
- "^website"
...
...
- path: "kubernetes/sig-testing/teams.yaml"
allowedRepos:
- "^test-infra"
- "^publishing-bot"
...
...
# kubernetes/sig-docs/teams.yaml
teams:
...
website-admins:
description: Admin access to the website repo
previously:
- kubernetes-website-admins
members:
- divya-mohan0209
- jimangel
- natalisucks
- reylejano
privacy: closed
repos:
website: admin
test-infra: admin
Deep Dive: Peribolos Team Management
(WIP) Solution!
# restrictions.yaml
restrictions:
...
...
- path: "kubernetes/sigs-docs/teams.yaml"
allowedRepos:
- "^website"
...
...
- path: "kubernetes/sig-testing/teams.yaml"
allowedRepos:
- "^test-infra"
- "^publishing-bot"
...
...
# kubernetes/sig-docs/teams.yaml
teams:
...
website-admins:
description: Admin access to the website repo
previously:
- kubernetes-website-admins
members:
- divya-mohan0209
- jimangel
- natalisucks
- reylejano
privacy: closed
repos:
website: admin ✓
test-infra: admin ✗
❯ make verify
INFO[0000] Validating restrictions for kubernetes org
"kubernetes/sig-docs/teams.yaml": cannot define repo "test-infra" for team "website-admins"
FATA[0000] restriction violation(s) detected.
exit status 1
⚠️
Deep Dive: Peribolos Team Management
(WIP) Solution!
# restrictions.yaml
restrictions:
...
...
- path: "kubernetes/sigs-docs/teams.yaml"
allowedRepos:
- "^website"
...
...
- path: "kubernetes/sig-testing/teams.yaml"
allowedRepos:
- "^test-infra"
- "^publishing-bot"
...
...
# kubernetes/sig-docs/teams.yaml
teams:
...
website-admins:
description: Admin access to the website repo
previously:
- kubernetes-website-admins
members:
- divya-mohan0209
- jimangel
- natalisucks
- reylejano
privacy: closed
repos:
website: admin ✓
❯ make verify
INFO[0000] Validating restrictions for kubernetes org
SUCCESS verify-restrictions.sh 0s
✅
Get Involved!
Tips on your first SIG Meeting
There are non-code related paths available
If you’re interested in having a non-code contributions meeting on a recurring meeting, please reach out on the #sig-contribex slack channel!
What are the most important areas that you can�help with?
Where to find us
Session Q+A
Thank you!