►
From YouTube: CNCF TOC Meeting 2020-09-29
Description
CNCF TOC Meeting 2020-09-29
A
B
B
B
C
D
C
E
C
F
E
C
E
C
E
On
okay
game
on
so
I
think
today
it's
all
about
graduation
requirements,
maintaining
diversity
and
alexis's
kind
of
suggestions
around
steering
committee,
and
you
know
how
we
might
be
able
to
help
projects
and
enable
projects
to
run
in
a
you
know,
a
way
that
is
good
for
the
entire
community,
while
also
you
know
well,
that's
be
good
for
the
entire
community
in
broader
ways
than
we
currently
require.
So
we
currently
have
the
multiple
organization
requirement
on
maintainers.
E
F
Sorry,
large
and
small
end
users
in
in
the
cncf
a
sort
of
four-legged
table,
and
I
think
that
if
we
stop
supporting
isvs,
we
might
find
the
table
wobbles
over
and
just
becomes
a
three-legged
table.
That's
half
on
the
floor
so
going
to
the
detail
and
that's
why
for
me,
what
I
would
really
like
to
hear
today
is
the
views
and
real
challenges
that
have
been
run
into
by
independent
software
vendors,
with
getting
more
maintainers
retaining
maintainers
and
maintain
keeping
up
the
the
mix
of
maintainers.
F
We
did
discuss
this
on
github
or
already,
and
so
for
me,
the
question
is
what
are
the
downsides
of
single
vendor
open
source
or
open
source
projects
where
there
is
a
lot
of
initiative
coming
from
a
single
vendor
and
I've
seen
various
different
versions
of
this
over
the
years
and
I've
seen
it
to
be
very
successful
under
foundations?
I
mean,
for
example,
we
talked
about.
I
think
the
example
of
kafka
on
the
apache
software
foundation,
asf,
where
most
of
the
committers
and
maintainers
are
people
associated
with
conflict,
but
but
not
all.
F
That
seems
to
be
one
where
the
community
feels
it's
maintaining
a
decent
balance.
I
think
that's
a
pretty
pretty
good
situation,
but
there
are
other
ones
as
well
and
not
all
projects
are
as
big
or
mature
as
kafka.
So
how
do
we
help
smaller
projects
get
there,
and
I
believe
it's
very,
very
important
that
whatever
we
are
doing,
we
are
helping
projects
if
we're
helping
projects
get
to
where
they
need
to
be.
F
F
One
of
them
was
this
issue
of
the
sort
of
I
think
what
was
the
the
project
that
was
acquired
by
apple
and
then
disseparated.
I
can't
remember
what
it
was
called
the
database
project.
Thank
you
very
much.
There's
the
foundation
db
problem.
Where
you
know
a
project.
A
has
employees
associated
with
it
from
a
single
company
that
gets
acquired
goes
into
large
co,
which,
for
whatever
reason
it
may
not
be
malicious.
F
Then
just
basically
evaporates
all
the
work
on
the
project
and
somehow
there
isn't
a
mechanism
for
rescuing
that
situation,
and
I
think
that
I'm
not
convinced
this
situation
is
truly
mitigated
by
having
multiple
vendors,
I
think,
having
lots
of
vendors
helps
in
the
case
of
something
like
kubernetes,
that's
a
big
enough
project
to
sustain
acquisitions
and
all
kinds
of
changes,
but
there
are
other
projects
that
are
smaller
and
medium-sized.
Where
you
know,
even
if
you
had
two
vendors,
it
would
rock
it
quite
a
bit
to
have
something
like
that
happen.
F
I
think
that
there
is
a
I
just
don't
like
projects
where
the
project
is
crippled
or
held
back
in
some
way
deliberately
due
to
a
servicing
someone's
commercial
strategy.
I
just
think
that
if
you're
gonna
play
the
foundation
game,
you
have
to
be
willing
to
have
a
fully
featured
product
and
sell
ancillary
things.
Like
you
know,
in
the
case
of
cinedia,
nats
is
fully
featured.
They
have
a
separate
product
in
the
form
of
a
sas.
F
F
I
mean
for
me
that
is
the
number
one
goal
of
graduation
other
than
long-term
stability,
and
I
believe
that
individual
companies
or
teams
or
groups
you
know
other
weird
structures
that
we
haven't
thought
of
perhaps
should
be
able
to
convince
the
cncf
they've
they've
taken
this
seriously,
and
so
one
model
that
I
thought
could
do.
That
would
be
the
so-called
steering
committee.
F
First
of
all,
one
alternative
certainly
is
for
every
project
to
be
like
kubernetes,
to
have
a
large
number
of
vendors
and
to
have
a
really
nice
quite
complicated
governance
model
with
with
sigs
and
steering
committees
and
charters
and
elections.
That's
great.
If
you've
got
a
big
enough
project,
then
you
have
the
other
model.
Where
you
don't
actually
have
a
steering
committee.
F
That's
great!
So
that's
another
model
and
then
there's
another
model
that
I
proposed,
which
is
the
so-called
steering
committee,
which
is
simply
a
recognition
that
end
users
and
coders
and
documenters
and
other
people
with
a
stake
in
the
project,
could
form
a
oversight
committee
which
acts
at
the
organizational
level
by
which
I
mean,
let's
take
prometheus
as
an
example,
there's
a
prometheus
org
and
it
has
multiple
repos
and
the
maintainer
is
associated
with
the
repo.
So
this
is
an
org
level
structure.
F
It
meets
periodically
it
acts
as
an
intermediary
between
things
that
are
concerns
of
maintainers
and
repos
and
the
cncftoc
itself.
So
it
can
listen
to,
for
example,
complaints
about
people
being
unfairly
treated
like.
Why
is
my
contribution
not
being
accepted?
Is
it
because
I
work
at
ibm?
Is
it
because
of
some
social
discrimination,
or
is
it
because
of
a
technical
reason,
and
that
would
be
a
complaint
that
could
be
heard
at
that
level?
F
F
We
are
completely
committed
to
the
what
I
would
call
the
previous
cncf
model
with
all
of
our
projects.
We
happily
work
with
refiner
labs
on
cortex
and
other
people
on
flux,
and
we'll
continue
to
do
that.
So
we're
not
looking
for
anything
like
this,
but
we
do
want
to
see.
I
do
want
to
see
healthy
projects
like
linkadee,
get
help
in
this
regard,
and
that's
as
well.
E
G
D
So
I
think
alexis
addressed
most
of
the
things
that
I
was
going
to
comment
on,
so
it's
hard
to
how
to
do
that
right
now.
So
one
thing
that
I
was
thinking
about
was
like:
how
do
we
set
up
like
a
progression
where
the
com,
the
project,
might
start?
The
way
you
know
alex
is
laid
out,
for
example,
right
and
then
how
do
we
over
a
period
of
time?
Maybe
they
start
getting
attracted
attracting
more
contributors
from
different
companies?
How
do
we
get
them
to
progress?
D
It's
almost
like
in
a
contributor
ladder
in
kubernetes
is
for
getting
contributors
to
go
where
we
want
them
to
go,
so
this
would
be
like
a
ladder
for
how
do
we
get
projects
to
go
from,
like
you
know,
to
a
better
stage
than
or
aspire
to
something
more
you
know.
So
that
is
the
kind
of
thing
that
I
was
looking
for
and
you
know,
because
I
don't
want
people
to
say.
D
D
G
Yeah,
the
the
other
thing
we
discussed
is
there's
a
huge
difference
between
a
syrian
committee
that
exists,
because
these
people
are
actually
leaders
of
the
project
and
a
steering
committee.
That's
been
imposed
by
the
cncf,
where
members
of
the
steering
committee
are
not
necessarily
otherwise
involved
in
the
project,
and
we
felt
that
the
second
kind
of
steering
committee
would
be
completely
ineffective
in
resolving
any
issues
around
multiple
organizations
ability
to
participate
in
the
project.
G
H
E
F
Think
that
the
a
steering
committee
would
be
welcomed
at
all
by
the
maintainers
if
it
was
imposed
from
above.
There
was
a
group
of
random
folks
who
you
know
it's
like
it's
the
classic
kind
of
architect
astronaut
problem,
and
I
also-
and
I
also-
and
I
also
believe,
the
ncf's
existence,
which
happily,
we
managed
to
fend
off.
There
was
an
early
desire
for
sponsors
who
paid
for
membership
to
form
essentially
groups
of
people
who
wrote
product
requirements,
documents
which
would
then
be
sort
of
imposed
on
the
projects.
F
And
you
know
I
had
to
sort
of
fight
against
this
because
it
was
sort
of
going
to
break
the
will
of
the
poor
people
working
on
the
projects
to
have
this
sort
of
thing
going
on.
It
would
be
much
better
for
those
things
just
to
service,
naturally
through
the
community,
which
in
fact
they
do
in
most
of
the
projects.
So
I
believe
the
steering
committee
or
if
it
includes
end
users
and
people
who
do
other
non-coding
activities,
should
it
should
arise
naturally
and
organically
from
the
community
itself,
who
are
around
the
project.
F
And
I
point
at
kubernetes
as
a
large-scale
example
of
such
a
thing.
I
don't
know
quite
how
this
has
been
achieved,
it's
to
the
credit
of
those
involved,
but
certainly
there
are
all
sorts
of
interesting
people
who
don't
all
write,
kubernetes
core
code
who
seem
to
be
welcome,
included
and
and
have
surfaced
through
the
system
in
a
good
way.
So,
let's
try
and
capture
some
of
that
thinking.
B
And
to
jump
in
here
on
this,
I
think
there
there's
an
important
element.
You
brought
up
that
happened
in
kubernetes
right,
you
saw
people
who
chopped
wood
carried
water
did
work,
it's
not
an
advisory
group
or
people
who
have
opinions
on
what
a
project
should
be
that
got
involved
in
the
steering
committee
model
or
even
got
involved
in
things
like
say,
docs
and
other
things
that
aren't
working
on
core
code.
But
it
is
people
who
ended
up
chopping,
wood
and
carrying
water
and
being
involved
in
the
day-to-day.
They
didn't
show
up
for
meetings.
B
B
That's
a
great
place
for
this
other
project
or
that's
a
great
place
to
create
a
new
project
to
solve
that
problem
and
as
somebody
who's
worked
to
maintain
things
as
a
kubernetes
sig
chair
and
on
helm
and
with
different
things.
What
I've
learned
is
lots
of
people
have
opinions
on
what
you
should
do
and
if
you
go
down
all
of
those
things
it's
going
to
be
the
death
of
a
million
paper
cuts
because
you're
getting
outside
of
your
core
thing,
and
so
whoever's
on
that.
Steering
committee
also
needs
to
be
of
here's.
D
So
I
don't
want
to
talk
about
kubernetes,
but
I
do
want
to
talk
about
turning
the
view
from
okay,
the
solution
to
the
problem
and
the
problem
is
what
can
end
users
of
a
of
a
project
expect
from
the
project
right?
How
can
we
surface
the
information
on
the
how
the
governance
works,
or
how
do
we
give
them
at
one
glance
that
look?
This
is
a
project
that
works
this
way
right.
D
Yeah,
the
the
short
version
of
it
is
like
how
so
the
toc
can
apply
badges
to
projects
and
the
badges
can
give
some
information
about
how
the
project
works
or
what
state
it
is
in.
We
can
include
all
the
in
stuff
that
we
already
have
like
incubating
levels
and
whatnot
right,
but
then
we
can
also
have
additional
badges
based
on
different
criteria
and
within
each
like
groups
of
badges
they'll,
be
like
a
progression
that
I
was
talking
about
before
right
so
and
so
it
we
kind
of
like
give
guidance
to
the
project.
D
Saying:
okay,
go
from,
you
may
be
starting
with
this
bad
set
of
badges.
But
then
this
is
what
you
need
to
aspire
to
and
you
can
earn
the
badges
as
you
go
along
right
and
then
this
is
so
when
the
toc
does
annual
reviews
or
whenever
it
talks
to
the
different
projects,
then
the
toc
can
say:
oh
now
looks
like
they.
D
We
can
call
them
like
whatever
multi-vendor
or
whatever
right
so
and
they
go
from
a
single
vendor
to
multivendor,
so
the
so
and
the
end
users
of
the
project
when
they
come
to
a
project
and
they
look
at
it.
They'll
say:
oh
okay,
I
know
what
to
expect
from
this
project.
This
is
the
set
of
things,
so
that
was
the
kind
of
idea
that
we
were
chewing
on,
but
we
haven't
finished
it
yet.
F
You
know
bronze
silver
and
gold,
reflecting
that
your
bronze
project
means
you
can
only
buy
things
from
one
vendor
silver
means
you
can
buy
from
more
than
one
vendor
and
gold.
You
know,
there's
lots
of
vendors
or
something
like
that
would
be
pretty
cool
because
then
you're
sort
of
making
it
into
a
business
thing
and
end
users
can
then
express
their
preferences
in
business
ways.
I
think
for
graduation.
F
This
should
be
about
governance
and
making
sure
that
the
project
is
well
looked
after,
has
good
mechanisms
dealing
with
complaints
and
error
handling
and
such
like
in
a
way
that
the
toc
can
provide
a
blessing
for
and
support
too,
without
creating
an
administrative
burden
for
itself
and
in
terms
of
how?
How
do
you
get
people
going?
There
is
one
example
of
this
out
there,
which
is
the
upbound
bassam,
has
got
a
thing
for
their
cross-cloud
project.
F
I
F
I
think
it's
about
being
stable
here
to
stay,
and
people
can
make
if
you're,
if
you're
a
big
it
shop.
You
want
to
know
that
you
can
basically
put
your
money
behind
these
projects.
That's
what
it
really
comes
down
to.
I
think
I
know
that
there
are
other
people
in
the
world
and
we
should
think
about
them
too,
but
ultimately,
I
think
the
people
who
are
really
paying
closest
attention
to
this
are
our
folks
making
big
risky
bets
on
the
technology.
F
So
I
think
we
should
make
sure
they
understand
that
the
technology
is
is,
is
relatively
likely
to
continue
to
exist
and
is
being
looked
after
by
the
cncf
and
the
toc
to
to
to
keep
it
on
an
even
keel
to
keep
it
moving
forward.
Now
that
doesn't
mean
that
there
that
is
impossible
for
a
project
to
run
aground,
but
I
think
it's
it
should
be
a
lot
harder
by
the
time
it
gets
to
graduation.
E
G
So
I
work
at
a
vendor
that
often
decides
to
participate
in
open
source
projects
that
were
started
by
other
companies
and
to
incorporate
those
into
our
stack
when
we
incorporate
a
project
into
our
stack.
One
of
the
things
that
we
want
to
know
is
that
the
you
know,
other
folks
involved
in
the
project
are
not
going
to
change
that
project
in
a
way
that
breaks
our
stack
and
the
best
way
for
us
to
ensure
that
is
to
ensure
that
we
have
some
kind
of
voice
in
how
the
project
is
run.
G
As
in
if
a
project
gets
to
graduated,
and
at
that
point
it
is
still
run
entirely
by
one
organization,
and
that
organization
has
the
ability
to
break
compatibility
with
other
projects
and
with
other
products
through
an
internal
process
right.
They
make
a
corporate
strategy
decision
and
it
breaks
everybody
else's
stuff.
Then
that's
kind
of
a
major
problem.
G
You
know,
and-
and
I'm
not
talking
about
you
know
other
vendors,
getting
to
say
how
the
project
is
wrong.
I'm
talking
about
other
vendors
who
want
to
put
people
on
the
project
to
make
sure
that
it
maintains
compatibility
with
their
products
and
are
prevented
from
doing
so,
and
we
would
like
to
think
no
one
would
do
that,
but
I
can
tell
you
from
other
outside
cnc
projects.
I
would
name
this
happens.
J
J
The
problem
with
a
steering
committee
approach
is
that
you
know
what
we're
trying
to
address.
Is
you
have
a
project
that
is
effectively
you
know
all
the
maintainers
are
from
a
single
company,
and
that
is
problematic
so
to
address
that
we're
saying,
let's,
let's
put
in
a
steering
committee
and
the
steering
committee
could
be
made
up
of
folks
that
are
from
other
organizations.
Potentially
end.
Users
are
not
completely
unrelated
to
the
project,
but
then
the
question
comes
down
to.
How
do
you
maintain
kind
of
the
relationship
between
the
maintainers
and
this
committee
in
general?
J
But
where
we're
kind
of
it's,
it's
a
we're
in
a
tough
spot
right.
We
want
this
multi-organizational
kind
of
cooperation
and
maintainership,
but
at
the
same
time
we
have
very
good
projects
that
don't
have
this,
so
we're
kind
of
struggling
to
find
a
governance
model
that
would
allow
us
to
have
have
both
effectively,
and
so
I
I
don't
know
a
steering
committee
could
work.
J
I'm
not
sure
it's
a
perfect
way
to
be
able
to
address
that
issue
and
then
going
back
to
the
second
issue
of
listening
to
end
users
and
ensuring
that
that
feedback
is
incorporated
back
into
the
project
roadmap.
You
know
a
steering
committee
is
made
up
of
a
fixed
set
of
folks.
It
may
be
that
today
you
have
users
a
b
and
c,
but
in
the
future
you
may
have
d
e
and
f
right.
J
And
ideally,
you
know
if
we
have
things
like
surveys
or
or
I
think
the
idea
of
an
evolving
or
dynamic
group
of
of
end
users
who
come
together
periodically
would
be
very
interesting.
So
I
think
what
I'm
getting
at
in
this
long-winded
way
is
that
I
completely
agree
with
the
problem
set.
I
think
what
I'm
concerned
about
is
dictating
a
very
kind
of
narrow
solution
from
the
toc.
J
Instead,
what
I'd
like
to
see
is
sorry.
I
just
wanted
to
complete
my
thought.
What
I'd
like
to
see
is
the
toc
would,
instead
of
dictating
a
solution,
would
instead
dictate
just
the
problem
statement
in
saying
that
hey
as
a
project
that
is
going
to
graduation,
you
must
provide
two
things.
One
is
a
longevity
plan,
which
means
if
the
one
company
behind
this
project
ends
up
disappearing.
J
How
do
you
ensure
longevity,
and
so
then
it
falls
on
the
project
to
figure
out
how
that's
possible
and
the
same
thing
with
with
user
feedback.
It's
give
us
a
plan
for
how
you
plan
to
incorporate
user
feedback
so,
instead
of
the
toc
enforcing
that
we
become
kind
of
fake,
hey
get
you
tell
us
what
works
for
you
and
the
toc
can
determine
whether
that
works
or
not.
A
Yeah,
I
just
I
just
wanted
to
sort
of
summarize
something
small.
So
if,
if
I
take
this
back
down
to
sort
of
the
core,
I
guess
what
we're
looking
to
do
is
to
have
graduated
projects
that
are
dependable,
long-lasting,
etc,
and
you
know,
as
as
alexa
said,
they're
projects
that,
after
due
diligence
and
after
that
stamp
of
approval
from
the
toc
that
companies
can
depend
on
that
companies
can
put
into
production
right.
It's
it's
it's
that
definition.
A
A
So
you
know
a
syrian
committee
could
be
a
good
idea
and
it
could
be
a
way
of
ensuring
longevity
multiple
maintainers
could
be.
Of
course,
you
can
always
argue
that
either
of
those
things
could
not
necessarily
ensure
the
longevity
or
the
or
the
roadmap,
or
you
know,
because
some
there
are
definitely
projects
with
multiple
maintainers
that
have
had
those
sort
of
issues
too.
A
So
we
probably
should
have
maybe
a
handful
or
one
or
two
or
three
methods
that
the
toc
probably
says.
Look.
These
are
things
that
we
can
recommend.
But
yes,
ultimately,
it's
up
to
the
project
to
prove
it,
but
I
kind
of
feel
if
we
don't
have
any
guidelines
at
all
and
just
focus
on
the
outcome
that
then
we
end
up
with
a
very,
very
subjective
decision
process.
B
So
people
can
see,
there's
different
ways
of
doing
it
and
then,
after
all
of
that,
take
to
maybe
a
few
different
projects
that
do
their
governance
slightly
different
and
point
people
to
these
as
examples
that
they
could
use
as
starting
points
if
they
wanted
to
understand
how
this
worked
as
a
whole.
And
then
you
get
your
outcomes,
you
get
a
general
set
of
patterns.
People
can
look
to,
and
hopefully
understanding
of,
why
these
patterns
work
and
take
them
from
successful
projects.
B
And
then
because
one
of
the
things
that
I've
been
asked
by
several
sandbox
projects
lately
is,
I
need
to
go,
do
a
governance.
Where
can
I
start,
and
of
course
you
tell
them,
go
look
at
this
project
or
that
project,
but
they
also
want
to
understand
why
and
what
patterns
and
so
by
pointing
them
at
some
projects
that
have
solved
for
it,
then
you
also
give
them
a
good
starting
point.
I
think,
if
you
have
those
three
things,
it
would
help
us
get
past
this
hurdle
without
recommending
just
one
way
to
do.
F
K
K
F
E
E
B
Yeah
and
and
just
one
of
the
simple
ways
to
do
that
is
whoever
your
top
body
of
maintainers
are:
don't
let
one
company
in
a
graduated
company
have
a
majority
of
those
maintainers
right,
because
then
you're
you're
forced
to
have
at
least
three
different
organizations
with
maintainers
and
they
have
to
coalesce.
In
order
to
do
that,
and
so
there
is
a
pattern
you
could
say
you
know,
no
one
vendor
has
so
control
of
the
project.
A
pattern
is
your
top
governing
body.
E
And
I
think
that's
why
we've
up
until
this
point
had
that
definition
of
multiple
maintainers
and
not
wanting
to
see
a
single
maintainer
having
control
over
the
project?
I
guess
what
we're
now
saying
is
code.
Committers
are
not
the
only
body.
There
can
be
a
another
level
of
body
who
and
are
we
saying
they
don't
make
technical
decisions,
but
they
are
a
body
to
whom
people
can
bring
complaints
if
they
believe.
E
F
So
liz,
I
think
one
out
one
one
artifact
that
could
be
created
by
a
steering
committee
is
a
road
map.
I'm
not
sure
this
is
the
right
thing.
Okay,
it's
brainstorming
live
here,
but,
and
you
know,
a
steering
committee
could
produce
a
three-month
a
roadmap
every
three
months
that
could
be
a
recommendation
and
that
reflects
that
it's
taking
input
from
end
users
on
high
level
direction
of
the
project.
I
think
that
would
go
a
very
long
way
to
dealing
with
this
issue.
G
Then
that's
a
very
different
situation
from
a
project
where
all
the
senior
maintainers
work
for
one
organization
and
they
don't
have
that
the
says
thing
number
one.
The
other
thing
I
want
to
remind
people
of-
and
I
address
this
on,
the
toc
mailing
list
is
well
it's
important
that,
whatever
structures
we
have
are
capable
of
taking
complaints,
we
can't
rely
on
complaints
as
a
way
of
determining
whether
something
is
wrong.
B
And-
and
I
I
like
what
you
said,
though,
with
the
whole
contributor
ladder
thing
what's
been
said
there,
because
it's
not
just
that,
somebody
who
approaches
the
project
knows
how
to
get
up
to
go
up
the
ladder
to
become
a
maintainer.
It
means
those
people
who
maintain
it
have
had
to
think
about
how
do
they
bring
in
new
people
and
how
does
that
process
work
for
lots
of
maintainers
who
just
want
to
go
sling
code
work
on
things.
B
They
may
be
great
at
getting
feedback
that
whole
world
of
mentoring,
bringing
in
other
people
is
foreign
to
them,
and
I
think
for
a
lot
of
the
folks
who
are
going
to
do
that,
they're
actually
going
to
struggle
with
this
and
giving
them
people
who
can
help
them
figure
this
out
and
understand
it
and
maybe
mentor
them
when
they
start
going
from
other
projects
who
already
know
how
to
do.
This
would
be
really
useful
and
kind
of
a
benefit
of
the
cncf,
because
right
now,
a
lot
of
projects
struggle
to
bring
in
new
people.
B
F
It's
also
important
to
retain
maintainers.
That's
been
a
big
challenge
that
I've
seen
with
smaller
companies.
Like
you
know,
boyan
mentioned
this-
that
you
know
somebody
comes
along,
contributes
for
a
year
and
then
for
some
reason
they
disappear.
So
you
need
a
sort
of
critical
mass
of
other
people
in
order
for
this
to
work.
I
You
know
I'll
share
our
experience
and
then
maybe
that
can
inform
from
the
discussion
we
have
about
90
repos
in
under
gnats
and
there's
there's
only
two
that
were
really
you
know
not
to
use
inflammatory
language
flagged
as
problematic
by
the
toc
and
and
they
were
our
server
repos.
So
if
you
look
at
maintainer
mix
as
a
whole
across
snaps,
we're
actually
pretty
good
in
these
two
repositories:
the
server
repositories
they
are
isv
led
and
and
cinedialed-
and
that's
that's
because
we
we
know
the
code.
I
We
have
efficacy
in
solving
problems
and
responding
quickly
to
to
bugs
they're
very
complex.
So
it's
not
a
weekend
project.
It's
not
something!
Somebody
can.
You
know
even
come
in
in
a
week
and
learn
it.
It
takes
a
dedicated
resource
and
we
kind
of
have
a
chicken
in
the
egg
problem
right.
We're
solving
these
problems
quickly,
we're
moving
very
quickly
the
project's
moving
quickly,
but
we're
doing
everything
right.
So
our
end
users,
don't
see
the
value
in
adding
a
resource
to
the
at
least
to
the
servers
they
do
with
clients
all
the
time.
I
So
I
would
argue
any
any
project.
That's
that's,
has
a
velocity
and
meaning
maintaining
and
gaining
adoption
and
users,
and
pr
in
particular,
if
they're
production
worthy,
if
they're
being
used
in
production,
they're
doing
the
right
thing,
and
I
don't
think
you
should
really
change
much
in
their
process
of
listening
to
user
requirements.
I
But
I
I
went
off
on
a
little
tangent
there
you
know
back
to
getting
maintainers.
We
have
tried
to
get
maintainers
for
the
servers
and
we
we
have
some.
We
have
a
couple
external
maintainers,
but
you
know
again.
This
is
this
is
an
area
where
we're
doing
things
you
know
we're
doing
things
very
good,
so
people
other
end
users,
don't
see
the
need
to
add
maintainers
to
these
particular
repositories
of
our
prod
project.
M
E
Well,
actually
so
long
as
it
solves
the
problems
that
we're
identifying,
which
seem
to
be
longevity
and
community
input
on
the
roadmap,
I
think
we're
saying
you
don't
have
to
have
walked
everybody
through
the
contributor
ladder,
we're
saying
you
have
to
have
a
contributor
strategy.
That
means,
if
somebody
really
wants
to
get
involved
in
your
project,
they
can
see
a
path
to
doing
that
and
that
you
would
accept
them
if
they
met
that
if
they
followed
that
path,
regardless
of
what
vendor
they
came,.
I
N
B
N
Colin,
I'm
sorry,
colin
and
so
part
of
the
other
thing
with
the
nats
project
and
cinada
is.
We
have
had
folks
that
do
have
a
vested
interest
in
gnats.
They
have,
they
know
nats
they've
learned
nats,
they
come
to
us
and
then
we
hire
them,
and
so
now
there
is
no
secondary
company,
now
they're
all
back
to
the
isv.
N
F
H
E
E
Then
you
know
any
governance
model
that
the
toc
believes
meets
that
those
would
solve.
Those
problems
should
be
acceptable.
I
think
we're
also,
I
mean
obviously
I'm
just
summarizing.
We
haven't
had
a
vote
here,
but
it
looks
like
there's
a
lot
of
support
for
requiring
some
kind
of
contributor
ladder
strategy
as
a
graduation
requirement.