►
From YouTube: CNCF SIG Observability 2021-03-16
Description
CNCF SIG Observability 2021-03-16
B
C
C
C
E
C
F
A
F
C
So
arthur,
I
took
the
liberty
of
moving
that
one
segment
up
front,
but
we
can
also
move
it
back.
It's
just
we
we
shouldn't,
we
shouldn't,
spend
ages
on
it,
but
on
the
other
hand,
we
shouldn't
not
talk
about
anything
else
either.
I
still
maintain
it's
way
too
early
to
to
split
stuff
into
a
separate
call,
but
like
synchronization
on
on
what
the
next
workbench
packages
and
such
are
make
absolute
sense.
G
C
C
C
G
G
G
Another
thing
that
I
wanted
is
we
have
a
lot
of
suggestions,
a
lot
of
things
to
reveal
and
those
calls
we
can
do
reveals
as
increased
as
synchronously
through
the
document.
But
I
don't
like
the
idea
of
deleting
accepting
or
rejecting
suggestions
without
being
loud
about
it.
So
I
don't
want
anyone
to
open
the
document
one
day
and
see
that
suggestions
just
disappear
or
I
don't
know.
I
I
like
to
be
transparent
and
be
make.
G
G
E
C
Historically
speaking,
it's
always
risky
to
just
have
more
meetings.
In
particular,
of
course,
you
will
run
into
issues
with
other
people,
maybe
not
having
the
time.
Maybe
they
they
made
time
for
this
time,
slot
blah
blah
blah
blah
blah
blah.
So
I
would
strongly
encourage
you
to
to
define
work
packages
to
work
on
the
mailing
list
or
in
slack
to
to
make
it
possible
for
people
to
to
to
chip
in
myself.
C
I'm
deliberately
not
doing
it
so
work
gets
more
distributed,
but
I
I
look
forward
to
actually
working
on
this
as
well,
but
yeah.
I
would
strongly
encourage
you
to
do
things
asynchronously,
because
you
will
just
run
into
scheduling
issues,
no
matter
how
you
do
it
and
you
also
see
a
lot
easier
who
is
driving,
which
parts
of
the
discussion
of
the
document
blah
blah
blah,
which
enables
you
to
to
travel
more
easily?
Who
is
doing
what
and
and
who
delivers
how
quickly
so
yeah.
I
Yeah
and
I
think
it's
fine
to
have
like
a
meeting
for
reviewing
the
the
work
and
synchronizing
and
we
can
use
sick
observability
for
that.
If
there
is
a
time,
but
especially
around
the
suggestions
archer,
maybe
you
can
just
limit
the
permission
to
yourself
and
allow
others
to
just
put
suggestions
into
document,
so
everyone
can
collaboratively,
you
know,
review
it,
and
then
you
will
be
the
blocker.
So
hopefully
you
will
have
time
to
be
on
those
kind
of
meetings
and
and
kind
of
apply,
maybe
have
more
people
than
just
you,
but
yeah.
I
D
C
G
C
And
for
everyone
again,
slack
and
and
the
mailing
list
are
the
official
channels
of
communication.
You
can
also
find
them
in
the
document,
which
is
just
above
the
thing,
and
you
also
like
where
you
just
wrote
yourselves
in
so
please
subscribe
to
the
mailing
list
and
or
come
to
slack,
because
then
you
have
this
asynchronousness
communication.
C
C
C
I
think
I
don't
think
we
will-
or
I
think
it's
clear
to
everyone-
that
we
will
not
be
finding
full
consensus,
the
complete
due
diligence
document
so
instead
of
both
sides
trying
to
convince
each
other,
I
would
suggest
trying
to
focus
on
on
finding
what
can
be
points
of
agreement
and
where
we
simply
now
done
two
two
different
views
and
then
hand
this
to
toc
course.
They
need
to
be
make
the
final
call
about
this
anyway.
C
J
J
Yeah,
so
I
guess
my
recommendation
for
that
or
my
proposal
would
be
what,
if
we
throw
that
into
another
google
doc,
like
the
original
work,
that
bartok
did
on
the
due
diligence
and
that
can
be
linked
in
here
as
well,
but
I'm
fearful
that
we'll
rabbit
hole
on
that
for
the
entire
conversation,
ideally
making
progress.
I
think
on
the
sections
here
where
there
are
our
comments
directly
related
and
then
we
can
discuss
how
we
want
to
handle
the
additional
feedback
things
in
the
separate
docs
separately.
C
I'm
not
against
it,
I'm
just
noting
that
we
did
try
this
in
the
past
and
ran
into
the
into
the
same
discussions
just
distributed
amongst
the
document,
as
opposed
to
having
this
discussion
in
in
a
distinct
block
and
then
being
able
to
to
get
rid
of.
You
know
to
get
rid
of
it,
but
basically
to
acknowledge
it
and
then
just
move
through
the
rest
at
pace.
We
can
try
both
yeah.
We
can
try
both
so.
I
I
Is
there
any
concerns
in
design
or
incubation
or
like
whatever?
I
have
the
statement
that
yeah
I
have
concerns?
I
have
three
major.
I
kind
of
reduce
them
to,
like
you
know,
birmingham
to
not
spend
time
on
details
which
are
less
actionable,
as
we
noticed
like
last
week,
but
there
are
like
three
major
points
that
I
don't
think
we
agreed.
So
that's
why
we
proposed
to
just
put
it
on
the
top.
So
anyone
else
who
is
looking
on
this
dog
it
has
a
clear
vision.
What
seek
observability
is
thinking
about
that.
D
On
yeah,
so
I
I
don't
necessarily
have
a
strong
opinion
if
we
put
that
in
a
separate
document
or
not,
but
we
should
be
100
percent
certain
to
make
sure
that
if
whoever
reads
that
does
not
get
the
impression
that
the
sick
observability
has
that
opinion,
it
is
one
opinion
and
the
way
it
is
phrased
where
we
say
you
know
we
and
our
and
so
on.
Whoever
reads
that
in
the
toc
might
get
the
impression
that
this
is
the
opinion
of
the
sick
observability
and
it's
not
my
opinion.
So
that's
something.
B
That
was
the
main
goal
here
there,
and
then
this
is
the
other
people's
set
of
opinion
and
then,
after
we
can
break
it
down
there
and
have
it
at
the
end
as
a
summary
right,
because
by
going
in
so
there's
two
things
that
can
impact
like
that
impacts.
This
project
negatively
is
one
is
having
such
a
negative
statement
in
the
beginning,
already
predisposes
people
to
look
at
this
under
that
bias
and
then
view
things
there
versus
viewing
right
like
this
is
supposed
to
be
looking
at
all
the
information
and
then
gathering
opinion
on
it.
B
So
if
you
have
that
at
the
end
of
it,
then
people
can
go
so
go
through
it
too,
and
then
after
say,
you
want
ice.
Like
you
know,
these
are
the
different
like
people's
different
conclusions.
I
either
agree
with
them
or
don't,
but
if
you
have
the
conclusions
up
front
right
that
shapes
everyone
thinking
to
think
that's
the
only
way
to
do
it
an
only
way
to
go
forward.
I
Okay,
I
think
yeah,
that's
that's
actually
understandable.
I
think
negotiating
we
are
negotiating
on.
You
know
how
it
will
look
on
further
steps
when
toc
is
looking
and
is
that
and
we
are
negotiating,
you
know
how
yeah,
how
likely
whatever
outcome
it
will
be,
and
I
think
I'm
happy
with
whatever
will
be
discussed
this
I
just
I
just
want
to
add
one
one
more
thing
is
that
yeah,
I
okay,
that's.
I
That
looks
like
my
only
opinion,
but
I
gather
that
from
the
sikh
observability
members
as
well-
and
I
understand
michael,
you
are
a
member
as
well,
but
there
are
members
with
you
know.
That
would
agree
with
my
point
of
view,
so
I
wonder
yeah
how
we
say
what
sick
observability
actually
thinks
in
this
case.
J
Think
the
consensus
is
the
markings
in
green
on
this
document.
If
people
want
to
form
a
different
opinion,
I
mean
I
think
it's
fine
to
have
that
document
and
maybe
everyone
that's
willing
to
put
their
name
on
it
can.
But
anyone
that
doesn't
like
you
can't
just
have
a
blanket.
We,
I
think,
like
people,
should
either
own
up
to
that.
They
agree
with
that
point
of
view
or
not.
L
D
Go
on
like
well,
you
can.
We
can,
for
example,
interesting
one
way
to
go
about
it
is
if
we
indeed
take
whatever
is
at
the
top,
which
at
least
you
put
together.
I
mean
I'm
not
saying
that
you're,
the
only
one
but
the
we
and
our
feels
like
it's
inclusive,
and
at
least
I
do
not
subscribe
to
that
yeah
and
let
people
essentially
say
like
you
know.
D
Yes,
I
agree
with
that
part,
and
we
already
said
that
in
the
in
the
agenda
right,
there
won't
be
an
an
overall
consensus
on
that
and
that's
perfectly
fine
right,
it's
okay
to
say
I
support
that
view
or
not.
Let's
just
not
make
this
blanket
statement
we
and
then
everyone
gets
the
feeling.
It's
the
entire
sick
opportunity
that
has
this
feeling
or
this.
C
C
So
steve's
suggestion
of
of
putting
names
into
specific
areas
or
under
specific
statements
can
make
sense
or
prob
most
likely
does
make
sense,
because
then
we
can
move
on
functionally
or
or
not
functionally.
Organizationally
speaking,
unless
there
is
consensus,
we
won't
mark
the
screen
and
historically
for
the
three
other
due
diligence
documents,
which
we
did.
C
We
put
the
summary
on
top,
so
I
would
I
would
I
mean
I
get
consensus
point
on
on
this,
potentially
being
being
the
rest
of
the
document
being
read
under
the
lens
of
affecting
that
statement
above.
On
the
other
hand,
that
is
precisely
the
intention.
As
far
as
I
gather
so,
and
as
it
is
not
an
opinion-
and
it
is
like
I
I
I
I'm
the
first
to
agree
that.
B
J
J
M
Was
saying
that
was
fine
and
I
kind
of
agree
there
should
be
the
assessment
and
then
at
the
bottom
there
can
be
a
section
that
contains
all
this
information
labeled
as
the
to
who
put
it
in
and
why
they
think
it's
important
and
then,
if
we
want
to
have
as
part
of
that
also,
you
know
the
open,
telemetry
gc
just
like
addressing
these
concerns.
I
think
that's,
that's
also
a
reasonable
thing
to
have
at
the
bottom,
and
I
don't
think
we
need
to
have
anything
more
than
that.
M
D
I
have
one
minor
tweak
if
you
scroll
a
bit
further
up
steve,
please
and
that
the
first
sentence,
like
imagine
the
whole
whatever
is
now
on
top,
is
rephrased
into
not
like
I
bartek
say
this,
but
whoever
signs
up
to
that
thing
like
okay,
the
group
of
people
who
have
that
opinion
you
know.
Currently
it
reads
I
bartek
say
I
can't
recommend
that
and
then
there
is
a
wii
that
is
kind
of
like
inconsistent
right.
D
Whoever
goes
behind
that
should
say:
okay,
here's,
the
group
of
people
who
subscribe
to
that
and
already
some
some
pointed
it
out
in
the
comments
pretty
straightforward
to
get
the
names
there
and
having
these
two
positions
in
there
clearly
saying
like
who
is
behind
what
would,
at
least
for
me
fulfill
all
the
needs
there.
Then
we
can
move
on.
C
C
C
If
we
look
at
the
breaking
changes
of
open,
metrics
versus
prometheus,
a
timestamps
are
are
different:
they're,
not
millisecond
anymore.
There
are
seconds
and
timestamps
are
explicitly
discouraged
within
prometheus
and
b.
You
have
a
mandate
you
underscore
create,
as
underscore
total
is
now
mandatory
for
counters
and
and
transparently
done
by
by
the
instrumentation
library.
That's
it,
which
is
also
why
datadog,
for
example,
was
able
to
just
take
that
code
base
of
open
metrics
and
just
reimplement
open
metrics
in
their
own
thing.
So
I
with
my
open
metrics
head
on
for
the
last
four
years.
C
I
have
been
really
trying
to
get
together
and
we
have
the
same
discussions
and
if
you
look
at
prometheus
wg,
you
see
precisely
the
same
discussions
we
had
back
in
2017
and
again.
Morgan.
Keep
me
honest.
Please.
It's
like
the
only
major
two
things
which
I
saw.
Progress
are
a
that
this
maximum
guarantee
of
90
days
of
stability,
which
was
initially
the
plan
for
open
telemetry,
is
gone,
and
now
we
have
long
term
guarantees
for
the
api,
the
data
model,
the
wire
format
and
everything,
and
not
this
maximum
of
90
days
and
be
the
histograms.
C
Precisely
so
yeah
I
I
had
to
get
that
off
my
chest,
because
that
seems
to
be
something
which
is
recurring
and
it's
just
not
factually
correct
and
everything
about
about
how
prometheus
metrics
work
have
been
in
the
open
since
2014,
when
it
was
stable
and
hasn't
changed
since
which
point
on
the
dock
are
you
replying
to?
I
can
put
it
into
the
chat
just
a
moment.
C
A
C
No,
it's
not
because
the
code
was
open,
but
if
we
want
to
talk
about
open
metrics
we
can.
But
then
we
stop
the
due
diligence
for
a
second
person,
because
then
I
need
to
stop
wearing
the
chair
head
and
I
need
to
reply
with
my
open,
metrics
add-on.
If
we
want
to
do
this,
absolutely
fine,
because
there
is
massive
confusion
about
the
history
of
of
the
projects.
C
M
So
can
I
jump
in
here
and
say
like
I,
I
can
see
why
these
kind
of
comments
are
are
totally
annoying
richard
and
I
think
we
should
stop
sniping
around
like
which
came
first
or
anything
like
that.
I
think
that's
that's
not
remotely
helpful.
I
think
the
the
focus
here
is
like
is
open
telemetry
like
trying
to
support
the
prometheus
ecosystem
or
is
it
not
and
we
believe
we
are
trying
to
support
the
prometheus
ecosystem?
M
We
have
a
proposal
for
how
we're
doing
it
and
we're
actively
doing
it,
but
it
is
different
from
saying:
does
the
project
like
use
open
metrics
as
its
internal
format
and
we're
saying
like
we're
not,
but
we
are
trying
to
support
openmetrics
the
way,
we're
trying
to
support
statsd
and
everything
else
and
we're
putting
a
lot
of
effort
into
ensuring
that
there
isn't
some
work
we're
doing
in
the
metrics
field.
That's
going
to
make
that
unfeasible.
C
M
Right
and
I
think
we
should
just
just
remove
anything-
that's
that's
implying
that
some
somehow
there's
some
technicality
for
why
it's
right
or
wrong
to
support
openmetrics
like
I
don't
think.
That's
that's
helpful
at
all.
The
question
is
like
what
are
these
communities
doing
today
and
are
they
trying
to
work
together
and
there
is?
We
have
our
approach.
It's
fine
to
have
a
critique
in
there,
which
is
saying,
like
that's
fine,
you're
doing
that,
but
it
would
be
better
if
you
used
openmetrics
internally.
K
M
I
Yeah
my
opinion
is
that
it's
very
relevant
to
this
work
because
since
I've
seen
so
much
background
that
this
compatibility
stays
there
and
while
activity
increased
to
resolve
those
incompatibilities,
I
don't
see
the
community
have
a
trust
that
it
will
be
that
quickly
done.
So,
if
it's
so
soon
like
it's
planned
to
be,
I
guess
some
some
discussions,
we're
talking
about
some
may
or
that
some
compatibility,
so
not
using
directly
but
like
just
compatibility,
will
be
there
in
may.
Let's
wait
for
that.
I
K
M
M
M
We
have
a
the
counter
con
comment,
which
is
like
we're
not
releasing
metrics
until
like
that
is
a
requirement
for
us
releasing
metrics.
So
we
don't
think
it's
a
problem,
but
I
think
it's
fine
to
just
have
those
comments
on
there.
I
think
that
that's
the
part
where
we
have
the
objective
reality.
This
is
how
open
telemetry
plans
to
support
prometheus.
M
That's
the
objective
part,
and
then
we
have
two
divergent
opinions
on
whether
that
means
we're
ready
for
occupation
or
not,
and
I
I
think
we
should
just
ensure
that
it's
the
objective
part
is
put
into
the
dock
and
then,
however,
we're
gonna
do
these.
This
commentary
like
at
the
bottom
we
put
the
rest
of
it
there
and-
and
I
do
think
it
is
fine
for
bartek
to
have
this
opinion
as
as
someone
working
with
the
cncf,
I
don't
think
he's
actually
trying
to
be
unfair.
On
this
point.
It's
it's.
M
I
Yeah
yeah
good
point
and
you
know
don't
get
me
wrong.
I
think
still
open
metrics
isn't
perfect.
I
have
so
many
features
to
add
there
that
are
required
to
you
know
like
even
better
iterations
on
it
and
you
know
kind
of
improvements.
So
I
would
love
to
to
see
community
kind
of
joining
efforts
and
continuing
under
one
specification
not
to
but
anyway
like
it
looks
like
we
are
going
in
this
direction,
but
because
it
happened
to
be
like
three
years
already
that
nothing
happens.
I
I
want
to
be
just
extra
sure
that
this
is
going
well
and
maybe
put
some.
I
don't
know
there
is
some
kind
of
motivation
to
get
there
sooner
as
well
and
and
collaboratively.
Hopefully,
that's
kind
of
the
intention
as
well,
but
you
know
I
have
like
a
bigger
question
because
that's
the
one
point,
but
the
biggest
point
we
are
iterating
over
is
that
hey
tracing
is
stable
but
matrix
unlocking
is
very
kind
of
barely
well.
There
are
certain
things
that
are
working,
but
there
is
no
big
adoption
there
right
and
open
telemetry.
I
You
are
arguing
that
this
is
not
needed
for
incubation,
because
this
is
plan
ahead.
That
was
a
plan
from
the
beginning
right.
So
my
question
to
you
is
that
how
do
we
supposed
to
kind
of
fulfill
the
goal
of
unified
signals?
If
we
just
have
one
signal
there
and
we
we
don't,
have
a
proper
data
models.
You
know
designed
that
will
actually
allow
us
to
even
you
know
kind
of
understand
if
this
solution
is
even
achievable,
if
we
can
even
unify
this
under
single
deployment,
because
those
signals
have
different
characteristics
of
as
well.
I
I
M
I
M
With
that,
I'm
sorry
to
cut
you
off.
I
think
because
I
feel
like
everyone
on
the
call
is
like
aware
of
this,
but
I
I
actually
agree
that
is,
that
is
a
totally
valid
opinion
to
have,
and
it's
fine
to
have
that
expressed.
I
just
want
to
make
sure
that's
clear,
I
think,
to
answer
your
question
from
the
open
telemetries
project
side.
M
We
have
done
a
lot
of
experimental
work
like
a
significant
amount,
including
running
this
stuff
in
production
for
a
long
time
in
open
census,
and
I
would
point
to
the
work
we've
done
around
stability
and
backwards
compatibility
and
how
we
add
signals.
The
work
that
I
think
is
relevant
to
incubation
is
that
we
have
a
plan
for
how
stability
works
and
how
new
functionality
is
integrated
without
affecting
the
stability
of
what's
already
out
there.
M
That
to
me
is
really
important
work
that
we
did
to
ensure
when
we
say
to
people
tracing
is
stable,
you
can
you
can
depend
that
you
will
get
no
breaking
changes
related
to
tracing
in
the
future
at
the
same
time
we're
developing
metrics
with
that
in
mind,
so
so
that's
baked
into
the
architecture
of
the
project
and
it's
in
the
spec.
So
but
again
I
think
these
are.
These
are
two:
the
factual
part
is
tracing
is
stable,
metrics
and
logging
are
still
experimental.
M
We
have,
we
have
a
stability
and
support
roadmap
that
describes
how
we
we
manage
all
of
this
from
an
architectural
point
of
view,
and
then
at
the
bottom
we
have
opinions.
Open
telemetry
group
thinks
is
fine,
because
we
have
plenty
of
prior
art
that
says
it's
going
to
be
fine
and
bart,
maybe
others
say
yeah,
but
like
we
should.
M
The
bar
for
incubation,
as
opposed
to
graduation,
should
be
that
these
are
complete,
like
I
think
it's
fine
to
have
those
as
opinions
at
the
bottom,
because
they're
both
valid
opinions,
the
toc
can
look
at
those
and
decide
whether
they
think
the
bar
is
for
incubation
versus
graduation
and
whether
this
is
like
fine
for
incubation,
but
we're
not
going
to
graduate.
Unless
we
really
do
it
right
or
this
is
not
ready
for
incubation.
M
C
Both
sides
can
simply
say.
Well,
we
refer
to
our
document
and
then
we
we
have
this
and
it's
long,
and
this
is
then
basically
not
taken
as
a
consensus
position
of
the
zig.
It
is
just
basically
pointing
to
that
thing
as
context
of
why
consensus
couldn't
be
reached,
which
is
not
precisely
it's
not
precisely
how
itf
works,
but
I
I
get
to
to
pull
a
little
bit
of
a
magic
trick
because
we
have
toc
behind
us
or
above
us
or,
however,
you
want
to
look
at
it.
C
Let's
call
it
statements
of
descent
as
to
where,
to
put
it,
that's
one
of
the
few
cases
where
I
actually
make
a
call.
As
as
the
chair,
I
strongly
believe
these
things
belong
at
the
top
to
give
context,
but
I
also
strongly
believe
that
all
sides
should
have
their
say
as
long
as
it's
technically
or
it
is
valid
on
a
technical
level,
not
technically
valid.
D
G
C
D
It
says
we
and
ours,
and
that
is
just
think
of
it,
like
someone
from
talk,
looks,
looks
at
that
and
says
like
wait,
first,
says
partner,
it
says
our
we
like
what
is
it
right
and
let's
make
it
very
explicit,
very
clear:
it's
not
just
partick's
personal
opinion.
This
is
you
know
here
the
whatever
people
that
have
that
opinion.
D
K
K
C
I
I
mean
fine
with
what
I
don't
feel
you
know.
I'm
particularly
you
know
I.
I
was
not
even
participating
in
open,
metrics
or
so
whatsoever,
I'm
a
user
of
those
things
because
I'm
user
of
cloud
native,
you
know
open
source
solutions
and
probably
most
of
us
are
using
prometheus.
So
all
of
us
cannot,
you
know,
state
our
position
and
also
we
are
talking
about
logging
and
tracing
here.
So
I'm
not
sure
what
exactly
made
me.
I
don't
know
too
biased,
but
I
would
be
happy
to
to
consider
I
don't
know
like
yeah.
I
K
C
C
L
And
just
I'm
not
sure
I'm
gonna
say
coi
per
se,
but
I
think
my
observation
and
these
conversations
not
that
I've
been
in
all
of
them
but
I'd
say,
have
been
about
half.
Is
this
that
there's
a
lot
of
sort
of
first
person?
Discussion
of
not
of
the
particulars
of
the
integrations
were
not
between
various
pieces,
particularly
around
metrics,
prometheus
openmetrics
and
open
telemetry?
L
That's
that's
being
made
from
the
standpoint
of
like
the
observability
tl
role,
so
I
mean
I,
whether
that's
a
conflict
or
not
is
something
that
could
be
interpreted,
but
I
mean,
even
today
I
think
you've
been
referring
to
your
own
personal
experiences
in
the
sort
of
actual
like
histories
of
these
projects.
I
think
that's
probably
where
the
grounds
would
come
from
just
that
you're
not
approaching
it
as
a
third
party.
L
It's
like
you've
actually
been
experiencing
this,
and
I
think
probably-
and
it's
fine
to
this-
is
well
speculation,
but
I
think
feeling
certain
frustrations
about
it
as
well,
that
are
coming
in
prior
to
the
discussion
of
incubation
and
this
review
process.
So
I
think
that's
probably
what
the
grounds
would
be,
as
opposed
to
say.
L
I
don't
know
I
mean
if
we
approach
someone
just
on
the
overall
cncf
toc,
who
had
nothing
to
do
with
prometheus
openmetrics
or
open
telemetry,
and
they
were
to
approach
this
in
a
sort
of
more
entirely
objective
way.
I
I
think
what
ted
said
I
would
agree
with,
but
I
think
I
personally
think
that
you're
completely
entitled
to
have
opinions
about
these
things
and
in
some
cases
I
think
they're
very
well
informed.
L
So
I
I
want
to
clarify
it's
not
like
a
value
judgment.
It's
just
sort
of
like
almost
an
objective
assessment
of
your
role
in
some
of
the
technical
discussions
like
historically
that
are
now
becoming
relevant
to
this
review
process.
That's
how
I
see
it.
I
don't.
I
don't
really
want
to
weigh
in
on
whether
that's
literally
a
conflict
or
just
sort
of
a
complicating
factor,
but
trying
to
be
more
precise
per
alex's
comment.
That's
kind
of
how
I
try
to
be
more
precise
about
it
as
and
I'm
speaking
for
myself
not
broken
telemetry.
D
I
think
that
that
makes
sense
to
me,
and
it's
like
for,
for
example,
when,
when
I
hear
richie
saying
certain
things
he
always
very
clearly
says,
like
you
know,
with
the
heads
right,
you
know
this
is
with
my
metrics
head
on
or
whatever
making
very
clear
from
what
point
of
view.
He
says
something,
and
you
know,
arguably
you
know
being
chair
and
tech
leaders
on
the
same
level
in
terms
of
responsibility
and
and
in
that
sense
I
think
I
agree
right.
D
C
C
I
would
also
like
to
note,
because
ben
was
referring
to
emotionality.
A
lot
of
those
calls
were
emotional
on
both
sides,
and
I,
I
suspect
it's
probably
not
easy
for
bartek
to
be
on
the
receiving
side
of
like
just
now.
We
had
four
or
five
different
people
speak
therapies
and
he
is
alone
more
or
less
so
I
can
also
see
how
that
is
not
an
ideal
balance
of
power.
I
B
C
We're
deep
in
territory
very
honestly
as
a
sick,
we
shouldn't
be.
I
I
think
it's
it's
fair!
That
bartek
writes
down
a
statement
of
noting
down
potential
conflicts
of
interest
by
listing
the
various
heads
which
he
has,
and
then
the
reader
or
watcher
of
recordings
can
make
their
own
assessment
of
this.
C
So
either
we
point
to
specific
cases,
and
we
do
this
properly
like
raise
it
officially
and
actually
look
at
it
and
have
other
people
look
at
it
at
specific
comments,
or
maybe
we
all
try
and
get
the
emotions
down
a
little
bit
and
and
just
work
on
that
document,
which
would
be
a
lot
nicer
to
be
honest.
But
I
I
like
some
things
which
have
been
said
are
super
serious
and
if
they
are
meant
as
seriously
then
in
my
opinion,
they
need
to
be
erased.
J
And
those
can
just
be
comments
right,
like
nothing
prevents
like
taking
this
top
thing
and
adding
a
comment
here
and
saying.
I
feel
that
blah
blah
blah
is
happening.
I
think
that
there's
a
conflict
of
interest
like
you,
can
express
comments,
I
think,
and
that
can
be
taken
by
the
toc
as
well,
but
technically,
the
due
diligence
is
owned
by
the
toc
sponsor
at
least
per
the
cncf
incubation
guidelines.
So
I
think,
like
putting
this
into
a
dock,
linking
it
and
handing
over
the
material
and
let
the
toc
sponsor
decide
probably
makes
the
most
sense.
B
B
E
B
J
J
Yeah
I'd
like
to
propose
the
following:
like
the
bartok,
if
you
could
put
your
comment
into
a
doc
like
you
did
for
the
other
summary
and
then
link
it
like
we,
we
talked
about
in
the
summary.
I
guess
it
would
go
here
that
would
be
great
and
then,
if,
if
hotel,
gc
or
others
want
to
work
on
a
document
as
well,
that
can
be
prepared
in
parallel.
Ideally,
what
I'd
like
to
see
for
next
meeting,
if
at
all
possible,
is
that
we
focus
on
these
sections?
C
Yeah
and
if
we
get
those
two
statements
written
down
and
then
acknowledged
by
the
other
side,
but
not
necessarily
accepted
just
acknowledged
for
existence,
and
that
both
sides
acknowledge
that
the
other
document
is
not
outright
wrong
or
just
based
on
hearsay
and
opinion.
But
with
actual
like
statements
and
also
whoever
wants
to
support,
either
document
puts
their
name
in
and
then
we
can.
If
we
don't
reach
consensus,
we
just
bounce
to
to
those.
Two
documents
refer
to
them
and
hopefully.
J
C
I
M
M
But
even
before
then
a
lot
of
that
evaporated,
and
it
was
just
it
was
just
shadows
on
the
wall
to
begin
with-
and
I
have
not
been
here
through
all
of
these
conversations
but
but
I
feel
like
I'm
experiencing
one
of
these
trigger
spirals
again
and
it's
not
possible
to
to
unwind
the
past
or
do
anything
like
that.
But
I
do
think
it
is
possible
to
figure
out
again
how
we
could
move
forwards
both
personally
and
professionally.
M
I'm
not
going
to
propose
anything
because
we're
at
time
right
now,
but
I
just
want
to
say
that
you
know
I
don't
I've
not
seen
anyone
be
a
complete
monster
in
this
situation.
I
have
seen
people
get
hurt
by
the
things
other
people
have
said,
and
that
does
happen
when
emotions
run
high
and
people
don't
know
each
other
and
there's
a
lot
of
trust.
M
But
I
think
these
are
things
that
we
can
potentially
move
fast,
but
it
takes
work
so
hopefully,
hopefully
we
can.
We
can
get.
I
actually
think
what's
left
to
do
on
this
document
is
fairly
simple
and
straightforward.
To
be
honest,
and
I
hope
we
could.
We
can
have
a
session
where
we
can
just
just
move
through
that
and
if
there
needs
to
be
additional
work,
which
I
think
there
does
need
to
be
due
around
just
healing
and
having
people
have
an
opportunity
to
be
heard.