►
From YouTube: CNCF SIG Contributor Strategy 2020-06-22
Description
CNCF SIG Contributor Strategy 2020-06-22
C
A
A
A
This
is
an
official
working
group
of
the
C&C
F
and
therefore
we
are
subject
to
the
CN
CF
code
of
conduct.
This
meeting
is
also
being
recorded,
so
don't
say
anything
that
you
wouldn't
want
your
mother-in-law
of
the
cloud
native
hacker
to
read
about
the
and
then
we
can
get
started.
We've
got
a
few
things
on
the
Genda,
but
not
a
huge
workload.
So
if
you
have
something
else,
please
add
it
and
we
could
have
just
lost
April.
So
hopefully
she
will
rejoin.
A
So
first
things
here,
most
of
our
activity
for
the
last
week
has
been
around
the
maintainer
diversity
requirement
as
its
called
for
graduated
projects.
So
this
is
a
requirement
for
graduated
projects,
that
is
in
the
CNC
F
graduation
document.
But
it's
there
is
kind
of
a
bear
sentence
that
just
says
the
project
must
have
committers
for
more
than
one
company.
A
That
has
an
example
of
the
kind
of
work
up
that
I'm
thinking
of
for
dealing
with
these
requirements
for
CID
contributor
strategy
in
the
governance
working
group
right,
which
is
the
idea,
is
to
give
projects
a
full
framework
for
understanding
the
requirement
and
how
to
fulfill
it,
and
part
of
that
has
involved
going
to
the
TOC
and
saying
okay.
This
is
your
requirement.
What
do
you
actually
mean
by
this?
What
is
it
you're
actually
looking
for,
because
I
mean
the
truth?
Is
we're
not
actually
looking
for
to
committers
from
different
companies?
A
A
But
the
to
us
answered
the
primary
requirement
was
that
they're
looking
to
demonstrate
that
the
project
is
open
to
contributions
regardless
of
employer
and
well.
There
are
other
ways
that
that
could
be
true
I
having
maintained
errs
that
don't
work
for
the
same
employer
is
the
most
material
demonstration
of
that
idea.
E
A
A
A
Now,
one
of
the
things
that
this
is
also
suggested
and
has
come
up
in
a
discussion
with
the
linker
D
project
is
that
backing
this
rationale
we
might
be,
you
know,
would
be
suggesting
that
it's
possible
to
make
a
case
for
a
project
to
demonstrate
their
openness
to
contributions
in
other
ways.
A
It's
just
that
it
would
be
much
harder
to
do
it
in
other
ways.
Right
if
you've
got
maintainer
x'
from
multiple
companies,
then
we
don't
really
need
to
look
at
anything
else.
But
if
you
don't,
then
we
need
to
look
at
okay,
how
many
real
contributions
came
in
from
outside
your
company?
How
were
they
approved?
What's
the
published
approval
process,
all
these
are
the
things
to
demonstrate
that
you're
still
open
the
that
has
not
been
approved
by
the
TOC.
A
C
I
don't
want
to
push
governance
on
folks,
but
the
accessibility
to
that
infrastructure
isn't
exactly
easy
at
because
the
kubernetes
community
has
its
own
infra,
kate's
infer
working
group,
not
the
side
rail
too
much,
but
where
I'm
working
with
some
folks
on
possibly
some
like
at
CN
CF
in
for
a
working
group
because
of
the
conformance
work
we're
doing
so
that
some
of
our
tooling
can
be
there.
You
know
that's
just
as
a
side
note
on
another
possible
metric
yeah.
A
Yeah
I
think
it's
a
good
idea,
I
mean
so
part
of
our
job
as
a
working
group
is
going
to
be
to
write
up
a
bunch
of
advice
to
projects
for
hey.
Here's,
how
you
do
these
things
and
I
think
writing
up
the
owners
file
structure,
and
you
know
how
this
is
a
good
way
to
sort
of
distribute
ownership
of
code.
Instead
of
saying,
hey
we're
going
to
have
this
one
owners
file
in
the
root
of
our
main
repo
and
that's
going
to
control
everything
I
think
it's
a
great
idea.
I.
C
A
A
A
Although
I
think
it's
worth
noting
that
the
one
person
posting
the
most
on
that
thread
is
not
on
the
current
two,
you
see
not
on
any
current
SIG's
and
not
actually
the
leader
of
any
current
CNC
of
projects
so
I'm,
just
just
for
a
sense
of
perspective.
That's
that's
Alexis!
He
was
on
the
first
TOC
that
we
had.
A
A
A
A
A
C
A
No
women
contributing
nobody
from
any
other
non-white
group
impossible
for
me
to
evaluate
obviously,
gender
presentation,
sexual
orientation
or
disability
just
based
off
with
people's
names,
but
with
the
projects
that
I've
been
working
with.
Let's
just
say,
if
we
were
going
across
the
board
with
ciencia
projects
and
doing
general
diversity,
scorecards
most
of
the
projects
would
be
getting
a
d-minus,
so
taking
it
on
is
going
to
mean
a
major
CNC.
If
a
wide
effort.
A
A
D
Variety
with
vendors
and
organizations
are
the
ones
that
have
either
community
managers
or
community
groups,
because
those
are
two
intentional
spaces
where
that
growth
can
happen,
and
it's
not
a
afterthought
and
I.
Think
that
is
the
difference.
I,
almost
wonder
if
we
should
put
a
graduation
requirement
that
you
have
someone
taking
care
of
you
and
not
just
as
someone,
but
people
and
I
think
that's
the
difference.
I
really
do
I
think
it's
the
who's
nurturing
who's
responsible
for
this
who
owns
this,
and
it's
not
just
a
like.
D
Oh
look
at
all
these
people
who
own
different
parts
of
the
code
base.
It's
who
actually
owns
the
operation
of
these
things,
who's
gonna,
like
you
know
and
it'll,
and
a
lot
of
their
cases.
What
you're
seeing
to
like,
even
with
max
like,
maybe
they
should
form
a
steering
committee.
It's
like
there
needs
to
be
some
kind
of
like
body
and
or
people
assigned
okay.
A
And
that
is
something
that
we
would
actually
approach
through
governance
requirements
for
that
matter,
because
one
of
their
parts
will
get
down
to
a
no
later
item.
Is
that
there's
a
requirement
that
the
project
have
governance,
yeah,
but
materially
all
that's
in
there
is
that
it
has
to
have
a
governance
WD
file
and
that
file
must
have
words
in
it.
Yeah
and
I
think
the
requirement
should
be
much
more
robust
and
I
think
the
idea
of
saying
hey
to
reach
the
graduated
level.
A
project
must
have
meta
management.
A
Right
must
have
something
beyond
just
code
management,
whether
that's
a
professional
community,
organizer
or
steering
committee
or
whatever.
We
could
totally
put
that
in
the
envy.
You
know
this
is
what
graduated
governance
looks.
Like
I
mean
we
might
get
pushback
on
that,
but
it
won't
happen
if
we
don't
ask
for
it.
C
D
A
A
A
A
A
So-
and
this
has
been
a
material
question
for
several
projects
that
are
currently
trying
to
get
any
incubation
where
they
have
a
bunch
of
adoption,
but
it's
among
companies
that
are
cloud
vendors
in
some
way,
even
if
they
don't
contribute
to
the
project
so
the,
and
that
includes
cloud
native,
build
packs
and
cloud
events.
Actually.
A
C
A
A
A
A
A
A
A
Started
writing
out
an
outline
and
I
haven't
gone
beyond
the
Google
Doc
stage
in
this,
because
I've
been
able
to
sync
up
with
April
on
it
or
anyone
else,
partly
because
of
other
things
going
on,
which
is
to
say,
okay,
the
main
product
of
this
working
group
is
going
to
be
honestly
a
bunch
of
documents.
A
Well,
documents
and
interactive
advice:
we've
already
started
on
the
interactive
advice
because
you
know
having
announced
contributor
strategy
projects
are
coming
to
us
and
some
of
them
have
governance
problems
and
they
end
up
here
the,
but
we
also
need
to
produce
a
whole
bunch
of
documents,
and
so
I
was
trying
to
construct
sort
of
an
outline
of
the
documents
where
we
need
to
produce.
What
is
our
checklist
of
documents?
We
need
to
produce
right
and
I
see
these
falling
into
two
areas
with
interlinking
between
them.
A
A
A
The
and
so
that's
you
know,
sort
of
what's
needed
and
documented,
like
hey
here's,
how
here's
some
suggested
steps
on
how
you
would
adopt
these.
You
know
here's
what
these
requirements
mean
and
here's
some
suggestion
steps
on
how
you
would
do
these
things,
one
of
the
things
that
doesn't
really
exist
at
all
now
that
the
TOC
is
interested
in
and
I
would
like
to
produce
as
basically
construct
these
sort
of
two
tiers
of
required
governance.
A
So
this
is
how
much
governance
we
expect
an
incubating
project
to
have
and
what
they
materially
need
to
have
to
fulfill
that
level
of
governance,
and
this
is
how
much
governance
we
expect
to
graduate
a
project
to
have,
and
this
is
what
they
need.
You
know:
here's
the
checklist
of
things
that
they
need
to
fulfill.
That
requirement.
A
A
You
know
like,
and
this
particular
set
of
advisory
documents
has
got
a
really
large
overlap
with
contributor
growth
to
the
point
where
I
think
we're
just
gonna.
It's
gonna
be
a
lot
easier
to
work
on
the
same
documents
and
Co
edit
them
because,
like
you
know,
I
say
from
a
governance
perspective,
you
have
to
have
a
document
outlining
who
is
a
contributor,
but
that
who
is
a
contributor
document
also
needs
to
have
a
bunch
of
contributor
growth
stuff
in
it
as
well.
Not
just
you
know
a
definition
of
here's,
the
requirements
for
being
a
contributor.
A
A
A
A
But
I'm
not
sure
about
that
I'm
also,
not
sure
about
where
I
kind
of
think
six
security
needs
to
be
in
charge
of
any
security
issue,
handling,
etc.
That
projects
have
there
actually
is
a
requirement
in
right
now
about
security
for
graduated
projects,
meeting
the
whatever
it
is
best
practices
guide,
which
is
another
Linux
Foundation
thing,
and
there
are
things
in
there
about
security
issue
handling
and
that
sort
of
thing,
but
again
we're
not
providing
project
with
any
advice
on
how
to
create
that.
C
To
make
sure
I'm
tying
things
together
correctly:
ja
I'm,
going
through
the
bullet
points
that
existed
when
when
I
started,
adding
notes
and
maintain
your
requirement,
30
and
doctoral,
and
then
I
started
editing
that
our
update
and
user
requirements,
but
I'm
unsure.
If
that
was
part
of
the
work
outline
for
what
your
documentation
link
further
know.
A
C
A
A
C
C
A
F
A
One
of
the
other
things
that
I
wanted
to
just
bring
up
for
this
committee,
though
we're
not
honestly
gonna,
do
a
lot
about
initially.
Is
that
currently
one
of
the
things
that
the
see
in
that
the
SIG's
and
the
TOC
consult?
Is
this
CN
CF
health
chart,
which
is
a
bunch
of
that's
based
off
of
a
dev
stats
model
that
Lucas
put
together
for
the
CNC
F?
A
It's
very
pretty,
but
it
is
very
hard
to
get
any
of
those
stats
to
correspond
to
any
kind
of
reality,
because,
like
I've
been
working
directly
with
a
couple
of
projects
that,
for
example,
are
having
trouble
with
the
maintain
or
diversity
requirement.
And
yet,
if
you
look
at
it
in
the
CN,
CF
stats
like
one
of
them
shows.
You
know
that
the
founding
company
is
only
responsible
for
55%
of
you
know
contributions.
A
A
You
know
that
that
aside,
one
of
the
other
things
that
Chris
a
has
requested
from
us
is
that
at
some
point
contributor
strategy
as
a
whole,
you
know
so
looking
at
the
various
areas
I
go
over,
that
health
chart
and
basically
suggest
what
we
really
should
be
looking
at,
because,
honestly,
that
chart
was
put
together
in
the
basis
of
you
know,
here's
two
dozen
statistics
that
we
can
easily
obtain.
B
C
Say
in
the
way
that
we're
looking
for
a
cadence
from
our
projects,
it
would
be
great
to
get
the
further
for
the
release
cycle.
It
might
be
good
to
get
a
health
update
rather
than
and
something
that's
curated
by
a
human
that
goes
through
and
checks
on
the
health
of
these
things
in
a
meaningful
way,
and
maybe
because
really
anything
like
it
wouldn't
I,
don't
know.
C
This
is
a
thought,
because
this
is
we're
talking
about
the
health
of
these,
and
then
we
say
we're
talking
about
the
you
know
the
graduation
criteria,
including
humans,
caring
for
the
humans
in
that
area.
It
would
might
be
good
for
a
human
to
check
in
on
the
health
of
those
communities
as
a
whole
and
give
a
report
on
these
are
the
things
we've
noticed
that
you
wouldn't
never
notice.
Unless
you
cared
yeah.
A
Currently,
by
the
way,
that
is
something
that
C&C
f
committees
and
staff
are
supposed
to
be
doing
for
projects.
Is
there
supposed
to
be
this
annual
review
process,
I'm,
not
clear
on
how
much
that
happens
in
reality,.
D
C
C
D
Now
it's
just
every
meeting
yeah
because
we
were
gonna
try
to
like
be
like
super
coy
and
be
like
oh
every
other
meeting
and
like
oh.
This
meeting
will
do
these
things
and
this
meeting
will
do
these
things
and
then
we
were
like
whatever
everybody
come.
If
you
need
help,
we'll
figure
it
out,
uh-huh,
so
yeah
I
know
every
I
want
I
want
I.
Would
love
for
these
meeting
every
Thursday
at
least
not
necessarily.
This
one
met
a
meeting
like
the
all
the
Thursday
meetings
for
contributor
strategy.
D
We
should
make
it
make
the
projects
feel
comfortable
to
come
to
us
or,
if
they
need
for
us
to
come
to
them.
We
should
also
have
that
as
a
service
cuz
like
I,
would
also
I'd
also
think
it's
cool
if
we
could
go
to
some
of
their
community
meetings
so
that
it
like
it
looks
like
we're
bridging
a
gap
and
not
necessarily
you
know,
people
have
to
come
to
the
principal's
office.
So,
like
that's
what
I've
been
telling
some
of
the
other
projects
too
like?
A
A
C
Josh
I,
like
your
idea
of
having
an
upcoming
thing
of
here's,
the
next
few
topics,
because
often
we
have
so
many
things
on
our
plate
in
community
stuff
that
having
a
deliverable
of
a
date
for
a
smaller
subset
of
things,
for
that
would
result
in
direct
benefit
to
the
community
on
a
rhythmic
basis.
I
think
would
almost
allow
a
continuous
release
valve
of
good
without
us
constantly
being
under
a
wave,
and
it
doesn't
take
all
of
us
to
do
that
thing.
We
can
alternate
out
on
who's
who's
the
release
valve
for
innovation
community.
C
D
D
It
was
like,
oh
so
it's
just
kind
of
like
you
know
my
personal
dreams,
but
anyway
we
can
still
make
something
work
and
make
it
wonderful.
I
don't
want
to
make
it
another
zoom
called.
Oh
that's
what
I'm
nervous
of
like
I,
wanted
to
make
people
feel
camaraderie
and
like,
and
you
know
something
meaningful,
not
necessary.
D
So
for
us,
from
our
sake,
we
really
like
the
first
thing
we
need
to
put
together
is
like
zoom
calls
and
not
not
to
me
is
like
just
that's
the
gut
kick
or
it's
like:
oh
yeah,
I'm
curating
it
a
yet
another
zoom
call,
but
no
maybe
it'll
be
different,
so
I'll
take
you
off
I'll,
take
line
and
we'll
talk
about
it
and
I'll.
Show
you
all
the
guys
and
that
we
have
so
far
I
would.
A
A
A
A
But
it
is
a
little
silly
that
I
am
currently
working
with
two
projects.
I
know
of
on
the
exact
same
problems
and
I'm
like
you,
two
should
be
on
a
call
together,
because
you
have
exactly.
C
C
A
It's
just
that.
There's
a
lot
of
chaos
right
that
we're
right
now
facing
this
giant
vat
of
chaos
and
and
it's
going
to
take
a
while
to
bat
to
rights,
but
I've
also
noticed
great.
You
know:
Timon
kubernetes
I've
noticed
how
quickly
something
that
you
introduce
as
a
you
know,
as
a
practice
to
solve
a
problem
becomes
institutional.