►
From YouTube: CNCF TOC Meeting 2020-09-15
Description
CNCF TOC Meeting 2020-09-15
A
B
C
D
B
Now,
before
I
move
forward
with
the
topic,
I
would
like
to
introduce
what
exactly
the
tech
radar
is
in
as
a
term
and
why
exactly
it's
such
an
important
tool
within
the
ecosystem
at
the
moment
now,
attack
radar
is
an
assertive
guide
or
quite
opinated,
guide
on
the
emerging
tool
within
the
ecosystem.
It
actually
aims
to
provide
these
context
of
the
tooling,
which
are
used
currently
by
the
end
user
company.
So
this
is
actually
quite
important.
B
It's
focused
on
the
end
users
and
what
they
utilize
at
the
moment
in
their
stacks
and
the
tech
creator
aims
to
showcase
three
main
areas
or
female
levels
of
adoption
or
categories
for
every
single
tool.
It's
going
to
be
adopt,
adopt
trial
and
assets
with
the
adopt
level.
There
is
a
clear
recommendation
to
use
this
technology
in
production.
It
actually
showcased
quite
stable
features,
and
it
provides
a
solution
for
the
current
problem
or
whatever
they
want
to
solve.
It's
actually
solved
with
this
particular
tool.
B
In
the
trial
level,
there
are
usually
the
tools
which
are
categorized
as
they
actually
aim
to
solve
part
of
the
problem,
but
at
the
same
time
there
is
some
success
with
them,
so
keep
an
eye
on
them
and
make
sure
to
adopt
them
or
poc
them.
If
you
would
like
to
adopt
anything
else,
and
the
ss
is
going
to
focus
on
pretty
much
more
of
like
emerging
technologies,
they
definitely
will
focus
more
on
solving
future
problems
into
the
technology.
So
there
is
definitely
something
to
keep
an
eye
on
in
the
future.
B
Now,
with
the
technology
radar,
there
is
a
theme
for
every
single
one
of
them,
and
this
particular
one
is
going
to
focus
on
observability
and
observability,
actually
is
quite
in
a
core
kind
of
functionality
in
every
single
company,
because
we
require
that
visibility
even
like
the
company's
success
can
is
not
able
to
be
measured.
If
you
don't
have
a
good
observability
stack,
so
it
will
mainly
focus
on
functionality
such
as
logs,
metrics
and
tracing,
and
currently
the
technology
radar
has
been
curated
by
a
radar
team.
B
B
They
will
be
able
to
add
new,
tooling
or
new
instrumentation
mechanisms
based
on
what
they're,
actually
using
their
stack
at
the
moment
and
they'll
be
able
to
as
well
categorize
those
tools
with
the
levels
we've
mentioned
before,
adopt
trial
and
assess
and
there's
actually
a
hold
vote
as
well,
which
means
that
the
company
don't
really
recommend
that
tool
to
be
used
in
the
future.
The
tech
writer
actually
aims
to
showcase
a
good
example
of
what
is
usable
now,
rather
than
what
should
not
be
used.
B
So
only
the
three
levels
are
presented
at
the
moment
and
with
this
observability
tech
radar,
there
were
more
than
almost
380
points.
If
there's
going
to
be
the
next
slide,
so
283
votes
and
these
are
coming
from
32
companies,
and
you
can
see
some
of
the
companies
all
the
logos
showcased
over
here.
When
you
look
into
the
number
of
employees
for
every
single
company,
there
is
a
slight
tilt
towards
the
companies
which
have
more
than
1
000
employees.
B
B
B
The
trial
level
is
going
to
be
composed.
It's
going
to
be
the
next
slide.
It's
gonna
be
composed
of
tools
such
as
jager
splunk,
light
steps,
that's
the
cloud
virgin
sentry.
Now
these
tools
have
a
very
good
kind
of
amount
of
votes
across
different
levels
as
well.
So
that's
why
I
think
the
radar
team
they
opted
to
put
them
in
the
trial
category.
But
if
you
look
into
the
distribution
of
this
drawing
some
of
them
have
been
around
for
quite
a
long
time.
B
B
Now
this
was
one
of
the
most
interesting
personally
for
me
areas
because
most
of
these
tools,
they
have
been
around
quite
recently,
and
I
think
there
is
a
wide
awareness
of
these
tools.
The
companies
have
been
widely
pocking
them
and
trying
them
within
their
stack.
However,
they
didn't
move
completely
to
potentially
a
production
environment
yet
so
this
is
something
definitely
to
keep
an
eye
on
which
again,
for
example,
if
thanos
they
have
potentials
to
solve,
like
blogs
injection
at
scale,
so
something
to
again
to
keep
an
eye
on
in
the
future.
B
B
Now,
if
you
look
into
all
of
those
tooling
which
we
have
on
the
radar
at
the
moment,
most
of
them
are
going
to
be
open
source
and
some
of
them
are
going
to
have
a
sas
provider
actually
coming
with
that
extra,
like
enterprise
support,
if
need
be,
or
the
support
team
itself,
with
the
this
particular
theme
as
well,
there
was
this
balance.
Well,
a
balance
could
be
seen
between
actually
running
the
product
in-house
and
actually,
or
vice
versa,
making
sure
that
a
sas
provider
will
provision
those
capabilities.
B
So
there
is
a
verifying
balance
between
in-house
build
or
in-house
maintenance
of
the
open
source
tools
or
paying
for
them.
The
second
theme
is
going
to
be
focused
about
on
the
what's
going
to
be
the
next
slide,
yeah
there's
going
to
be
no
consolidation
in
the
observability
space
now,
based
on
the
votes
currently
or
for
this
decorator.
B
Most
of
the
companies
are
going
to
use
between
five
and
ten
different
tooling
within
their
observability
stack,
and
what
it
actually
means
is
that
when
we
talk
about
kubernetes,
we
say
that
there
is
not
one
platform
which
is
the
same,
and
I
think
this
is
applied
for
the
observability
stack
as
well.
There
is
not
one
observability
stack
which
is
going
to
incorporate
the
same
tooling
or
provisioning,
the
same
solutions
or
same
functionalities,
and
that's
why
we
see
that
companies
actually
opt
to
use
different
tools.
B
Yes,
another
thing
which
was
actually
outlined
here
is
that
it's
easy
to
adopt
new
tools
rather
to
then
rather
than
migrate
to
new
tooling.
Now
observability
is
something
which
everyone
wants
within
their
stack.
However,
at
the
same
time,
if
you
incorporate
a
new
feature,
if
you
have
a
new
tool
that
will
come
with
a
new
observability
endpoint,
potentially
so
there's
kind
of
this
expansion
growth
of
the
tooling
within
a
company-
that's
why
you
don't
have
consolidation,
but
at
the
same
time,
it's
difficult
to
fully
migrate
to
a
different
system
as
well.
B
So
that's
why
we
have
like
different
components
and
different
tooling
taking
care
of
different
functionalities,
and
the
last
thing
which
was
identified
is
that
prometheus
and
grafina
are
frequently
used
together.
This
is
something
which
is
interesting.
It's
kind
of
a
natural
outcome.
Nowadays,
if
you
run
prometheus,
there
is
going
to
be
a
grafana
and
vice
versa,
actually,
the
prometheus
team,
they
deprecated
the
prom
dash
in
four
years
ago,
or
so
in
favor,
for
a
graffana
dashboard.
B
So
there
is
a
clear
association
between
how
the
law
should
be
ingested
differentiates
and
a
potential
visualizer
with
grafana
as
well
and
as
well.
The
community
quite
heavily
focused
on
provisioning,
the
documentation,
different
kind
of
examples
which
are
focused
on
deploying
prometheus
and
grifana
side
by
side,
and
these
are
pretty
much
kind
of
the
main
themes
which
were
outlined
all
together
and
overall,
we
can
see
that
they
take
radar
for
observability.
B
If
we
go
to
the
next
slide,
so
the
decorator
for
observability
has
kind
of
different
level
of
adoptions.
As
expected,
we
can
see
that
some
of
the
tooling,
which
are
very
stable,
they
are
very
widely
used
and
quite
commonly
used
in
the
big
companies,
and
these
are
outlined
by
adoption.
The
trial
itself.
B
I
think
there
is
an
area
which
is
a
good
step
for
well
matured,
new
projects
and
projects
which
have
been
around
for
quite
a
while,
but
they've
been
able
to
transform
and
keep
up
to
date
with
some
of
the
new
kind
of
principles
and
trends
within
the
technology.
So
that's
kind
of
an
area
for
kind
of
side
by
side,
new
and
emerging
technology.
B
While
in
assess,
we
have
again
new
standards,
new
new
way
of
observability,
so
something
which
definitely
will
solve
the
future
problems
we're
talking
about
scale
and
enterprise,
and
if
we
go
to
the
next
slide,
yes,
there
is
a
new
initiative.
Actually,
there
is
a
new
endpoint
to
see
all
of
these
tech
creators.
That's
going
to
be
on
radar.cncf.io.
B
That
will
contain,
of
course,
the
the
diagram
itself
with
the
main
takeaways
and
some
of
the
reasoning
behind
that,
including
the
tech
radar
team
and
currently
there
is
this
decorator-
is
going
to
be
deployed
or
put
together
every
single
quarter.
So,
if
you'd
like
to
vote
on
the
next
theme,
please
do
so
and
that's
going
to
be
on
the
next
slide
as
well.
So
currently,
the
votes
are
on
a
github
issue.
So
please
be
aware
of
that.
B
If
you'd
like
to
choose
any
particular
thing,
please
vote
and
if
you'd
like
to
actually
vote
for
some
of
the
technologies
in
this
ecosystem,
please
join
the
end
user
community.
Only
the
engineers
are
users
are
able
to
input.
All
of
these
data
points,
it's
very
end
user,
driven
rather
than
vendor,
driven.
So
there's
going
to
be
the
next
slide
as
well,
and
the
last
slide
is:
if
there
are
any
feedback,
you
would
like
to
improve
or
add
new
additional
features.
The
decorator
or
any
new
information
you'd
like
to
get
from
these
data
points.
B
C
B
It's
32
companies,
but
we
have
they
actually
had
300
almost
300
data
points
so
based
on
their
usage.
Now
I've
seen
cortex
mentioned
here
here
and
there
I
was
actually
surprised
as
well.
That
cortex
is
not
on
the
radar,
especially
when
we're
looking
at
the
adoption
companies
for
cortex.
There
are
quite
a
few
companies.
I've
been
using
cortex
quite
heavily
as
well
in
production.
B
I
think
this
is
like
going
back
to.
We
need
more
users
to
actually
have
their
input,
and
this
is
something
which
I
think
the
cncf
is
working
on,
but
it's
all
about,
like
it's
not
like
cortex,
is
not
used.
It's
just
like
it's
not
represented
well
enough
on
the
radar
and
as
well.
There
are
more
than
tools
I
think,
voted
on
in
the
overall
in
the
spreadsheets,
but
there
is
a
kind
of
a
choice
to
have
a
limited
amount
of
tooling
on
the
radar
not
to
make
it
too
overwhelming
overall.
C
C
C
D
D
If
you
come
from
a
vendor
company,
then
the
way
to
contribute
to
this
is
to
ask
your
end
users
to
join
and
to
vote
on
the
things
that
they're
using
it's.
Not
it's
not
a
like.
You
know,
get
your
end
users
to
join
and
then
you'll
definitely
end
up
on
the
radar,
but
it's
also
a
great
way
for
them
to
get
involved
with
the
community
and
get
engaged
with
open
source.
So
it's
a
good
way
to
do
it.
D
Yes,
the
point
about
feedback
being
funneled
to
the
cigs,
so
I
had
a
chat
with
rishi,
who
is
the
chair
of
the
sig
observability
group,
and
he
I
don't
think
he
is
here
today.
Is
he
yeah?
I
think
he
had
a
clash
today
today,
oh
you're,
here,
okay,
awesome.
I
think
you
should
weigh
in
then,
since
we
had
a
chat
about
how
what
sig
observability
can
do
with
this
information.
G
With
both
my
prometheus
and
my
sister's
vulnerability
had
on,
I
would
like
to
enable
end
users
to
onboard
themselves
onto
the
more
modern
solutions
amongst
the
survey.
Of
course,
there
was
at
least
one
surprise
in
that
list,
at
least
to
me,
and
basically,
what
cheryl
and
me
talked
about
is
to
to
create
a
kind
of
short
questionnaire
of
actually
actionable
things
which
we,
as
a
community
of
maintainers
and
six
can
provide
to
end
users.
What
are
their
main
main
pain
points
like
it
could
be
applied
from
here?
G
It
could
be
how
to
migrate
from
step
c
to
prometheus.
It
could
be
whatever
like
come
up
with
a
few
of
those
questions,
send
them
to
the
end
user
community
and
have
the
end
user
community
choose
what
type
of
content
gives
them
the
most
value
to
to
use
modern
technology.
Basically,
and
if
anyone
has
any
suggestions,
we
have
the
sick,
observability
call
right
after
the
toc
meeting
and
you're
more
than
welcome
to
join
or
you
can
send
email
to
me
or
you
can
poke
the
permissions
team.
All
of
those.
D
D
D
H
You
know
in
specific
projects
that
have
been
hard
to
for
users
to
overcome,
and
that's
in
part
why
a
specific
project
is
still
out
on
the
periphery,
like
just
some
of
those.
Some
of
those
detail,
like
you,
can't
put
all
those
details
into
the
you
can't
digest
all
those
in
a
in
a
picture,
and
so
I
think
that
that's
kind
of
an
example
of
like
if
there
are
specific,
pr's
or
issues
or
or
maybe
those
things
haven't
been
documented.
H
That
old,
like
you,
said
ultimately
getting
that
that
back
to
the
project,
maintainers
is
kind
of
the
gold
the
cigs
can
can
potentially
help.
In
that
regard,
let
me
brainstorm
on
a
different
perspective,
and
that
is
that,
like
in
sig
network,
there's,
we've
formed
a
service.
Mesh
working
group.
Part
of
the
goals
of
that
group,
is
to
put
forth
common
patterns
of
use
and
can
curate.
H
You
know
curate
those
patterns
as
things
that
end
users
conceptually
could
either
learn
from
or
inform,
and-
and
we
don't
we're
not
connected
in
that
way.
Today
we
don't
have
a
or
I
don't
know
that
we
have
a
like,
or
at
least
facilitated
through
the
cncf.
I
don't
know
that
we
have
a
vehicle
for
sort
of
exchanging
those
in
advance
of
publishing
them.
C
D
D
H
Is
nice
I'll
also
interrupt
to
say
that?
Well,
it's
it's
like
absolutely
necessary
for
a
couple
of
reasons
that
they
there
is
a
divider
that
like
not
all
of
that
is
open.
You
you'd
articulated
one
of
those
and
another
one
that
I
would
say
is
just
that
having
been
on
both
sides
of
that
line
that,
like
with
my
end
user
hat
on,
I
would
say
we
don't.
We
don't
want
those
thinking,
vendors
here
kind
of
getting
in
the
like.
H
D
D
I
think
it's
very
hard
for
a
group
of
people
to
just
collectively
come
up
with.
You
know:
here's
our
top
three
pain
points.
You
know.
If
it
was
that
easy,
then
they
would
just
go
to
file
an
issue
or
vote
up
on
an
issue,
so
the
I
think
some
of
these
also
are
not
things
that
are
well
encapsulated
as
issues.
D
For
example,
one
of
the
companies
who
responded,
who
a
lot
of
these
companies
use
many
many
tools
right
as
katie
was
saying.
There's
no
consolidation,
and
one
of
the
reasons
is
because
in
some
way
many
companies
observability
is
not
a
core
business
function
or
business
value
to
them
and
therefore
investing
the
time
to
move
away
from
an
existing
observability
solution
to
a
new
one
is
a
very
hard
sell.
D
You
know,
and
that
sort
of
thing
is
not
a
fault
of
the
project.
It's
not
an
issue
that
can
be
resolved.
It's
just
how
the
observability
space
works
and
I
think
that's
different
from,
for
example,
the
first
radar
in
ci
cd,
where
there's
a
benefit
to
having
everybody
on
one
solution
or
having
everybody
on.
You
know
all
your
developers
using
the
same
cd
solution
compared
to
observability,
where
there's
benefit
to
having
a
few
different
ones,
because
maybe
there's
different
strengths
or
different
approaches
in
different
tools.
D
I
I
You
know
when
you've
got
an
install
base.
You
know,
adopting
a
new
technology
is
going
to
be
a
challenge
and
uncomfortable
right,
so
I
think
it
would
still
be
helpful
since
this
is
you
know,
a
technology
radar
if
there
are
business
conditions
that
influence
their
assessment,
somehow
capturing
that,
so
that
we're
not
trying
to
solve
technology
problems,
but
you
know
get
an
understanding
of
kind
of
the
you
know.
The
real
life
business
impacts
that
also
apply.
D
Yeah,
no
steve-
that
is
a
that's
a
great
point
and
one
that
I
think
this
is
where
the
the
sigs
and
the
project
maintainers
should
work
directly
with
end
users
to
figure
out
these
points.
I
don't
think
I
think
it's
very
hard
for
people
to
just
spontaneously
say
here
are
the
reasons
why
why
we're
not
moving
to
this
technology
or
what
our
pain
points
are
here,
but
I
think
in
a
discussion.
D
D
J
J
What's
the
business
use
case,
I
mean
we
have
so
many
different
lines
of
business
and
internal
groups
and
there's
so
much
different
uses
of
technology,
depending
on
sort
of
where
it's
at
so
it's
not
possible
to
just
distill
this
down
to
here's
the
business
use
case
for
this
thing,
so
I'm
with
cheryl,
you
know
more
real
engagement
with
end
users
throughout
the
process
and
the
lifetime
of
the
projects
versus
trying
to
you
know,
pull
snippets
off
off
radars.
The
radar
is
great,
but
it's
not
gonna.
I
K
So
I
think
what
it
kind
of
read
between
the
lines,
it's
great,
that
you
have
product
adoption
in
there
that
it's
an
honest
feedback
from
end
user.
That's
all
amazing,
but
you
also
focus
on
guidance
why
certain
technologies
are
where
they
are.
Why
end
users
see
them
where
they
are
say
for
users
as
well?
We
are
very
good
at
metrics,
but
we
unlock
some
z
but
we're
just
moving
into
tracing,
or
we
have
certain
use
cases
where
actually
we
just
get
enough
out
of
these
technologies
or
using
certain
technologies
only
in
certain
areas.
D
D
C
C
C
D
So
the
the
definitions
are
very
specific.
For
this
reason,
putting
something
in
assess
or
in
child
does
not
mean.
This
is
a
bad
solution.
It
just
means
there
was
not
broad
enough
consensus
to
say
positively
that
everybody
who
uses
cloud
native
should
adopt
this
thing,
but
it
is.
It
is
a
very
hard
line
to
it's
a
very
subtle
distinction.
C
D
E
Yeah-
and
I
think
a
good
point
was
brought
up-
that
not
every
cncf
project
is
everybody
use
it
kind
of
thing.
Some
are
going
to
be
for
specific
use
cases,
so
there
isn't
just
the
the
column
of.
Should
everybody
use
it
because
then
you'd
never
have
specialized
tooling,
which
of
course,
you
need
right.
E
If
you're
going
to
scale
really
big
you're
going
to
be
different
than
somebody,
you
know
and
really
broad
and
have
many
clusters
you're
going
to
have
somebody
different
than
you've
got
a
small
setup
right,
and
so
there
there
are
other
angles
other
verticals
to
look
at
as
well,
including
should
everybody
adopt
it
as
far
as
if
you're
measuring
success,
and
I
think
that
would
maybe
be
useful
to
put
into
context
and
to
take
into
account.
We
shouldn't
measure
everybody
by
the
same
stick.
If
it's
not.
D
M
I
have
a
comment
so
like
I
like
that
I
like
the
the
current
radar,
because
I
think
I
think
it's
it's
it's
about
the
projects
and
it's
about
the
technology
adoption
as
well.
So,
like
I
look
at
it.
If
I
see
that
if
I
see
the
tracing
in
the
ss
and
trial
and
not
in
the
adopt
it's
just
to
me,
it's
like
it's.
It's
not
as
adopted
as
a
monitoring,
so
I
think
having
a
generic
radar
is,
is
good.
Having
a
more
specialized
radar
can
be
good
too.
B
I
think,
from
my
perspective
as
well,
I
was
compared
to
the
first
radar.
If
you're
looking
into
the
adopt
section
in
the
cicd,
we
had
maybe
free
tools,
whilst
in
here
we
actually
have
five
and
there
was
a
potential
to
have
even
more
tools
in
the
adoption
and
it
actually
showcased.
I
was
surprised
slightly
disagreeing,
but
then
I
realized
every
single
company
that
I've
been
interacting
with.
B
They
actually
use
like
more
than
four
or
five
tools,
so
they're
observability
and
it's
absolutely
fine-
and
I
think
this
is
like
one
of
my
main
surprises
about
the
current
shape
of
the
radar,
especially
as
well.
If
you
go
to
the
next
level,
there
is
plenty
of
tools
again.
There
is
not
one
way
to
actually
or
one
golden
path
to
make
sure
that
all
your
components
are
going
to
be
very
well
measured
within
your
infrastructure.
With
this
like
free
tools,
everything
is
going
to
be
fine.
B
There
is
a
subset
of
different
things
that
you
need
to
use,
so
I
still
think
it's
a
realistic
example,
but
like
putting
my
like
community
headphone,
I
still
would
love
to
see
more
of
like
the
open
source
tools
there
like
a
bit
more
presentation
but
yeah.
I
think
I'm
actually
curious.
If
we
do
the
same
survey,
maybe
in
a
year
like,
I
would
be
I'll
be
very
pleased
if
that
would
happen.
B
If
some
of
the
tools
from
the
trial
would
actually
move
all
the
way
down
to
like
a
more
center
like
towards
the
center
of
the
radar,
which
will
actually
showcase
a
real
increase
in
the
usage
of
that
tool
in
the
inducer
community.
So
yeah,
I
think
maybe
we
kind
of
redoing
the
same
the
same
exercise
on
the
same
thing
at
some
point
in
the
future
and
kind
of
differentiate
them.
K
Yeah,
I
think
that
that's
a
great
idea,
because
you
also
see
how
certain
areas
develop
over
time,
because
there
will
be
development,
especially
if
you're
in
a
not
so
much
consolidated
space.
That
would
definitely
be
helpful.
I
think
you
know
that
the
more
people
know
about
it
and
more
people
will
contribute
to
it.
C
K
K
Sorry,
I
just
wanted
to
share
some
very
positive
feedback.
Like
there
was
this
long
discussion
on
twitter.
I
think
that
every
one
of
us
really
read
about
like
the
landscape
being
a
nightmare,
and
I
think
this
is
a
very
good
answer
to
this.
Like
there's
the
technology
raider.
This
is
where
you
see
adoption.
It's
not
just
the
landscape,
you
see
more
end
user
focus
data
on
how
people
are
using
certain
projects
and
so
forth.
K
So
I
think
that's
definitely
a
move
in
the
right
direction
and
I
really
like
the
direction
that
it's
going
so
take
this
as
like,
as
we
used
to
say
in
german,
like
critique
at
a
very
high
level.
I
think
it's,
it's
amazing
that
we
are
moving
in
this
space
and
I
think
it
answers
a
a
concern.
It
was
raised
on
on
twitter
and
other
channels
about
the
landscape,
and
I
think
that's
it.
That's
a
good,
that's
a
good
direction
that
this
is
going.
So
I
really
like
this.
G
To
to
add
to
this
point,
I
think
it
as
an
input.
It's
super
valuable,
but
not
as
two
distinct
things
again,
the
the
landscape,
as
it
is
at
least
to
me-
and
I
I
know
we
had
this
conversation
within
the
sick.
Talk
call
before
needs
the
ability
to
be
sliced,
enticed
as
to
the
user's
needs
as
to
what
they
care
about
at
the
moment
and
what
they
need
to
see
at
the
moment.
G
N
N
I
don't
know
if
it's
the
right
forum,
but
it
would
be
interesting
to
see
if,
if
it
were
possible
to
survey
what
drives
people's
decisions,
certainly
in
our
company
and
then
talking
to
some
colleagues
and
other
other
other
folks
across
the
spectrum.
You
know
obviously
there's
there's
competing
interests
when
it
comes
to
the
selection
of
particularly
observability
tools
and
many
people
have
many
in
parallel,
as
you
said,
but
you
know
that
there's
a
lot
of
ambiguity.
It
seems
at
least
as
I've
heard
people
say
around.
O
Yeah,
I
think
that's
that's
a
really
good
point.
I
mean
every
company
organization
has
their
own
priorities
and
different
projects,
different
resources,
different
amount
of
engineers,
so
it
would
be
interesting
to
see
you
know
like
a
trend.
You
know
whether
companies
are
actually
you
know,
thinking
more
about
open
source
lines
or
they're
thinking
more
about
vendor.
You
know.
N
Yeah,
it
might
be
nice
to
be
able
to
provide
that
not
not
only
to
the
end
user
community
of
decision
makers
but
back
to
projects
as
well
to
help
them
prioritize.
You
know
how
much
time
do
they
spend
on
documentation
on
quick
starts
on.
You
know,
on
material
for
people
new
to
the
project,
to
either
use
as
a
consumer
or
to
engage
as
a
contributor.
C
E
C
D
N
Yeah,
that
might
be
some
that
might
be
a
place
where
the
sig
observability
could
help.
I
mean
part
of
our
our
mission
and
then
we're
just
getting
getting
rolling
after
after
launching
the
sig
earlier
this
year
is
to
curate
you
know,
case
studies
and
patterns
and
and
and
try
to
you
know,
facilitate
gathering
that
that
that
data
and
and
reporting
back
to
the
toc.
D
D
J
No,
no,
we
we
don't
well,
we
use
the
landscape
occasionally
to
I
think
the
card
mode
is
actually
not
bad,
and
if
you
actually
go
into
some
of
the
you
know
categorized
by
by
the
actual
grouping,
you
can
get
like
a
meaningful
sort
of
list
of
sort
of
the
the
things
in
that
space.
In
terms
of
the
larger
landscape,
I
mean
certainly
again
we're
we're,
probably
a
more
sophisticated
sort
of
I.t
buyer
just
based
on
how
big
we
are
and
what
have
you.
J
But
you
know
we
we
generally
don't
rely
on
landscapes
to
drive,
so
we're
adopting.
So
there's
a
much
more
rigorous.
You
know,
assessment
of
what
we
need
and
and
what's
out
there
and
what
sort
of
makes
sense
and
existing
vendors
and
these
sort
of
things.
So
we
don't.
We
don't
rely
on
things
like
landscapes
or
or
really
even
research
like
stuff
from
even
large
research
shops
doesn't
make
the
cut
because
it's
typically
lagging
a
long
way
behind
and
sort
of
at
a
a
different
type
of
customer.
J
So
it's
occasionally
helpful
to
help
people
get
sense
of
a
space.
If,
if
you
can
break
it
down
by
the
actual
category,
but
the
thing
on
its
entirety
is
is
obviously
way
too
big,
and
I
think
that
this
is
going
to
be
a
really
interesting
friction
point
right,
so
we've
got
the
the
radar
which
is
coming
from
an
end
user
point
of
view
and
we've
seen
what
happened
to
the
landscape.
It's
just
a
land
grab.
J
P
P
You
know
financial
and
security
issues
all
the
time,
so
we
look
at
the
landscape
to
kind
of
give
us
an
idea
where
problem
space
could
be
helped
for
us
to
solve,
and
so
it's
been
very
useful
to
our
teams
and
that
they
look
at
it
when
there's
a
problem
they're
trying
to
solve
when
we
don't
have
a
current
solution
for
it.
We
look
at
what's
available
in
the
open
source
community
because
we're
trying
to
be
much
more
open
source
focused
these
days,
and
so
that's
where
it
comes
into
play
for
us
extensively.
P
D
Okay,
michael
ken,
thank
you.
I'm
glad
that
you
put
your
viewpoint
in
first
that
also
lines
up
with
what
I've
seen
from
end
users.
It's
there
they'll
look
at
it
on
occasion
as
a
reference
point,
but
they're
not
going
to
use
it.
They'll
always
be
a
second
level
of
evaluation
within
their
own
environment.
C
That
I
think
the
the
landscape
discussion
will
we'll
probably
run
and
run,
but
since
we've
touched
on
it,
it
was
interesting
to
to
to
mention
it.
I
think
we
have
well.
We
have
six
minutes
left
and
I
would
quickly
like
to
go
on
to
the
second
item
on
the
agenda,
which
is
hopefully
pretty
quick.
So
does
anyone
have
any
last
comments
on
the
technology
radar
before
we
move
on.
C
So
the
the
other
thing
that
we
had
on
the
agenda-
the
kubernetes
sig
chairs
and
leads-
are
now
required
to
take
the
I
think
it's
called
inclusive
speaker
training
in
terms
of
making
sure
they
have
awareness
of
diversity,
inclusion
issues
and
the
the
question
was
raised.
It
was
raised
such
a
long
time
ago.
I
can't
remember
where
it
came
from
whether
or
not
we
should
also
make
the
same
requirement
extended
to
cncf
sig
chairs,
toc
project
maintainers.
L
Hey
it's
michelle
here.
I
I
had
suggested
to
the
kubernetes
steering
committee
during
my
time
there
that
we
take
this
course.
I
think
chris
had
suggested
that
we
do
this
inclusive
speaker
training
and
it
was
more
of
a
like
a
top-down
effort
to
like
lead
by
example
and
make
sure
you
know,
like
the
the
governance
body,
is
doing
all
the
right
things
to
be
inclusive,
so
kind
of
started
with
steering
first
and
then
the
sig
chairs.