►
From YouTube: 2021-11-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
A
The
calendar:
well,
I
guess
it's
probably
because
I
use
google
calendar
for
everything,
but
it
if
you
use
google
calendar,
you
know
you
can
subscribe
to
the
group
and
it
keeps
all
the
all
the
stuff
in
sync
yep.
C
Because
it's
really
like
morgan
was
mentioning
that
the
link
would
keep
changing
at
least
once
in
a
year.
But
if
it
is
like
only
once
a
year,
we
should
be
able
to
just
copy
it.
And
like
put
it
in
the
note,
so
it's
much
easier
to
just
close
it
directly.
A
A
No,
I
missed
it
this
morning.
Okay,.
D
A
C
So
maybe
I
can
give
a
quick
update
on
the
release
thing
so
and
after
that
we
can
take
any
other
thing.
So,
once
again
like
reminder
in
case
like
you
had
like
zoomed
in
shared,
like
copied
in
your
calendar
or
some
place,
make
sure
to
get
it
always
from
the
calendar.
So
it
looks
like
there
are
some
changes.
C
You
have
to
get
it
from
the
calendar
trying
to
see
if
it
is
the
same
link
for
every
monday
every
morning
meeting
and
every
different
thing
for
every
evening
meeting
and
based
on
where
I'll
try
to
put
it
in
a
hard
link
here.
So
it's
slightly
easier
for
folks
to
join
yeah
for
the
release.
So,
as
we
discussed
last
week,
we
have
really
like
two
things
which
needs
to
happen
before
we
can
do
like
stable
and
one
thing
has
happened,
but
the
second
thing
hasn't
happened.
C
Yet
we
don't
know,
I
mean
I
don't
really
know
whether
it
will
happen
today
or
it
will
happen
next
week.
So
dotnet
side
is
done.
The
six
has
released
and
the
spec
being
marked
stable,
so
that
pr
is
basically
this
one
so
depending
on
if
it
gets
masked
or
if
it
gets
merged
conditionally.
I
think
some
portions
are
moved
out.
Then
we
need
to
update
our
plan
accordingly.
So
as
of
now,
I
don't
know
anything
if
it
will
be
merged
or
not.
C
So
if
it
gets
merged,
then
we
are
good.
We
can
just
release
one
dot
stable,
if
not
we'll
have
to
figure
out,
what's
the
best
way
to
deal
with
it.
So
if
it
is
not
going
to
be
merged,
then
we
will
remain
in
rc1
or
c2
like
something
which
is
not
stable.
It
can
be
like
an
erc
or
even
beta,
it's
fine.
C
So
that's
this!
The
update,
I'm
still
hoping
that
there
will
be
like
some
progress
by
end
of
day
today,
because
it
was
actually
discussed
in
today
metrics
sick
meeting
as
well.
C
So
that's
the
key
thing
which
I
wanted
to
update
and
in
terms
of
churn,
I
think
things
which
we
still
have
not
closed,
probably
be.
Okay,
I'm
still
adding
like
some
like
logging
interviewing
the
public
api.
So
most
of
the
things
should
be
like
done
like
by
now
I
mean
by
end
of
day.
C
Probably
there
are
like
few
things
which
we
haven't
done,
which
is
basically
violation
I'll
put
some
notes
into
the
issue
to
say
that
why
it's
not
trivial,
it's
not
basically
checking
the
value,
because
in
the
future
we
would
allow
aggregations
to
be
changed
with
view.
C
So
we
need
to
pay
close
attention
to
what
is
the
actual
thing,
which
is
aggregating
the
incoming
number.
So,
for
example,
if
it's
a
counter-
and
we
are
validating
that
converse
can
only
have
positive
numbers,
but
if
the
user
wants
to
treat
it
a
segways,
then
negative
numbers
all
of
a
sudden
make
sense.
So
we
need
to
find
the
right
place
to
do
that
validation.
C
So
we
cannot
do
it
too
early,
because
we
don't
know
what
is
a
b
configuration
and
we
need
to
do
it
like
the
right
place
and
if
you
do
it
too
late,
then
it
may
be
like
already
like
waste
of
so
much
effort,
because
we
spend
a
lot
of
time
looking
up
dictionary
and
everything.
So
we
need
to
find
that
sweet
spot
to
do
that,
validation
without
being
expensive
to
the
proof
and
also
not
doing
anything
incorrect.
C
So
that's
why
these
two
validations,
wherever
we
can
fail
fast,
we'll
be
doing
it
because
there
are
places
where
we
can
fail
faster
in
the
meter
provider,
construction
itself
or
that's
mostly
restricted
to
views
if
we
use
registered-
and
it
has
something
incorrect,
we
can
throw
right
away
so
because
of
these
these
two
issues.
It
might
make
some
changes
today,
but
it
won't
block
one
point:
we
might
be
blocked
by
the
stable
race
of
the
spec,
but
these
two
will
not
block
it,
and
this
is
unrelated
to
matrix.
C
We
are
unlikely
to
have
it
like
in
the
next
couple
of
days,
so
this
will
not
be
part
of
one
or
two,
but
it's
not
really
required
for
one
two,
so
that's
it
and
yeah.
These
are
like
cleanups,
and
this
is
just
a
documentation
where
we
shared
our
plan
like
one
year
back.
C
I
basically
updated
this
original
issue
with
where
we
are
currently
so
like
just
recapping.
If
the
spec
gets
marked
as
stable
as
is,
then
we
will
be
releasing
1.2
if
it
is
a
selective,
sorry
picking
some
part
of
the
spec
which
says
it's
stable,
then
we
need
to
do
some.
Adjustments
probably
means
we
won't
be
able
to
do
it
in
one
day
or
two,
because
if
some
portions,
which
we
already
have
public
api
and
spec,
says
they
are
not
stable,
we
have
to
pull
it
out
or
mark
them
in
general.
C
So
it's
going
to
be
like
little
bit.
Non-Trivial
work
so
I'll
share
an
update
as
soon
as
the
pr
gets
merged,
either
in
the
chat
or
probably
in
the
next
meeting.
Whichever
comes
earlier
so
that
ends
my
agenda
still
like
adding
some
logging
like
final
reviewing
of
to-do
and
things,
so
you
can
expect
like
more
peers
happening
today
as
well,
but
none
of
them
are
like
functional
cases,
just
like
some,
like
additional
error
messages.
C
So
now
alan,
like
you,
can
talk
about
the
otp
exporter
options
issue.
Oh
maybe
like.
Let's
ask
this:
can
you
go
first,
like
maybe
maybe
faster?
What
was
the
issue
which
you
wanted
to
discuss.
D
Hey
I
just
want
yeah
the
basically
the
update
you
gave
about
my
question
was
about
when
the
ga
release
can
be
expected,
and
I
think
you
answered
that.
D
That
was
basically
my
question
and
also
I
kind
of
aside
the
one
issue
that
I
have
is
the
net
counter
instrumentation
trying
to
figure
out
where
that.
A
D
Like
if
there
is
any
kind
of
kind
of
timeline
on
when
you
would
like
that,
much
or
anything
like
that,.
C
Oh,
no,
it's
not
really
blocking
our
one
two
two
releasing
anyway,
because
not
really
like
we're
not
blocked
by
that.
So
whenever
you
have
time
you
can
go
ahead
and
do
that
one
central
thing
is
the
month
of
december.
We
expect
a
lot
of
people
be
on
vacation
yeah,
so
it's
I
mean
I
would
be
like
working
at
least
for
the
next
couple
of
weeks
like
alan
might
be
working
as
well.
So
I
don't
know
about
other
maintenance
for
our
course.
C
So
you
may
have
like
less
luck
getting
people
to
review,
but
I
will
try
to
at
least
do
a
quick
review
if
there
is
a
pr
coming.
C
Okay,
yeah,
so
alan,
can
you
walk
through
the
thing?
Okay,
this
one
right.
A
A
That
there's
in
there's
trace
specific
stuff
and
there's
metric
specific
stuff
on
them
and
there's
a
lot
of
like.
If
you
set
this
option,
then
this
other
option
will
be
ignored.
I
think
it's
potentially
gonna
get
more
confusing.
Today,
there's
two
trace
specific
settings
and
there
are
three
metric
specific
settings
on
our
otlp
exporter
options
class.
A
C
A
Yeah,
okay,
so
that
this
pr
is,
is
playing
around
with
the
idea
that
there's
basically
a
different
class
for
each
option,
but
that
they
can
work
in
kind
of
a
hierarchical
fashion.
So
if
I
use
just
the
the
base
and
there
it's
it's,
not
a
it's,
not
like
an
inheritance
hierarchy,
at
least
not
right
at
this
second.
But
if
I
use
the
base
otlp
exporter
options,
I'm
able
to
set
something
like
endpoint
there,
but
then
set
the
trace
specific
stuff.
C
Okay,
so
basically,
let's
like
really
abstracted
into
the
base
class
kind
of
thing
where
things
which
are
applicable
to
all
signals,
you
would
put
it
here,
anything
which
is
specific
to
trace
specific
okay
would
come
here,
so
it
would
be
things
like
fraud.
Okay
protocol
is
coming
from
the
base
yeah,
so
this
is
very
specific
to
the
tracing
okay
and
like
quickly
checking
what
is
the
specific
thing
about
matrix
yeah.
We
have
the
temporality
and
reader
thing
as
well.
Okay,
so
those
would
be
part
of
the
as
well
okay.
C
It
looks
neat
like,
but
you
said
like
we
have
to
like
do
some
absoluting,
because
this
is
breaking
change
right.
A
Yeah,
so
if
you
go
up
to
the
otlp
x.
D
C
So
we
will
be
like
still
supporting
it,
but
we
will
putting
a
message
in
the
absolute
saying
that
it
is
recommended
to
use
the
trace
or
metric
of
signal
specific
options
right,
okay,
yeah.
I
think
it's
full.
I
don't
think
there
is
any
I
mean
the
other
option
is
to
just
ignore
it
completely
and
like
let
it
be
as
messy
as
before
and
probably
make
it
slightly
more
complicated
by
adding
metrics
to
it.
That's
one
option,
but
it
looks
like
this
is
a
much
better
option.
C
Saluting
should
be
fine
because
it's
just
marking
it
as
absolute,
so
it's
not
every
can
change
it.
People
can
still
use
it.
We
want
to
move
it
until
2.0,
so
at
least
we'll
get
a
clean
start.
I
mean
clean
thing
for
the
matrix,
because
for
matrix
we
haven't
made
anything
we
shipped
anything
stable,
so
we
should
be
able
to
at
least
not
add
more
to
the
messy
stage.
A
A
As
kind
of
just
like,
maybe
we
just
keep
the
kitchen
sink
class
with
all
the
trace
specific
stuff,
all
the
metric
specific
stuff
on
on
it,
but
maybe
create
a
a
builder
like
api
that
enables
you
to
build
this
class
up.
C
A
Right-
and
I
think
the
maybe
maybe
a
slightly
messy
thing
there
is
that
we
have
these
helper
extension
methods.
Like
add
otlp
exporter,
and
currently
you
know
they
take.
They
take
a
a
delegate
that
modifies.
D
A
C
Yeah
I
mean
like
the
moment
we
ship
one
dot,
one
like
anything
after
that
would
be
a
teaching,
so
I
think
we
have
to
either
leave
with
that
or
even
in
this
approach
we
are
still
increasing
right,
like
we're,
adding
like
new
things.
So,
probably
okay,
I
don't
I
don't
see,
that's
a
big
issue.
C
A
C
Yeah
yeah
like
like,
since
we
already
have
the
tracing
hotel
tx4,
are
stable,
like
whatever
we
do.
I
think
marking
something
as
absolutely
are
going
to
be
inevitable,
because
that's
the
only
thing
only
way
we
can
remove
it
in
2.0,
so
we
don't
really
have
to
mark
it
absolute
today,
but
if
you're
writing
it-
and
we
should
subsequently
mark
things
as
absolute.
So
in
some
future,
when
we
do
2.0,
we
come
out
as
much
cleaner.
B
Yeah
yeah,
that
was
me:
okay
yeah.
So
I'm
like,
I
had
a
question
so
like
would
it
be
like?
How
would
this
approach
be
if
we
keep
continue
having
odlp
exporter
options,
if
we
have
otlp
exported
options,
class
dedicated
for
trace
when
you
create
a
new
otlp
metric
exported
options,
and
you
repeat
the
the
the
fields
like
the
url
and
the
headers,
and
all
of
that
so
that
we
just
remove
the
metric
part
and
create
a
new
class.
B
That
way
we
will
have
to
duplicate
the
the
like
endpoint
and
headers
fields
in
both
the
classes
but
yeah,
then
I
think
you.
A
That
that
is
kind
of
what
I'm
doing
in
this
in
this
pr
effectively.
I've.
C
C
B
Like
if
we
we
can
avoid
a
situation
where
we
have
to
mark
feels
obsolete,
because
we
will
have
the
otlp
exporter
options.
Class
dedicated
for
just
traces.
C
Yeah,
it's
still
a
little
bit
odd
because
we
are
like
somewhere
telling
that
okay
trace
gets
first
class
treatment.
Everyone
else
has
to
have
like
their
own
thing.
C
Yeah,
it's
it's
better,
I
think
at
least
like
people
when
they
upgrade
they
wouldn't
notice
any
absolute
warnings
scrambled
but
yeah.
At
least
I
mean
it's
still
not
fixing
it's
just
like
we
choose
to
like
hide
it.
A
D
A
You
know
you
see
the
environment
variables
there,
hotel
exporter,
otlp
endpoint,
you
know,
there's
one's
hotel,
exporter,
otlp,
traces,
endpoints,
and
so
that's
one
of
the
reasons
why
I
created
both
a
metrics
and
a
trace
specific
class.
C
Okay,
so
I
think
it's
a
reasonable
thing
to
like
like
further
explore
this
idea
and
see
if
we
can
make
it
happen
before
one
point
and
if
you
want
to
like
delay
like
1.2
while
we
are
getting
it
totally
fine,
and
we
can
probably
like
restrict
this
to
otp
exporter
option.
I
mean
otlp
exporter
itself,
so
we
might
be
able
to
do
that
without.
Like
really
delaying-
and
I
agree
that
it's
something
which
we
should
do
it
feels
ugly.
C
Without
that
I
mean
I
didn't
even
pay
attention
until
I
started
sharing
something
yesterday,
so
yeah
okay.
So
what
do
you
suggest?
Just
that
next
action
item
we'll
be
like
like
trying
to
tune
this
little
bit
further
and
make
it
apr?
So
I
mean
non-draft,
so
we
can
start
reviewing
or
do
you
want
to
share
any
educational
feedback
and
maybe
like
we
can
ask
like
michael
also
to
come
in
because
he
had
like
maybe
like
alternate
proposal.
C
So
we
have
like
option
to
look
at
both
and
we
can
compare
and
pick
which
one
makes
sense.
A
Yeah
I'll
get
this
pr
cleaned
up
today
and
in
a
non-draft
state,
make
sure
it
works.
I
need
to
add
some
tests
and
so
on
the
and
then
yeah
I'll
I'll
note,
michael's
idea
ping
him
and
then
hopefully
it
won't
need
to
delay
anything
all
that
much
I'll.
Try
to
get
this
try
to
get
this
cleaned
up.
C
C
So
we
that
means
we
had
to
like
create
a
separate
version
for
from
there.
So
we
can
maybe,
like
temporarily,
do
that
for
otlp
also
and
once
thus,
once
we
like
finish
up
our
thing,
we
can
release
them
together,
but
we
can
figure
that
out
like
if
you
think
that,
like
this
need
like
a
couple
more
days,
it's
totally
fine
because
we
don't
want
to
like
ship
something
and
like
later
regret
it
for
the
rest
of
one
daughter,
our
lifeline,
okay
yeah.
C
C
Okay,
any
other
topics.
I
really
wanted
to
ask
about
the
december
6
meetings,
but
probably
I'll
ask
that
next
week,
because
I
know
for
sure
I'm
working
next
week
so
after
that
I'll
see
if
there
is
enough
interest
to
keep
it
running
for
december
third
and
fourth
weeks,
if
not
we'll
cancel
that,
but
let's
make
that
call
next
week.
D
Cj
since
we're
here,
can
I
ask
you
a
quick
question,
yeah
sure,
so,
with
the
event
source?
Sorry,
there
is
already
a
diagnostic
source
listener.
So
are
you
expecting
the
event
counter
listener
to
go
in
here
or
go
in
one
of
the
other
instrumentation
libraries?
Oh
no.
I.
C
Don't
think
so
because
that
even
source
thing
has
a
completely
different
mechanism
to
subscribe,
so
the
diagnostic
source,
one,
is
basically
different,
like
technology
altogether
to
subscribe
to
events,
so
the
even
source
one
is
different.
So
and
again
it's
not
specific
to
any
like
libraries
like
asp.net
or
http
client.
C
So
what
you
would
be
writing
would
be
like
a
general
purpose,
open
elementary
dot,
instrumentation
dot,
even
counters,
which
converts
I
mean,
listens
to
even
counters
and
internally
called
the
open,
telemetry
api.
C
Most
likely
it
will
be
the
control
gripper,
because
we
already
have
like
too
many
things
in
the
main
point
where
I
mean
at
some
point
in
time,
we'll
do
a
cleanup
of
shifting
all
the
instrumentation
libraries
out
so
since
this
is
something
which
we
are
starting
new,
we
should
start
in
the
right
place,
gotcha
that
would
be
the
contract
yeah.
But
if
you
just
want
to
like
get
some
feedback
draft,
it's.
C
D
So
I
mean
even
counters
are
basically
special
purpose
event
source
right,
so
I
kind
of
didn't
think.
A
D
Different
than
the
event
source
ones,
but
so
yeah-
and
there
is
a
bit
of
a
pattern
going
here,
so
you
think
it's
best
to
just
keep
it
separate.
I
guess.
C
I
mean
separate
from
which
one
the
diagnostics
was
right:
yeah.
C
So
the
one
which
we
are
subscribing
to
in
most
of
our
instrumentations,
like
asp.net,
core
http
client,
they
are
diagnostic
source.
So,
okay,
okay,
it's
really
unrelated,
okay,
lowest
comparison.
You
have
is
the
sql
client
for
dotnet
framework.
It
has
this
even
source
callback
which
we
listen
to,
but
it's
still
even
it's
not
even
counter.
I
I
know
like
assembly
implementations,
because
I
have
done
it
for
application
sites,
so
I
can
share
that
and
also
the
dotnet
counters
tool
also
listens
to
encounter.
C
So
yeah,
of
course,
on
how
to
really
listen
to
this
thing,
yeah
and
then
you
can
convert
that
into.
I
think
the
conversion
would
be
all
two
languages
observable
gauges
in
the
new
world,
but
yeah.
Those
are
things
which
we
can
figure.
D
C
A
C
Don't
like
you
cannot
anticipate
anything.
I
don't
think
like
anyone
was
talking
about
any
new
instruments.
The
only
thing
which
I
am
even
aware
of
is
the
timer.
There
is
a
potential
for
a
new
instrument
for
timer
related
stuff.
That's
my
thinking,
but
either
way
like.
If
there
is
a
new
instrument
which
better
suits
the
need,
we
can
always
change
the
instrumentation.
D
So
do
you
like
I'm
having
a
bit
of
mental
block?
Maybe
you.
A
D
Help
me
out
like
why
you
know
when
you
have
a
counter
and
you
go
and
create
a
counter,
and
then
you
go
record
when
you
need
it
inside
a
loop
or
whatever.
Why
wouldn't
you
want
to
do
something
similar
with
the
gauge.
C
Oh
yeah,
so
that's
a
good
question
for
the
spec.
It
was
like
debated
heavily.
C
Like
the
reasoning
behind
like
oh,
why
do
we
need
like
each
instrument
and
why
not
something
else?
If
I
find
that
actual
thing,
I
can
send
it,
but
I
haven't
done
like
enough
homework
to
give
a
like
somebody
else.
D
That's
fine,
that's
fine
I'll,
keep
digging
and
try
to
really
understand
it,
but
yeah
I'm
having
a
little
bit
of
a
mental
block.
There.
A
I
mean
just
on
this
topic:
I'm
I'm
still
personally
kind
of
struggling
with.
You
know
gauge
versus
up
down
counter,
as
you
know,
when
when
would
I
choose
one
over
the
other
yeah,
so
there
is
some
like.
C
Like
document
in
the
spec
which
says
like
when
you
should
use
one
versus
other,
so
it
clearly
says
at
least
one
case
where
which
should
be
preferred
over
I'm
down
counter.
Both
are
asynchronous
version,
so
I
I
can
just
send
that
link
it's
in
the
supplementary
headlines,
but
it
doesn't
use
a
specific
example,
so
it
may
or
may
not
be
like
easily
digestible.
C
There
were
like
examples.
I
mean
george
mack
j
macd
from
the
matrix.
He
wrote
a
very
detailed
pr
or
issue
which
really
compared
like.
Why
do
we
even
need
these
instruments,
but
it
never
got
merged.
So
if
you
begin
the
repo,
you
would
find
like
a
very
detailed
example
based
in
this
transaction
yeah.
It
should
be
in
this
big
ripple
yeah,
but
it's
like
you
have
to.
A
C
Digging
to
find
out-
because
it's
not
much
so
okay,
it
did
exist,
but
it
never
got
much
so
it
got
lost
so
yeah.
If
I
find
it
like
straight
away,
I'll
just
share
it,
because
I
don't
like
it.
I
appreciate
it.
Thank
you.
So
what
island
shared
here
is
basically
the
thing
from
the
fact
which
says:
how
do
you
pick
which
instrument,
but
this
one
as
I
said
it
really
explains
it,
but
it
doesn't
give
a
specific
example
where
one
metric
would
one
instrument
type
would
be
preferred
over
other
types.
C
So
there
is
not
enough
examples,
but
the
version
which
jmfd
had.
I
think
it
had
like
specific
examples.
Maybe
when
the
current
stack
was
written
there
were
these
examples,
but
like
it
was
intentionally
removed
from
this
packet.
If
you
dig
enough,
you
will
find
it
because
I
remember
like
reading
all
these
examples,
which
riley
and
josh
two
josh's
who
were
writing
this
putting
there,
but
in
respect
you
won't
like
have
like
detailed
explanation
of
each
and
everything.
You
would
only
have
the
final
spec,
but
what
led
to
that
thing?
C
A
A
A
Okay,
yeah
take
a
look.
If
you
learn
things,
let
me
know
because
it's
it's
it's
secret
style.
C
And
it
was
complicated
enough
that
it
warranted
like
a
one-year
delay,
because
if
you
look
like
last
year
by
number,
there
were
like
plans
to
make
matrix
sdks
table
line,
but
then
it
was
decided
against
that
and
we
basically
rebuilt
all
the
instruments,
so
it
it
was
fairly
complex.
Otherwise
we
should
have
been
like
done
with
that
like
long
time.
C
So
I
expect,
since
the
topic
itself
is
complex,
it
would
be
like
equally
complex
to
like
incorporate
that
into
like
our
use
cases
as
well,
and
there
were
like
feedback
even
like
when
the
original
apis
were
written
like
we
had
like
nine
instruments
at
that
time.
There
were
like
some
feedback
on
that.
Even
now
we
have
like
six
of
them.
So
it's
not
really
like
that
straightforward.
C
You
still
have
to
figure
out
which
one
to
use,
but
I
believe
the
reason
the
the
metrics
had
was,
if
you
extreme-
and
you
just
have
like
one
instrument,
you
can
just
submit
whatever
value
you
want,
it
is
kind
of
not
what
the
sick
wanted.
They
really
wanted
people
to
be
like
very
explicit
and
pick
an
instrument
to
convey
their
intention
rather
than
just
picking
like
some
random
instrument.
I
mean
it
is
a
general
purpose
one
and
then
using
views
to
configure
the
default
aggregation.
C
So
that's
why
there
are
like
all
this
instrument
and
then,
like
you,
obviously
talk
about
different
kind
of
instrument
and
there
are
like
10
companies
trying
to
align,
so
you
can
expect
there
will
be
like
some
complexities
here.
Personally,
like
I
worked
in
application
instead
before
it
only
had
a
single
type
of
instrument,
so
it
was
easy,
but
I
also
worked
in
other
metric
sdk
within
microsoft.
C
It
also
had
like
at
least
three
instrument
types,
not
not
directly,
mappable
to
open
elementary,
but
I
think
is
also
had
like
four,
so
it's
kind
of
given
that
there
will
be
like
more
than
one,
so
we
just
have
to
like
make
sure
we
understand
it
if
not
like.
We
can
ask
the
spec
for
specific
examples
as
to
like
when
to
use
this
one
versus
other.
C
If
you
ever
get
stuck
like,
I
think
one
good
place
to
ask
is
in
the
slack
channel
for
the
matrix
you
can
ask
okay,
this
is
a
scenario
I'm
trying
to
use
this
instrument.
I
mean
the
right
path
or
not.
There
are
like
plenty
of
metric
experts
there
who
can
tell
you
whether
you
are
in
the
right
path
or
not
very
quickly.
I
may
not
be
able
to
do
that,
but
there
are
people
in
the
matrix
who
might
be.
C
I'll
reach
out,
then
thanks
all
right
anything
else
to
be
discussed.
If
not,
we
can
end
early.