►
From YouTube: CNCF TOC Meeting - 2019-04-02
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
C
A
F
F
F
B
B
B
B
B
B
F
F
F
F
You
know
we'll
go
through
the
community
kind
of
backlog
of
which
presentations
to
put
on
the
schedule
for
next
week
and
then
open
it
up
to
any
Q&A
that
folks
have
so
first
first
bit
of
news:
let's
go
next
slide
because
of
our
TOC
chair
election
results.
Liz
rice
has
won
the
TOC
chair
seat.
So
that's
awesome.
Good
news
she'll
be
leading
these
lovely
meetings
moving
forward.
F
D
F
Cool
awesome
in
terms
of
project
voting
updates,
so
OPA
was
announced
to
the
incubator
this
morning.
Voting
for
creo
and
fluency
are
still
going
on
and
those
are
for
the
incubation
and
graduation
levels
creo
coming
in
as
a
kind
of
a
new
project,
even
though
technically
lives
under
urban
80
SIG's
and
then
also
CN,
CF
SIG's
have
been
recently
approved
and
will
be
working
on
on
those
soon
which
I'll
cover
and
a
little
bit,
but
for
TOC
and
community
members.
F
F
Cool
alright,
so
you
know,
one
thing
we
have
coming
up
is
projects
that
live
in
the
sandbox
are
essentially
reviewed
by
the
TOC
on
an
annual
basis
based
on
the
process.
So
this,
basically,
we
almost
have
something
every
month
for
the
rest
of
the
rest
of
the
air
kind
of,
depending
on
how
you
look
at
it,
but
next
month,
Clawd
events
and
telepresence
will
be
on
kind
of
the
review
block
and
then
moving
on.
We
have
a
bunch
of
other
projects
that
are
kind
of
scheduled
throughout
the
year.
F
I,
basically,
did
it
all
the
way
up
to
the
end
of
2020
19
4
for
folks.
So
any
questions
are
concerned
about
this
just
kind
of
wanted
to
make
the
TOC
and
the
wider
community
aware
of
kind
of
what's
on
the
docket
in
the
future.
It's
a
you
know.
It
was
about
a
year
since
we
a
little
over
a
year
since
we
created
the
sandbox
level.
So
a
lot
of
these
things
are
kind
of.
Finally,
finally,
but
not
for
for
view,
I
have.
A
A
good
question
just
just
to
get
an
idea
of
precedence.
There
is
a
sandbox
project
who
wants
to
be
who
wants
to
go
for
incubation?
They
asked
me
if
they
should
wait
till
or
like
when
that
would
be
appropriate
I'm
just
wondering
in
the
past
how
people
waited
till
their
sandbox
like
annual
review.
I
know,
sandbox
is
new,
so
I
don't
even
know
if
there
was
precedent
here.
But
how
does
that
work?
They're.
F
F
F
It's
not
where
it's
not
required,
at
least
based
on
the
the
current
documentation
of
how
things
may
have
structured.
You
know
with
over
30
projects.
Now
you
could
imagine
if
we
did
that
it
would
eat
up
quite
at
the
time.
I
think
the
TOC
wants
to
do
that.
We
were
able
to
do
it.
I
would
just
be
worrisome
about
the
amount
of
time
that
would
take
I.
Think
it's
okay
for
the
TOC
to
say:
hey.
Maybe
this
particular
project
we
would
like
to
have
them
come
and
present
the
kind
of
see
where
things
are.
F
Maybe
we
feel
things
are
a
little
bit
shaky.
You
know
with
the
archiving
and
discussion
today.
Maybe
that's
something
that
could
be
an
option
if
there's
a
project
that
we
feel
isn't
doing
well
or
you
would
like
more
oversight
on
that.
That
could
be
one
route
but
I'm.
All
yours
like
it's
it's
kind
of
hard
to
do
this
in
a
scalable
fashion,
in
Prior
reviews,
I,
think
from
from
I.
D
Guess
have
two
sorts
on
that
one
is
yeah.
My
question
was
really
triggered
by
the
archiving
question
and
whether
we
should
have
a
bit
of
a
more
rigorous
sort
of
even
to
address
possible
archiving.
Perhaps-
and
the
other
thing
is
just
opening
the
question-
that,
if
we're
going
to
broaden
the
idea
of
having
more
sandbox
projects,
these
annual
reviews
can't
be
very
heavyweight.
We're
going
to
have
to
keep
them
pretty
lightweight
if
we're
gonna
make
the
admission
criteria
low.
So
we
might
need
to
think
about
that
yeah.
F
I
mean
I
totally
know
one
interesting
thing
about
the
archiving
discussion
is,
you
know,
last
year,
I
think
it
was
Alexis
brought
up
a
lot
of
you
know
it
would
be
great
if
we
would
have
like
a
project
health
dashboard,
so
you
could
kind
of
easily
see
the
status
of
projects
right
if
a
project
doesn't
have
a
commit
in
the
last
you
know
three
months
or
six
months.
Is
it
because
it's
super
mature
or
is
it
because
the
community
is
kind
of
dead?
F
So
we
took
an
initial
stab
at
that
and
I
put
the
link
in
the
zoo
chat.
They
get
to
kind
of
take
a
peek,
and
you
know
that
could
potentially
be
used
by
the
TOC
and
and
others
to
you
know
make
that
type
of
judgment
call.
But
you
know
all
yours
I'm
just
trying
to
figure
out
how
to
do
this
in
a
scalable
fashion.
F
I
I
think
that
the
proposed
model
for
scaling
this
is
the
SIG's
and
I
think
it
would
be
perfectly
reasonable
to
the
cigs
review
every
project
every
year,
whether
it's
sandbox,
incubation
or
graduated
for
that
matter
and
present
the
TSE
for
the
very
summarized.
You
know
we
think
it's
fine
to
stay
there.
We
think
it
should
graduate.
We
think
it
should
be
archived
at
cetera.
I
think
I
think
that's
the
proposed
way
of
scaling
this
okay.
J
I
think
maybe
one
thing
that
isn't
clear
is
whether
it's
okay
for
projects
to
go
into
the
sandbox
and
sit
there
for
a
long
time.
My
my
personal
view
is
they
that
should
be
fine.
I
know
of
a
number
of
projects
that
are
have
been
at
least
informally
chatting
about
like
hey.
We
just
need
a
neutral
ground
place
to
collaborate
on
a
project
between
several
companies,
and
I
don't.
I
don't
necessarily
think
that
the
sandbox
is
a
pipeline
of
projects
headed
to
graduation.
F
F
Well,
one
thing
to
Quinton's
point
is
as
someone
that
may
have
I,
don't
wanna
say
like
PTSD
from
from
the
Apache
foundation,
but
doing
kind
of
you
know
reports
all
the
time
from
a
project
thing
is
a
huge
time
sink,
so
my
advice
would
be
to
try
to
automate
that
as
much
as
possible,
so
whether
it's
you
know
improving
the
metrics
from
dev
stats
to
take
in
more
data,
but
like
a
lot,
a
lot
of
a
kind
of
review
could
be
almost
automated.
In
my
opinion,
versus
asking
project
maintainers
to
manually,
submit
reports.
I
Yeah
yeah,
that
seems
reasonable
to
me.
I
was
just
doing
some
math,
so
we
got
six
six
and
we
got
12
months.
So
potentially
every
sink
could
just
have
a
report
back
twice
a
year
to
say:
here's
all
the
projects
that
we
have
and
here's
our
take
on.
You
know
the
health
of
them
in
general
and
sort
of
call
that
a
day
and
that
that
could
be
a
you
know,
10
minute
slot
and
the
TSE.
I
You
know
once
a
month
kind
of
a
thing
you
would
have
one
sig
come
back
and
give
you
a
summary
of
all
of
their
projects
with
proposals
as
to
you
know,
things
that
might
be
put
up
for
graduation
or
things
that
might
be
put
up
for
archiving,
etc,
and
most
of
the
load
of
that
would
be.
You
know,
inside
the
signal.
F
So
a
lot
of
you
I'm
sure
aware
you
know,
given
that
the
schedule
for
Q
con
plenty
of
con
you
know,
Europe
was
posted
that
we
have
a
big
conference
coming
up
where
we
should
probably
get
around
10,000
folks,
which
is
a
little
bit
terrifying
at
some
level,
but
it's
awesome
to
see
the
community
grow
for
the
wider
community.
This
is
the
final
week
for,
if
you're
interested
in
sponsoring
at
any
level
or
doing
like
a
little
reception
or
whatever,
whatever
is
all
those
little
things
into
perspective.
This
is
the
final
week
to
do
it.
F
So
please
reach
out
to
you
know
our
events.
Team
events
at
scene
see,
if
thought,
oh,
if
you're
interested
in
sponsoring
and
of
course
we
have
China
North
America
events
recently.
As
an
interesting
note,
we
recently
did
a
kubernetes
day,
as
kind
of
you
know:
we've
gotten
some
feedback
from
from
the
community
that
we,
you
know
you
know,
be
good
to
have
like
kind
of
smaller,
more
regional,
focused
events,
and
we
did
one
in
India,
which
we
posted
the
videos
recently,
which
I
think
went
pretty
well.
F
I
know
if
Liz
you
wanna,
you
know,
share
some
thoughts
on
that.
Since
you
were,
you
know,
they're,
helping
read
that
about
I
think
it
was
a
kind
of
a
great
way
to
you
know,
grow
the
community
kind
of
more
regional
events
that
are
a
little
bit
smaller
in
focus,
but
Lizzie
ur
control
of
the
program
feel
free
to
give
some
thoughts.
Yeah.
D
For
sure
that
was
900
people
there,
who
gave
up
their
Saturday
and
seemed
extremely
excited
about
having
an
event.
You
know
local
to
them,
that
they
could.
You
know
they
could
they
could
get,
it
was
accessible
to
them.
We
did
it
as
a
single
track
event,
I
think,
maybe
going
forward.
We
want
to
look
at
maybe
having
two
tracks
cuz.
There
was
definitely
quite
a
spread
of
folks
who
are
new
to
the
whole
cloud
native
world
versus
people
who
are
really
very
experienced
so
having
a
bit
more
spread
of
topics
going
forward.
F
F
Quite
a
while,
but
you
know
I'm
kind
of
happy
and
announce
that
they
finally
have
come
to
an
agreement
on
merging
the
open
census
and
open
tracing
projects
under
kind
of
one
new
brand
that
they're
trying
to
come
up
with
under
the
community
haven't
chosen
this
kind
of
new
branding,
but
it's
hopefully
gonna
be
finalized.
You
know
fairly
soon
I
offered
open
consensus,
but
I
don't
think
they're
gonna
go
with
that
one.
F
Unfortunately,
in
terms
of
a
process
question
you
know,
if
you
know
that,
there's
an
opportunity
for
them
to
completely
present
to
the
TOC
and
wider
community
and
go
through
the
typical
project.
You
know
approval
process
that
we
already
have
in
place.
The
other
kind
of
way
to
think
about
this
is
when
the
link
Rd
project
kind
of
merged
in
conduit
as
link
Rd
to
they
essentially
presented
to
the
community
about
their
plans,
everyone
kind
of
okayed
it
there
was
no
formal
vote.
F
You
know
how
does
the
TOC
feel
this
should
be
approached
with
this
kind
of
new
moon
urged
entity,
because
they
intend
to
do
this
under
understand
CF,
so
it
could
just
be
folded
under
open
tracing
and
there's
a
new
brand
name,
or
they
kind
of
go
through
the
formal
process
we
have
in
place.
I,
don't
know
how
people
feel
about
this.
We've
kind
of
done
both
types
of
things
in
the
past,
so
I'd
like
to
kind
of
learn
from
the
TOC
in
the
good
water
community,
how
they,
how
they
feel
about
this.
A
K
Because
there's
a
question
you
know
as
to:
if,
if
something
wants
to
come
back
in
you
know
and
a
project,
let's
say
that
they
were
incubation
and
they
made
to
really
change
direction.
Should
they
automatically
come
back
in
as
incubation
or
should
they
go
back
to
sandbox
or
something
like
that,
so
it
does
seem
like
having
a
process
and
and
and
doing
a
vote
probably
makes
sense.
I
mean.
G
I
think
it
is
another
example
where,
essentially,
it
was
a
rewrite
reimplementation
of
a
part
of
the
project
that
you
know
was
sort
of
a
sub
incubation
inside
of
that
project
to
actually
do
a
new
effort,
and
so
I
think
you
know,
there's
sort
of
a,
but
what's
the
name
of
this
sort
of
the
boat
where
they
replaced
all
the
planks
and
it
was
like,
is
it
still
the
same
boat
like
as
these
projects
evolve
and
as
they
sort
of
renew
themselves?
Are
they
still
the
same
project
over
time?
K
No,
it's
actually
not
I've
I
thought
about
this.
A
lot
and
I
I
think
that
those
are
interesting
case
is
to
look
at
and
I
think
at
some
of
those
cases.
You
can
make
a
strong
argument
that
those
projects
should
have
come
in
as
a
separate
sandbox
project,
so
I
I
think
my
personal
feeling
is
that
we
should
do
the
process
and
if
they
want
to
come
in
as
an
incubation,
we
should
have
a
proposal
and
do
a
vote.
O'brien.
F
H
We
being
the
best
contemporary
example,
where
he'd
replaced
all
of
his
parts
over
time,
but
I
would
just
say
that
a
little
bit
finer
point
on
it.
I
think
everybody
agrees
that
this
couldn't
happen
in
a
stealth
way
or
in
a
way
that
the
community
is
not
aware
of
I.
Think
the
key
question
is:
what
should
the
default
be,
so
the
precedent
for
link,
Rd
and
conduit,
which
the
TOC
is
not
bound
by,
but
was
that
they
presented
to
the
TOC
independent
community?
H
Everybody
was
aware
of
it,
but
it
would
have
taken
a
proactive
vote
of
the
TOC
to
say
this
isn't
allowed
as
opposed
to
the
other
way
of
saying.
Oh
no,
it
takes
six
of
six
votes
to
allow
it,
and
I
would
just
point
out
that
there
is
a
tradition
of
deference
to
the
projects.
But
again
it
is
up
to
the
TOC
to
decide.
I'm.
D
I'm
slightly
leaning
that
way,
and
in
that
so
long
as
we
get
the
information
we
get
the
exposure
to
to
what
the
plan
is.
If
we
start
saying
we
have
to
have
a
vote
at
a
point
when
somebody
wants
to
import
some
code
into
a
project,
you
know
we're
not
going
to
go
to
the
logic
of
that
is
we
have
a
vote
every
time
somebody
wants
to
do
a
pull
request.
We're
not
gonna.
Do
that
say.
F
A
I
One
last
comment,
so,
first
of
all,
just
to
recognize
yeah
I
think
there's
a
there's,
a
big
slippery
slope
here,
where
you
know
certain
things
seem
clear
and
other
things
like
pr's
seem
clear
that
we
shouldn't
have
review
those
and
I
think
it's
very
difficult
to
sort
of
decide
ahead
of
time
on
a
general
rule
and
secondly,
if
the
seasons
are
going
to
be
checking
on
the
health
of
their
projects
every
six
months.
Usually
these
changes
don't
happen.
You
know
overnight,
like
a
big,
you
know
version
kubernetes
version,
one
to
kubernetes
version.
I
Two,
which
one
might
argue
is
a
you
know
major
implementation
and
would
require
another
vote
by
the
TOC.
Just
to
give
an
example
that
that's
something
that
the
six
should
presumably
escalate
as
and
when
required.
Rather
than
have
you
know
every
project
that
changes
version
number
have
to
perhaps
go
through
a
bit.
I,
don't
know
if
that
makes
sense.
But
what
I'm
suggesting
is
that
we
put
most
of
the
responsibility
on
six
to
identify
when
things
like
this
are
happening
and
and
escalate
them
to
the
TRC
when
they
think
it
is
appropriate.
G
F
F
Think
that's
enough
discussion
on
this
topic
look
forward
to
kind
of
an
update
soon
from
that.
So
next
discussion
point:
you
know
it
we've
been
discussing
this.
You
know
for
a
while.
Cn
CF
is
over
three
years
old.
Now
you
know
I
think
it's
healthy,
always
for
communities
to
essentially
sometimes
go
through
spring
cleaning
and
archive
things.
Don't
always
have
to
exist
within
you
know
the
project,
especially
as
technology
trends
and
maturities
and
communities
of
all
over
time.
F
So
we've
discussed
the
notion
of
formalizing
kind
of
archive
projects
and
also
you
know
related
to
that
also
having
kind
of
a
transparent,
Health
metrics.
So
it's
easier
to
kind
of
come
to
these
discussions.
So
there's
a
PR
out
there
with
a
basic
process
for
archiving
projects.
I
would
love
the
TOC
and
community
kind
of
take
a
look
at
that,
since
you
know,
I
think
it
needs
fresh
eyes
since
its
last
been
proposed,
and
then
you
know
just
like
with
anything
else
out
there
I
think
you
know
always
having
a
pilot.
F
You
know,
project
or
pilot.
Something
to
go
with
with
this
type
of
process
could
be
useful
to
kind
of
ensure
that
it
works.
So
so
basically,
two
questions
one,
you
know:
what
should
we
do
for
archiving
projects
and
do
we
have
any
candidate
projects
potentially
that
would
want
to
run
this
through
so
I'll
open
it
up
to
the
TOC
in
community
for
discussion
here.
D
I
think
we
all
probably
have
rocket
in
mind
as
a
possible
archiving
candidate
I
think
as
a
far
as
the
process
is
concerned,
I
think
an
important
part
of
this
should
be
going
to
the
maintain
is
of
a
project
and
saying:
is
this
something
you
want
to
come
and
present
about?
Do
you
want
to
do
you?
Consider
yourself
active?
Is
it
something
that
you
would
continue
to
benefit
from
by
being
in
the
scenes
yeah?
So
that
should
be
the
first
step
in
any
archiving
process.
D
F
F
Basically,
the
initial
thought
was,
you
know,
2/3,
you
know
super
majority
vote
for
the
POC
to
archive
something,
and
then
essentially
what
would
happen
is
the
project
would
essentially
just
live
under
the
Linux,
Foundation
and
NEC
and
CF
branding,
marketing,
stuff
or
dollars
or
whatever
would
be
essentially
removed
from
it.
It
would
just
kind
of
be
a
an
independent
project
that
just
lives
under
the
LF,
with
minimal
support.
Why.
G
G
F
E
F
Could
be
potentially
it
depends.
What
you
want
to
mean
by
archive
archive
can
mean,
like
you
know,
we
shut
down
the
repos
or
archive
can
mean
we
just
dissociate
any
CN.
Cf
branding
and
the
project
continues
kind
of
run.
How
it
does
you
know
whether
it's
you
know
they
come
in
every
once,
once
a
year
or
once
every
six
months,
yeah.
G
I
mean
I
just
the
thing
is
that,
like
you
know
it's
you
know
things,
don't
always
stay
dead,
and
so
the
question
is,
you
know
what
happens
after
that
who
gets
to
decide,
and
so
it
seems
like
if
somebody
submits
something
to
the
CN
CF.
Even
if
it
is
sort
of
in
this
you
know
atrophied
state
it
should
it
should
still
stay
within
the
CNCs
yeah.
Okay,
that's
fair
I.
F
I
F
L
F
L
L
No
jet
land,
so
a
couple
good
examples
in
the
now
open,
jazz
foundation
would
be
dojo
and
jQuery.
So
you
know
those
projects
are,
you
know,
continue
on,
as
you
know,
kind
of
projects
that
exist
and
are
essentially
in
archival
mode
and
have
moved
from
the
J's
foundation
from
the
agrarian
foundation
to
the
Jazz
foundation.
Now
to
the
Open
Jazz
foundation,
continuing
that
ongoing
coverage
of
having
the
governance
of
foundation.
F
All
right:
let's,
let's
move
discussion
to
the
PR
and
we'll
catch
up
on
this,
and
hopefully
we
could
come
to
a
conclusion
for
a
be
104.
The
archiving
process,
project,
presentation
meetings
so
yeah
we
started
to
do
these
last
month.
For
the
first
time.
You
know
we
have
a
backlog
that
we're
actually
starting
to
chip
away
at
which
is
awesome.
I
think
this
is
a
good
idea.
So
thank
you
to
whoever
proposed
us
to
have
a
meeting
dedicated
to
project
presentations.
The
the
next
one
is
coming
up
next
week.
F
I
have
one
project
slotted
right
now
that
already
volunteered
and
sent
a
presentation,
so
we
have
room
for
two
more
so
I,
don't
know.
If
there's
anything,
the
TOC
would
like
to
see
on
the
on
the
docket,
but
I
think
this
is
the
time
to
propose,
since
we're
only
about
a
week
away
from
from
that
particular
meeting,
I
need
thoughts
on
the
TOC
based
on
the
current
backlog
or
something
they
would
like
to
see.
D
Not
exactly
I,
don't
if
this
is
the
right
time
to
make
this
point,
but
I
think
I
mentioned
on
one
of
the
mailing
lists.
The
idea
that
those
backlog
items
that
are
allegedly
in
progress
in
the
backlog
I
really
feel
like
they
should
have
owners,
and
it
would
be
great
if
we
could
try
to
assign
some
owners
and
get
those
items
actually
kind
of
God.
Having
somebody
who
takes
responsibility
for
pushing
those
three.
F
D
Way
great
yeah
I
mean
it's
it's
things
like
you
know
these
graduation
applications
where
you
know
just
somebody
needs
to
kind
of
make
sure
that
it's
really
gonna
happen
and
that
we're
really
doing
the
whatever
G
diligence
we
need
to
do
actually
like
actually
taking
ownership
of
the
PR
would
help
clarify
who's.
Making.
These
things
happen.
F
F
All
right
so
we'll
we'll
figure
it
out
if
there's
project
that
wants
a
volunteer
for
the
next
meeting.
Let
me
know,
but
we
at
least
have
one
schedule
that
I
think
already
has
met
the
minimum
sandbox
sponsorship,
at
least
let's
go
on
to
the
next
slide.
Oh
final
call
that
if
you
know
any
students
out
there
that
are
interested
in
having
an
opportunity
to
work
on
ciencia
projects,
there
is
summer
code.
These
student
applications
are
closing
April.
Ninth.
We
actually
have
a
ton
of
projects
participating
on
as
part
of
this
process.
F
So
it's
an
awesome
program
so
highly
recommend
you
do
your
best
to
share
that
scene,
see
us
participating
this
and
students
applied,
given
that
the
the
date
for
student
application
closes
on
on
April
9th,
which
is
pretty
soon
cool.
Alright,
since
you
have
SIG's,
we
discussed
this
that
the
vote
kind
of
went
through
one
kind
of
new
bit
of
information
outside
of
the
process
being
approved.
Is
we
have
T
of
Steel
liaisons
for
the
initial
set
of
SIG's?
Thank
you,
Quinton
and
Alexis
for
driving
a
lot
of
of
this
to
get
it
off
the
ground.
F
If
you
go
to
the
next
slide,
the
kind
of
proposed
process
here
is
will
pilot
it
with
one
sig,
first
kind
of
in
the
governance,
security,
space
and
kind
of
get
that
going
trying
to
figure
out.
You
know
where
I
live,
how
we're
gonna
kind
of
document
it
and
get
up,
and
so
on.
So
we'll
start
there,
and
then
you
know
after
that
works
well,
we'll
follow
on
with
all
the
the
rest
of
the
SIG's.
So
anyone
have
any
questions
here.
F
You
know,
in
my
opinion,
the
folks
in
the
governance
security
space
have
been
more
than
willing
to
spend
the
time
to
kind
of
get
this
off
the
ground,
they've,
actually
volunteered.
So
that's
kind
of
how
I've
made
the
choice
versus
the
others
also
the
kind
of
safe
security,
whatever
the
name
they
have
for
that.
Current
group
has
been
kind
of
a
pilot
for
a
lot
of
the
initial
sig
process
discussions
and
so
on.
E
N
So
that
was
and
then
we,
you
know,
had
a
number
of
conversations
with
other
TOC
members
and
started
to
prioritize
the
white
paper.
So
it
was
really
a
matter
of
you
know.
Perhaps
it
was
a
miscommunication
on
priorities
of
the
TOC,
but
we
weren't
at
that
time.
A
TOC
we
weren't,
formerly
affiliated
with
the
CNCs,
so
we
didn't
focus
on.
We
focused
on
figuring
out
what
that
process
would
be
rather
than
taking.
You
know
worrying
about
what
the
direction
was.
N
D
Actually,
really
in
favor
of
using
this
safe
kind
of
proposal
processes
and
reviewing
those
working
through
those
because
those
could
be
used
as
a
model
for
other
six
that
haven't
even
started
yet
the
white
paper
output
is
a
valuable
thing
and
an
artifact
in
its
own
right,
but
it
won't
help
us
with
the
scalability
issue,
I
think
getting
processes
right.
That
really
will
help
us
and
I
know
that
the
folks
are
safe,
have
got
some
some
proposals
and
coming
together
that
may
help
us
with
the
other
SIG's
as
well.
F
D
F
G
We
want
to
bring
up
I
mean
there
was
a
great
discussion
going
on
in
the
chat
here
about
this
sort
of
flu.
Indeed,
flu
and
bit
thing
from
earlier,
and
you
know,
I
was
totally
wrong,
saying
that,
like
it
wasn't
part
of
the
project
from
the
start
and
I
think
there
is
an
interesting
discussion
of
like
you
know
when
we,
when
we
promote,
we
do
it
based
on
a
mean
project,
but
then
there's
these
sub
projects
and
sort
of
how
do
we
separate
out
different
maturity,
levels
for
sub
projects
versus
the
main.
O
G
I
think
kubernetes
is
a
great
example
of
this.
There's
like
a
gazillion
like
sort
of
like
sub
projects,
sub
efforts
that
are
not
at
the
same
maturity
level
as
the
rest
of
kubernetes
and
so
I.
Don't
know
what
the
answer
there
is,
but
I
think
you
know
to
some
degree
or
all
of
our
processes
really
sort
of
conflate
the
idea
of
project
and
in
specific
you
know,
code,
and/or,
artifacts
out
of
that
and
and
one
project
may
be
mature,
but
it
may
have
some
parts
of
it
that
are
not
quite
as
mature.
F
G
O
G
G
So
the
kubernetes
incubator
is
no
more
all
right.
What
we
did
is
we
replaced
it
and
then
Brendan
wrote
up
a
plan
around
this
with
sig's
can
sponsor
sort
of
side
projects
that
are,
you
know
still
within
the
Coverity
scope,
they're,
not
officially
part
of
the
kubernetes
or
release
they're
wholly
within
that
sig,
and
so
you
know,
Brian
in
the
comments
here
are
saying
something
like
an
alternative.
G
You
know
if
folks
want
to
self-organize
write
some
code,
you
know,
discuss
it
on
the
kubernetes
slack,
you
know,
adopt
the
the
CN
CF
COC,
all
that
type
of
stuff
they're
free
to
do
so,
but
that
doesn't
come
with
any
sort
of
endorsement
from
kubernetes,
because
one
of
the
things
we
saw
with
with
the
incubator
I
think
we
see
a
similar
thing
with
with
with
the
sandbox.
Is
that
sometimes
projects
we
want
to
be
part
of
it
just
to
get
sort
of
that
blessing,
that
sort
of
marketing
lift
of
being
associated
with
it?
G
But
I
guess
there's
a
question
I
think,
and
this
is
also
going
on
like
like:
when
does
it
go
too
far
right
like
if
you,
if
a
project
comes
in
and
doing
acts
and
over
time
it
changes
and
it
doing
something
completely
different
it
pivots
into
why
and
it's
a
whole
new
codebase?
Does
it
still
like
you
know,
I,
don't
know
we
haven't
hit
that
situation
yet
I,
don't
think.
But
it's
it's.
You
know
theoretically
possible.
Yeah,
sorry,
don't
want
to
don't
want
to
eat
up
people's
time.
I
just
wanted
to
correct
the
record
there.
G
F
No,
it's
it's!
It's
an
interesting
line
where
I
think
you
know,
we've
grown
so
much
that
projects
essentially
are
doing
their
own
subprojects
right
in
our
kind
of
oversight.
There
is
very
minimal
once
a
project
becomes,
except
that
we
kind
of
defer
to
them
to
run
with
their
own
governance
yeah
and
define
what
they
are
yeah.
F
A
Want
to
add
something
real,
quick,
Liz
I
think
brought
up
a
good
point
around
in
one
of
our
mailing
lists
around
defining
what
it
means
for
a
spec
to
graduate
from
the
CNC
our
graduate
from
incubation
and
become
a
graduated
project.
I'd
love
for
us
to
noodle
on
that
subject,
as
Joe
likes
to
call
it
at
some
point
with
the
wider
community.
If
we
have
some
time
on
the
agenda
at
some
point
like.