►
From YouTube: CNCF TOC Meeting 2023-05-16
Description
CNCF TOC Meeting 2023-05-16
A
B
B
B
So
we
can
have
this
discussion
today,
so
for
those
of
you
that
are
haven't
been
following
some
of
the
TOC
dialogue,
as
of
as
of
recent
we've,
been
asking
a
lot
more
around
a
lot
of
questions
around
project
health
or
status,
checking
in
with
them,
because
the
current
process
says
that
we
have
annual
reviews
for
sandbox
projects,
but
we
don't
have
the
equivalent
for
incubating
and
graduated
and
as
projects
move
between
levels,
they
experience
a
lot
of
changes.
Some
of
them
take
off.
B
They
see
widespread
rampant
adoption
and
then
in
other
cases,
some
of
them
don't.
So
what
do
we
do
with
projects
that
reach
in
an
active
state?
It
could
be
any
number
of
reasons.
Maintainers
could
have
taken
some
time
off
to
go
deal
with
some
personal
matters
or
change
companies
or
organizations,
but
we
might
expect
them
to
come
back.
So
I
want
to
open
the
floor
to
the
discussion.
We've
got
some
initial
questions
here.
That
I
think
can
help
drive
the
conversation
a
little
bit
in
this
space.
B
So
I
wanted
to
First
make
everyone
aware
that
we
do
have
several
dashboards
that
exist,
that
the
foundation
puts
together
for
us
that
from
Dev
stats
we
also
have
project
Health
table
that
lets
us
know
kind
of
like
what
are
the
most
recent
commits
of
a
project.
How
long
has
it
been
since
they've
had
them,
but
these
are
not
always
good
indicators
of
a
Project's
activity.
B
There
could
be
things
that
are
going
on
outside
of
the
actual
git
commits
and
the
repos,
so
I'm
gonna
silence
myself
real,
quick
and
kind
of
like
open
the
floor
for
discussion.
If
you
have
something
that
you
would
like
to
mention,
come
off,
mute
raise
your
hand
we'll
try
to
do
a
good
job
of
making
sure
everyone
has
the
opportunity
to
speak.
D
B
E
E
B
F
E
So
yeah
I
mean
it's
baby,
weird
for
me.
Considering
the
work
but
yes,
I
fully
agree
just
having
a
dashboard
is
not
going
to
be
super
effective
because
it's
a
case
of
putting
expensive
humans
in
front
of
a
screen.
Automated
reports
alerts
and
such
would
be
much
better
I.
With
my
project
hat
on
or
two
different
project.
E
Hats
on
a
I
fully
agree
with
Emily
that
this
must
be
automated
as
much
as
possible
and
only
if
certain,
if
certain
things
are
not
being
met,
should
we
even
actively
reach
out
and
really
introduce
much
of
a
process,
because
most
of
the
projects
are
really
resource
and
time
strapped
already
and
putting
more
burden
on
them
is,
is
not
precisely
why
you
use
a
project
join
an
umbrella.
The
other
thing
is
tracking
will
not
be
always
possible,
like
with
my
open
Telemetry
head-on.
B
B
It
basically
states
that
it.
The
project,
has
to
continue
to
meet
the
criteria
for
cncf
acceptance
and
the
criteria
changes
depending
on
what
level
it
is
that
you're
looking
at
for
the
most
part,
we
see
projects
that
come
in
at
the
sandbox
level.
We
have
some
criteria
that
is
already
defined,
but
it's
not
very
robust
and
when
the
TOC
is
evaluating
projects
for
sandbox
inclusion,
we
cover.
We
look
at
a
lot
of
different
things.
We
we
look
at
how
many
maintainers
they
have,
how
active
they
are.
What
kind
of
documentation
exists?
B
What
plans
do
they
have
for
the
project?
What's
the
direction
that
they're
heading
in
and
those
projects
provide
us
with
a
lot
of
information
about
what's
going
on
with
them,
so
that
we
can
help
make
those
decisions
but
for
incubating
projects?
That
criteria
looks
a
little
different.
Projects
need
to
be
ready
and
what's
ready
for
one
project
doesn't
look
the
same
as
another.
We
go
through
the
due
diligence
process.
B
We
do
have
criteria
that
are
defined
at
the
incubation
level,
so
my
question
is:
is
the
criteria
that
we
have
for
archival
enough
of
a
low
bar
for
determining
whether
or
not
we
need
to
re-engage
with
projects
if
they
come
up
as
inactive
and
how
could
we
potentially
programmatically
identify
indicators
that
would
allow
us
to
have
that
conversation
because
I,
don't
believe
based
off
of
the
criteria
that
we
have?
We
can
do
that
today.
E
I
think
there's
there's
at
least
three
and
a
half
substrands
in
in
answers
to
to
that
question.
Maybe
on
the
high
level
first
I
personally
believe
that,
yes,
there
should
be
more
scrutiny
on,
let's
say
a
graduated
project
than
than
the
sandbox
project,
due
to
a
simple
fact
that
it
is,
people
are
more
likely
to
trust
it.
So
there's
also
more
more
risk
of
sorts
in.
E
If
that
thing
goes
still,
I
lost
part
of
the
track
of
the,
but,
as
you
asked
me
directly
at
the
latest,
when
we
trigger
whatever
mechanisms
or
whatever
threshold
we
we
have,
we,
we
must
be
engaging
with
the
projects,
but
that's
like
a
kind
of
total
logic
anyway,
but
we
should
give
them
a
fair
warning
before
we
do
so,
and
at
least
like
ask
about
the
health
of
the
project
and
things
like
these
yep
and
I
forgot.
The
rest.
Sorry.
B
B
F
B
E
E
We
always
came
out
at
a
this
being
super
confusing
for
end
users,
the
back
and
forth,
and
also
about
this
like.
If,
if
you
are
graduated
and
you
you're
idly
enough
to
need
a
warning,
it
should
be
a
strong
warning
and
not
basically
a
soft
cushion
of
oh
I
can
basically
just
as
soon
as
I
ramp
back
up
everything
will
be
fine
and
dandy.
I
think
there
should
be
more
of
a
more
of
a
cliff
to
honestly
keep
people
motivated
at
that
point
where
things
are
already
pressing.
E
H
Craig
there
was
a
comment
that
I'd
put
on
one
of
the
issues
when
you're
talking
about
adding
more
requirements
to
graduation
and
I
think
it
was
more
like.
Let's
say
that
there
needs
to
be
a
current
diversity
of
Maintenance
in
the
event
that
the
project
otherwise
stayed
the
same
in
terms
of
adoption
and
no
longer
had
that
diversity.
It
technically
wouldn't
meet
the
criteria,
but
because
it
had
at
some
point
in
the
past,
it
would
remain
in
that
bucket,
and
so
they
didn't
come
up
in
the
context
that
Daniel
would
use.
H
But
I've
quoted
a
broader
idea,
which
is
what,
if
there
were
just
cncf
projects,
and
then
there
were
tags
in
the
kubernetes
label
sense,
rather
than
the
tag
sense
applied
to
them,
that
this
project
is
diverse.
Maintainership,
this
project
has
a
security
badge
and
so
on,
because
right
now
there
is
such
a
requirement
from
maintainers
and
companies
and
so
on
to
move
in
a
one-way
process
through
this
graduation
thing.
But
it's
not
necessarily
always
going
to
be
true
that
they
meet
all
of
the
requirements
and
Richard.
H
There,
like
there
will
be
times
where
I
graduated
project-
it's
not
going
to
need
archival,
it
won't
archival,
but
it
may
no
longer
meet
the
requirements
that
otherwise
a
graduated
project
would
be
set
out,
and
so
its
options
effectively
are
demoted
back
to
incubation,
which
requires
a
huge
effort.
Then,
if
it
ever
meets
those
requirements
or
just
have
an
approach
whereby
you
can
say
all
right,
it's
it's
all
these
things,
but
it's
currently
inactive
for
it.
B
So
I
think
badging
is
is
an
interesting
concept.
The
motion,
I
think
is
also,
however,
I
want
to
ensure
that
we
understand
what
the
value
of
doing
that
would
be
for
a
project,
because
there
is
a
lot
of
benefits
and
value
that
projects
get
at
certain
levels
from
the
foundation
and
the
motion
would
be
attained
in
what
is
available
to
them,
particularly
moving
from
incubation
to
sandbox.
B
B
It
allows
us
to
provide
better
visibility
and
transparency
to
potential
adopters
around
the
state
of
the
project.
There
may
be
some
adopters
that
don't
necessarily
way.
Maintainer
diversity
is
very
high.
They
just
want
to
ensure
that
it's
active
and
it's
moving
forward
for
us
in
the
TOC.
We
we
want
to
ensure
that
the
project
has
enough
maintainership
both
in
that
they
can
collab
collectively
and
collaboratively
drive
the
direction
forward
so
that
there
is
no
single
entity
that
can
change
the
direction
of
the
project
on
their
own
and
that's
kind
of
defined
in
governance.
B
And
we
allow
projects
to
do
that
to
set
those
limitations
for
themselves.
But
we
also
want
to
ensure
that
if
something
were
to
happen,
if
maintainers
want
to
take
a
vacation,
because
everybody
would
love
to
take
a
vacation
and
open
source
that
they
can
do
so
and
step
away
and
the
project
can
still
kind
of
move
forward
for
an
extended
amount
of
time
and
they
can
still
receive
commits
and
that
they're
not
relying
on
a
single
person
or
two
or
three
individuals
to
carry
the
entire
weight
of
its
progress.
Moving
forward.
B
I
J
G
B
Okay,
so
to
make
sure
I
understood
correctly,
the
your
consideration
for
security
activity
associated
with
the
project,
their
ability
to
make
sure
that
all
their
dependencies
are
up
to
date
that
they're
resolving
any
active
vulnerabilities
that
are
reported
to
them
that
they
have
a
good
response
window.
Is
that
did
I
understand
that
correctly
as
a
consideration.
J
F
F
F
How
can
we
rescue
this
project,
not
demoting
it
to
incubate?
It
I
think
that
should
be
a
truly
exceptional
turn
of
events.
For
that,
on
the
other
hand,
going
from
you
know
for
a
project
going
from
incubated
to
sandbox
I
think
that
is
something
that
that
we
could
talk
about
because
it
is,
after
all,
incubating
and
and
that's
kind
of
a
possibility.
B
B
It's
essentially,
as
Amy
stated
anything
that
hasn't
had
activity
for
120
days,
but
that
again
that's
looking
purely
at
GitHub
and
git
commits
it's
not
always
a
strong
indicator.
I
was
spending
some
time
this
morning,
actually
looking
at
one
of
those
to
try
to
understand,
what's
gone
on
with
the
project,
and
we
do
lose
a
lot
of
history
when
we're
relying
solely
on
get
and
get
versioning
and
all
those
commits
that
have
been
happening
over
time.
So
we
need
a
better
indicator
there.
B
E
E
B
Okay,
there
was
some
discussion
in
chat,
don
identified,
that
openmetrics
is
a
standard,
and
we've
talked
in
the
past
about
how,
depending
on
what
kind
of
project
it
is,
if
it's
a
standard
or
not,
their
activity
is
going
to
look
very
different.
So
that
might
be
an
occasion
where
having
badging
or
some
other
labeling
associated
with
project
is
a
enough
of
a
good
indicator
that
this
one
might
be
fine.
But
we
should
still
look
Craig
also
followed
up
in
chat
with
when
external
parties
or
adopters
or
other
entities
who
are
not.
B
And
this
for
me,
I,
would
expect
the
tag
or
the
TOC
to
re-engage
with
the
project
to
talk
to
the
maintainers,
because
there's
the
they're,
the
the
ones
that
are
responsible
for
owning
the
commits
and
moving
the
project
forward
and
engaging
with
them
to
understand
kind
of
where
they're
headed,
regardless
of
any
of
the
external
factors,
then
that
kind
of
brings
us
back
to
the
discussion
of
what
is
considered
healthy
and
active.
What
sorts
of
indicators
do
we
have
in
place
for
that?
B
A
Looking
at
the
health
of
a
project,
I
would
under
I
would
look
to
understand
issues
and
resolution
of
those
issues.
I'd
like
to
understand
releases
like
are
we
actually
moving
those
really
moving
those
issues
or
things
that
are
found
in
the
project
toward
a
release
and
releasing
things
that
are
fixed?
These
are
the
things
that
I
usually.
A
And
actually
I'll
Echo
Don's
statement
about
another
another
Health
metric
is
the
security
impact
right.
So
if
somebody
opens
a
security
issue
or
if
they're
dealing
with
some
kind
of
a
way
of
dealing
with
security
issues,
that's
also
an
indicator
of
health
because
it
usually
comes
after
the
project
is
actually
already
in
a
reasonable
in
a
reasonable
place.
For
the
most
part,
having
a
security
response
mechanism
is
really
important.
D
Yeah
yeah,
I,
I
think
actually
I.
Think
Ricardo
raised
a
question
whether
we
would
like
the
project
to
have
a
new
report.
Actually
I
think
that's
a
good
idea.
You
know
and
if
the
annual
report
can
include
some
indicators,
health
indicators
of
the
project
right,
you
know
like
security,
wanna
honorabilities,
which
was
rested.
You
know
back
on
before
and
also
some
like.
D
You
know
the
activity
level,
yeah,
maintenance,
Etc,
and
then
you
know
if
we,
if
that
report
was
you
know,
we
see
some
some
issues,
I
think
it's
better
to
combine
that
with
annual
review
or
or
we
can
have
a
I
think
it's.
We
need
to
give
a
chance
for
the
apartment
Tenors
to
explain.
You
know
like
you
know.
If
we
see
some
issues,
why
those
issues
and
then
we
can
decide
on
what
to
do.
I
also
agree
with
Charles
comment
on.
D
You
know:
we
need
to
treat
The
Graduate
graduated
project
differently
than
sandbox
or
incubating,
because
once
we
approve
those
projects
to
be
a
graduating
project,
I
think
you
know
there
will
be
quite
some
users
using
it.
So
we
need
to
put
in
extra
I,
think
care
and
effort
to
make
sure
those
projects
should
not
go
to
the
archive.
You
know
that
status.
B
There
was
also
a
question
in
chat
around
whether
or
not
how
long
it
takes
to
reviews
and
close
out
PRS
or
issues
is
a
good
indicator
from
a
recent
discussion.
I
had
with
one
of
the
companies
that
does
security
audits
for
projects,
it's
not
always
a
good
indicator
of
activities.
There
are
some
vulnerabilities
or
design
flaws
that
do
exist
within
projects
that
just
take
an
extremely
long
amount
of
time
to
get
resolved
and
require
a
lot
of
individuals,
involvement,
so
leveraging
kind
of
the
time
that
a
PR
has
been
open.
B
Isn't
always
a
good
indicator
same
thing
with
issues.
It
could
also
be
that
the
projects
that
their
roadmap
and
they're
going
to
work
on
those
issues
that
are
defined
underneath
of
their
Milestones
first
and
foremost,
because
it's
entirely
up
to
them
to
prioritize
what
work
it
is
that
they
would
like
to
do.
Nikita
had
a
good
suggestion
or
observation
around
what
kubernetes
currently
does
and
potentially
re-leveraging
some
of
that
prior
art
I,
like
the
idea
of
a
maintenance
mode
for
projects
that
are
they've
kind
of
capped
on
the
amount
of
voracious
activity.
B
Ricardo
had
a
good
suggestion
on
coming
up
with
indicators
for
each
level.
Yep
I
think
we
we're
gonna
we're
gonna
go
down
that
path
as
well
as
looking
at
automating.
The
detection
of
those
indicators,
so
I
think
I
think
we're
on
an
agreement
around
that
one
Josh
added
around
metrics
or
what
triggers
the
TOC
member
investigating
I
think.
That's
still
up
for
discussion.
B
B
So
I
think
we
have
a
culmination
of
a
lot
of
really
good
ideas
that
need
to
be
pulled
together
into
like
some
different
options
that
we
can
start
exploring,
but
I
want
to
know
who,
so,
in
addition
to
the
TOC
looking
at
the
the
activity
of
projects,
what
about
tags?
What
about
other
maintainers,
whether
what
about
adopters
they're
going
to
be
looking
for
different
sets
of
information.
B
E
Three
points
so
far
for
who
I
think
TUC
and
project
maintain
is
primarily,
maybe
also
tag
attacks
to
who
does
it
I
somewhat
strongly
believe
cncf
Steph?
The
reason
why
I
believe
this
and
I
don't
think
this
is
something
which,
which
should
be
at
least
led
by
the
tags
as
the
unfortunate
one
who
did
three
full
due
diligences
as
part
of
a
little
bit
of
a
test
balloon
within
type
observability.
B
G
So
I
was
just
I
think
that
this
should
be
for
adopters
and
in
users.
I
think
this
information
is
very
very
useful.
I
had
a
question
for
Craig,
which
was
if
he
was
suggesting
to
add
badges
in
addition
to
the
maturity
levels
or
just
drop
in
the
levels
completed,
but
he
already
answered
in
the
chat
and
the
concern
there.
We
should
also
ask
end
users
what
they're,
using
this
maturity
levels
for,
because
it's
kind
of
a
stamp
on
the
project
and
it's
quite
kind
of
useful
to
have
these
levels.
H
I
G
We
have
a
lot
of
indicators
like
browsing
through
the
projects
might
be
a
bit
more
complicated,
so
yeah.
Maybe
maybe
we
need
to
to
ask
the
end
users
as
well.
What
do
you,
what
they
see
the
benefit
of
the
levels
and
adding
badges?
What
you
could
bring
I?
Think
it's
a
great
idea.
Yeah
definitely
has
value
for
end
users.
The
current
levels
right
now.
B
So
if
you're
interested
in
the
moving
levels
discussion
and
how
potentially
that
could
be
changed
and
shifted
to
provide
a
more
healthy
ecosystem
for
all
of
our
projects
and
a
positive
experience
for
all
of
our
project,
adopters
and
tags
as
well,
please
check
out
that
if
someone
has
it
handy,
I'd
appreciate
you
dropping
it
in
the
chat
for
everyone
to
follow
up
on
so
I'm
hearing
that
badging
has
a
potential
value.
Add
here
for
understanding.
B
What's
currently
going
on
with
projects
hearing,
definitely
a
yes
to
an
annual
reporting
mechanism
that
needs
to
be
driven
by
the
current
level
that
a
project
exists
in
whether
or
not
it's
sandbox,
incubation
or
graduation,
and
that
graduated
projects
definitely
need
to
be
treated
different
and
I.
Think
Josh's
point
that
it
should
be
a
rescue
effort
for
them
is,
is
pretty
spot
on
and
that's
kind
of
the
behavior
mechanism
that
the
TOC
has
been
following
with
some
of
these
projects
as
we
are
alerted
to
them.
But
that
is
a
reactionary
mode.
B
We
need
to
be
a
little
bit
more
proactive
on
some
of
those
indicators,
so
I
think
my
next
question
for
everyone
is
one:
do
you
have
any
other
observations
or
any
other
gotchas
that
we're
not
seeing
here
and
then
two?
What
do
we
want
to
do?
Next?
With
this,
we've
had
a
lot
of
really
good
ideas.
We
need
to
start
moving
them
together,
thanks
Don
for
posting
that
in
the
chat,
how
do
we
want
to
move
forward.
B
E
F
B
B
How
this
all
is
intended
to
work
and
then
from
there
going
through
a
public
review
and
comment
on
whether
or
not
the
process
that
we're
going
to
Define
here
Works,
whether
or
not
the
indicators
is
also
good.
That
may
require
engaging
with
the
end
user
and
the
adapters
to
understand
what
they're
looking
for
it
may
require
engaging
with
all
of
the
tags
to
make
sure
that
they
are
invested
and
understand
what
their
roles
and
responsibilities
are
in
this
process.
B
A
So
it's
the
definition
of
this
just
to
look
at
the
different
indicators
for
the
health
of
a
project
and
figure
out
how
to
derive
them
from
the
project
itself
or
like
like
what
again
I'm
still
struggling
to
understand,
like
I,
feel
like
we
need
at
least
a
version
I
need.
We
need.
We
need
at
least
another
rendition
of
the
document
or
the
notes
that
you're
putting
together
so
that
we
can
break
this
up
into
things
that
could
be
taken
on,
because
at
the
moment
it
feels
like
it
feels
pretty
nebulous
yeah.
B
B
B
B
All
right,
so
what
I'll
do
is
I'll.
Take
the
action
I'll
go
ahead
and
write
up
the
summary
for
what
it
is
that
we're
looking
to
do
kind
of
the
different
project
areas.
What
some
of
the
suggestions
have
been
around
here,
I'll
tag,
the
individuals
that
expressed
interest
on
it
and
I'll
make
sure
that
this
is
available
in
the
TOC
channel
for
anyone
to
stop
by,
as
well
as
the
tag
chairs
channel
for
any
of
the
tag
chair
members
that
were
unable
to
participate
today.