►
Description
Speaker: Josh Berkus
A
So
you've
heard
Gwen
and
Noah
up
here,
use
the
word
cig,
like
probably
30
or
40
times
by
now,
and
for
those
of
you
who
haven't
done
anything
in
the
kubernetes
community
before
you're
like
well,
what's
a
cig,
and
this
actually
turns
out
to
be
really
important
when
you're
getting
involved
with
kubernetes
as
a
contributor.
Now
the
term
cig
is
an
acronym
which
stands
for
special
interest
group.
A
This
isn't
necessarily
what
it
sounds
like
it's
a
cryptic
acronym
and
it's
not
important
to
analyze
it
but
more
how
we
use
it.
Now
we
got
the
term
cig
from
the
IETF
and
USENIX
and
some
other
older,
open
source
and
Technology
things,
and
we
hear
a
special
interest
group.
It
sounds
kind
of
like
it's
like
a
meetup
which
it
isn't
but
then
again
it
kind
of
is
so.
The
thing
is
in
the
kubernetes
project.
A
We
have
something
in
the
realm
of
2,000
active
contributors,
so
we
can't
all
attend
one
big
meeting,
I
think
that's
well
outside
of,
for
example,
what
zoom
will
support
and
not?
Everybody
is
interested
in
Cubana
in
all
the
different
parts
of
kubernetes,
which
is
a
very
large
platform,
and
so
we
actually
divide
up
all
of
the
different
all
of
the
work
that
has
to
be
done
for
kubernetes
contribution,
that
sort
of
thing
into
several
dozen
different
areas
and
those
become
the
SIG's
and
work
groups
and
sub
projects,
but
we'll
get
into
those
in
a
minute.
A
Now
the
SIG's
themselves
are
our
main
sort
of
organizing
concept
for
kubernetes
as
Ian.
They
have
a
lot
of
autonomy,
and
this
is
our
sort
of
structure
of
authority
for
kubernetes.
That
is,
if
we
have
a
patch
for
doing
some
new
kubernetes
networking,
then
the
decision
on
whether
or
not
that
goes
in
is
up
to
say.
Networking
and
nobody.
A
So,
for
that
reason,
when
you
get
started
contributing
picking
an
initial
sig
that
aligns
with
your
interests
is
actually
fairly
important
and
so
I'm
going
to
actually
go
over
in
general,
some
of
the
SIG's
there
are
later
on
at
3
o'clock,
we're
going
to
have
a
meet
the
sig
session,
so
you
can
actually
learn
about
some
of
the
SIG's
in
more
detail,
so
I'm
going
to
actually
divide
them
up
into
sort
of
five
unofficial
groups.
You
won't
find
these
groups
referenced
anywhere
outside
this
presentation.
A
So
the
first
thing
and
the
sort
of
obvious
sig
grouping
is
what
we
call
feature
areas,
and
so
these
feature
areas
are
have
a
lot
to
do.
These
feature
areas
have
to
do
with
different
technical
parts
of
kubernetes,
for
example,
I've
seen
here
in
this
room.
We
have
somebody
from
upbound
and
another
person
who
works
in
open
EBS,
and
so
those
two
people
are
really
gonna.
A
So
the
kubernetes
community,
repo,
which
I'll
talk
about
a
little
bit
more
in
a
minute,
but
this
is
actually
a
good
guide
to
saying.
There's
a
lot
of
detailed
information
about
SIG's
here,
there's
also
an
easy
to
reference
list
in
github
format,
so
you
can
actually
kind
of
follow
along
in
more
detail
with
what
I'm
doing
here.
This
has
all
the
different
SIG's,
the
general
name
who
the
leads
are
and
where
their
meeting
is
and
what
their
contact
information
is.
A
A
So,
anyway,
furious
eggs
are
obvious
if
you're
planning
on
hacking
on
kubernetes
code
or
on
kubernetes
plug-in
code
you're
going
to
be
joining
one
of
these
things.
However,
we
have
a
lot
of
things
that
do
other
things,
because
kubernetes
is
a
big
project
and
it
needs
a
lot
more
than
just
people
hacking
on
shippable
code,
for
example.
A
All
these
different
features
actually
need
to
be
glued
together
and
they
need
to
actually
work
together
and
users
need
to
be
able
to
interact
with
them,
and
so,
if
a
number
of
SIG's
that
actually
handle
all
of
or
manage
all
of
the
sort
of
plumbing
that
sticks,
everything
together
primary,
which
is
SiC
API
machinery,
but
also
includes
things
like
cluster
lifecycle,
thinks
about
issues
like
upgrading
and
downgrading
and
installing
and
instrumentation.
That
obviously
thinks
about
how
to
we
make
everything
observable,
there's
also
the
cloud
provider
SIG's.
A
So
if
you
work
for
a
cloud
provider
like
you
know,
you
work
for
IBM
or
you
work
on
OpenStack
or
something
you're
gonna
be
interested
in
one
of
these.
If
you
are
for
that
matter,
in
operations
and
deploying
on
a
particular
cloud
provider,
you
may
be
interested
in
one
of
these
and
they
handle
the
particular
glue
code
between
kubernetes
and
deploying
on
that
particular
cloud
provider
and
making
full
use
of
it.
A
So
if
your
background
is
like
project
management,
qee
personnel
management
architecture,
you
know
API
design,
that
sort
of
thing,
then
you
actually
may
be
in
more
interested
in
one
of
these
things,
like
signal
architecture,
thinks
about
what
is
acceptable
kubernetes
and
what
is
not
acceptable
in
kubernetes
register.
All
the
api's
said
contributor.
Your
experience,
you've
heard
about
a
lot
is
that
we
manage
contributors.
Sig
p.m.
tries
to
manage
the
features
process.
I
spend
a
lot
of
time
in
cig
release
which
releases
kubernetes.
A
So
if
you're
a
lot
more
interested
in
managing
people
and
processes
than
one
of
these
six
is
actually
probably
going
to
be
a
better
bet
for
you
and
then,
of
course,
we
actually
have
our
single
largest
sig
in
terms
of
total
number
of
contributors,
which
is
sig
Docs,
so
sig
Docs
is
in
charge
of
both
the
documentation
and
the
kubernetes
website.
The
discrimination
website
is
mostly
documentation,
so.
A
Everybody
interacts
with
sig
Docs,
even
if
you
don't
actively
participate,
because
if
you're
going
to
be
writing
something
for
any
other
part
of
kubernetes
sooner
or
later,
you're
gonna
need
to
write
documentation
for
it.
The,
but
if
you're
interested
in
writing,
documentation
or
you
just
interested
in
getting
started
contributing
to
kubernetes-
and
you
don't
have
a
go
technical
background
and
you
don't
want
to
manage
people
CID
Docs
is
a
really
good
place
to
be
because
our
documentation
always
always
always
needs
improvement,
and
you
hear
more
about
that
later.
A
On
now,
I
did
mention
there
were
things
called
working
groups
and
sub
projects.
So
it's
not
just
six.
So
we
have
a
number
of
working
groups
that
are
sort
of
inner
sig
efforts
to
accomplish
specific
things.
Sometimes
these
things
are
time,
limited,
sometimes
they're,
more
or
less
indefinite,
and
then
a
lot
of
SIG's
have
particular
focus
areas
that
are
labor
intensive
but
are
narrower
than
the
Sigma
ssin
as
a
whole,
and
for
these
they
create
sub
projects
so,
for
example,
a
good
example
of
a
working
group
and
well
actually
so.
A
Here's
a
personal
list
of
working
groups
is
the
working
group.
We
sort
the
w/g
resource
management,
and
this
is
a
group
of
people
I
who
are
looking
at.
How
do
we
provide
both
observability
and
control
over
the
resources
of
the
machines
that
kubernetes
is
running
on
or
w
g
iot
edge
right
is
we're
just
starting
to
get
into
the
hey:
let's
run
kubernetes
on
devices.
A
So
if
that's
what
you're
interested
in
you
want
to
be
in
that
working
room
now,
for
these
small
focus
areas
that
fall
entirely
within
the
sig,
then
we
have
the
sub
projects
that
are
usually
in
the
kubernetes
SIG's
repoed
talking
in
there,
and
this
will
include
cloud
tools.
Building
tools
alternate
container
runtimes,
the
new
version
of
kubernetes
multi-cloud
is
federation.
A
So,
in
order
to
pick
the
right
cig
again,
the
starting
out
with
you
choose
your
own
adventure
journey
right
figure
out
what
it
is
you
want
to
work
on
and
then
find
out
which
cig
or
working
group
or
sub
project
covers
that
general
area.
You
can
go
to
the
cigs
page
that
I
showed
you
under
community
to
actually
look
through
all
of
the
SIG's.
You
can
do
the
cig,
intros
at
3:00
p.m.
A
So
I've
mentioned
a
whole
bunch
of
repositories
related
to
all
of
this
and
actually
want
to
get
a
little
bit
into
the
sort
of
repo
stuff
in
general.
Now
one
of
the
things
to
understand
is
we're
constantly
moving
around
repositories.
A
lot
of
stuff
that
is
there
currently
is
historical
in
nature,
and
so
don't
just
assume
that
it
is
because
of
the
repository
in
one
of
the
kubernetes
namespaces
that
it's
something
you
should
be
working
on.
There
is
a
Bandhan
where
there
ask
somebody
in
the
appropriate
sig
about
it,
if
you're
not
already
sure.
A
A
It
also
forms
a
coordinating
area.
So,
if
I
want
to
file
an
issue
about
a
ten
failure
in
kubernetes
and
I
want
to
make
sure
it
gets
looked
at
I
will
file
it
in
KK,
even
if
the
issue
is
actually
caused
by
something
in
a
separate
plug-in
repo,
and
that's
because
I
need
for
the
release
process.
I
need
a
central
place
to
track
everything,
and
so
things
like
the
the
issues
under
kubernetes
kubernetes
and
the
PR
zone
of
kubernetes
kubernetes
become
tracking
even
for
things
that
may
actually
live
in
satellite
rico's.
A
That
said,
we
are
in
the
process
of
taking
a
lot
of
stuff
that
exists
in
subdirectories
in
KK
and
pushing
it
out
into
plugins
right.
All
the
cloud
providers
are
going
to
become
plugin,
so
all
the
storage
is
gonna
become
plugins,
and
so
the
goal
is
to
actually
have
less
stuff
and
KK
in
the
future,
because
right
now
it's
gigantic.
A
A
Enhancements
is
for
tracking
the
addition
of
new
features
to
kubernetes
and
the
improvement
of
features.
The
steering
committee
has
their
own
repo
there's
a
giant
repo,
there's
actually
more
than
one
repo
for
testing
infrastructure,
automated
testing
and
the
scalability
and
performance
folks
actually
have
their
own
separate
set
of
tasks
with
its
own
repo.
So
we
use
a
bunch
of
repos
for
stuff
like
that
now
again,
one
of
the
biggest
repos
and
one
of
the
most
active
ones,
Kay
website,
which
is
our
documentation.
A
A
We
do
have
a
bunch
of
stuff
in
there
that
is
developer
tools
for
building
kubernetes
components,
building
things
on
top
of
kubernetes
they're
there
for
convenience,
like
if
you're
building
your
own
API
server,
here's
a
set
of
templates
to
help
you
to
do
that
and
that
sort
of
thing
the
and
that's
part
of
what's
under
the
kubernetes
namespace.
And
then
we
have
a
bunch
of
these
things
that
are
called
staging
repos.
A
So
this
is
brother.
This
is
all
in
the
kubernetes
namespace,
and
what
stage
and
repos
are
is
a
copy
of
something
that
currently
lives
in
a
subdirectory
in
kubernetes
kubernetes,
but
can
be
built
separately,
and
so
this
automatically
synced
copy
exists
so
that
people
can
do
build
and
test
on
stuff
that
involves
that
component,
only
frequently
for
working
with
plugins
and
other
things.
A
And
so,
if
you
look
at
some
of
those-
and
you
say,
oh,
this
looks
like
a
duplicate,
it's
other
thing,
and
it's
because
it
is
a
duplicate
and
those
are
those
staging
repos
and
they're,
only
applicable
to
you.
If
you're
working
on
certain
areas
of
the
code
like
API
server,
a
few
of
the
SIG's
have
their
own
repos,
because
they
have
code
for
special
things
like
kubernetes,
Federation,
etc.
A
Which
is
you
know
huge,
and
we
have
a
lot
of
repos.
We
do
try
to
show
you
the
primary
ones
here
right,
which
are
gonna,
be
kubernetes,
namespace,
testing
for
etc.
But
then
we
have
some
other
namespaces
here.
The
main
active
one
is
going
to
be
this
kubernetes
SIG's
namespace
and
the
kubernetes
SIG's.
These
are
those
sub
projects
that
I
talked
about.
A
So
if
a
cig
has
something
that
they
want
to
work
on,
that
is
either
very
specific
or
maybe
never
going
to
be
part
of
main
kubernetes
or
maybe
too
experimental
to
know
if
it's
gonna
be
part
of
main
kubernetes.
It
now
goes
into
kubernetes.
Six
and
you'll
see
there's
a
few
things
there
and
there
will
be
a
lot
more
there
in
the
future.
A
A
So
one
of
the
other
important
things
to
understand
he
is
you're,
gonna,
hear
a
lot
and
you
gonna
work
on
process
for
PR
and
issues,
and
that
sort
of
thing
and
rules
for
that.
These
are
the
rules
that
apply
to
the
kubernetes
kubernetes
repo
and
to
several
of
the
other
core
repos.
Some
of
the
other
repos
actually
have
different
rules
and
different
workflows,
because
those
teams
really
care
about
having
a
different
workflow
couple
of
good
examples
of
that
kay
website.
A
The
docs
team
has
a
more
multi
stage,
PR
approval
process
because
there's
a
technical
review
and
then
there's
a
copy,
edit
review,
etc,
and
so
they
will
have
slightly
different
rules.
The
Kumud
mint
eehm,
which
is
has
a
very
different
workflow
for
things
going
into
coop,
admit,
and
so
you
shouldn't
expect
that
to
necessarily
work
the
same
as
even
learning
the
rest
of
the
day.
Most
increasingly,
though,
everybody
is
actually
adopting
the
sort
of
consistent
central
workflow,
mostly
because
they
want
to
use
the
automation
that
we
have.
A
They
want
to
use
the
bots
and
the
bots
require
you
to
have
a
certain
workflow,
but
some
things
are
different
and
if
you
contribute
in
those
areas,
you
should
be
prepared
for
that.
So
that
said
now,
let's
actually
look
at
going
ahead
and
contributing
to
these
things
and
I
will
switch
off
back
to
Glynn.
B
B
Thanks
so
much
for
your
patience,
okay,
so
you
hear
y'all
talk
to
each
other
about
this
is
where
I
want
to
contribute.
This
is
my
general
area.
Maybe
some
of
you
have
poked
around
the
repositories
and
found
a
really
cool
looking
issue
or
you
have
this
bug.
That's
been
burning
in
your
back
pocket
for
the
last
several
weeks
and
you're
like
I,
can't
wait
to
get
to
coop
con
and
figure
out
how
to
fix
this
bug.
So
you're
super
excited.
You
all
look
super
excited,
I,
don't
know
maybe
I'm
the
most
excited.
B
So
where
do
you
start?
First,
I
want
to
talk
a
tiny
little
bit
about
membership.
I'm,
going
to
talk
more
about
membership.
Membership
on
github
in
general
is
a
thing
that
github
orgs.
Do
the
orc
grants
you
membership
in
itself
and
kubernetes
is
no
different.
The
kubernetes
is
an
organization.
Kubernetes
is
an
organization
on
github
and
it
can
grant
you.
Membership
membership
in
the
kubernetes
organization
is
a
little
bit
different
than
what
you're
used
to
probably
and
what
it
does
for.
What
you
have
to
know
right
now
is
that
membership
will
grant
you
certain
privileges.
B
B
B
This
is
one
of
my
first
Pony,
quests
and
I
know.
There's
a
couple:
people
who
had
some
trouble
signing
the
contributor,
License
Agreement,
no
sorry
I'm,
confusing
myself.
This
is
my.
This
is
my
first
Pony
quest
and
if
you
notice,
there's
a
little
label
on
the
very
bottom,
it's
a
little
small,
it
says
needs
okay
to
test.
This
was
because
I
had
not
joined
the
kubernetes
organization,
as
a
member.
Non-Members
have
to
run
all
of
their
changes.
B
B
B
B
Members
come
with
privileges
and
responsibilities,
I
already
kind
of
mentioned.
It's
going
to
make
it
easier
for
you
to
interact
with
the
automation
which
I
will
introduce
in
a
minute
are
actually
you
know
what
I'm
gonna
pause?
Are
there
questions
in
the
room?
This
is
a
workshop,
not
a
lecture.
So
are
there
questions
in
the
room
about
membership.
B
B
B
Let
me
go
back
to
the
previous
slide,
so
you
will
notice
that
there's
several
layers
of
privileges
and
responsibilities
on
this
contributor
ladder
on
this
membership
ladder
right
above
the
regular
member
we
have
reviewers
above
them,
we
have
approvers.
All
of
these
people
have
certain
special
knowledge
in
a
specific
area,
one
when
you
won't
become
a
kubernetes
member.
You
are
a
member
across
the
board,
but
reviewers
and
approvers
are
a
little
bit
more
granular.
For
example,
people
who
really
know
all
about
storage
are
much
more
likely
to
attain
reviewer
or
approver
status
in
related
repositories.
B
Then
say
you
know,
they're
going
to
work
on
testing
where
maybe
they
haven't
really
had
a
lot
of
experience
or
work.
This
is
where
owners
files
come
in.
Josh
has
shown
you
a
little
bit
about
the
project
structure
and
each
repository
in
the
kubernetes
organizations
hat
is
is
organized
by
owners
code
owners.
There
are
owners
files
on
almost
every
level
of
the.
B
B
B
Yeah,
that's
that's
where
we're
getting
into
good
question.
Yes,
so
I'm
telling
you
about
owners
files,
because
these
are
the
folks
that
will
be
reviewing
your
code.
Each
owners
file
will
have
in
it
the
people
that
are
specialists
about
where
you're
contributing
and
they
are
in
these
files,
because
we
have
a
lot
of
automation
on
top
of
kubernetes.
That
allows
us
to
solicit
reviews
from
code
owners
that
allows
us
to
manage
pull
request,
workflow
and
that
allows
us
to
manage
testing
automation
when
you,
when
you
are
in
an
owner's
file,
the
kubernetes
pull
request.
B
Bot
knows
that
you
are
a
reviewer
or
an
approver
and
will
either
suggest
or
automatically
ask
for
you
to
review
certain
pull
requests.
This
is
important
for
you
to
know,
because,
when
you
are
having
a
hard
time
finding
a
reviewer
or
someone
to
look
at
your
pull
requests
or
your
issue,
you
can
go
look
at
the
owners
file
and,
you
know,
say:
hey
person
who
is
in
charge
of
this
repository.
What
do
you
think
of
my
change?
Always
keeping
in
mind
to
you
know,
wait!
Wait
time.
B
The
next
bit
of
automation
that
we
need
is
labels
I
already
showed
you
what
happens
when
actually
I
didn't
show
you
I'm
going
to
show
you
right
here.
This
is
a
set
of
labels
on
a
pull
request,
and
you
will
see
that
there's
a
red
one
that
says
CN
CF
CLA.
No,
that
is
one
of
the
many
labels
that
we
keep
track
of.
That
gives
us
information
about
the
status
of
a
pull
request.
Let
me
go
back.
B
Github
basic
the
basic
functions
that
github
comes
with
are
usually
enough
for
most
projects
to
effectively
manage
their
membership
and
their
workflow
kubernetes
is
kind
of
too
big.
For
that
we
have
multiple
orgs
multiple
sub
projects,
multiple
repositories
and
because
our
membership
is
somewhat
our
membership
process
is
a
little
bit
different.
We
want
people
who
are
not
actually
orgas,
who
are
casual
contributors
who
maybe
have
like
one
patch
that
they
want
to
do.
We
want
people
who
are
not
fully
sold
to
be
able
to
submit
patches,
and
this
is
what
the
automation
is
for.
B
If
you
are,
if
you
have
explored
a
little
bit
in
the
repositories,
you
will
find
out
that
you
can't
use
some
of
the
functions
that
are
normally
available
in
github.
You
won't
be
able,
to.
You
know,
request
a
reviewer
by
clicking
on
that
sidebar
and
pellagra
quest
reviewer.
That
is
not
activated
on
the
kubernetes
repositories.
Instead,
we
use
labels
and
thought
automation
and
I'm
going
to
talk
to
you
a
little
bit
how
to
talk
to
the
bots
I
already
showed
you
the
stack
of
labels.
Most
of
these
labels
are
either
put
there
by
the
kubernetes.
B
Pull
request
bot
some
of
them
are
automatic,
like
the
size
label,
and
some
of
them
are
put
there
by
actual
people.
So
you
can
use
the
automation
to
request
a
reviewer.
You
can
use
the
automation
to
say
this
poll
request
looks
good
to
me.
I
approve
this,
and
so
in
a
way
we
use
labels
for
almost
everything
in
terms
of
automating,
our
workflow,
and
that
can
be
super
overwhelming.
B
You
saw
that
stack
of
labels.
Yes,
you
do
have
sometimes
opening
a
pull
request
in
kubernetes
feels
like
this.
Oh,
my
god,
I
have
to
get
all
the
labels.
I
have
to
have
all
the
necessary
labels.
There's
even
some
automation
that
tells
you
hey.
You
don't
have
this
label,
you
need
to
get
this
label
somehow,
and
here
are
some
of
those
examples.
B
This
is
kubernetes
issues.
If
you
actually
just
go
to
kubernetes
issues,
you
can
some
of
the
labels
actually
have
brief
descriptions
on
them.
Not
all
of
them.
There
is
a
super
long
list
of
labels
and,
yes,
they
completely
differ
by
repository.
I
will
go
over
some
of
the
required
and
most
common
issues,
common
labels
to
get
you
started
conceptually
most
of
the
labels
work
very
similarly,
but
different
repositories
might
have
slight
differences
and
I'm
going
to
focus
on
kubernetes
kubernetes,
our
core
repository
for
the
next
few
slides.
B
So
there
is
a
slight
difference
between
issues
and
pull
requests,
I'm
going
to
start
with
issues
because
they
generally
have
fewer
labels
on
them.
The
only
required
labels
that
you
need
are
the
cig
label
and
the
kind
label
somebody
later
will,
probably
probably
in
conjunction
with
you,
put
a
priority
on
it.
The
priority
label
is
is
a
little
bit
different,
but
all
of
those
are
necessary
to
be
put
on.
B
Let's
talk
about
the
cig
label,
when
you
sorry
I
lost
my
train
of
thought
there
for
a
second,
you
already
know
about
cigs,
and
you
will
get
a
better
idea
of
where
which
part
of
the
code
belongs
to
what
sig.
As
you
keep
working,
it's
always
okay
to
ask
on
some
repositories.
The
bots
will
actually
know
or
make
a
make,
an
educated
guess
about
which
cig
this
pull
request
belongs
to.
The
reason
you
want
to
put
on
the
sig
label
is
so
that
you
can
get
attention
on
your
pull
request.
B
Basically,
what
happens
if
you
just
opened
a
pull
request
on
the
org
is
nothing
is
going
to
happen
because
people
don't
know
what
it's
about.
They
don't
know
you
there's
no
labels
on
there
and
they're
like
I,
don't
know
what
this
is.
So
that
is
why
we
require
that
we
put
a
sig
label
on
it
and
if
you
don't
know
what
what
sig
is
responsible
for
your
patch
or
your
issue
in
this
case,
that's
okay,
take
a
guess.
Someone
from
that
sig
will
come
along
and
be
like.
B
B
B
B
So,
that's
that's
how
you
do
it
so
that's
I
gave
you
a
couple
of
examples.
I'm
always
super
confused
because
the
label
has
sig
slash
name
and
then
the
BOD
commanders,
slash,
sig,
Space
name,
so
don't
feel
bad
I
have
so
many
issues
lying
around
that
have
multiple
comments
from
me,
trying
out
various
ways
of
getting
the
bot
to
pick
up
this
label.
So
if
the
label
doesn't
get
picked
up,
it
probably
means
you
typed
something
wrong
and
you
have
to
check
the
bot
command
help.
So.
B
B
The
kind
label
kind
is
a
little
bit
unintuitive,
but
basically,
this
is
for
somebody
to
tell
you:
hey
I
want
us
to
be
a
feature
I
want.
This
is
a
bug.
I
found
a
bug,
do
put
this
label
on
there.
There
will
also
be
some
instructions
on
a
pull
request.
When
you
open
a
pull
request,
there
will
be
some
prompts
tools
to
help
you
out,
but
we
need
this
to
be
able
to
triage
it's
important
for
the
release
process.
It
is
important
for
the
SIG's
to
know
this.
B
B
B
The
other
ones
are,
you
know
long-term,
maybe
maybe
this
is
something
that
is
related
to
a
feature,
that's
being
rolled
out
in
the
next
release
or
the
release,
after
that,
that
would
be
a
way
to
use
the
priority
label.
In
general,
you
communicate
with
your
cig
about
what
priority
this
should
be.
Yes,
yes,.
B
B
B
There
is
not
really
a
standardization,
don't
worry
about
it
too
much
once
you
get
going.
You'll
have
more
feel
for
this.
One
I
already
mentioned
triage
and
project
management.
These
labels,
as
Noah
mentioned
earlier.
We
don't
really
use
github
for
support
requests.
We
use
slack
for
that
and
you
can
ask
you,
can
post
and
discuss
as
well.
These
labels
are
really
more
for
for
us
to
realize
Oh
somebody
is
somebody's
asking
for
help.
Somebody's,
not
responsive.
This
is
a
duplicate.
This
is
really
more
like.
B
These
are
the
labels
we
use
when
we're
not
going
to
act
on
something
almost
always.
This
is
not
you
as
a
new
contributor.
You
wouldn't
really
use
these
labels,
because
this
is
really
more
for
project
management.
Again,
we
try
to
be
polite
about
closing
support
issues
and
we
usually
ask
people
to
go
and
ask
in
the
kubernetes
dev
channel
on
flack.
B
B
Especially
the
the
release
note
one
all
issues,
all
pull,
requests
on,
kubernetes
kubernetes
need
a
release
note
or
at
least
need
to
pass
a
test
that
says
this
doesn't
require
a
release.
Note
you
will
see
some
labels
that
say
needs
needs,
release,
note
needs
kind,
needs
cig,
and
that
will
be
your
cue
to
respond
to
those.
B
B
The
LTTE
m'
label
is
what
code
reviewers
can
bestow
upon
your
PR
to
say
this
PR
is
this
PR
looks
good
to
me,
I'm
good
with
merging
it.
It
is
a
technical
label
that
says
I
understand
this
code.
I
approve
this
code.
I
want
this
code
to
go
into
the
project.
The
approved
label
is
a
little
different.
Only
code
approvers,
which
is
one
level
above
code
reviewers,
can
put
this
label
on.
B
This
is
going
to
be
your
most
difficult
label
to
find
on
your
pull
request,
because
there's
generally
only
a
few
approvers
in
each
owners
file.
However,
the
approved
label
does
not
necessarily
mean
that
person
looked
closely
at
your
code.
That's
what
the
LG
TMS
4.
We
have
some
granularity
and
prowl
that
allows
us
to
require
more
LG
TMS
than
just
widen.
B
B
So
here's
an
example
of
the
pull
request
in
kubernetes
kubernetes.
You
see,
there's
a
lot
more
labels.
There
are
some
needs
kind
needs
priority
release.
Note
none
those
those
help
us
make
sure
that
we
can
tell
our
CI
integration
on.
You
know
when
to
kick
off
tests
and
when
to
merge
and
to
master
or
a
release
branch
as
it
were.
B
So
when
I
mentioned,
the
bot
will
help
you
a
lot
of
the
time
when
you
open
a
pull
request.
The
kubernetes
spot
will
talk
to
you
and
say:
hey.
Your
PR
is
not
approved.
Well,
duh,
it's
not
you
just
opened
it,
but
the
bot
can
help
you
find
reviewers.
The
bot
can
help
you
find
approvers
and
the
way
that
you
add
reviewers
and
approvers
is
exactly
the
same
way
as
you
would.
With
with
the
labels
you
go,
slash,
assign
and
then
their
user
name.
B
And
yes,
you
can
totally
assign
Joe
Beda
to
you
a
pull
request.
Please
do
if
the
bot
says
assign
Joe
Beda.
You
should
assign
Joe
Beda
unless
you
already
know
someone
else
that
you'd
rather
have
that
you'd
rather
have
take
a
look,
but
what
I
ran
into
and
I
saw
this
the
first
time
I'm
like
okay.
This
is
a
huge
community
full
of
thousands
of
people
and
I,
don't
know
you,
and
is
it
really
okay,
if
I
at
you
on
github
I,
don't
know
I
don't
want
to
do
it
please
do.
B
B
Another
part
where
labels
can
help
you
is
they
can
help.
You
find
your
first
issue
when
people
file
issues.
Sometimes
we
ask
that
we
ask
actually
we
ask
of
every
sig
to
have
a
handful
of
issues
that
are
help
wanted
and
good
first
issues,
so
that
people
who
are
new
either
to
the
codebase
or
the
community
can
just
sort
of
get
started
and
learn
a
little
bit
about.
What's
going
on,
we
have
actual
guidelines
that
are
documented
on
how
to
use
both
these
labels.
B
These
labels
aren't
at
this
point
not
really
for
you
to
put
on
your
issues.
These
labels
are
for
you
to
look
through
issues
and
look
for
good.
First
issue
comes
with
a
ton
of
support.
You
will
be
able
to
ask
hey:
where
do
I
start?
Is
there
an
example?
Can
you
help
me
help
once
it
is
a
little
bit
more
hands-off,
but
still
clear
tasks,
low
barrier
to
entry?
These
are
just
designed
to
get
people
started
in
what
can
otherwise
be
a
really
really
big
daunting
task?
B
B
B
B
B
For
the
cherry-picks,
this
is
a
cherry-pick
question
yeah.
So
I
want
to
thank
you
for
asking
this
question
because
cherry-picks
are
a
little
bit.
They
were
a
little
bit
one
of
the
more
more
obscure
parts.
We
actually
have
some
automation
there
too.
So
basically,
the
way
cherry-picks
work
is,
if
you
happen
to
be
in
a
part
of
the
release
cycle,
where
certain
branches
are
locked
from
having
code
added
to
them.
B
You
can
still
work
on
your
change
and
contribute
and
have
it
merged
to
master,
which
is
currently
not
the
current
release
branch
and
then,
once
it
proves
to
be
stable,
you
can
request
to
have
it
cherry-picked
into
the
release
branch
so
that
it
becomes
available
on
that
version.
Cherry-Picks
are
basically
what
you
want
if
the
release
for,
for
example,
112,
has
been
cut
already,
but
you
really
really
wanted
that
change
to
be
in
112,
so
you
continue
to
contribute
it.
B
B
B
All
right
so
before
we
all
head
out
for
lunch,
I
would
ask
that
after
lunch,
everyone
come
back
to
the
table
and
the
people
that
they
are
at
now,
because
what
we're
going
to
do
is
we
are
going
to
put
some
of
you
in
owner's
files
and
then
you
can
all
play
around
and
start
looking
at.
What
a
lot
of
this
automation
looks
like
in
real
time.
We'll
also
have
some
tutors
to
help
when
you
get
stuck
so
that
will
be
really
more
of
like
an
open
project.