►
From YouTube: Diagnostics WG meeting - Apri 17 2019
Description
A
So
welcome
to
the
no
Deus
Diagnostics
working
group
for
April
17
2019,
we'll
follow
the
agenda,
as
mentioned
in
issue
number
292.
If
everybody
who's
here,
I'm
just
gonna
paste
the
link
into
this-
that,
if
everybody's
here
can
add
themselves
to
the
present,
that
would
be
good
first
on
the
agenda
is:
does
anybody
have
any
announcements
that
they'd
like
to
share.
B
A
A
B
B
B
A
Really
comes
down
to
how
many
active
participants
you
have
I
think
you
know
so,
for
example,
for
an
API,
we
did
do
reviews.
You
know
we
asked
for
like
one
of
their
PR
review
before
we
landed
things,
but
we've
had
quite
a
few
people
working
on
it.
There
is
like
a
full
review
when
you
make
the
PR
into
core
anyway
right
yeah.
So
if
you're
the
one
doing
most
of
the
work
I,
don't
think
it
necessarily
needs
to
slow
down
waiting
for
other
people's
reviews.
A
B
A
A
Might
put
some
information
on
that?
That's
like
hey!
If
you
want
to
become
a
contributor
or
if
you
you
know,
here's
how
we're
doing
reviews
you
know
at
this
point
just
land,
whatever
you
want
or
or
I
mean
other
people
won't
be
able
to
land,
because
I
think
I
only
added
you
to
the
team
right,
but
it
could
be
like
one
sided
to
the
team,
feel
free
to
land
things
and
we'll
do
a
final
review
at
the
end
or
whatever
yeah.
B
B
B
B
C
C
A
A
B
Think
that
was
there
last
time.
Okay
I
took
an
action
at
him
to
check
in
on
that
see.
Oh,
that
was
a
stagnated
because
there's
no
opended
left
google
right
got
it.
Okay,
but
I've
gotten
to
that.
Yet!
But
I'm
someone
I'm.
A
D
D
A
C
C
A
Next,
one
expectation
about
tear
support,
really
the
focus
is
on
defining
the
best
practices,
so
I
think
we're
just
gonna
drive
the
expectation
on
the
tear
support
I
think.
Maybe
even
we
could
take
the
agenda
item
off
of
this
one
as
well,
until
we
get
that
done
and
then
we'll
sort
of
drive
tagging
or
pushing
those
things
based
on
that.
Does
that
make
sense
to
people?
B
A
A
A
E
It's
maybe
interesting
here,
because
now
we
have
the
flag
for
unhandled
objections
in
note
4
and
the
question
is:
should
we
and
decide
on
a
new
default
for
it
and
I
personally,
so
we
might
talk
about
it
at
the
summit,
but
just
like
briefly,
because
I'm
not
sure
if
we
want
to
change
it
right
away
or
not,
but
we
could,
for
example,
also
have
a
survey
from
our
users
about
this
topic.
What's
the
current,
so
the
default
is
then
nothing
changed.
Its.
E
A
A
E
E
How
am
I
no
rejections
in
general
work
and
what
does
it
normally
means
and
then
ask
our
user
base
and
what
would
you
prefer
to
have
as
a
general
default,
because
we
are
not
a
browser
and
therefore
we
have
different
requirements
for
most
people
and
also
it
would
be
interesting
to
see
if
there
is
a
difference
between
different
user
bases,
let's
say:
you're
a
clean
user
or
in
the
company
or
I.
Don't
know
what
you
know:
I.
E
B
E
E
A
B
A
Yeah
no
I
agree
that
the
both
like
I,
like
Peter,
says
having
it
being
user
driven,
would
be
a
good
idea,
so
we
can
do
a
user
survey
through
with
support
of
the
user
feedback
team.
We
still
pretty
much
need
to
to
write
up
the
survey,
any
questions
that
we
want.
So
that's
really
the
first
step.
The
other
thing
we
can
do
is
in
the
user
feedback
team,
we're
working
on
a
approach
where
we
can
actually
get
like
in
person
back
at
meetups.
A
The
first
one
is
going
to
be
about
adoption
of
new
releases
and
stuff,
but
it's
a
case
where
you
know
we
can.
We
can
also
have
you
know,
ask
at
some
point
that
one
of
the
questions
that
happens
in
those
meetups
is
like.
What's
your
feeling
on
this
and
then
we
would
point
them
back
to
somewhere
where
they
could
do
the
result.
You
know
it
could
comment
and
it
might
be
through
the
survey
or
through
something
else
or
but
I
think
writing
up.
A
E
A
E
E
C
Have
another
neat
picking
topic
if
we
are
done
with
this
topic,
while
I
was
reading
the
the
diagnostic
working
group
read
me.
Basically,
what
is
our
mission?
I
was
really
surprised
to
be
honest
and
let
me
copy
paste
it
into
the
into
the
text.
This.
This
mission
was
kind
of
stated
by
someone
three
years
ago,
who
is
not
part
of
the
working
group
anymore
and
I'm
really
surprised
that
what
we
are
focusing
these
building
documents
and
api's
for
the
vendors
basically
and
I'm,
not
sure
this
is
really
the
status
anymore.
I
see.
C
A
Think
the
thinking
at
the
time
was
we
didn't
necessarily
want
to
compete
with
anybody
like
who's
providing
tooling.
So
we
wouldn't
necessarily
write
a
debugger,
but
the
API
which
people
could
connect
to
with
the
debugger
was
not
an
issue,
but
you
know
and
I
don't
have
any
strong
feelings
like
if
we
basically
wanted
to
trim
it
after
the
NDP
is
or
something
or
the
way
to
move
forward,
just
create
a
PR
that
suggests
what
you
think
it
might
be
updated
to,
and
we
can
have
a
good
conversation
in
there.
C
A
Haven't
heard
I
was
definitely
telling
him
to
try
and
get
approval
and
everything
lined
up,
but
I
think
the
other
I
know
he
is
traveling
the
next
two
weeks.
Sorry
I,
don't
know
I'm,
certainly
encouraging
him
sense,
Sam
Roberts,
who
isn't
actually
part
of
the
working
group.
It
does
have
some
interest
on
the
diagnostic
side.
I've
heard
we'll
be
there
as
well.
Okay,.
A
A
A
H
G
A
A
To
sum
it
was
that
if
we
define
an
API
for
context,
propagation,
which
is
kind
of
like
at
a
different
higher
level
than
async
hooks,
that
may
then
mean
that
we
don't
need
to
focus
as
much
on
getting
Easton
hooks
out
of
experimental,
because
we
could,
you
know,
change
them
and
have
this
higher
level.
Api
stay
consistent
and
I.
Think
that
discussion
is
what
triggers
vladimir
to
open
that
that
issue.
So
it
is
related
in
that
sense,.
A
A
A
Don't
see
any
questions
on
the
YouTube
channel,
then
so
there's
nothing
else,
we'll
call
it
a
week
and
I
will
heads
up.
I
am
off
on
vacation
two
weeks
from
now,
but
I'm
hoping
Mike
will
be
Basco
he'll
share
the
meeting
and
I'll
catch
up
with
you
all
through
github
between
now
and
then,
but
after
that,
probably
at
the
next
meet.