►
From YouTube: Diagnostics WG meeting Sep 22, 2021
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).
A
I
take
it
as
a
no
and
the
first
item
in
the
agenda
is
39283,
which
is
asynchronous
multi-tenant
promissor
kpi
stephen,
is
not
here,
so
I
believe
we
are
not
going
to
discuss
this
one
and
the
next
one
basically
will
directly
go
to
the
issue.
Number
499,
which
is
update,
cleanup
profiling,
root
pro
root,
folder
raphael.
B
Yeah,
actually
it
was
a
draft
pr,
but
it
looked
like
it
should
close
it.
The
question
that
I
would
like
to
bring
here
is
since
most
of
the
tutorials
that
we
are
moving
to
to
write
in
the
documentations
folder
is
pretty
similar
to
what
we
already
have
in
our
official
documentation
or
official
guidelines
like
simple
profiling,
and
I
think
that
we
may
overlap
something.
B
That
is
not
necessarily
right
now
I
mean
my
my
suggestion
is
instead
of
create
a
tutorial
for
every
path
that
we
have,
maybe
in
your
documentations
folder.
We
firstly
create
a
issue
to
track
what
what
is
the
missing
tutorials
and
then
we
work
on
that.
C
B
Yeah,
actually
we
had.
Let
me
find
here.
B
We
have
this
issue
that
I
will
send
in
the
chat
that
is,
it
was
created
some
a
long
time
ago,
but
we
we
have
defined
the
what
we
should
have
in
the
future,
which
kind
of
tutorials
we
should
have,
and
for
instance,
I
have
added
me,
add
profiling
and
looks
like
it
was
already
create.
I
mean
I
have
created
in
the
diagonal
repository,
but
it
may
overlap
what
we
have
right
now.
So
I
a
bit
confused
what
we
should
what
I
am
supposed
to
do
right.
B
C
A
Yeah,
if
the
problem
determination
experience
is
fully
covered
in
the
core
api
documentation
itself,
we
don't
need
to
reinvent
the
whole
story
again,
but
on
the
other
hand
at
least
I
have
seen
in
some
cases
where
api
documentation
is
very
abstract.
I
mean,
I
wouldn't
say
abstract,
but
it
follows
certain
conventions.
It
cannot
expand
a
lot
just
for
one
set
of
capabilities
because
it
has
to
be
standardized
across
all
the
apis,
whereas
in
this
scenario
we
might
take
a
little
step
more
to
explain
certain
things
in
a
little
more
consumable
manner.
A
So
we
have
that
liberty,
whereas
core
api
documentation
may
not
have
it.
I
I'm
not
saying
that
in
this
case
we
should.
We
should
write
everything
of
our
own.
I'm
just
saying
the
general
difference.
C
C
Yeah,
so
I
think
raphael
my
my
my
suggestion
would
be
like
if
we
think
that
that's
a
good
description,
then
you
know
just
ping
ring
a
a
pointer
to
that,
and
you
know
we
can,
depending
on
where
it
goes.
In
the
end
we
might
like
duplicate
content
or
if
it's
just
ends
up.
We
put
it
in
the
guides,
then
having
a
link
to
the
other
sections
makes
a
lot
of
sense
too.
B
So
I
will
take
a
look
in
most
of
or
to
do
listing
the
documentation
and
if
I
found
some
some
white
I
would
just
point.