►
Description
CNCF SIG Contributor Strategy Governance Working Group 2020-09-29
A
A
B
C
B
B
D
B
D
B
B
B
B
A
huge
agenda
today,
a
couple
of
things
was
pardon
me.
We
had
a
governance
discussion
on
the
toc
meeting
this
morning
and
I
wanted
to
recap
that
particularly
the
sort
of
three
deliverables
that
came
out
of
that,
because
we'll
be
involved
with
that
as
a
working
group
and
then
just
you
know,
go
over
what
we've
got
in
progress
in
terms
of
people's
work
on
prs
and
the
stuff
that
we
already
knew
about.
B
B
B
B
I
that
proposal
was
not
adopted,
but
after
a
bunch
of
discussion,
what
came
out
of
the
meeting
instead
was
the
idea
that
we
would
mutate
the
and
replace,
what's
currently
the
multi-organizational
requirement
for
graduated
projects
and
instead
require
potentially
three
things
out
of
projects
that
are
closer
to
what
the
cncf
really
cares
about,
one
being
a
sort
of
longevity
sustainability
plan.
For
you
know,
how
does
this
project
continue?
B
B
Yeah
second
thing
is
requiring
feedback
on
the
roadmap
from
community
and
end
users,
and
there
was
a
discussion
of
making
a
contributor
ladder
or
analogous
plan
a
requirement
as
well,
but
I
didn't
get
as
far
as
sort
of
getting
general
approval.
I
mean
I'll
note
that
there
wasn't
actually
a
vote
on
any
of
these
things,
but
people
were
pretty
positive
about
the
first
two
requirements.
People
were
generally
positive
about
the
third
requirement.
It's
just
that
it
didn't
come
up
in
the
last
five
minutes
in
the
meeting.
B
B
The
general
idea
was
forgot,
who
said
matt?
Were
you
the
one
who
suggested
this
somebody
suggested
they
pointed
out
that
hey,
if
requiring
multi-organizational
maintainers
is
kind
of
a
proxy
for
these
other
issues
that
we
care
about?
Why
not
just
require
that
projects
do
something
directly
about
the
other
issues
and
yeah.
D
D
Think
about
it
as
a
pattern
and
then
come
up
with
two
or
more
implementations
that
people
have
done
of
each
of
those
things
and
then
maybe
point
to
some
examples
of
governance
that
are
a
full
thing
that
look
like
what
we
want.
You
know
maybe
one's
a
steering
committee,
one
something
else
so
that
way,
people
can
see
what's
really
needed,
different
patterns
for
solving
it
and
learn
an
understanding
of
how
it
solves
it,
along
with
seeing
an
overall
governance
that
does
these
things
that
that
was
kind
of
my
my
stick
for.
D
D
Cool
and-
and
I
also
want
to
point
out
here-
and
I
know
I
said
it
over
there-
the
multi-org
maintainers-
there
is
one
little
nuance
to
this-
that
I
think
is
problematic
towards
the
real
end
goal,
because
the
end
goal
is
what,
if
a
vendor
pulls
out,
then
what
happens
to
projects
right
if
it's
being
driven
by
a
vendor,
then
how
do
you
have
that
longevity
of
a
vendor
just
pivoting
away
and
leaving
right?
Well,
if
you've
got
multi-organization
maintainers
that
doesn't
necessarily
solve
it?
D
If
you
have
one
vendor
and
a
bunch
of
their
customers,
because
if
the
vendor
pivots
away,
the
customers
are
going
to
pivot
away
the
project's
still
in
lurch,
so
it
doesn't
completely
solve
it.
If
they're
very
closely
related
in
that
aspect,
like
you,
don't
have
any
competitors
in
the
vendor
space.
There.
B
B
Yeah,
so
this
is
going
to
be
interesting,
because
you
know
sig
contributor
strategy
in
general
is
probably
going
to
be
in
charge
of
writing
these
the
documentation
for
this.
The
and
a
couple
of
these
the
require
feedback,
and
the
longevity
plan
are
interesting
in
that
these
are
not
things
that
we
have
good
examples
of
in
existing
mature
projects.
B
The
and
so
and
the
required
feedback
is
a
little
bit
easier
to
imagine.
I
do
know
examples
of
this
because
we
actually
have
in
our
internal
maturity
model
for
red
hat.
We
actually
have
stuff
about
having
you
know:
open
forums
for
customer
feedback
etc
for
red
hat
projects
that
operate
within
red
hat.
So
I
think
that's
pretty
easy
to
imagine
like
I
don't
know
a
canonical
independent
documentation
that,
but
it's
easy
to
imagine
what
would
be
in
that
document.
For
the
longevity
plan
is,
you
know,
hey.
B
B
D
Yeah,
oh
and,
and
one
other
thing
just
hit
me:
what
about
projects
that
don't
have
vendors
and
grpc
is
going
to
be
my
example
of
this
right?
They
are
an
incubating
project
that
presumably
someday
will
want
to
go
for
graduation,
and
what
do
they
look
like
because
they're
not
something
like
kubernetes
or
prometheus,
that
you're
going
to
run
with
vendors?
What
does
this
model
look
like
for
them?.
B
B
D
Okay,
then
I'll
pull
out
a
slightly
different
project.
Let's
take
helm,
for
example,
a
package
manager.
You
see
tons
of
people
using
it,
whether
it's
people
using
it
directly
to
install
things,
and
there
are
people
who
distribute
their
stuff
over
it
but
find
me
and
they're
people
who
build
stuff
on
top
of
it
right
like
we've
worked
flux
or
I'm
now
at
rancher
and
rancher
has
fleet.
That's
that
uses
it
right.
D
We
use
this
stuff
all
over
the
place,
but
find
me
a
vendor
that
will
just
provide
you
helm,
support
and
the
same
thing
find
me
a
vendor
that'll
find
you
homebrew
or
apt
or
yum,
or
any
of
those
supports
for
package
managers
in
general.
You
don't
tend
to
find
it,
and
so
there's
an
example,
that's
kind
of
hard
because
it
doesn't
fit
the
spec
model
and
it
doesn't
fit
the
it
doesn't
feel
like
the
kubernetes
prometheus
being
offered
by
a
vendor
model
either,
and
I
imagine
there's
more
projects
like
that
in
the
cncf.
B
D
A
Yeah,
I
really
don't
like
to
focus
on
vendors.
I
mean
for
me
what
I,
what
I
think
is
important
in
this
discussion
is
the
discussion
of
contributors,
so
so
less
of
what
vendor
is
going
to
eventually
do
something
with
this
piece
of
software,
but
do
we
have
do
we
have
contributors
from
a
bunch
of
different
companies
contributing
to
it,
because
that
that
to
me,
I
think,
is
kind
of
the
the
core
of
the
problem,
we're
trying
to
solve
it's
less
about
the
vendors,
taking
it
more
about
who's.
B
B
B
So,
if,
like
you're,
looking
at
worst
case
scenario,
you're
managing
a
scenario
where,
for
example,
vmware
has
a
fight
with
the
linux
foundation
and
pulls
all
of
their
people
out
of
linux
foundation
projects
and
starts
running
their
own
fork
of
harbor,
then
you
know,
even
though
there
are
additional
contributors
who
don't
work
for
vmware.
I
don't
know
that
that
really
solves
the
sustainability
problem.
Those
additional
contributors
are
not
capable
of
carrying
the
project.
A
Yeah,
I
think
that's
a
really
good
point.
I
mean
that's
something
that
you
know
we've
seen
in
the
kubernetes
project
as
well.
You
know
where
you
know
it's,
google
employees
that
hold
the
keys
to
certain
things
and
we've
backed
out
of
that
bit,
but
it's
easier
in
kubernetes,
it's
harder
with
a
project
like
harbor
where
so
much
of
it
is.
B
Yeah
and
the
thing
is,
it
doesn't
even
have
to
be
a
permissions
thing
right.
It
can
just
be
a
knowledge
thing
right
like
in
kubernetes.
Nobody
is
preventing
other
people
from
getting
involved
with
kubernetes
performance,
but
the
simple
truth
is
ninety
percent
of
kubernetes
performance
is
woe-checked
and.
B
B
B
B
Yeah
the
so
that's
going
to
be
challenging
and
I
think
we're
going
to
have
to
go
back
and
forth
to
the
toc,
because
I
think
it
was
sort
of
easy
to
say
that
we
should
have
this,
but
trying
to
figure
out
what
one
looks
like
I
think,
is
going
to
be
a
long
effort,
the
I'm
more
sanguine
about
pushing
for
requiring
a
contributor
ladder,
because
that's
something
I
would
have
liked
in
the
first
place
right.
I
mean
honestly
think
by
the
time
a
project
gets
to
graduated.
B
B
B
D
D
I've
offered
up
end
users
who
want
to
come
sit
down
and
have
time,
and
it
actually
turns
out
for
a
lot
of
projects
pulling
that
end
user
support
and
or
that
end
user
feedback
isn't
always
an
easy
thing
to
capture
right
on
the
helm
project.
We
found
that
when
we're
face
to
face
at
a
conference,
we
can
usually
grab
somebody
at
a
company
who's,
a
user
and
sit
down
with
them.
D
That's
a
pretty
easy
thing
to
do,
but
in
this
virtual
space
saying
hey,
can
I
get
a
half
an
hour
of
your
time
or
who
wants
to
talk
about
it?
Who
wants
to
give
feedback?
It
turns
out.
It's
not
such
an
easy
thing
to
go,
collect
that
feedback
and
just
sit
down
with
somebody
and
talk
with
them,
and
so
what
may
be
obvious
for
some
or
the
inroads
they
have
in
their
project,
isn't
obvious
for
others,
and
they
don't
have
the
setup
or
even
people
willing
to
give
them
that
feedback
on
another
project.
D
B
A
B
I
I'd
actually
like
to
you
know,
hear
because
the
toc
was
kind
of
vague
about
whether
they
want
to
use
the
term
end
user
community
and
I'd
rather
kind
of
focus.
You
know
and
try
to
steer
them
towards
making
the
requirement
community
feedback,
because
you
know,
for
example,
there's
going
to
be
a
whole
set
of
the
community
who
are
not
end
users,
but
still
should
have
input
in
the
process.
B
So
you
know-
and
you
know,
for
that
matter,
you
can
get
a
lot
of
feedback
from
from
those
people
like,
for
example,
if
part
of
your
community
consists
of
independent
consultants,
then
those
consultants
can
often
tell
you
a
lot
about
what
the
actual
end
users
are
doing,
because
they
are
intimately
involved
with
it.
Even
if
you
can't
reach
those
end
users
directly.
A
D
Yeah,
I'd
also
like
to
point
out
that
end
user
in
cncf
terms
can
mean
a
very
specific
community.
There's
the
cncf
end
user
group,
which
is
now
over
a
hundred
different
companies
that
aren't
vendors
but
they're
end
users
and
they've
got
their
own
private
meetings
and
they
discuss
things
and
they
even
elect
their
own
toc
members.
B
B
B
A
I
will
go
ahead.
Do
we
want
to
do
that
or
do
we
I
feel,
like
the
steering
committee
meeting
was
kind
of
all
over
the
place
like
these
are
our
takeaways
for
what
we
think
are
maybe
the
right
things
to
do
as
the
next
steps
out
of
that
meeting,
I
wonder
before
we
get
too
far
down
the
path
of
putting
together
docs
for
this.
A
Do
we
want
to
circle
back
with
the
steering
committee
and
make
sure
that
these
are
the
right
things
to
do
and
maybe
provide
them
with
a
little
more
information
about
what
we
think
would
be
in
this
doc
to
help
them
kind
of
make
that
decision,
but,
but
I
do
feel
like
there,
there
wasn't
really
anything
tangible
that
came
out
of
the
syrian
community
meeting
today.
It
was
a
lot
of
a
lot
of
different
people
with
lots
of
different
opinions,
and
some
of
them
were
louder
than.
B
B
B
A
A
B
B
B
B
D
You're
absolutely
right,
I
mean
in
the
last
month
I've
had
people
from
more
than
one
company
on
more
than
one
new
sandbox
project.
Saying.
Can
you
help
us
get
going
with
governance?
Can
you
point
us
in
the
right
direction
and
I'm
sitting
there
going?
What
do
I
point
you
at
I
start
asking
questions
and
then
I
start
pointing
okay.
You
do
things
like
this
here
is
kind
of
what
somebody
else
has
already
done
in
a
graduated
project
and
here's
their
governance
and
it's
sort
of
similar
to
what
you've
got.
A
Yeah,
that's
a
hard
problem
too,
because
every
project
is
different
and
whatever
project
needs
for
governance.
There's
no
there's
no
cookie
cutter.
You
can't
just
send
people
to
this,
and
it's
like
you
need
this
and
this
and
this
and
it's
it's
really
easy
it
just.
It
doesn't
work
that
way
so,
like
the
leadership
selection,
doc
that
I
put
together
has
like
10
options
for
how
you
might
select
leaders
and
some
of
the
best
practices
for
you
know
for
doing
that.
But
it's
not
it's
not.
This
is
what
you
do
check.
B
A
B
C
B
Okay,
so
we've
got
that
matt
jaime.
You
can
see
the
list
of
of
things
if
there
is
not
a
name
after
any
of
the
items
on
that
content
tracking.
It's
because
nobody
has
volunteered
to
be
responsible
for
that,
so
feel
free
to
grab
any
of
those
for
that
matter,
even
if
somebody
has
something
assigned-
and
it's
not
done
feel
free
to
ping
that
person,
because
all
of
us
have
multiple
competing
things
on
our
time
and
if
there's
something
that
you're
like
hey,
I
already
have
stuff
for
this.
B
Jennifer
davis,
she
was
going
to
coordinate
with
sig
security
on
the
the
the
little
bit
of
glue
code.
That
says:
hey
your
project
as
governance.
Your
project
needs
to
have
a
documented
process
on
how
you
handle
security
issues
and
here's
a
link
to
all
of
security
stuff
about
that,
because
they
have
stuff
about
that
right.
But
when.
B
B
B
Otherwise,
yeah
a
lot
of
projects
don't
have
anything
formal
which
is
bad
because
because,
among
other
things,
you
know
completely
aside
from,
they
may
actually
have
a
de
facto
process
for
handling
security
stuff.
But
if
I
discover
a
security
hole
and
I'm
not
a
regular
contributor
to
that
project,
I
need
to
know
what
to
do.
D
Oh
yeah
yeah,
so
on
helm
we
actually
have
this
and
we
use
the
github
security
notification
thing,
that's
been
added
and
they
go
out
and
it's
a
little
slower
to
have
them.
Go,
get
the
cdes
with
it
than
me
myself
going
out
to
get
it
we'll
actually
get
cbes
and
have
them
do
it
because
you
get
private
branches
automagically
from
them.
When
you
use
it,
and
so
there's
a
lot
of
neat
things
if
you
actually
use
it.
D
So
we've
had
a
security
process
for
a
while
over
on
helm,
but
I'm
all
actually
looking
to
say
how
do
we
revise
that
process
to
improve
on
it,
because
there's
this
whole
okay,
we've
got
this
far,
but
is
there
a
way
to
get
better
at
doing
this
and
what
criteria
and
then
what
could
we
share
with
others?
Then
too.
B
D
B
B
You
know
things
like
a
contributing.md
file
and-
and
you
know,
a
governance,
dot,
md
file
or
a
steering
committee
charter
or
any
of
these
various
pieces
of
paperwork.
Your
project
might
need
done
in
a
sort
of
mock-up
template
format,
so
that
a
cncf
project
that
comes
in
with
some
of
these
things,
but
not
all
of
them-
can
honestly
just
fork
that
project
and
use
the
templates
there
to
build
the
rest
of
their
stuff.
D
B
B
You
know
figuring
out
where
that
is
is
kind
of,
because
we
came
up
with
a
couple
of
ideas.
Cncf
staff
said
no
because
of
conflicts
with
with
some
of
the
names
that
you
know
some
of
the
spaces
that
we
looked
at
and
so
now
we're
kind
of
in
the
hey.
There
needs
to
be
a
place
where
approved
stuff
lives.
Ideally
it
should
not
just
be
in
a
git
repo.
There
should
be
some
sort
of
web
publication
so
that
people
can
actually
google
it.
B
Yes,
yep
so
the
but
yeah
we
do
need
a
place
and
and
and
that's
been
an
outstanding
issue,
and
I
should
really
just
go
ahead
and
open
an
issue
with
the
toc.
I
guess
and
say,
find
us
a
place:
the
yeah,
because
there's
a
bunch
of
other
stuff.
In
addition
to
all
this
governance
documentation,
we
want
a
place
for
maintainer
circle
activities,
which
is
another
project
contributor
strategy,
maintainer
circle
activities.