►
From YouTube: CNCF SIG Contributor Strategy 2020-10-22
Description
CNCF SIG Contributor Strategy 2020-10-22
A
C
C
C
C
B
A
C
D
Yeah,
so
I
think
what
we
can
do
since
we
have
so
forward-looking.
Our
intent
was
to
have
kind
of
like
either
a
separate
maintainer
circle,
meeting
or
yeah
that
that
so,
basically
alternating
the
every
every
two
weeks,
a
standard,
sig
contributor
strategy
meeting
and
then
the
alternating
two
weeks
would
be
the
maintainer
circle
meetings.
So
since
you're
here
we'll
pretend
this
is
a
maintainer
circle
meeting
which
was
planned
to
be
and
talk
a
little
bit
about
container
d,
maybe
not
linker
d.
B
Okay,
so
I
picked
him
and
I
hope
he
can
join
but
yeah
so
yeah
I
mean
like
I
was
really
excited,
so
I
joined
buoyant
recently
a
month
a
month
and
a
half
ago,
and
for
me
it's
the
first
time
working
for
a
company
that
is
also
a
maintainer
of
source
of
open
source
project
and
one
of
the
things
that
we're
trying
to
do-
and
I
was
like.
Oh
my
god,
this
sounds
like
this
is
some.
B
I
think
this
is
like
a
really
good
sig
for
us,
because
one
of
the
challenges
we
have
is
well.
We
are
a
small
company,
we're
a
startup
and
so
we're
putting,
and
we
put
a
lot
of
work
and
effort
into
link3d,
but
we
also
have
to
start
working
on
stuff
that
we
can
monetize
right.
So
somehow
we
need
to
also
so
what
we
want
to
do
now
is
kind
of
help.
Help
and
charles
is
joining
hey.
Charles.
B
Okay,
how
can
we
engage
the
community
more
because
it's
a
lot
of
the
work
has
been
done
by
people
like
charles
and
some
other
people
who
are
like
really,
like
writing,
content
being
on
slack
helping
out
and
we
wanna
incentivize
the
community
to
be
more
engaged
because
we're
always
I
mean
it's
all
about
community
and
and
and
open
source,
but
people
focus
a
lot
on
contributing
code.
But
we
want
to
say
like
it's
more
about
that.
B
B
If
you,
you
know,
if
you,
your
writing,
skills,
aren't
that
great
you're,
not
confident
if
you
haven't
submitted
a
talk
yet,
and
so
I
was
wondering
so
yeah
we're
trying
to
think
around
those
lines,
and
I
was
wondering
if
that
is
any,
because
I'm
sure
you
discuss
lots
of
different
things.
But
if
that
is
kind
of
the
stuff
that
we
can
discuss
here
too,
is
like
how
to
engage
them
more,
and
it's
like
because
that's
been
always
like
the
big
challenge
for
us.
B
D
Okay,
cool
yeah,
and
if
you
have,
if
you
have
anything
that
you're
interested
in
forwarding
over
to
our
list,
we
have
a
mailing
list
as
well.
Give
me
a
second:
it's
yeah.
It's
higher
up
in
the
dock,
list.cncf.io
cncf,
sig
community
contributor
strategy,
very
easy
to
remember,
but
yeah.
I
think
that
you're
you're
touching
on
something
pretty
pretty
important
around
you
know
so.
Josh
and
I
are
both
in
the
kubernetes
community
as
well
as
josh,
has
had
some
time
in
the
postgres
community
as
well.
D
I
think
that
kubernetes
has,
I
think,
kubernetes
has
the
mass
to
do
so.
A
lot
of
these
things,
but
considerations
around
you
know
like
when
I
think
of
decks,
we're
we're
spinning
up
a
website
or
we've
spun
up
a
website,
and
it's
like
okay,
who
maintains
this
now
right
like
do
we
have
the
skills
within
the
maintainers
to
do
that?
Do
you
know
thinking
about
information
architecture?
How
do
we
get
people
to
the
places
that
they
need
to
go
quickly
and
easily
right?
D
And
you
know
in
terms
of
sustainability,
like
I
want
to
everything
that
I
do.
I
want
to
build
more
maintainers
like
how
do
I
do
that
right
and
also
thinking
from
the
the
field
engineering
perspective,
because
I'm
a
former
field
engineer
and
solutions
architect,
I
don't
want
to
do
that
day
to
day
right,
like
the
your
primary
driver,
is
essentially
building
products
and
solutions
for
customers
right
and
and
pushing
that
feedback
into
product
roadmaps
right
our
project
roadmaps.
So
how
do
we
do
that
effectively
right?
C
E
Yeah,
I
can
answer
that
and
so
josh,
it's
good
to
see
you
again
howdy
steven.
It's
always
always
a
pleasure
to
be
on
a
call
with
you.
So
the
current
situation
is
we.
We
we're
we're
at
the
point
where
we
have
to
be
really
engaged
with
folks
from
the
like
the
maintainer
perspective
and
where
we're,
which
is
fine,
that's
what
we
want
to
do.
E
We
want
to
be
the
shepherds
and
the
stewards
to
make
sure
that
we
have
a
healthy,
healthy
community
and
what
we're
looking
to
do
with
the
anchor
program
that
catherine
mentioned
is
to
get
you
know,
basically,
ambassadors
or
captains
or
whatever.
The
analogous
term
is
to
have
folks
who
are
who
love
liquidity,
who
want
to
use
it
and
who
are
so
excited
about
it
that
they
want
to
share
their
experiences
with
it
and
that's
our
approach
to
growing
one.
That's
our
current
primary
approach
to
growing
the
community.
E
Should
this
not
give
us
the
result,
so
we
want
we'll
go
back
to
the
drawing
board
and
see
if
we
can
figure
out
another
plan,
but
this
is
seems
to
be
the
tried
and
true
approach
and
so
yeah.
We
just
I
forget
how
we
discovered
this,
this
sig
contrib
growth
group,
but
this
is
certainly
something
that
we
could
use
right
now,
we're
using
slack
and
github
as
our
primary
interfaces
with
folks.
E
We
have
a
discourse,
but
it
just
doesn't
get
a
ton
of
traffic,
it's
mostly
for
linker
d1
stuff
and
there's
not
a
ton
of
linker
d2
content
on
there.
So
things
that
we're
thinking
about
are,
as
how
do
we
get
content
and
we've
got
a
good
plan
there,
where
internally
we're
having
each
of
the
the
maintainers
or
contributors
generate
one
blog
post
or
one
tutorial
once
a
once
a
month.
So
that'll
keep
us
if,
if
nothing
else,
changes
that'll
keep
us
going.
E
We
don't
to
make
or
ask
people
to
do
something
that
they're
uncomfortable
with.
We
really
want
people
who
are
excited
to
share
what
they're
doing
with
open
source
technology,
how
they're
integrating
it
with
other
pieces
of
open
source
technology
and
gluing
these
things
together,
and
these
are
a
lot
of
the
conversations
that
I
have
with
folks
on
slack.
Just
as
like
dms
and
they're
saying
oh
man,
we
just
integrated
prometheus
and
linker
d
with
cortex
and
it's
driving
all
of
our
metrics.
And
it's
super.
E
You
know,
they're
super
excited
about
it,
and
so
that's
where
we
pick
up
on
those
cues
and
try
and
encourage
them
to
get
involved
as
well.
So
taking
that
abstracting
that
away
from
for
taking
the
link
or
d
part
out
of
that,
what
we're
looking
for
is
just
common
patterns
or
even
shared
shared
thought
around
continuing
to
grow
continuing
to
encourage
folks
now,
I've
said
a
lot
of
words.
C
E
So
I
feel
like
we're
in
touch
with
a
lot
of
like
we
know
what
people
want
out
of
linker
d,
where
I
think
there's
a
disconnect
is
our
road
map
and
what
people
are
looking
for,
and
so
that's
that's
the
converse.
That's
the
first
time.
I've
ever
said
that
at
all
it's
first
time,
I've
ever
had
that
thought.
E
So
it
probably
is
something
I
need
to
think
about
more
before
we
go
down
that
rabbit
hole,
but
the
few
we
have
a
few
folks
that
are
just
really
engaged,
and
then
people
that
come
in,
I
think,
over
the
last
few
months
they
weren't
getting
the
right
amount
of
attention.
They
would
join
the
slack
channel,
ask
a
question,
and
maybe
it
took
too
long
or
maybe
they
never
got
an
answer
or,
and
so
they
kind
of
just
bounced
out.
E
So
that
course
correction
work
that
we're
doing
now
is,
and
it's
I
don't
even
consider
it
work.
It's
like.
Oh,
I
see
somebody's
new
in
the
slack.
Let
me
just
go
say
hi
right
when
they've
joined
it's
that
kind
of
thing
just
to
build.
That
welcoming
and
like
encourage
folks
to
write,
ask
questions,
because
I,
I
am
also
the
kind
of
person
who's
hesitant.
Oh,
like
I
will
scour
the
internet
for
a
ques.
E
D
I
mean,
I
think,
that
you
know.
I
think
that
part
of
that
is
like
it's
a
good
pattern,
and
maybe
I'm
saying
it's
a
good
pattern,
because
it's
something
that
I
do
as
well,
but
it
also
starts
to
poke
holes
and
kind
of
like
your
information
flow.
If
I
can't
get
the
answer
quickly,
then
that
points
to
of
an
opportunity
for
optimization
right.
I
think
that
I'm
not
saying
that
slack
or
disco
course
should
be
a
last
resort,
just
that
people
should
be
able
to
self-enable.
D
Essentially
so
you
mentioned
roadmap-
and
I
was
going
to
mention
roadmap
to
you
as
well.
Having
a
clear
vision
of
what's
next
in
the
project
is
is
huge
for
a
lot
of
people,
I'm
seeing
that
you
have
131
issues
open
on
on
just
linker
d,
linker
d,
I'm
I'm
sure
there
are
tons
of
other
repositories
to
consider
right.
Yeah,
that's
linker,
d1,
so
linker.
D
Okay,
all
right
and
that
one
is
209
209
open
so
like
if
you
can
yeah.
So
if
you
know
finding
a
way
to
kind
of
aggregate,
some
of
that
stuff
get
a
better
idea
of
of
who's
doing
what,
when
is,
is
helpful
for
users.
It
sounds
like
just
like.
I
know
this.
I
know
this
problem
too,
and
it's
and
it's
a
you
know
it's
a
triage
problem.
D
C
E
Not
so
much
stack
pieces
that
integrate
with
linker
b,
they
are
integrating
linker
d
with,
like
I
said
that
that
prometheus
cortex
is
a
good
example
or
integrating
linker
d
into
a
ci
cd
system.
Like
argo,
we're
seeing
that
kind
of
stuff
and
yeah
the
the
maintainers
and
adopters.
That's
that's
where
william
had.
E
C
Of
the
things
that
we've
seen
that
has
worked
better,
is
you
recruit
contributors
around
the
sort
of
fringe
for
the
project?
You
know:
integrations
plug-ins,
ui,
stuff,
that
sort
of
thing
and
as
people
build
up
experience
and
a
commitment,
they
eventually
get
into
submitting
stuff
to
the
core
project
itself.
D
That
we
see
that
too
and
then
and
then
overall,
like
from
the
you
know
the
cncf
level,
that
is,
you
know
something
that
people
look
at
deeply
for
for
graduation
considerations.
Right
is
it
is
it
company
diver,
like
is
their
company
diversity
right,
so
just
staring
at
the
maintainers
at
least
for
linker
d2.
I
see
only
one
email
address
that
is
non-buoyant
right
now,
so.
C
Yeah,
that's
pretty
honestly
pretty
standard
for
a
lot
of
these
startup
projects,
yeah
yeah,
because
it's
very
it's
very
different
compared
to
the
big
company
projects,
where
the
project
is
one
of
800,
different
things
that
that
company
has
the
so.
But
you
know
we're
looking
at
some
of
these
things.
C
You
know
people
who
might
have
linker
d
as
part
of
a
stack
for
more
substantial
contributions
closer
to
the
core
just
because
of
the
time
commitment
involved,
the
so,
but
I
mean
it
sounds
like
part
of
it.
You
know
begin
with
what
you're
already
addressing
this
anchor
program
is,
is
kind
of
connecting
with
your
users
right,
because
you
have
your
pyramid
and
the
users
is
the
broadest
part
of
it,
and
then
contributors
is
is
almost
is
always
a
subset
of
users.
C
C
How
clear
is
the
path
right,
assuming
that
I,
as
a
potential
contributor,
have
the
time
to
put
in
the
work?
How
clear
is
the
path
for
getting
that
contribution
in
like
like
how
difficult
is
it
for
me
to
figure
out
how
I
would
contribute
that
thing?
Whether
or
not
even
can
contribute
that
thing,
because
one
of
the
big
obstacles
that
we
have
with
the
smaller
company
projects
is
this
perception
that
the
perception
that,
if
you
don't
work
for
company
x,
you
can't
contribute
to
the
core
actually
exceeds
the
reality.
C
E
Yeah,
that's
that's
a
good
question
good,
but
I
think
we
could
make
it
easier
and
I
think
you
could
say
that
about
any
contribution
path.
Right
like
we
could
make
it
easier
so,
and
I've
had
thoughts
around
this
recently,
just
about
like
a
tutorial
for
setting
up
your
development
environment
for
lingerie.
E
E
E
Oh
feature
requests,
it
comes.
They
all
come
in
through
github,
though,
and
that's
kind
of
the
manual
part
where
it's
up
to
us
to
pick
up
on
them.
You
should
we'll
get
some
that
just
come
in
straight
into
slack
through
issues,
and
we
have
a
template
for
a
feature
request
for
github
issue,
but
we
also
have
people
the
the
second
most
popular
way.
Is
people
will
come
into
slack
and
they
say:
hey
does
link
rd
do
this
or
it
would
be
really
cool.
E
If
linkerd
does
this
and
so
going
back
to
what
we're
just
talking
about
about
that
contributor
process,
our
our
current
process
is
to
say:
hey,
we'd,
love,
some
help
with
that.
Would
you
either
file
an
issue
or
if
you
want
to
pull,
do
you
have
time
for
pr?
That
would
be
great
as
well.
That's
our
current
process
and
that's
the
one
that
I'm
I
need
to
think
through
that
catherine
and
I
can
think
through
that.
I
think
that
we
could
make
improvements
on.
B
What
I'm
kind
of
trying
to
search
now
is
like
okay,
who
is
doing
it
right
like
who
has
figured
it
out,
and
maybe
no
one
has
right,
but
it's
like
that's.
Why
we're
trying
to
do
this
anchor
program
and
so
on?
It's
like
like
who
else
has
been
able
to
engage
and
get
people
excited
what
what
has
been
getting
people
to
speak
about
it
publicly?
C
C
E
Yeah,
I
think
you're
right
there
josh,
we
sorry
to
cut
you
off.
We
we
identified
that
as
we
identified
that
as
being
like
the
thing
that
would
move
the
needle
the
most
and
the
fastest
for
us
is
if
we
could
find
a
company,
an
external
organization
like
an
end
user
that
was
available
to
dedicate
their
engineers
to
building
contributing
yeah.
D
Two
you
have
the
you
know
you
have
the
the
toc
list,
the
the
sig
contributor
strategy
lists
at
your
disposal
to
kind
of
to
help
market
some
of
this
as
well,
and
the
end
user
community
right
so
cncf
has
an
end
user
community
exactly
to
raise
these
kinds
of
topics.
So
so
there
are
few
avenues
to
go
down
in
terms
of
building
this
out.
I
think
I
think
that
you
know
one
of
the
best
strategies
is
to
help
people
drink
the
kool-aid.
C
D
C
D
E
C
F
F
And
once
you
get
a
couple
of
individual
people
that
are
outside
of
your
company,
then
it
gets
easier
to
start
to
scale
that
and
put
some
mentoring
programs
in
place
and
kind
of
build
up
the
contributor
ladder,
which
is
what
the
contributor
growth
team
working
group
looks
at.
But
it's
it's
honestly.
It's
it's
a
lot
of
hard
work
and
it's
a
lot
of
convincing
individual
people
that
they
really
want
to
contribute,
and
that's
it's
hard.
But
if
you
approach
it
from
that
that
direction,
that's
the
best
experience.
I've
had.
C
D
C
E
E
Yeah
well,
thank
you
all
yeah,
that's
don
you're
right,
I
think
boy.
It
was.
It
was
certainly
much
easier
when
in
person
when
we
could
like
get
kubecon
is
the
best
example
when
I
would
run
into
folks
run
into
users
who
are
curious
about
linkedin
and
then
fast
forward
a
year
and
they're.
They
have
cubecon
talks
about
how
they're
using
linkedin
production.
That's
like
that's
a
really
good
feeling
for
us,
but
you're
right.
E
It's
been
a
long
long
road,
that's
been
long,
hard
work
and
so
to
your
point
about
it
being
difficult
these,
the
virtual
interactions,
I've
found
have
made
it
much
more
difficult,
and
this
is
probably
my
perception
I
feel
like
when
I'm
dming
somebody
on
slack,
I'm
one
of
about
18
to
23
other
conversations
that
they
have
going
on
at
any
given
moment
and-
and
my
the
main
thing
about
that
is.
I
really
feel
bad
about
bothering
people,
so
anything
that
I
can
do
to
offload
their
cognitive
workload
would
be
great.
E
D
I
think
in
some
sense
like
we're,
you
know,
for
every
you
know,
for
every
kubernetes
sub
project
or
something
that
we
may
spin
up.
It's
it's
a
very
similar
situation
where
we
have
to
do
the
recruiting.
We
have
to
do
the
one-on-one
time
with
people.
We
have
to
think
about
the
way
that
we
want
to
market
the
the
sub
project.
So,
like
you
could
you
could
see
them
as
as
as
many
projects
and
in
and
of
themselves.
D
I
think
you
know
very
sensitive
to
the
very
sensitive
to
the
the
slack
overload
it's
actually
currently
happening
and
what
what
is
maybe
a
good
task
to
do
is
think
about
the
questions
that
you
get
on
slack
right.
The
questions
that
you
ask
and
the
questions
that
you
receive
on
slack
and
say
did
some.
D
E
F
F
That
shows
people
that
it's
not
it's,
not
just
your
company,
that
is
responsible
for
answering
questions
and
reviewing
all
the
pull
requests,
because
if
that's
what
people
see
that's
the
expectation
you
set
and
the
more
you
can
do
to
change
it
in
small
ways
that
helps
kind
of
make
it
easier
to
to
make
it
better.
In
the
long
term.
D
There
are,
there
are
also
you
know,
more
minimal
permissions
that
you
can
provide
to
people.
I
think
there's
like
a
triage
option
on
github.
So
if
you
have
repos
that
are
like
you
have
a
few
repos
that
could
use
triage
right
as
a
short
version.
So
if
you
have
people
who
have
been
commonly
committing
code-
or
you
know,
non-code
contributions,
pull
them
in
for
triage
as
well
right
or
you
can
set
up
boards.
D
You
don't
have
these
don't
have
to
be
repo
pinned
boards,
but
you
can
set
up
github
project
boards
right
and
assign
permissions
outside
of
the
repo
permissions
right.
So
that
way,
you
kind
of
get
around
the
the
the
problem
that
you
often
run
into
where
you
have
a
repo
scoped
project
board
and
the
only
way
for
someone
to
actually
maintain
it
is
to
give
them
a
host
of
permissions
on
that
repo
right
so
having
an
org
level
one
or
having
several
org
level
ones.
B
D
So
I
think
so
we
have
so.
The
sig
itself
has
a
a
mailing
list.
The
toc
list
tends
to
get
a
lot
more
traffic
than
we
do
and
then
there's
also
the
end
user
group.
The
end
user
group
we'd
have
to
amy,
probably
knows
more
about
how
we
could
activate
that
for
you,
so
I'll
shut
up
now,
yes,
but
cheryl
is
the
one
who
is
is
running
that
I'm
just.
G
D
E
F
A
D
F
E
C
Here's
a
bunch
of
things
that
people
would
like
to
have,
but
nobody
from
buoyant
is
working
on.
You
know.
So
if
you
want
them,
someone
else
has
to
step
up,
and
here
are
the
things
we
have
to
decide.
Are
these
things
ever
going
to
be
part
of
link
or
d
right,
because
you
have
to
every
project
has
to
decide
what
their
scope
is
and
that's
that's
a
process.
You
don't
have
to
decide
what
your
scope
is
just
once.
C
I
mean
particularly
an
environment
where
you're
competing
against
other
open
source
service,
mesh
projects,
product
projects
right
and
a
big
part
of
in
a
competitive,
open
source
situation.
A
big
part
of
how
you
drive
adoption
is
implementing
the
feature
that
the
other
ones
don't
have,
and
then
it
turns
out
that
people
want.
D
I
think
the
hardest
thing
that
we
have
to
deal
with
outside
of,
like
all
of
the
many
many
things
in
the
kubernetes
project,
is
the
at
some
point
kind
of,
like
all
of
the
responsibilities,
start
funneling
into
the
de
facto
roles
for
six
right.
So
so
the
the
chairs
and
and
technical
leads,
which
means
they're
doing
you
know
they're
doing
the
technical
leadership
stuff
they're
doing
the
the
cherry
stuff,
they're
running
meetings,
they're,
triage
they're,
building
out
boards,
they're
they're
reviewing
enhancements
for
for
features.
D
D
You
know
these
these
other
tasks
occupying
the
mental
space,
to
be
able
to
say,
like
we
don't
actually
have
bandwidth
for
for
this
right
and
and
being,
I
think,
you
know
being
able
to
be
honest,
really
honest
about
that
stuff
like
one.
The
map
helps
because
you
can
just
look
at
it
and
go
like
this-
is
just
not
not
in
the
cards
for
120
or
whatever
release
rate,
but
two
like
giving
that
opportunity.
D
By
having
the
roadmap
and
saying
like
this,
is
you
know
this
is
in
the
freezer
or
the
backlog
or
whatever
like
you,
can
feel
free
to
pick
it
up,
but
no
one
will
be
there
to
maybe
to
maybe
carry
it
along.
So
if
you're
comfortable,
you
know
if
you're
comfortable
engaging
in
that
way.
If
this
is
a
future
that
is
important
to
you,
then
feel
free
to
carry
it
but
being
able
to
say
no
as
a
maintainer
is
so
important.
E
C
C
C
C
It's
a
challenge
for
everybody
right
that
some
projects
kind
of
manage
to
be
in
the
right
place
in
the
right
time
to
attract
other
companies
that
put
a
lot
of
time
into
open
source
and
they
get
to
advance
quickly
and
then
the
rest
of
us
are
like.
We
have
to
make
this
happen
ourselves
and
that's
a
lot
harder.
G
C
Us
together,
having
one
of
those
during
kubecon,
wouldn't
be
a
bad
idea,
particularly
if
we
could
make
it
after
our
session,
because
we're
doing
by
the
way,
we're
doing
an
actual
session
in
the
program
on
project
paperwork
on
all
of
fulfilling
all
of
the
requirements
that
cncf
expects
in
terms
of
of
paperwork,
etcetera.
So.