►
From YouTube: CNCF SIG Contributor Strategy 2020-08-25
Description
CNCF SIG Contributor Strategy 2020-08-25
B
A
C
A
A
Welcome
to
the
container
d
folks,
derek,
as
I
mentioned
on
our
last
call-
came
to
contributor
contributor
growth
working
group
and
was
just
kind
of
like
what's
this
about
and
we
talked
for
a
while
and
we
got
here
so
welcome.
Let
me
summarize
and
then
derek
what
I
want
to
do.
Actually,
let's
just
do
a
round
of
intros
because
we,
like
always
usually
know
each
other
in
this
group,
so
we
don't
do
intros
anymore,
but
I
think
that's
actually
important.
A
C
F
G
A
H
H
I
Hi
I'm
carolyn
vince.
Like
I
work
at
microsoft,
I
used
to
work
on
kubernetes
a
bit
now
I
work
in
the
broader
community
working
on
a
cnab
cloud
native
application,
bundles
and
importer,
which
was
just
submitted
to
cncf
and
I'm
here
mostly
because
I
usually
end
up
writing
and
doing
a
lot
of
the
contributor
growth
activities
on
any
project
I'm
on.
So
I
just
have
lots
of
opinions.
B
J
D
Hello,
a
maintainer
on
container
d
did
a
lot
of
the
original
work
with
lantau
on
the
cri
functionality.
That's
in
container
d
now
it'll
be
default,
plug-in
we're
integrating
it
into
continuity,
container
continuity
in
the
one
to
five
release.
I
worked
on
operating
systems
that
blue
screen
of
death
behind
sebastian.
I
did
some
work
on
that
as
an
ibm
right.
I
worked
on
os,
os2,
os3
and
nt.
The
original
version
so
you'll
find
my
name
down
in
that
deep
vowels
of
that
code.
A
Welcome
mike
all
right
thanks
everyone
for
doing
that,
we
never
really
do
that
because
it's
usually
just
us,
the
the
first,
the
first
half
of
that
crew.
So
the
summary
that
I
took
away
and
derek
I
want
you
to
actually
take
it
away
from
me-
is
y'all
want
some
help
with
contributor
growth
topics,
but
specifically
in
some
of
these
areas,
one
role,
identification
and
building
sounds
like
you
also
have
some
probably
roles
already
in
mind.
A
Maybe
even
have
you
know
have
built
off
that
from
the
last
time
we
talked,
and
then
also
community
management
strategy
and
goals,
to
maybe
help
the
help,
maintainers
out
figuring
out
how
to
actually
sustain
that
part
of
the
function
and
then,
ultimately
the
outreach
for
that
said
thing.
So,
whether
remember
we
talked
about
whether
or
not
it's
like
a
a
group
of
people
to
help
out
with
community
management,
a
person,
some
kind
of
like
strategy
and
or
goal
setting
there
did.
I
summarize
that
right.
B
Yeah,
I
think
that's
accurate.
I
think
in
the
past
container
d's
had
some
of
that,
but
as
people
have
kind
of
moved
on
and
as
even
the
maintainers
have
like
switched
to
different
companies
and
stuff
like
we
haven't,
had
like
a
full-time
community
manager
in
a
couple
years
and
yeah,
it's
kind
of
hard
to
like
keep
up
with
like
other
projects,
especially
as
a
graduated
project
like
keeping
the
same
level
of
visibility.
A
B
A
A
That's
fine
all
right
and
then
let's
go
into
a
little
bit
more
of
the
background
around
the
roles.
Do
you
and
because
I
can't
remember
from
the
conversation
that
we
had
before
do
you
currently
have
any
other
roles
identified
outside
of
like
the
standard,
whether
it's
maintainer
or
what
have
you
do?
You
have
any
tell
us
a
little
bit
about
the
roles
that
you
have.
B
The
reviewers
and
maintainers
are
the
more
active
roles,
so
the
the
difference
really
is
just
maintainers
are
almost
like
part
of
our
governance
process
in
terms
of
like
voting
on
issues
and
then
actually
like
with
write
access
for
doing
merges,
but
otherwise,
like
the
roles,
are
pretty
much
the
same.
So
like
it's
just
the
act,
the
active
part
is
just
reviewing
code
most
for
both
of
those
roles
but
yeah.
Those
are
the
only
rules
we
have
identified
today.
A
G
So
yeah
I'd
love
to
know
like
what's
working
or
what
isn't
working
today
it
sounds
like
you
have
some
new
roles.
How
long
have
you
had
the
roles?
Are
they
doing
what
you
intended
and
are
there
places
where
we
could
offload
or
where
you
could
offload
work
from
that's
classically
divine
in
one
of
those
roles
into
a
new
role.
B
I
mean,
I
think
my
goal
is
that
I
want
to
have
a
lot
more
reviewers,
so
we've
added
the
reviewer
role
for
about
a
year,
or
so
I
know
sebastian
may
know
better
about.
We
added
that,
but
we've
tried
to
grow
that
number,
because
that's
that's
really
like
what
allows
our
project
to
scale
in
terms
of
like
review,
and
especially
a
project
like
container
d,
something
that's
really
low
and
has
high
stability
requirements.
B
We
want,
as
many
people
kind
of
looking
at
each
of
those
pull
requests
as
possible,
even
for
the
small
things,
so
that
that's
one
of
the
things
that
I
I
think
we
could
do
better
at
and
the
other
is
just
like.
I
think,
kind
of
at
the
project
management
level,
and
just
so,
for
example,
like
there
was
some
issue
around
not
having
like
a
security
md
and
like
our
container
d
project.
B
Even
though
we
had
it's
like
a
github
requirement,
even
though
we
had
kind
of
listed
like
oh
here's,
how
you
list
things,
there
was
some
issue
where
somebody
was
trying
to
file
something
they
couldn't
find
it
and
cmcf
actually
kind
of
got
involved
and
said
like
hey.
You
need
to
have
this
like
specific
file
and
stuff
like
that,
and
as
maintainers
are
just
like.
Oh
okay,
sure
like
we
don't
know
like,
or
we
don't
really
care
too
much
like
how
stuff's
like
laid
out
from
like
a
like
a
github
perspective.
D
J
I
think
for
the
reviewers
part-
and
that's
something
I
see
in
many
repositories-
is
that
I
think
the
occasional
visitor
of
a
repository
considers
the
actual
mainstays
to
be
responsible
for
doing
the
reviewing,
and
I
think
in
general
it
is.
People
should
become
more
aware
that
basically
anyone
should
be
able
to
review
whatever
repository.
J
Know
I
I
guess
if
you
get
more
people
that
are
aware
of
that-
and
maybe
you
get
involved
into
in
that
you
can
also
pick
actual
reviewers
out
of
that
as
to
hey
this
person
is
a
great
reviewer.
I've
seen
a
couple
of
reviews
of
this
person
on
some
random
requests
and
I
trust
this
person
to
be
doing
actually
proper
review.
But
getting
that
message
out.
Maybe
one
thing
that
I
think
could
help
the
project.
I
D
D
Individual,
you
know
one-on-one
kind
of
efforts
to
try
to
get
people
to
review,
step
or
maintain
or
step.
We
also
have
what
I
don't
know.
If
derek
mentioned,
we
we
have
experimental
projects
that
are,
you
know,
non-core
projects.
You
know
sub
projects
that
are
extending
and
enhancing
community,
but
haven't
you
know,
been
brought
into
the
main
main
core
set
and
in
those
we
have
their
own
maintainers
they're
they're,
not
core
maintainers,
they're,
sub-project,
maintainers,
sort
of
like
kubernetes,
you
know
sigs,
and
then
you
know
for
a
type
stud
great
project.
G
So
so
a
few
questions
falling
out
of
that
to
to
kind
of
tag
onto
what
josh
was
saying.
Documentation
is
huge,
contributor
documentation.
If
people
things
are
a
lot
more
accessible.
If
people
are
given
explicit
instructions
on
how
to
do
them,
two
would
be
a
question
on
how
you
select
reviewers
in
the
first
place.
I
G
D
D
C
But
if
you
have
a
piece
of
documentation
that
says
here
is
how
you,
as
a
contributor,
can
do
a
review
that
clues
people
into
the
fact
that
they
can
do
a
review.
If
you
follow
me,
because
your
biggest
barrier
to
getting
more
reviewers
is
that
even
people
who
contribute
code
to
container
d,
don't
think
that
they
are
qualified
to
be
a
review.
B
Yep
yeah,
I
think,
having
more
documentation
around.
That
is
definitely
one
of
the
things
we're
looking
to
get
guidance
from
from
this
group,
especially
because,
like
I
mean
the
the
documentation,
we
know
works
for
the
people
who
are
involved,
but
we
don't
have
kind
of
a
good
sense.
All
the
time,
especially
like
trying
to
step
out
and
looking
at
that
from
the
outside,
like
we
know,
our
documentation
is
not
great,
but
we're
not
quite
sure
how
to
fix
it
on
both
like
a
process
and
like
a
technical
level.
A
Mike
was
the
culprit
on
that.
I
was
like
looking
at
everybody
that,
like
no
just
kidding,
I
feel
like
before,
like
before.
We
do
the
outreach
that
you
need
the
people
like.
We
should
have
at
least
some
of
the
skeleton
documentation
so
that,
like
while
we're
when
we're
doing
these
mega
outreach
efforts
that
say,
like
oh
container
d,
is
looking
for
new
reviewers
they'll
have
something
to
like
go
towards
and
be
guided
to
so
from
a
documentation
standpoint.
A
G
I
would
say,
depending
on
your
technique,
like
not
everyone
is
a
visual
learner
or
visual
teacher.
I
guess
so
even
before
doing
the
videos,
if
you
want
to
step
back
and
say
like
what
does
my
day,
look
like
right,
if
I'm
reviewing
a
pr
for
container
d,
if
I'm
like
doing
maintenance
work
right
like
what
does
that
look
like
do,
I
do
I
stare
at
the?
Do
I
stare
at
a
project
board
first
right,
do
I
do
some
github
queries
do
like
what's?
G
We
brought
on
a
program
manager
and
it's
something
that
we
have
been
sorely
lacking
to
say
it
nicely.
I
think
it's
it's
one
of
the
first
times
that
we've
done
a
explicitly
named
role
like
that
in
the
community,
and
so
lori
apple
has
been
just
jumping
everywhere
and
identifying
like
things
that
we
take.
You
know
like
we
make
assumptions
on.
We
make
huge
assumptions
on
and
it's
just
because
they're
part
of
our
day-to-day
workflow,
like
as
an
improver
or
as
a
as
a
sig
chair,
I'm
going
to
do
certain
things
right.
G
That
may
be
happening
in
the
background
like
if
it's,
if
it's
sorting
project
boards,
if
it's
adding
new
milestones,
if
it's
you
know,
pinging
this
person
via
dm
to
make
sure
that
they're
doing
x
right,
we
have
to
come
back
and
say
like.
Is
that
stuff
documented
right
and
it
and
it
may
feel
like
it's
it's
a
lot
of
the
work
that
could
be
done
by
other
people
is
assumed
to
work
right.
It's
work
that
you're
already
doing
it
isn't
written
down
anywhere.
B
Documented
yeah,
it
makes
sense
yeah
discussing
this
with
within
or
kind
of
within
the
maintainer
group
yeah,
it's
it's
it's.
It's
definitely
hard
like
getting
everybody
together,
especially
with
like
recently
with
like
time
stuff
like
but
yeah.
I
understand
there's
no
like
quick
recipe
for
some
of
these,
but
we
definitely
want
to
figure
out
like
a
good
place.
We
can.
We
can
start
and
make
some
early
progress.
A
C
Well,
one
of
the
things
it
sounds
like
is
a
major
need
is
that
you
need
to
attract
some
volunteer
contributor
management
advocacy,
whatever
contributors
that
is.
These
are
things
that
used
to
be
done
by
paid
staff
from
some
company
or
another
they're
no
longer
done
by
paid
staff,
and
and
now
you
need
to
figure
out
how
to
get
somebody
to
volunteer
to
do
it.
B
Yeah
yeah
kind
of
we
we
don't
necessarily
need
people
coming
in,
just
contributing
a
bunch
of
code.
I
mean,
or
at
least
like
code
contributions
and
code
review,
should
scale
but
like
yeah
right
now,
I
think
one
of
the
biggest
lacks
is
yeah,
not
necessarily
those
code
contributions,
but
those
other
forms
of
like
the
technical
contributions
and
helping
with
the
process
and
stuff.
I
think
that's
right.
C
L
L
Oh
no,
no
problem
at
all,
but
just
kind
of
I
I
think
this
may
fit
here.
But
you
know,
container
d
is
an
interesting
project
because
there
I
feel
like
there
aren't
as
many
people
all
that
interested
in
contributing,
but
who
love
to
play
around
with
it
as
an
api
driven
container
runtime.
And
so
I
you
know,
even
our
user
base
is
like
kind
of
fragmented
as
a
negative
word,
but
I
don't
mean
it
that
way.
L
But
you
know
there
are
a
ton
of
people
who
just
use
container
d,
because
it's
a
cri
pluggable
runtime
and
they
really
don't
care
it
works.
It
does
what
it's
supposed
to
do,
but
then
there's
a
bunch
of
people
who
end
up
in
the
container
d
slack
channel
who
are
trying
to
build
some
crazy
tool
and
doing
really
cool
things.
L
Those
seem
like
the
people.
If
we
have
the
time
or
energy,
you
know
they're
kind
of
playing
in
the
code
so
to
speak,
but
yeah.
That's
what
I've
been
trying
to
think
about
and
again
you
know
most
of
us
are
not
well.
I
can't
speak
for
all
the
maintainers,
but
most
of
us
have
you
know,
day
jobs
that
aren't
100
driven
to
let's
make
container
d
a
better
community.
So
I
don't
know
that's
an
area.
I'd
love
to
investigate.
L
A
I
think
on
building
some
kind
of
outreach
group
for
you
all,
it
should
probably
be
like
a
priority
whether
it's
outreach,
whether
it's
like
contributor
experience
and
it
doesn't
need
to
be.
You
know,
20
people,
you
know
it
could
be
a
handful.
It
even
could
be.
You
know
some
of
your
maintainers
who
also
already
do
this
stuff
to
like
bootstrap
it,
but
like
josh,
is
saying
I
feel
like
putting
a
putting
a
call
out
and
explicitly
saying
this
stuff.
A
You
should
explicitly
say
this
stuff
say
we're
looking
to
grow
the
community
in
this
way,
like
we
help
with
the
following
things,
and
just
be
very
explicit
about
your
intentions
right
and
see
what
happens?
I
think
building
that
out,
though,
like
whether
it's
like
I
said
a
community
manager
would
be
super
helpful,
and
I
can
give
you
some
like
pros
and
cons.
I
can
like
do
a
doc
for
you
with
some
pros
and
cons
of
kind
of
like
each
group
versus
like
person
and
kind
of
go
from
there.
B
All
right,
yeah,
that
sounds
good,
I
mean
we've
been,
we
have
a
zoom
channel,
we've
been
looking
to
utilize
it
to
start
something
regularly,
but
I
can,
I
think,
what
you
said
by
having
something
that's
explicit,
around
saying:
hey
we're
trying
to
grow
the
community
in
this
way
we're
having
a
meeting.
That's
specifically
about
this,
might
invite
the
right
people
to
come.
I
mean
maybe
nobody
shows
up.
Maybe
people
do.
A
G
And
I
would
I
would
say
you
said
you
don't
have
a
mailing
list.
I
would.
I
would
create
one
asap
just
for
the
sake
of
like
if
you
can't
schedule
a
meeting
yet
because
because
your
schedules
don't
allow
it
at
least
you
can
start
having
that
asynchronous
conversation
with
people
and
start
generating
ideas
for
what
might
be
in
those
meetings.
So.
A
A
B
Yeah
we've
been
having
a
discussion
about
setting
up
a
mailing
list,
we're
in
the
midst
of
a
few
different
things
on
on
that
realm,
but
yeah.
What
we're
trying
to
figure
out
kind
of
at
the
higher
level
is
yeah
how
we
schedule
these
meetings
and
how
we
get
the
word
out.
The
problem
with
like
mailing
lists
is
they're
they're
kind
of
hard
to
bootstrap.
C
B
B
I
You
may
want
to
take
advantage
of
a
couple
different
places
where
existing
users
are
and
be
shameless
about
mentioning
the
mailing
list
and
do
two
things.
One
repeat
yourself
so,
like
don't
just
mention
the
million
list
once
because
people
mute
slack,
you
know
what
I
mean.
They
don't
check
twitter
for
three
months,
because
twitter
sucks
right
now.
So,
like
repeat
yourself,
every
time
you
do
release
go,
hey,
here's
a
mailing
list
or
every
time
you
know
every
so
often
in
slack
just
go.
Are
you
tired
of
like
slack
being
super
noisy?
I
Do
you
want
something
like
traffic,
we're
just
gonna,
announce,
releases,
interesting
features
or
blog
posts
or
whatever,
and
then
the
other
piece
of
it
is
say.
What's
going
to
be
talked
about
on
the
mailing
list,
like
what
you're
going
to
type
of
topics
or
things
you're
going
to
be
pushing,
so
people
have
a
reason
to
sign
up
for
it.
I
So
they
understand
why
they'd
like
to
and
try
to
give
them
a
little
push
to
go
over
there,
because,
like
a
lot
of
people
like
they
sign
up
for
your
slack
channel,
but
then
like
80
of
them,
mute
it
things
like
that
so
like
right
there.
That
may
be
like
that's
why
I
think
we
got
like
everyone
to
sign
up
for
the
mailing
list.
I
G
B
Yeah
I
mean
I'm
not
I'm,
definitely
not
against
the
mega
calendar.
It's
it's
really
good
for
like
discovering
like
new
events
and
stuff,
but
I
wasn't
sure
if
there
was
any
for
if
other
projects
were
doing
a
different
method
or
if
there
had
issues
like
just
getting
getting
people
to
either
subscribe
to
the
mega
calendar.
Just
for
one
event
or
an
approach
like
that.
G
So
yeah
calendar
wise
tongue.
You
know
it
depends
on
what
it
is
if
it's,
if
it's
something
that
I'm
actively
contributing
to,
I'm
probably
going
to
be
on,
like
the
mini
calendar
of
the
individual
group
right,
but
like
knowing
that
oh
container
d
is
having
a
discussion
about
this
thing
today.
Maybe
I
want
to
drop
in
right
and
having
that
information
kind
of
at
hand.
G
Another
thing
I
would
say
about
the
the
project
phases
right
is
that,
as
you
know,
you
know
for
kubernetes
at
least
right
a
lot
of
a
lot
of
the
documentation
that
gets
generated
across
many
of
the
cncf
projects.
You
know
they
use
kubernetes
as
a
template.
I
would
say
that,
as
a
graduated
project,
people
are
also
going
to
be
looking
at
you
as
as
a
potential
template
for
their
processes.
So
I
would
say
to
you
know
one
of
the.
G
I
guess
one
of
the
gentle
asks
would
be
like
think,
deeply
about
your
processes
right
because
you
didn't
just
get
to
a
graduated
state
for
nothing
right.
You
worked
at
it
over
several
years,
so
there
are
lots
of
good
things
in
your
process
that
maybe
they
just
aren't
documented
right,
maybe
like
it
just
works
so
well
between
the
maintainers
that
you
have
that
it's
taken
to
be
assumed
right
and
that's
something
that
could
help
a
sandbox
project,
an
incubating
project.
So
take
some
time
to
think
about
that
stuff.
C
C
What
you're
really
looking
for
in
terms
of
like
a
volunteer
community
manager,
whatever
you're
honestly
looking
for
one
or
two
people
right
you're,
not
going
to
get
a
whole
bureau,
because
you
never
do
for
that
kind
of
a
project.
But
if
you
have
one
or
two
people
who
really
cares
about
that
and
has
some
time
they
can
put
in
and
put
in
their
20
time,
then
that
will
also
probably
be
good
enough.
B
Yeah,
I
agree,
I
think
we
consider
kind
of
cncf
as
kind
of
that
bureau
or
like
that
yeah
larger
body
associated
but
yeah.
The
number
of
like
people
involved
like
is
smaller,
and
I
think
that's
it.
That's
why
yeah
we're
going
to
cncf
to
say
or
to
ask
for
help
and
like
generating
these
rules
or
in
some
cases,
like
just
advice
for
like
documentation
and
stuff
we're
almost
stuff
that
could
be
funded
as
well.
If
we
need
to.
C
Yeah
documentation,
I
think
you
might
be
able
to
get
some
direct
help
with
because
they
have
staff
and
a
contractor
network.
But
one
of
the
things
that
I
honestly
think
you
need
to
do
is
that
I,
honestly
that
you
are
going
to
need,
is
somebody
who
can
be
your
interface
for
cncf,
as
in
cncf
as
a
bunch
of
people
and
from
staff
they're
good
about
fulfilling
specific
requests.
You
know
I
need
an
x,
but
somebody
needs
to
write
up
that.
I
need
an
x.
C
B
Yeah
yeah,
we
we
had
a
little
bit
of
an
exercise
for
that
earlier
in
the
year
and,
unfortunately,
it
fell
through,
but
yeah
we
had
somebody
who
was
interested
in
doing
some
documentation
but
as
contract
work,
but
submitted
something
through
the
service
desk
and
basically
like
the
task
was
work
with
the
work
with
the
individual
to
come
up
with
a
very
specific
contract,
which
you
know
it's
kind
of
out
of
my
expertise.
In
terms
of
like
I
don't
I
don't
know
what,
like
this
sort
of
like
work.
B
B
F
So
I'm
going
to
drop
in
and
actually
give
a
a
future
attraction
in
here,
one
of
the
things
yeah.
Sorry
I
joined
leighton.
You
know
hello,
surprise,
one
of
the
things
that
I'll
be
working
on
with
the
tech
writer
team
is
starting
an
a
meeting,
that's
available
for
projects
to
be
able
to
come
in
and
join
and
talk
with
the
tech,
writers
and
kind
of
get
a
sense
about
like
if
we
were
to
be
able
to
have
a
structure.
F
I
mean
it
was
perfect,
though
no
I
mean
it
is
perfect
because,
like
this
came
to
me
like
monday,
and
I've
been
working
with
the
team
like
through,
like
I
mean
it's
only
thursday
here
but
being
able
to
like
track
towards
man.
If
we
were
to
be
able
to
have
a
touch
point
with
some
of
our
tech
writers,
we
would
have
a
better
sense
of
what
the
projects
need
and
what
the
tech
writers
are
actually
here
for
man,
wouldn't
that
be
cool.
G
Yeah,
I
think
the
the
frustrating
thing
about
that
that
interconnect
is
that
a
lot
of
the
times
having
having
to
write
the
documentation
is
one
thing
and,
and
potentially
farming
it
out
is
another.
But
like
a
lot
of
the
times,
you
are
the
person
in
the
best
position
to
write
the
documentation
or
like
dump
things
out
of
your
head
and
yeah.
Someone
without
context
on
the
project
is,
is
not
going
to
be
able
to
do
the
the
same
level
of
depth
as
you
will
so
yeah.
G
I
that
that
can
be
a
frustrating
time
when
you
have
to
sit
down
and
do
documentation,
especially
if
you
hand
the
task
off,
because
this
has
happened
several
times
to
me
recently.
If
you
hand
the
task
off,
and
it's
not
clearly
defined
and
someone
who
is
not
familiar
with
the
area
starts
doing
the
documentation.
F
F
B
So
like
we've
had
people
go
through
this
experience
and
say,
like
oh,
like
I
got
container
d
to
work,
but
it
was
way
harder
than
I
wanted
it
to
be,
and
you
know
I
wrote
this
documentation
for
like
here
were
all
my
frustrations
and
stuff,
and
you
know
like
when
a
tech
writer
does
that
exercise.
You
know
it
tends
to
produce
really
good
results
as
well
as
show
us
where
we
need
kind
of
that
that
deeper
technical,
like
the
design
and
architecture
stuff
like
that
kind
of
stuff
yeah.
B
I
would
definitely
expect
the
maintainers
to
to
do,
but
in
terms
of
like
those
documentations
like
getting
started
and
stuff
like
that,
like
the
maintainers
aren't
the
best
people
to
do
that,
because
we're
not
getting
started
and
we
don't
have
a
good
perspective
so
like
yeah
having
technical
writers
go
through
getting
started
and
be
like.
This
is
what
sucks
about
your
documentation.
This
is
what
like
I
couldn't
find
anywhere
like
yeah.
I
think
as
maintainers.
We're
definitely
realize
that's
on
us
to
like
go
and
fix
that.
C
G
Yeah,
I
think
I
think
part
of
that
is
is,
is
information,
architecture
right,
making
sure
that
the
stuff
that
you
need
is
actually
in
the
right
place.
So
like
what's
cool
about
that,
repo
is
like
one.
It
gives
you
a
very
clear
disclaimer.
I
think
a
lot
of
people
use
use
it
as
as
law
and
they're
like.
Why
couldn't
I
do
x,
and
it
gives
you
a
very
clear
disclaimer
that
it's
not
something
that's
supposed
to
be
done
for
production
usage
right.
G
My
first
step
is
not
to
the
website.
My
first
step
is
to
like
the
community
repo
right,
which
is
a
totally
different,
ingress
point
right,
and
you
may
not
know
about
that
until
you
hit
the
website,
but
it
from
the
website.
Is
there
a
clear
way
to
get
to
the
community
repo
and
like
so,
you
start
thinking
about
like
how
people
move
through
your
process,
and
you
know
for
like
sig
release.
G
Sig
release
has
its
own
repo
for
documentation
right
that,
like
we
lead
you
from
the
community
rebo
into
our
repo
right,
because
we
know
that
everyone
who's
focused
and
our
maintainers
reviewers
approvers
on
that
content
are
gonna,
be
living
in
that
repo
anyway
right.
So,
like
it's
yeah,
I
would
say
think
about
the
experience.
Think
about
the
maintainers
experience
too.
There
are
some
things
that
probably
frustrate
you
about
your
process
day-to-day.
Those
are.
Those
are
things
to
start
writing
down
to.
G
B
C
G
G
C
G
It's
yeah.
I
know
I
mean
it's,
it's
masochism
right
like
there's
something
that
I
really
really
love
about,
the
the
I
I
don't
know
it's
it's
beyond
the
technical.
I
think
that
we're
you
know
we're
starting
to
really
get
deep
into
some
real
process
problems
that
have
existed
for
a
few
years
that
are
related
to
tooling
as
well
and
starting
to
like
fix
them.
G
So
it's
steady
as
she
goes
for
a
little
bit
on
on
that
end,
I'm
like
I'm
hoping
to
kill
lenago
by
1
20
by
the
end
of
120.,
but
I
think
what
I
love
most
about
it
is
that
they're,
it's
just
like
where
you
see
a
lot
of
contributors
start
like
they
get
tossed
into
the
fire
of
the
release
team
and
then
you're
like
now.
Go
free
and
go
do
this
thing
over
here
that
relates
to
it
and
seeing
that
happen,
every
cycle
is
just.
H
M
C
C
G
C
C
C
There's
no
ability
to
break
it
down
into
different
segments,
the
so
the
and
and
the
reason
why
it's
not
there
is
it's
not.
It
was
not
considered
a
useful
graph
for
kubernetes
for
various
reasons
and
the
because,
mostly
because
honestly,
we're
not
in
kubernetes
we're
not
worried
about
tracking
our
overall
number
of
contributions,
because
it's.
C
Right
and
so
most
of
the
cncf
project,
dashboards
were
just
covered
copied
as
a
subset
of
the
kubernetes
dashboard,
and
I
think
here
we're
seeing
one
area
where
that
is
not
the
correct
path.
Gotcha,
but
I
want
everybody.
This
touches,
including
dawn
and
lori,
and
carolyn
to
actually
sign
off
in
the
definition
before
lucas.
Does
any
work
on
it,
since
what
I
don't
want
to
do
is
create
a
chart
and
then
have
him,
delete
it
and
create
another
chart.
G
G
I
C
C
G
H
G
H
F
C
So
yeah
I
mean,
I
guess,
there's
two
different.
There's
two
different
issues.
Number
one
is:
should
the
cncf
recommend
that
all
projects
have
a
steering
committee?
That's
question
number
one
and
the
question
number
two
is
if
a
project
does
not
have
sufficiently
varied.
Maintainers
is
having
a
varied
steering
committee
sufficient
to
meet
graduation
requirements.
G
I
G
The
earlier
discussion
with
with
container
d
you're,
saying
like
this,
is
a
graduated
project
right
and
with
a
lot
of
potential
that
are
concerned
about
overall
project
health
right
and-
and
it
sounds
like
part
of
that
path-
is
building
building
reviewers
building
approvers,
it's
the
same
problem.
We
have
in
kubernetes
right
building
continuing
to
build
those
those
people
across
the
ladder.
That's
what
would
seed
the
discussion
for
a
steering
committee
in
one
of
those
projects.
I
don't
see
like,
I
think
it's
like.
Is
it
a
good
idea?
G
H
I
I
also
like
the
istio
steering
model
was
done
for
a
specific
reason.
Yeah,
I
wrote
it
it
is.
It
was
designed
for
so
this
will
always
be
my
baby.
It's
designed,
for
you
know
the
to
reflect
the
fact
that
there
were
going
to
be
these
corporate.
You
know
companies
that
they're
contributing
devs
and
here's
a
spot
to
ensure
that
those
folks
will
always
have
a
say
in
like
marketing
and
the
administrative
ops
kind
of
stuff.
H
So
I
don't
see
that
being
a
solution
to
the
diversity
maintainer
issue,
like
that's
to
me,
that
I
don't
think
that
a
project
that
had
that
kind
of
a
steering
model
would
somehow
pass
graduation
if
it
still
was
just
one
maintainer
company,
because
those
folks
that
are
on
steering,
for
instance,
I
was
on
istio
steering
when
I
worked
on
the
project,
would
I
be
able
to
keep
the
project
going
if
every
other
maintainer
decided
to
like
move
to
an
island?
No.
C
Yeah
yeah.
That
makes
because
because
our
attitude
was,
if
the
maintainers
all
work
for
a
single
organization,
it
doesn't
matter
who
the
steering
committee
works
for
yeah
and
and
it
would
make
it
harder
for
the
cncftoc
to
understand
what
was
going
on
with
the
project
the.
So
you
know
and
and
I'll
admit,
that
I
have
a
significant
amount
of
impatience
with
him
specifically
because
we
invited
him
to
discuss
it
and
he
was
not
into
discussing
it.
G
I
G
And
I
was,
you
know,
you
know
kind
of
kind
of
getting
ready
to
pop
the
popcorn
when
I
saw
the
istio
steering
committee
subject
line
says
like
I
need
to
read
this
later
and
but
overall
I
think
it.
It
is
a
discussion
that
should
should
happen
here
right
if
it's,
if
it's
governance,
that's
cool.
If
it's,
if
it's
us
making
a
recommendation,
it
should
eventually
make
its
way
to
this
meeting
or
to
some
recommendation
on
our.
C
If
you
look
at
the,
if
you
look
at
the
leadership
document
that
we
have,
there
dawn
wrote
in
her
own
words,
recommendations
around
steering
committees.
You
know
mostly
it's
that
it's
appropriate
for
some
projects
to
have
a
steering
committee
and
here's
you
how
you
know
in
a
very
short
version
of
here's,
how
you
would
go
about
getting
one
that
yeah.
G
Right-
and
I
think
that
you
know
if
we
haven't
done
it
already-
we
need
to
make
very
clear
that
our
our
discussions
and
recommendations
that
we
make
are
exactly
that
recommendations.
This
is
something
that
we're
you
know
we
run
into
in.
We
like
we
want
to
help,
but
we
don't
want
to
be
on
the
hook.
I
guess
for
a
failure
of
one
of
those
recommendations.
Necessarily
so
it's
it's
something
similar
that's
happening
with.
You
know.
G
Now,
how
do
we
execute
that
recommendation
across
the
project
right
as
opposed
to
well,
this
body
of
four
people
decided
that
we
were
going
to
change
all
the
language
in
the
project
and
what's
going
on
with
that
right,
because
we
get
a
few
questions
like
that,
and
we
have
to
make
it
very
clear,
like
we
are
making
recommendations
that
that
eventually
will
hopefully
get
approved
by
by
higher
body
right.
So
I
want
to
make
sure
that
we
have
a
bit
of
like
a
lever
to
step
back
from
a
recommendation.
C
N
G
Going
to
keep
it
in
this
little
subdirectory
that
we
have,
but,
like
my
personal
feeling,
is
that
it
lives
alongside
the
style
guide
right
here.
Something
contributor
guide
documentation.
So
it's
very
clear
that
it's
like
okay,
this
is
a
recommendation
that
has
turned
into
law
or
something
or
the
general
suggestion
for
the
project.
So
yeah,
that's
it's!
It's
tricky
it's
tricky,
but
I
also
want
to
make
sure
like
it's
not
entirely
on
our
heads
once
we
make
certain
recommendations.