►
From YouTube: CNCF SIG Contributor Strategy Governance WG 2020-09-01
Description
CNCF SIG Contributor Strategy Governance WG 2020-09-01
A
B
C
A
A
A
A
A
So
please
I
please
behave
as
you
would
with
your
more
civilized
relatives
and-
and
we
can
have
a
good
discussion
about
things
and,
like
I
said,
do
put
your
name
down
on
the
notes.
If
you
are
here
attending,
because
I
see
seven
people
here
and
only
two
people
only
two
names
on
the
thing
this
morning,
we
only
have
two
things
on
the
agenda.
A
A
But
beyond
that,
we'll
go
over
that
I
wouldn't
mind
taking
some
time
to
discuss
that
because
our
second
item,
unless
somebody's
going
to
add
something
to
the
agenda.
Our
second
item
is
to
actually
get
all
of
our
documents
currently
in
draft
which
are
all
advisory
documents,
merged
they've,
been
sort
of
hanging
out
as
prs
for
an
inordinately
long
time,
but
half
of
those
drafts
were
primarily
authored
by
dawn
and
she
has
told
me
she's
going
to
be
joining
us
late.
A
A
A
A
A
A
A
In
the
end,
we
recommended
against
the
proposal
on
the
basis
that
a
project
that
has
reached
the
the
point
of
proposing
to
be
graduated
and
has
not
attracted
a
single
main
maintainer
from
outside
the
primary
participating
organization
has
issues
that
cannot
be
resolved
by
a
steering
committee
and
and
while
steering
committees
can
be
great
for
projects.
For
other
reasons,
they
are
not
effective.
A
A
Also,
it's
not
actually
on
the
agenda
because
it
was
proposed
by
someone
who's,
not
a
toc
member,
so
they're
not
actually
required
to
vote
on
it.
So
I
the
status
is
pending.
I
guess
hence
it
coming
up
in
the
toc
again
and
since
this
is
the
governance
working
group,
we
wanted
to
provide
an
opportunity
to
discuss
this,
particularly
with
new
people
who
did
not
attend
the
previous
meeting.
A
You
know
evolving
the
governance
requirements
the
so
one
of
the
other
things
that
came
out
of
it
was
that
we
would
prepare
a
document
that
included
advice
on
establishing
a
steering
committee.
If
you
want
one
which
is
currently
in
draft,
it's
one
of
the
things
in
the
second
half
of
this
agenda
to
try
to
get
merged.
A
A
A
So
feedback,
and
for
that
matter
we
have
two
people
here
from
nats
and
I
would
be
very
interested
in
hearing
from
them,
since
they
have
not
spoken
up
in
the
toc
discussion
if
they
feel
that
there's
a
path
specifically
for
gnats,
so
not
necessarily
a
general
path
for
all
cnc
projects,
but
a
path
specifically
for
gnats.
That
involves
the
steering
committee
as
a
way
of
dealing
with
some
of
the
the
governance.
Wonkiness.
A
D
D
D
Yeah
sure
yeah
I
mean
as
a
whole
we
and
the
nazi
team.
We
have
a
lot
of
you
know
many
many
different
companies
contributing
the
repositories
for
our
servers
are,
admittedly,
various
nadia
heavy,
and
that's
because
you
know
it's
not
a
weekend
project
for
somebody.
It's
it's
a
very,
very
strong
investment
in
time
to
actually
get
something
running
in
the
server.
It's
very
complex,
highly
performant-
and
you
know
I've
had
my
own
prs
rejected
because
they
didn't
come
to
par.
D
So
in
that
we've
been
working
with
the
community
in
in
taking
their
input
and
we
can
deliver
their
features
with
much
more
efficacy,
which
is
better
for
the
community,
so
in
in
terms
of
project
health.
If
you
have
you
know
again,
if
you
have
a
project
that
spans
many
many
repositories
and
overall
it's
very
has
a
lot
of
maintainer
diversity
in
terms
of
companies.
A
D
Okay
in
wow
yeah,
well,
the
question
I'm
asking
is
in
terms
of
governance:
if
you
have
a
project
with
many
repositories
and
diverse
company
contributions
there,
but
a
few
core
repositories
that
tend
to
be
company
heavy.
Where
does
that
stand
in
terms
of
health?
You
know
in
your
in
your
opinion
and
then
in
terms
of
governance
around
to
you
know,
based
on
that,
where
do
you
go
in
terms
of
governance?
What's
your
recommendation.
F
F
So
it
ties
all
back
to
that
original
question.
We're
trying
to
solve,
like
this
diversity
issue
and
the
steering
you
know,
was
proposed
as
like
a
way
to
maybe
have
a
at
least
my
understanding
was
to
have
like
an
overall
governing
body
that
could
kind
of
represent
the
project
overall,
instead
of
again
for
grpc
like
the
swift
repo,
obviously
the
apple
devs,
that's
theirs.
F
I
hope
I
did
did
you
write
by
that,
but
I
think,
like
that's
at
least
my
kind
of
you
know
the
thing
that
I
I
know
we've
dealt
with
this
with
grpc
is
like
we
keep
coming
back
to
that
same
question
of
like
it's,
this
mysterious
thing
of
like
what?
What
kind
of
diversity
are
we
looking
for
when
we
say
the
diversity
requirement,
because,
like
even
you,
josh
mentioned,
you
know
having
a
project
that
didn't
have.
F
I
think
that's
what
the
steering
idea
came
from
was
that
it
was
a
way
to
address
some
of
those
diversity
concerns
without
having
to
say,
for
example,
you
know
you
have
to
have
10
different
maintainers
on
like
the
core
infrastructure
of
a
project
when
you
may
not
actually
have
you
know
that
many
other
people
that
want
to
do
it.
So
I
think
that's
what
that's,
how
I've
interpreted
things
up
until
now
with
regards
to
like
what
the
steering
committee
idea,
so
I
think
that
does
tie
into
like
you
were
saying
josh
like
not.
F
I
know
from
the
grpc
perspective,
I'm
totally
cool
with
the
idea
of
a
steering
committee,
and
you
know
so,
has
everybody
else
been,
but
it
doesn't
sound
like
that's
gonna
be
enough
to
solve
the
toc
diversity
issue.
So
again,
it's
just
kind
of
like
all
right.
What
I
feel
like
we
still
haven't
had
that
defined.
A
F
F
I
agree
with
you
completely,
I
just
that's.
That
was
my
understanding
of
what
kind
of
like
when
alexis
was
proposing
the
steering
idea.
That's
how
I
understood
it
was
like
you
know:
hey
here's,
a
relatively
easy
way
to
say,
like
we've
got
a
lot
of
representation
from
other
orgs,
but
you
don't
have
to
necessarily
you
know.
Each
project
has
its
own
requirements
for
how
you
become
a
maintainer
but
yeah.
F
That
was
that
was
how
I
understood
it
and,
like
I
said
it
might
work
fine
for
grpc
and
nets,
but
to
your
point
it
doesn't
solve
the
issue
for
any
other
project.
Although
I
don't
know
of
any
other
project.
That's
had
this
issue.
Are
we
aware
of
any
other
cncf
projects
that
have
had
similar
issues
trying
to
graduate.
E
A
Did
they
graduate
they've
been
proposed
for
graduation,
and
I
believe
that
they
have
you
know
they've
got
like
I
don't
know
eight
or
nine
maintainers,
two
of
whom
don't
work
for
the
main
company.
So
that's
why
I
keep
saying
you
know
one.
You
know,
that's
why
I
keep
saying
these
low
numbers
is
that
the
actual
written
requirement
for
the
toc
is
not
substantial?
It's
not
a
majority
of
maintainers.
A
C
A
F
F
H
So
I'm
just
going
to
say:
okay,
not
just
as
that's
maintenance.
My
first
time
at
this
welcome
yeah.
Thank
you
so
yeah.
It
has
been
interesting
to
follow
the
discussion
so
yeah.
My
name
is
wally.
I've
been
involved
in
the
nuts
project
actually
for
around
seven
years
now,
even
before
scientia,
and
before
this
other
upset
I
could
use
to
maintain
as
well,
but
so
yeah.
H
It
has
been
out
there
for
a
while
and
so
hearing
committee
proposal
when
it
came
up,
is
that
it
puts
back
some
of
the
into
the
spotlights
of
the
use,
the
end
users
and
what
they
need
instead
of
like
the
livelihood
of
the
maintainers.
So
I
mean
as
and
that's
as
an
axe
maintainer.
You
do
one
like
the
best
for
your
project,
but
we
also
want
to
graduate
how
to
bring
away
like
without
like
it
costing
us
everything
you
know
and
right
now
it
depends.
B
Well,
maybe
you
could
implement
a
practice,
that's
kind
of,
or
you
could
implement
a
structure,
that's
kind
of
like
this,
but
it
doesn't
necessarily
translate
into
how
how
that
that
will
turn
into
the
overall
conditions
that
we
want
to
cultivate.
I
think
it's
it's
like
for
me.
It
kind
of
gets
lost
in
translation,
exactly
what
are
we
trying
to
achieve?
What's
the?
What
are
the
outcomes
right
we
want.
B
We
want
people
to
to
feel
comfortable
that
if
you
have
a
meaningful
contribution
that
completely
makes
sense
to
get
into
an
open
source
project
that
it's
going
to
be
weighed
on
on
its
merits
and
and
not
on
on
some
agenda
that
it's
external
to
the
collective
right.
But
I'm
not
sure
that
the
steering
committee
as
a
as
an
organization
of
like
you
could
implement
this
kind
of
group
of
people.
If
that's
really
going
to
to
to
get
where.
I
think
we
want
to
be.
F
F
You
get
to
the
point
where
you're
no
longer
saying
benevolent
dictator
for
life
projects
are
totally
welcome
to
grant
to
up
to
graduate,
and
that
may
be
very
that
may
be
100
what
the
direction
the
toc
wants
to
take,
but
again
like
we
just
need
to
know
like
if
it
is
going
to
be
the
kind
of
thing
where
I
think-
and
I
said
this
in
the
email
like
you
know.
I
think
we
can
all
agree.
F
Every
project
is
different
and
needs
something
different,
but
if
we
can
have
the
toc
kind
of
tell
us
what
exactly
it
is
they're
wanting
to
do
and
if
they
are
wanting
to
say
here's
three
governance
models
that
we
really
like
projects
pick.
One
of
these,
then
that's
something
that
we
as
the
working
group
can
then
create.
You
know
templates
or
guidelines
or
whatever.
We
just
need
that
direction,
and
I
feel
like
that's
the
thing
that
we've
been
kind
of
struggling
to
get.
B
That's
like
building
something
together,
but
what
we
want
to
cultivate
is
an
intendedness
in
that
team
of
people
that
they
are
collaborating
in
ways
that
are
going
to
help
that
project
grow
and
and
have
a
a
very
long
and
and
fruitful
existence
right
and
one
of
the
things
that
I
that
I,
that
I
worry
about
and
lots
of
different
frameworks
that
we
use
and
kind
of
evaluating
performance
and
graduating
the
different
levels.
I
think
about
this.
In
the
same
way
of
like
what
does
it
take
to
get
promoted
at
a
big
company?
B
You
end
up
with
a
an
anchor
bias.
You
end
up
like
losing
the
the
personal
narrative,
that's
a
very
individual
kind
of
aspect
of
like
someone's,
someone's
career
and
and
and
progression
right.
You
just
lose
all
those
details
if
you
get
very
specific
about
the
criteria-
and
it
has
to
look
like
this
in
order
to
move
up
to
the
next
level.
A
That
is,
the
cncf
includes
startups.
Some
companies,
have
you
know
over
the
cncf
lifespan,
stop
being
involved
with
the
cncf
and
as
a
result,
for
a
project.
If
a
project
gets
to
graduated,
the
cncf
has
a
soft
commitment
to
make
sure
that
project
continues
in
some
way
and
if
a
hundred
percent
of
the
people
who
regularly
work
on
code
for
that
project,
all
work
for
the
same
organization
that
adds
a
significant
risk
to
the
continuity.
F
F
To
the
first
one
I
would
say
I
don't
I
don't
know
what
the
nats
maintainer
process
looks
like,
but
I
know
for
grpc.
If
you
want
to
be
a
maintainer,
all
you
have
to
do
is
ask
so
the
fact
that
we
don't
have
a
lot
of
other
maintainers.
Isn't
like
I
don't
the
barrier.
There
is
something
that
I
think
I
know
paris
has
talked
about
a
lot
with
the
overall
control
strategy,
say
of
like
how
should
cncf
be
kind
of.
F
I
think
this
all
kind
of
ties
in
like
how
should
cncf
be
helping
projects,
get
new,
maintainers
and
grow.
That
kind
of
incubation
status
of
like
to
your
point.
If
a
project
has
been
donated
to
cncf
and
then
everybody
just
like
wins
the
lotto
and
goes
to
retire
on
an
island
without
computers,
because
that's
my
I
don't
like
the
bus
factor,
I
like
the
island
with
no
electricity
factor
then
like
cncf,
is
ultimately
left
with
the
project
and
so
has
to
find
a
way
to
you
know,
keep
it
going.
F
So
it's
kind
of
like
what
kind
of
I
think
that's
a
lot
of
what
you
know.
The
contributor
strategy
you're
trying
to
figure
out
is
like
how
can
we
better
serve
projects
to
get
those
maintainers,
and
I
I
think
that
some
of
the
again
not
going
to
speak
for
the
gnats
folks,
but
I
know
at
least
from
the
grpc
side.
A
lot
of
it
is
like
we
don't
have
the
resources
necessarily
to
go
out
and
actively
recruit
a
bunch
of
extra
maintainers,
and
I
know
a
lot
of
smaller
projects
for
even
less
resource.
F
F
Something
like
that,
crazy
and
so
like
when
you
imagine
all
of
them,
you
know
have
graduated.
You
know,
like
the
logistical
overhead
starts
to
become
a
little
a
little
much
and
so
it's.
How
can
we
create
these
tools
that
projects
can
use
and
then
it
can
scale
up
and
so
that
the
cncf
ecosystem
is
assured
it'll
keep
going,
even
if
we
all
win
the
water.
G
And
I
think
this
new
maintainer
from
other
orgs
sort
of
turns
into
a
chicken
and
egg
problem
right,
because
until
you
get
those
first
couple
from
another
organization,
it
looks
like.
Maybe
I'm
not
welcome,
because
all
of
the
maintainers
are
from
another
company
and
it's
really
hard-
it's
really
hard
to
get
that
first,
one
or
or
two
from
another
organization,
because
you
don't
have
any,
and
so
you
get
this.
You
do
get
into
kind
of
this
loop
where
it
is
really
hard
to
get
them.
C
G
B
If,
if
you
have
a
small
team,
that's
like
that's
not
necessarily
keeping
a
mindful
kind
of
outward
focus
and
looking
to
to
draw
people
in
and
and
encourage
them
and
invite
them
to
to
do
more
and
and
looking
for
the
signs
they're
like
okay,
we,
we
should
look
for
ways
to
give
to
give
you
more
opportunities
and
then
more
more
more
responsibility
and
authority
over
time.
It's
it's!
It's
very
much.
A
part
of
like
of
of
growing
people,
yeah.
C
B
G
G
It's
people
problems,
but
I
think
it
shows
a
project's
maturity
that
once
they're
starting
to
get
over
that
hurdle
of
having
the
first
couple
of
maintainers
from
another
organization,
and
I
think
it's
I
think
it's
important
now
I
mean
numbers
aside.
I
don't
I
don't
know
how
we
that's
the
hurdle
we
need
to
figure
out,
but
I
I
do
think
it's
kind
of
kind
of
important
to
see
that
in
a
project.
F
We
have
a
lot
of
we
have.
I
don't
even
know
the
number
full
number
we
have
a
lot
of
different
repos,
because
we
have
a
lot
of
different
implementations
if
there
are
20
apple
doves
working
on
the
swift
repo-
and
you
know
I
know,
salesforce
has
done
a
lot
with
they're
reactive.
I
think
it's
reactive.js,
that's
all
well
and
good,
but
like
they
can't
take
over
the
entire
project,
should
we
all
win
a
lot
of
you
know
what
I
mean
like.
F
You
can't
apply
the
same
standard
because
I
could
have
you
know
one
repo
like
the
go.
Implementation
can
have.
You
know:
20
different
companies,
20
different
people
from
20
different
companies.
You
know
represented
on
that
maintainer
list,
but
that
doesn't
mean
they're
going
to
pick
up.
Should
you
know
the
rest
of
them?
The
rest
of
the
repos
and
implementations
just
fall
away,
and
so
I
think
that's
where
we
get
into
this
situation,
at
least
from
the
next
grpc
side
of
where
it's
like.
F
It
doesn't
work
for
us,
and
it's
not
because,
and
what
made
me
think
of
this
is
specifically
like
what
matt
was
saying
about.
You
know
identifying
those
folks
in
the
community
and
and
bringing
them
in
and
with
the
grpc
case.
I
have
done
that.
But
again
it's
it's
ryan
who's
written
his
own
implementation
and
that's
great.
F
He
is
happy
to
you,
know,
control
that
repo,
but
he
could
not
take
on
all
of
it
should
something
happen,
and
he
quite
frankly,
doesn't
necessarily
have
an
interest
or
even
the
skill,
to
take
over
the
core
implementation,
which
is
like
c
plus
plus.
So
you
know,
then
it
comes
down
to
the
issue
of
like
you
can't
expect
the
java
maintainers
to
be
responsible
for
go
implementation,
etc.
And
that's
why
we
get
in
that
spinning
cycle
and
I'm
sure
it's
very
similar
for
nets.
D
It
is,
it
is,
and-
and
I
I
do
think
this
needs
to
be
quantified,
you
know
I.
I
agree.
I
agree
that
that
does
take
some
of
the
the
personal
aspects
out
right:
the
people,
the
connections,
but
we've
met
the
letter
of
graduation
for
over
a
year.
Now
you
know
letter
of
the
law
and
the
you
know.
Quite
frankly,
the
bar
keeps
moving
so
we're
looking
for
something
to
help
us
move
forward,
and
you
know
if,
if
that's
a
steering
committee,
great
we're
all
on
board,
but
we
just
we
need
guidance.
F
And
you
know
I
know-
we've
talked
about
different
things
about
like
having
labels
on
github
to
show
like
the
status
of
a
project,
and
you
know
be
more
specific-
is
to
call
out
whether
or
not
like
it's
one
maintainer
or
multiple
maintainers.
But
what?
If
we
kind
of,
took
this
approach
of
like
hey,
we
see
there's
x,
number
of
projects
that
have
this
type,
this
structure
that
requires
a
little
extra
handling,
it's
a
little
unusual,
and
then
you
know
we
can
advise
the
toc
on.
F
F
You
know,
maybe
it's
it's
almost
like
an
audit
of
the
existing
cncf
projects,
which
there
are
66
exactly
and
he
tells
us
he
knows
everything
and
she's
awesome,
but
if
there's
66
different
projects
like
can
we
do
some
sort
of
high
level
grouping
in
terms
of
not
necessarily
the
governance
model
they
have
today,
but
in
terms
of
like?
Is
it
a
mono
repo?
F
F
You
know
a
platform
that
people
could
build
on
top
of
where,
theoretically,
if
the
main
piece
would
no
longer
maintain,
you
still
have
these
other
pieces
things
like
that,
like
I
wonder
if
we
can
just
do
kind
of
a
high
level
audit
of
all
the
different
projects,
and
I
wonder
if
that
would
also
tie
into
some
of
the
work
from
stick
trip.
Strap
of
like
you
know,
I
know,
paris
has
got
the.
We
did
the
survey
of
like
what
you
know
models.
F
E
B
Okay,
so
I
think
I
I
think
that
to
me
in
in
an
approach
of
like
grouping
existing
graduated
projects
and
kind
of
inspecting
their
governance,
and
things
like
that,
it's
like
we're
trying
to
do
a
sorting
hat
function.
You
know
who's
who's
going
to
be
gryffindor
and
who's
slytherin,
and
it's
also
it's
a
point
in
time,
and
I
think
that
the
really
resilient
projects
in
their
communities
evolve
over
time.
They
grow
they
change
they
they
they
they
were
like.
B
Some
kind
of
outcomes
that
were
not
overall
beneficial
to
the
the
way
the
project
runs
and
not
we're
trying
to
meet
the
criteria
for
graduation
right.
If
the
goal
is,
we
need
to
graduate
to
get
to
you
know
the
next
level
in
cncf,
but
that
that
overall
is
not
aligning
you
to
build
the
best
more
most
vibrant,
most
diverse,
most
resilient
kind
of
of
community.
Then
that's
not
necessarily
we're
not
the
overall
mechanics
of
this.
B
B
And
that
leads
to
kind
of
looking
at
well.
We
need
to
make
sure,
there's
governance
there,
that
it's
going
to
maintain
that
status
at
the
time
that
we
looked
at
have
you
met?
Have
you
met
the
the
graduation
criteria
right
and
so
that
that,
in
practice
I
think
I
might
be
wrong
about
this
is
just
my
intuition.
I
haven't
really
done
a
deep
inspection
of
of
these
kind
of
projects,
but
that
often
means
that
it
becomes
really
hard
to
change
the
governance
of
a
project
which
means
it.
A
Okay,
I'm
going
to
pause
you
there,
because
we
have
13
minutes
left
and
I
would
like
to
get
our
outstanding
pull
request
resolved,
preferably
on
this
call,
because
this
includes
advice
to
projects
on
leadership
which
is
obviously
relevant
to
here.
So
let
me
do
that
and
then
we
can
go
back
to
this.
If
we
finish
in
time.
A
A
So,
with
four
outstanding
pull
requests,
although
the
project
health
document
is
actually
waiting
on
contributor
growth
working
group,
I
believe
it's
already
been
approved
by
by
this
working
group.
So
there's
a
couple
of
things
here:
one
is
just
a
few
updates
for
governance.
References
for
those
of
you
are
not
aware.
We
have
a
document
here
that
just
has
a
large
list
of
references
for
things
to
look
at.
A
G
Yeah
this,
actually,
I
think,
wasn't
wasn't
about
the
links
of
references.
This
was
about
the
governance
working
group
was
still
listed
as
proposed
in
the
on
the
readme,
and
so
I
fixed
that,
and
instead
of
linking
to
the
issue
where
you
were
talking
about
it,
I
linked
to
our
governance.
Working
group
read
me,
so
it's
just
a
clean
up,
and
I
added
the
meeting
time
for
this
meeting,
which
wasn't
on
there.
I
A
A
longer
one
primarily
authored
by
don,
which
is
advice
on
leadership
selection
for
those
of
you
actually
haven't
looked
at
this.
This
is
a
long
document
saying:
hey.
Here's
a
whole
bunch
of
different,
a
whole
bunch
of
different
ways
that
you
can.
You
know
compose
the
leadership
of
your
project,
including
a
steering
committee.
A
A
A
F
A
Yeah
I
mean
I
feel
like
we
need
to
have
a
higher
standard
for
well.
The
thing
is,
you
know
with
all
of
these,
even
after
we
approve
these
there's
still
one
more
stage,
which
is
that
the
toc
needs
to
approve
them
and
then
put
them
in
another
location
which
they
still
have
not
determined
where
they
become
official
advice
to
projects.
A
A
This
was
a
bunch
of
material
written
by
me
and
brian
barenhausen,
of
red
hat
for
the
open
source
way
book
that
I
revamped
to
make
it
specific
to
the
cncf
projects
and
then
got
a
lot
of
input
on
it
from
the
rest
of
the
governance
working
group
and
then
opened
it
as
a
oh.
This
still
needs
a
couple
of
changes
before
we
can
merge
it,
then
open
is
a
pr.
It
does
need
a
couple
of
there's
still
a
couple
of
outstanding
changes,
some
things
that.
A
A
A
And
this
is
a
call
to
everybody
on
the
on
the
call
if
you
want
to
take
on
any
of
these
planned
documents,
please
go
ahead
and
do
just
claim
them
in
that
issue.
If
you
want
to
avoid
duplicating
somebody
else's
work,
you're
not
even
required
to
claim
them.
But
you
know
it's
always
annoying
to
duplicate
work
and
say:
hey,
I'm
going
to
work
on
this,
because
we
want
to
get
all
of
this
material
out
to
projects
so
that
we
can
say:
hey.
A
List:
okay,
so
that
is
pull
requests.
I
don't
think
we
have
any
open
issues
other
than
that.
Oh
the
end
user
promotion
criteria.
We
need
to
actually
take
back
to
the
toc,
that's
another
one
where
clarity
required
and
obviously
we
spent
a
long
time
discussing
the
multi-org
thing,
which
is
why
it
is
not
resolved
because
we
keep
discussing
it
so,
okay,
so
back
to
discussion,
because
we
have
five
minutes
left
unless
somebody
else
has
something
to
say
about
current
open
pull
requests
and
issues.