►
From YouTube: Diagnostics WG meeting 2021-05-19
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
A
A
B
I
think
it's
the
same
as
last
time
I
haven't
seen
too
much
going
on
so
basically
taking
a
few
methods
and
trying
to
stabilize
them
not
stabilizing,
inter
with
in
particular,
so
I
think
it's
still
able
to
go
forward
last
we
talked
about.
There
were
no
objections
unless
somebody
has
one.
B
C
I'll
take
that
as
a
no,
so
I
guess.
B
C
Yeah,
it's
still
in
the
same
state,
so
vladimir's
had
no
time
to
actually
complete
the
changes
to
get
the
through
gi
and
whatever.
But
it's
just
doing.
D
B
D
A
C
B
D
I
think
well,
I
think
steven's
plan
was
to
write
a
blog
post,
which
we're
then
going
to
publish
to
try
and
get
some
some
larger
input
on
on
those
use
cases.
You
know
we
just
as
another
way
to
try
and
publicize
that
hey
we
would
like
some
of
them.
I
don't
know
if
you
have
other
suggestions
too,
but
that
was
the.
B
B
A
D
So
the
what
happened
is
there's
there's
an
issue
in
the
openjs
world
that
suggested
we
we
sync
back
in
september
to
see
like.
Is
it
possible
to
do
something
in
person
more
likely
or,
if
not,
you
know,
let's
schedule
a
collaborator
summit
at
a
different
time,
so
that's
kind
of
where
it
was
left
that
let's
look
back
in
the
september
time
frame
to
see
what
we
can
do.
A
There
was
a
much
more
lightweight
format,
which
I
remember
something
happened
in
montreal.
I
believe
that
I
believe
it
was
something
called
community
corner
where
you
don't
need
to
register.
You
just
come
to
a
public
corner
and
stand
up
and
talk
for
five
minutes
around
what
is
happening
in
your
community.
A
D
Okay,
I
think
you,
you
know
that
was
possible
to
submit
lightning
talks,
so
I
think
there's
some
lightning
talks
as
part
of
that
which
is
kind
of
related,
but
there's
there
isn't
a
community
corner
equivalent.
Okay,
it's
not
it's.
A
good
idea
like
that
might
have
been
something
to
suggest,
but
well,
I
think
we're
we're
only
a
few
weeks
away,
it's
probably
too
late
for
that
now
yeah.
D
I.
I
do
think,
though,
that
we
should
plan
on
you
know
a
collaborator
summit
of
some
form
for
this
year,
because
we
definitely
get
valuable
feedback
from
that
it
just
when
it
just
didn't,
like
I
kind
of
agree
that
it's
probably
we'll
probably
get
more
people
and
more
engagement.
If
we
do
it
as
a
separate
thing
versus
having
been
collocated
with
the
conference
itself,.
D
A
D
E
D
A
A
A
A
If
not,
I
have
a
item
which
I
added
to
the
meeting
for
today,
which
is
the
diagnostic
documentation,
best
practice
talk,
which
we
myself
and
mary
are
planning
to
present
in
next
week's.
A
A
A
D
A
Fair
enough,
basically,
the
whole
idea
of
this
talk
is
to
evangelize
spread
awareness
on
the
diagnostic
best
practice
documentation
and
see
if
there
is
an
interest
in
the
community
and
called
for
participation
now,
the
whole
flow
of
this
talk
is
arranged
in
in
the
way
we
see
in
the
agenda.
Basically,
we
talk
about
what
is
node.js
community
and
what
is
diagnostic
working
group,
which
is
a
subsection
of
the
node.js
community
and
we
introduce
the
philosophy
around
the
user
journey
and
how
the
user
journey
is
driving
the
best
practice
documentation.
A
We
also
introduce
the
concept
of
tooling
tires
and
how
we
organize
or
classify
the
tools
based
on
certain,
and
where
do
we
stand
with
respect
to
the
documentation
work?
What
is
the
activities
which
we
performed?
What
are
the
challenges
we
face
and
what
support
we
need?
That's
how
we
organize
this
talk.
E
A
Okay,
partly
to
do
with
the
logistics,
we
were
having
no
clue
about
how
to
record
from
two
different
locations
and.
D
A
A
So
in
terms
of
community,
so
we
want
to
talk
about
node.js
as
a
technology
which
is
the
you
know,
open
source
cross
platform,
javascript
runtime,
which
in
in
simple
sentence,
is
a
javascript
in
the
backend
and
which
is
powering
most
of
the
modern
workloads
such
as
cloud,
ai,
mobile
iot
and
other
things.
A
The
you
know
the
high
performance
in
the
concurrent
workload,
as
well
as
the
small
footprint
which
made
this
technology
as
the
first
class
citizen.
For
most
of
these
workloads
and
in
terms
of
the
community,
we
want
to
emphasize
on
the
high
standards
that
we
keep
on
the
values
and
the
values
centered
around
the
openness,
diversity
and
inclusivity.
A
A
I'll
make
that
change.
I
wasn't
sure
about
how
many
active
collaborators
we
have.
I
know
the
numbers
from
the
core
repo,
but
when
we
talk
about
the
organization,
I
don't
know
if
there
is
a
clear-cut
way
of
counting
that,
so
I
just
condensed
it
into
thousands
of
active
contributors
that
makes
sense.
A
A
F
A
D
A
A
A
D
D
A
D
A
Sometime
back,
we
used
to
say
that
the
third
or
fourth
most
activated
in
the
entire
github,
but
I
I
don't
think
that
is
still
the
case.
We
might.
A
All
right,
let
me
know,
let's
think
on
that,
and
please
inform
me
something
else.
I
will
keep
it.
I
will
think
about
it
at
this
point
of
time
and
we'll
come
back
to
it
or
think
about
it.
A
A
A
A
Okay
and
then
we
come
across
introducing
the
user
journey
concept,
to
put
it
simply:
the
user
journeys,
the
end-to-end
experience
for
a
person
with
node.js
diagnostics
or
the
experience
than
at
a
diagnostic
context.
As
when
the
nodus
deployment
came
across
a
production
anomaly,
what
is
the?
What
is
the
experience
they
get?
What
is
the
workflow?
What
is
the
step-by-step
process
through
which
they
take
it
up
to
the
resolution?
A
Then
we
define
a
term
called
long-term
supported
use
cases
which
essentially
means
use
cases
are
not
transient,
they
are
not
short-lived.
We
look
at
the
deployment
models.
We
look
at
the
supported
scenarios,
workloads,
etc
and
attach
the
diagnostic
use
cases
to
those
and
call
it
a
long-term
supported
use
case
then
help
the
tool
help
identify
the
tools
which
are
most
relevant
for
those
lds
use
cases
and
then
document
the
user
journeys
document,
the
diagnostic
practices,
diagnostic
processes
and
the
methodologies
and
do's
and
don'ts
all
those
things
in
the
form
of
the
best
practice.
D
D
D
A
We
have
a
well-defined
structure,
starting
from
how
do
you
prepare
your
productions
for
a
future
diagnostic
process
in
mind
up
to
the
best
practice
and
the
methodologies
with
different
tools
on
the
on
the
same
issue,
so
I
would
say
the
two
two
key,
pioneering
or
vital
aspect
of
using
journeys
and
best
practice
documentation
is
one
is
aligning
identifying
and
aligning
the
user
journeys
with
the
tools.
A
Number
two
is
the
case:
studies
with
different
tools
on
the
same
issue.
For
example,
if
you
have
a
memory
memory
leak
issue,
how
do
we
troubleshoot
the
memory
leak
issue
with
the
help
of
heap
dump
and
the
chrome
developer
tools
that
would
that
would
form
one
workflow
that,
on
the
other
hand,
the
same
issue
the
same
use
case?
How
do
you
handle
with
the
ll
node,
for
example,
and
with
the
diagnostic
report?
A
So
the
same
scenario
is
dealt
through
three
different
workflows
and
based
on
the
actual
context
of
the
user,
based
on
the
maturity
model
of
the
tool
or
based
on
the
familiarity
with
the
tool
the
user
is
able
to
make
use
of
one
of
it
with
relative
ease
and
that
essentially
improves
the
consumability
of
the
of
the
tools
and
the
overall
node.js
deployment
experience.
Production
experience.
F
Yeah,
I
think
that
makes
much
sense
to
tell
to
the
user
the
journeys
how
to
debug
some
possible
issue
in
production,
for
instance,.
A
Yeah
one
one
tool
may
be
best
suited
for
diagnosing
that
specific
issue,
but
because
of
the
user's
context,
such
as
maybe
security,
context
or
specific
execution
environment.
That
tool
is
not
suitable.
That
should
cannot
that
tool
cannot
be
used.
Then
we
do
have
one
or
two
alternative
flows
which
will
still
help
them.
F
We
currently
have
exposed
our
documents
that
we
made
about
this
this
this
journey
or
is
still
what
thing
to
do.
A
F
F
Probably
would
be
great
to
share
this
issue.
This
is
shown
on
the
dragonosc
repository
that
contains
four
four
for
documents
that
we
made
along
the
the
journey.
Okay,
make.
A
A
What
is
the
maturity
level
of
the
tool
at
this
point
in
time,
and
what
is
the
adoption
strength
in
the
user
ecosystem
and
how
well
the
tool
is
maintained?
Tool
can
be
maintained
by
the
node.js
project
or
external.
It
doesn't
matter,
but
how?
How
strongly
or
how
well
it's
maintained.
So,
based
on
all
these
parameters,
we
assign
a
peer
to
the
tool
which
helps
in
two
aspects.
One
is
for
a
user
based
on
the
context,
their
context.
They
can
picture
the
right
tool
for
that
specific
case
or
a
context.
A
D
So,
basically,
you
know,
as
you
moved
up
the
tier
level,
it
would
imply
things
that
we
would
do
to
keep
them
working
in
the
project.
Right,
like
tier
one,
implies
that
we're
running
ci
testing,
I
think
yeah
and
the
lower
levels
are
like
hey.
These
are
important,
so
it's
kind
of
like,
as
as
we
move
these
things
up,
the
tiers,
it
was
an
acknowledgement
that
we
think
they're.
D
A
Okay,
so
it
was
more
around
to
support
our
lts
strategy
around
the
core
base.
We
also
want
our
tools
to
also
be
aligned
with
that
lds.
D
A
D
D
A
A
By
looking
at
the
table
in
the
tier
document,
one
can
clearly
say
that,
okay,
this
is
the
area
where
a
lot
of
issues,
but
very
less
number
of
mature
tools
exist,
whereas
on
on
this
particular
say
ffdc,
there
is
one
critical
tool
that
is
existing.
That
is
already
in
tier
one,
so
I
don't
I
need
to
as
a
contributor.
I
can
well
focus
on
this
particular
aspect
where
there
is
real
value
in
my
contribution.
A
Definitely,
and
we
could
also
get
help
if
we
have
more
real
world
stories
from
the
production
in
certain
cases,
and
we
could
also
get
help
from
external
participation.
Those
who
have
been
working
with
node.js
deployments
can
come
and
say
this
is
the
area
where
we
could.
A
A
A
A
Yeah,
it
should
be
raphael's
register
somewhere
here
here
slide
number
seven.
It
should
be
either
here
or
it
should
be
here.
That
is
where
we
are
talking
about.
The
current
status.
A
F
A
D
A
A
So
that's
it
from
that.
Any
other
topic
for
discussion.
A
A
If
not,
let's
call
it
today,
thanks.