►
From YouTube: 2022-10-12-Next 10 years of Node.js
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
So
welcome
to
the
node.js
next
10
meeting
for
October
12
2021
we'll
go
based
on
our
agenda,
as
was
posted
in
the
issue
which
is
number
164.
A
before
we
get
started.
Does
anybody
have
any
announcements
they'd
like
to
share.
A
A
I
did
paste
into
the
issue
itself
a
couple
of
the
boards
from
the
the
sort
of
top
10
prior
technical
prior,
the
technical
priorities
and
the
community
discussions
and
I
guess
we.
We
should
maybe
open
some
issues
to
review
those
and
take
next
steps.
B
So,
at
least
for
the
you
know,
documentation
one
I
think
just
of
course
an
issue
to
keep
track
of
things,
but
I
think
the
scale
that
one
will
be
open
are,
the
you
know
to
you
know,
propose
the
changes
in
the
structure
and
everything
is,
you
know
possibly
going
to
change
in
the
documentation
standards.
B
Is
it?
Is
there
a
place
where
we
usually
opened
our
seas
or
okay.
A
I
think
like
so
there's
two
places
that
I
can
think
of.
That
might
be
a
good
place
to
do
that.
One,
let
me
find
the
you,
don't
really
have
an
RFC
process
or
anything
like
that
and
I
think
PRS
tend
to
get
the
most
views
so,
but
I
think
we
have
like
a
doc
strategy,
doc-
foreign-
maybe
it's
not
in
here.
B
Car
docs,
you
know
node
slash,
block,
slash,
API
yeah.
A
Okay,
because
I
think
we
have
actually
a
PR
doc,
see
if
I
can
find
that.
A
Yeah,
that
might
be
a
good
idea
to
sort
of
discuss,
see
if
we
we
can
agree
among
ourselves
and
then
take
that
to
the
I
pasted
in
the
chat
there.
There
is
a
link
that
came
out
of
some
earlier
discussion
in
terms
of
like
a
additions
to
the
style
guide,
to
make
it
easier
to
parse
for
typescript.
A
But
I
think
the
I
think
like
to
John's
point.
It
might
be
good
to
come
up
with
a
strategy,
because
just
putting
a
huge
change
in
didn't
seem
to
be
very
successful,
like
I
think.
What
we
need
to
figure
out
is
like
here's,
where
we
at
what's
a
nice
consumable
step
that
that
you
know
we
can
communicate
and
people
will
look
at
and
say
yeah,
okay,
that
makes
sense
and
then
what's
the
next
step
after
that
and.
B
Yeah,
at
least
in
the
sense
when
the
changes
that
we're
talking
about
are
not
the
Style
guy,
like,
for
example,
how
people
should
Place
headings
and
code
Snippets
and
formulate
things
inside
the
documentation.
But
it's
more
like
the
pure
nature
of
how
the
metadata
documentation
is
done.
So
for
separating
I
mean
it's
what
we
discussed
on
collapse,
image
having
the
problem
files
that
are
purely
just
for
the
metadata,
for
example.
What
are
the
methods
that
the
class
provides?
B
You
know,
and
you
know
one
was
added
the
history
changes
and
then
having
respective
marked
on
files,
which
are
the
actual
content
example
description
below.
A
Right
so
I
I
understand
exactly
where
you're
coming
from,
but
I
know
from
the
past
discussion
on
this
particular
PR.
It
gets
all
mixed
together
and
so
like
this
pier
started
out
as
like,
hey
here's,
a
whole
new
thing
and
people
are
like
well
wait
a
sec.
We
already
have
something
that
didn't
like
so
and
and
and
I
know.
This
is
called
the
style
guide,
but
like
somewhere
in
there.
It
basically
I
think
now
says
every
you
know.
Things
should
have
an
example,
and
so
it's
not
strictly
the
style.
B
It's
more
like
yeah
I
see
it's
also
how
this
structure
should
be
done
with
when
the
meaning,
but
that
that
we're
talking
about
is
the
mark,
don't
count
the
part
right.
So
one
of
the
ideas
here
is
to
extract
present
that
the
ammo
sections
we
have
inside
the
markdown
and
have
separate
files
for
them
and
also
destruct
the
current
you
know
magnifies
to
smaller
pieces
instead
of,
for
example,
one
big
fiber
module.
B
We
have
one
fiber
class,
then
you
have
like
directories,
for
example:
FS
then
promises,
then
you
know
whatever
that
is
Insider
yeah,
but
yeah,
but
I
think
we
are
derailing
here.
A
little
bit.
I
mean
that's
part
of
this
question,
so
I
mean
the
question.
Original
question
was
more
like
what
would
be
a
good
place
for
or
to
pick
up
this
discussion.
You
know.
A
Right
and
I'm,
just
gonna
show
you
like
here
in
this
talk,
it
actually
mentions
the
ammo
as
well,
so
I
think
like
what
I'd
really
like
is
us
to
get.
This
change
landed
and
then
figure
out
a
strategy
to
add
the
next
step
to
it
right
and
then
the
next
step.
A
I
I
think
so
what
I'm
thinking
is
like
this
is
a
good
place
to
propose
a
change.
If,
over
time,
people
are
like
yeah,
okay,
we
need
to
expand
it
out,
like
I.
Almost
we
have
in
in
the
doc
collaborators.
There's
like
we
have
like
you
know,
wasm
strategy.
I
could
see
us
having
like
a
document
strategy
but
I,
don't
think
that
would
be
well
received
to
start
with
I
think
it's
better
to
try
and
like
adjust.
A
B
Yeah
yeah
I
mean
yeah
I
mean
let's
do
baby
steps
here.
I
will
give
a
full
read
on,
for
example,
that
PR
because
88
comments
that
will
take
some
time
to
go
on
and
see
where
we
are
at.
A
Yeah,
it
is
one
of
my
goals
that,
like
I,
haven't,
had
a
chance,
but
to
get
back
to
that
and
see
how
we
can
get
that
landed,
because
I
think
that
first
step
does
have
some
of
the
things
that
that
you
know,
like
always
having
an
example
that
we
talked
about
and
it's
a
step
in
the
right
direction.
It'll
help
with
typescript
and
then
once
it's
there,
it's
a
good,
a
good
place
to
then
say:
okay,
what's
the
next
little
thing,
we
could
oh.
B
A
But
I
think
the
idea
of
a
strategy
doc,
like
John,
said
in
in
the
next
10
it's
a
sort
of
a
smaller
group
of
place
where
we
can
chat
about
a
good
strategy
in
outlining
the
like.
Maybe
if
you
want
to
open
an
issue
that
says
like
here's,
the
proposal
that
says
hey,
we
talked
about
all
these
things.
Here
are
the
things
you
know.
A
Maybe
here's
that
other
doc
that
I
I
pointed
to
you
know
step
one
get
that
landed
step,
two
whatever
and
so
forth,
right
and
I
think
once
we
have
that
we
can
try
and
see
if
we
can
grow
the
audience
too
like
are
there
other
people
who
are
doc
or
if
docs
interested
that
you
know
aren't
here,
but
that
we
should
pull
into
the
discussion.
I
know
like
rich
is
often
quite
quite
involved
with
them.
So
it'd
be
good
to
say:
hey.
Can
you
take
a
look
at
this
right.
B
Yeah
yeah:
that's
how
the
company
sounds.
Fine
I
think
I
can
even
make
a
draft
issue
which
is
just
to
keep.
You
know
the.
If
it's
written
down,
you
know
what
we're
talking
collapse,
Summit
and
strictly
say
hey.
This
is
a
draft
that
showed
actually
start
to
be
worked
on
after
this
lens.
Actually,
and
then
you
know
so
we
have
oh.
A
A
B
B
A
You
think
was
agreed,
add
the
link
in
the
in
there.
That
basically
says
like
okay,
here's
the
you
know
it's:
what's
it
October
2022
collaborator,
Summit
discussion
so
that
people
can
can
find
them
and
then
the
related
work
or
whatever
you
can
have
the
link
to
like.
What's
the
proposal
and
that
sort
of
all
gives
us
the
the
starting
point
to
say
yeah,
this
is
one
of
the
things
that
we've
identified.
We're
working
on
and
people
can
find
stuff.
B
Yeah
I
saw
that
you
actually
already
made
an
issue
number
one
121,
so
I
can
also
just
keep
the
conversation
already
there,
or
does
it
make
sense
or
another
one,
just
October,
which
one
was
that
the
document
metadata
one
two
one
next
time.
A
Yeah
wait
right
round
one
two,
one:
okay,
so
that
that
was
out
of
the
pure
yeah
yeah.
That's
a
very
specific
thing
like
that's
about,
like
that.
We
haven't
even
documented
our
metadata
I.
Think
you'd
be
better
off
like
creating
an
issue
that
says
here's
the
capture
of
what
was
discussed
at
the
collaborator,
Summit
yeah
yeah
right
because
it's
nice
to
go
back
and
say
like
hey,
we
kept,
we
all
got
together.
This
is
what
people
seem
to
agree
and
be
able
to
refer
back
to
that
so
and
I.
Don't
you
know
we?
A
A
A
So
so
I
might
yeah
I
think
it
would
be
good
to
have
an
issue
here
that
says
like
collaborator,
Summit,
October
documentation
session
and
try
and
capture
everything
you
think
that
was
agreed
and
discussed
there.
B
Yeah
sure
I
can
work
on
that.
Just
definitely
at
least
you
know
talking
about.
You
know
how
the
people
reacted
to
what
was
told
there.
Initial
feeling
was
that
there
was
no
verbal
objections,
but
of
course
that
doesn't
indicate
anything.
But
are
we
also
after
credit
issue,
try
to
tag
the
people
that
were
in
the
session
to
see
you
know
what
are
their
opinions?
Yep
start
off,
because
both
Joe
and
trot
were
not.
You
know,
they're,
always
a
remotely
I,
don't
recall,
I,
don't
I,
don't
think
so.
A
B
Yes,
exactly
but
I'm
sure
that,
for
example,
even
after
we
start
creating
the
pr
as
you
posted
you
know,
things
go
smooth
I'm
sure
that
there
will
be
a
lot
of
iterations
even
on
whatever
that
we
agree,
because
I
mean
what
is
in
my
head
versus
everything
that
we
might
need
is
those
are
completely
different
words
right
yep
for.
A
A
It's
it's
one
thing
to
say:
hey.
We
can
split
that
out,
but
then
it's
like
figuring
out
what
all
you
know
of
the
the
Machinery.
B
I
remember
that
they
made
the
clone
of
the
tooling,
because
so
the
current
trolling
that
exists
inside
node
core
uses
AST
for
generating
both
the
HML
and
the
Json
counterparts
and
I
create
a
simplified
version
of
it
and
also
always
everything.
The
only
thing
that
doesn't
do
yet
is
Json,
but
in
each
part,
is
that
I
could
also
add
a
Json
processor
to
just
because
I
already
have
all
the
data,
and
then
he
created
an
output
but
yeah.
B
If
for
them
for
whatever
changes
that
actually
happens,
you
know
to
the
metadata.
Definitely
changes
need
to
land
on
either
tooling.
You
know
yeah
I
just
find
the
existing
tooling,
that
is
in
core
a
little
bit
too
big,
there's
so
many
files
and
there's
no
like
easy
written
documentation.
So
when
I,
okay
I'm
a
little
bit
biased
because
you
know
I
Rose
the
refactoring
for
training
that
is
used
on
the
new
node.js
Dev
website,
but
I
added
documentation
for
every
piece
like
what
this
exactly
does.
Why
this
does
this
and
Etc?
B
And
it's
very
clean
code,
I
suppose
I
feel
that
the
initial
tooling
was
created.
You
know
and
just
expanded
over
the
time,
with
no
real
direction
as
it
needed,
and
it
resulted
on
what
we
have
today.
A
A
Do
miss
a
lot
of
documentation
right,
like
one
of
the
things
that
I
think
would
be
great,
would
be
like
in
the,
but
here
in.
B
A
You
know
like
I'm,
maintaining
the
dock
tooling
or
something
would
be
probably
a
great
document
so
that,
like
people
collaborators
come
in,
they
could
read
that
and
get
a
get
an
idea
of
like
well.
How
does
it
all
work-
and
you
know.
B
Yeah
I
I,
basically
linked
to
the
file
where
I
created
a
new
tooling
it
just
one
file
and
basically
it
explains
and
Trend
what
happens.
This
is
basically
just
audio
changes
that
transform
the
source
marked
down
on
what
you
see
in
the
pages,
for
example,
right,
not
sure
if
you
ever
had
a
chance
to
check
the
new
generated
documentation
with.
Basically
this
is
the
new
language.
B
This
is
how
it
looks
on
the
new
website,
but
basically
the
whole
specification
is
the
same.
You
know
the
same
output,
it's
just
a
different
style
of
the
website
right,
but
if
I
use
this
crypto
generate
the
same
thing
should
also
work
on
the
Target
on
the
old
infrastructure,
right
yeah,
but
yeah
I
think
pretty
much.
That's
it
I.
A
Mean
did
you
figure
out
the
old,
tooling
and
sorry
it's
like
I
would
like?
Did
you
figure
out
the
old
tooling,
because
you
know
I
think
a
short-term
thing
that
would
add
value
would
be
to
actually
document
the
old,
tooling
and
add
that
maintaining,
because
that
helps
people
like
if
we
want
to
get
to
the
point
where
there's
something
new
helping
once
people
understand.
What's
already
there
I
think
is
a
step
yeah
right.
B
I
think
the
reason
why
I
decided
initially
to
create
a
new
tooling
was
the
overall
structural.
The
current
tooling
was
even
if
I
added
doc
blocks
like
the
hard
spot
is
where
it
starts.
Where
it
ends,
and
you
know
all
do
I
iterate,
you
know
on
the
things
that
happen
inside
basically,
for
example,
in
the
new
one
there's
this
basically
one
method
called
create
Magnum,
parser
and
then
in
basically
says
first,
this
happens
then
just
happens.
Then
this
happens
then
just
happens.
A
I'm,
not
necessarily
like
you
know,
ad
doc,
add
dock
to
the
existing
tooling
files,
it's
more
even
like
the
higher
level
like
do.
We
have
written.
A
B
A
Actually
that
high
level
thing
that
says
like
here's,
what
here's
what
comes
in
yeah
and
here's,
what
comes
out
to
me,
that
would
be
quite
useful,
because
then
people
can
under
understand
that
high
level
thing
and
say:
okay
well
now,
I
understand
what
we're
changing
versus
the
you're
changing
the
black
box.
If
you
know
what
I
mean.
B
Yeah
yeah,
that's
true,
that's
true,
yeah!
Definitely,
actually
that
makes
very
much
sense
if
you
could
create
a
CTA.
I
can
definitely
try
to
create,
even
if
it's
in
Google
doc
for
now,
just
you
know
to
keep
track
of
what
I'm
writing,
because
I'm
not
sure
always
where
I
should
land
this.
It
should
be
on
core
or
over
I.
Think
that.
B
Actually
yeah,
actually
PR
already
makes
sense
from
the
beginning,
because
you
just
marked
down
just
you
know
just
documenting
whatever
happens,
yeah
I
will
add
to
my
personal
knowledge
list.
So
I
remember:
okay,.
A
A
Know
if
you
want
us
to
take
a
look
along
because
I'd
be
interested,
you
know
I
poked
a
little
bit
at
it
with
like
we
were
trying
to
get
the
electron
parser
going
for
the
typescripts
and
stuff,
but
I
still
don't
have
a
clear
picture
myself
so
I'd
be
happy
to
read
what
you've
got
and
learn
and
give
you
any
feedback.
So.
A
Electron
has
like
part
of
one
of
the
earlier
discussions
on
the
the
the
documentation
and
API
docs
came
up
in
a
couple
discussions
one.
We
had
like
a
deep
dive
on
just
documentation,
but
the
other
one
was
types
and,
as
you
saw
like
in
the
collaborator,
Summit
types
are
still
top
of
people's
minds.
We
don't
necessarily
want
to
ship
the
types
for
node,
but
we
want
to
make
it
easy
for
people
to
be
able
to
generate
them.
We
currently
generate
I
think
it's
Json
from
the
docs.
B
A
That's
used
by
the
typescript,
but
it's
not
well.
It's
not
well
structured,
you
know.
Basically
they
can
kind
of
do
it,
but
then
they
got
to
do
some
manual
work.
So
what
we
wanted
to
do
was
improve
that
and
part
of
what
electron
has
a
tool
which
was
this
parser,
which
parses
their
Docs
and
generates
a
well-structured
output.
A
A
Of
that
other
PR
that
that
I
pointed
you
to
was
to
put
more
things
in
and
say
and
like
formalize,
like
everything
has
to
have
a
header
like
this
and
a
header
like
that,
so
it's
easy
to
easier
to
parse
and
that
tool
parse
it
and
then
separately
we
were
trying
to
see.
Can
we
use
their
parser
to
then
give
us
this
better
output?
A
And
that's
where
that
you
know
it
was
like
a
tool
that
already
existed.
So
why
not
start
with
that?.
B
Yeah
a
woodchuck
could
oh,
let's
see,
reduction
because
he's
on
an
electron
team.
If
you
can
link
me
to
the
tooling
and
see
if
I
can
also
talk,
yeah.
A
Let
me
see,
did
I
do
I
have
anything
I'm
sure,
I
document
it
somewhere.
A
Anyway,
I'll
look
at
it
afterwards
and
see
if
I
can
can
ship
that
over
to
you,
because
I
did
play
with
it
and
tweak
the
the
the
parts
were
a
little
bit
and
that
it's
basically
where
the
next
step
to
move
things
forward
really
is
to
get
that
other
PR
landed,
which
is
stalled
for
quite
a
while.
But
if
we
can
get
movement
on
that,
but
it's
all
related
to
what
you've
got
like.
As
we
read
or
structure
the
docs,
we
could
better
do
those
kinds
of
things.
A
Yeah
no
they're
they're
right
now,
they're
just
a
set
of
docs
which
are
like
you
know,
if
there's
a
few
so,
for
example,
if
you're
looking
at
like
http,
which
is
one
that
has
one
our
dependencies,
are
one
where
there's
some
like.
You
know:
there's
there's
a
maintaining
dependencies,
there's
a
maintaining
HTTP
but
you're
right.
It's
relatively
ad
hoc
at
this
point,
oh.
A
It's
basically
like
hey
like
maintaining
npm.
If
you
need
to
do
an
npm
update,
because
we
have
that
as
a
dependency,
it'll
be
the
place
that
has
those
instructions
right
and
it's
in
the
some
of
the
some
of
the
cases
like
the
I'm
seeing
like.
Where
is
our
sort
of
types
one
in
their
types,
so
maintaining
types
for
node.js?
A
If
you're
going
to
work
in
a
particular
area,
it's
a
place
to
put
some
some
some
some
specifics,
but
it
has
been
growing
more
ad
hoc
and
it
was
not
called
that
something
it
was
called
something
else.
I
don't
know
what
it
was
called,
but
it
now
makes
more
intuitive
sense
to
me
this,
like
Doc,
contributing
because
now
I
can
I
know
where
to
go
and
look
and
find
those
things.
B
A
B
A
Right
that,
at
some
point,
we
have
like
a
separate
collaborator
guide,
but
that
separate
collaborator
guide
is
more
of
a
high
level.
How
do
you
land,
PRS
stuff,
like
that
this?
This
could
use,
maybe
like
hey?
If
you
want
to
dive
down
into
any
of
the
areas,
here's
all
the
things
you
kind
of
get
a
table
of
contents
just
by
looking
in
the
directory,
but.
B
A
Okay
right,
let
me
get
back
to
can
I
find
our
shoes.
A
A
A
B
I
can
create
an
issue
for
I
should
put
like
no
I'm,
also
gonna.
A
Yeah,
if
you
can
do
it
right
now,
then
we'll
put
it
in
them
and
it's
like
I
figure.
We
might
as
well
use
this
one
as
a
working
session
to
say,
like
what
are
all
the
next
steps
and
then
the
following
meetings.
We
can
actually
like
I'll
tag
this
one
for
our
agenda,
because
then
it's
actually
going
to
start
to
show
up
on
our
agenda,
so
we
don't
forget
and
we
can
do
the
same
one
with
the
with
any
of
the
others
that
make
sense.
B
A
A
Okay,
I
guess
like
in
terms
of
the
the
collaborator
Summit.
Are
there
any
other
sort
of
next
steps
that
we
should
plan
for,
or
foreign.
C
C
A
A
Yeah
we
have
to
dive
deep
dive
a
little
bit
more
into
these
to
see
that's
probably
worth
the
session
on
its
own.
So
maybe
next
week
we
can
plan
to
go
through
these
and
say:
okay,
let's
start
working
on
those
and
how
how
maybe
that
should
adjust
our
technical
priorities
and
then
the
you
know.
How
do
we
highlight
with
these
I'm
gonna
actually
get?
A
So
because
I
think
it'd
be
nice
to
follow
up
with
the
rest
of
the
attendees
and
say
hey
like
here's,
the
things
that
we're
output
and
you
know
use
that
as
a
as
a
way
to
continue
some
of
that
discussion.
A
A
C
Yeah
nothing
new
yet
since
last
week,
I
stay
as
soon
as
you.
I
will
also
check
Maybe,
because
I'm
still
not
entirely
sure
on
how
we
want
to
display
that,
because
we
already
have
a
file
which
show
the
different
action
we
did
on
the
past
year.
So
I
don't
know
exactly
how
to
display
something
like
that
correctly,
without
being
almost
the
same.
Let's
say
as
a
blank
file,
so
I
have
to
think.
A
I
think
the
the
color
is
like
it's,
maybe
the
the
very
like
a
very
compact
picture
that
says
we're
green
on
these
and
right
on
these
other
ones.
That's
kind
of
interesting
right,
okay,
good,
try,
but
yeah
so
it'd
be
interesting
to
see
what
it
looks
like.
We
could
look
at
it
and
say:
oh,
it
doesn't
really
add
anything
or
not,
but
but
I
like
that
idea
when
you,
when
you
thought
of
it
so
okay.
C
Yeah,
so
this
one
was
also
linked
to
what
we
discussed
during
during
the
next
10
session
during
the
karabata
summit.
Mainly
it's
one
of
the
parts
that
we
discussed
not
just
being
linked
to
the
so
yeah,
basically
being
into
the
documentation,
but
not
only
to
the
pure
PLC
side.
But
what
do
we
want
to
do
for,
let's
say
newcomer,
and
it
includes
both
easier
documentation,
which
is
no
searchable
thanks
to
the
working
group
working
on
the
new
website,
but
also
what
do
we
want
to
do
on
some
keto
Peak
or
find
article?
C
A
Yeah
and
I
think
that
one
I
mean
there's
been
discussion
back
and
forth,
and
it's
been
like
the
example.
The
example
repo
I,
don't
think,
has
had
much
activity
and
even
on
some
of
the
websites
that
what
I've
heard
a
few
times
is
like
not
that
people
don't
wish.
We
could
do
more
of
that,
but,
like
we
just
have
not
been
able
to
do
very
much
of
that
and
we
don't.
The
the
project
itself
doesn't
have
the
resources
to
help
actively
curate
those,
so
they
go
out
of
they
go
out
of.
A
They
become
stale
different
things
like
that,
and
so
the
sense
I
get
is
like.
Maybe
we
should
stick
to
the
API
Docs
and
you
know
it's
to
the
broader
community
and
if
we
do
anything
it
might
be
to
like
curate
and
have
links
to
docs
versus
anything
else
as
opposed
to
having
them
on
our
sites.
But
that's
just
sort
of
what
I've
I've
heard
on
that
one.
So
I
don't
know
what
other
people
have
kind
of
heard
in
terms
of
feedback.
C
I
think
it
was
something
like
that.
Also
the
main
issue
is
we
don't
have
them
just
basically
the
manpower
to
work
on
everything
into
mainly
that
Pathways,
which
require
a
lot
of
continuous
changes
and
update
and
even
more
if
we
want
to
have
example,
based
on
multiple
version,
if
sometimes
we
do
have
some
Breaking,
Chains
or
stuff
like
that,
so
it's
really
cool
it
will
require
a
lot
of
work
on
my
and
I
would
agree
with
everything
you
said
Michael,
but
I.
C
Think
that,
having
your
being
your
home
time
without
a
way
for
newcomer
to
understand
or
to
have
at
least
linked
to
good
resources
to
find
on
which
case
it
can
be
useful
how
to
use
it.
Basically,
even
if
it
doesn't
go
on
every
function,
but,
let's
say
main
use
case
I
would
say
just
if
we
are
talking
just
about
node.js,
let's
say
just
even
basically
redirect
to
some
documentation
on
fastify
or
Express
or
any
other
framework,
because
if
today
you
are
coming
on
the
node.js
website.
C
Okay,
you
know
some
stuff
about
node.js.
But,
let's
be
honest,
no
one
is
writing
HTTP
server
based
on
your
node.js,
except
for
something
button.
If
you
don't
know
Express
or
fastify
and
stuff
like
that,
you
will
just
be
lost
and
it
will
also
maybe
in
there
or
because
I
don't
think
this
year
will
talk
a
lot
about
that.
But
how
do
we
want
to
continue
as
energy
as
a
JavaScript
runtime
to
be
relevant
for
company?
A
B
Topic
that
I've
seen
a
lot
of
different
operators
discuss
even
for
example.
Recently
we
were
auditing.
For
example,
other
learn,
learn
pages
that
we
have
on
the
new
website
and
the
guides
on
the
old
website,
and
one
common
conclusion
is
that
well
some
things
to
give
examples,
for
example,
making
HTTP
web
server
Etc.
B
Libraries
right,
so
one
of
the
conclusions
was
that,
instead
of
us
giving
examples
of
what
people
can
actually
real
world
applications
that
you
can
do
with
node.js,
we
could
link
to
outside
resources,
because
there
are
hundreds
of
courses
of
people
saying
what
you
can
do
with
node.js
and
stick
with
documenting
more
like
whole
work.
B
Node.Js
works,
for
example,
a
synchronous
modules
have
actually
a
better
documentation
for
how
you
can
understand
the
file
system,
module
streams,
module,
node,
nlpa,
API
or
Etc,
because
one
thing
that
I
often
get
asked
for
is
the
current
API
docs
they're
too
straight
to
the
point
and
many
things
that
have
examples
and
etc,
etc
and
I
think
it
goes
back
to
what
Michael
was
saying
initially,
with
the
huge
PR
cone
DNA
regarding
restructuring,
hollow
blocks
or
problems.
B
But
then,
just
to
you
know,
trdr
those
two
different
things
here,
the
developer
experience
you
know
how
to
make
dogs
be
better
for
new
people
of
you
know
to
allow
them
to
become
champions
of
node.js
easier.
You
know,
and
the
second
part
which
is
you
know
what
is
the
content
that
should
actually
be
inside
or
docs?
You
know
you
know.
A
I
think
like
from
my
perspective
and
I,
think
it's
a
little
bit
of
what
you
just
said
is
we
can
do
a
lot
of
good
by
improving
our
API,
Docs
and
so
actually
starting
there
like.
If
we
get
to
the
point
where,
like
our
API
docs,
are
what
we
think
we'd
like
them
to
be
and
they're
fully
like,
they
have
all
the
examples
they
have
all
those
things.
A
B
Yeah,
that's
where
I
think,
for
example,
that
I
think
that
currently
already
or
API
docs
are
not
just
tier
API,
docs
and
strict
sense
of
API
experience.
If
you
go
to
npmjs
docs,
those
are
API
docs
like
we're
using
CLI
reference,
for
example.
Those
are
references
of
what
is
exposed
and
our
apis
are
mixed.
They
are
neither
one
or
another
because
in
in
some
documentations
present
in
some
Magnum
files,
people
added
examples
at
a
nice
introduction
and
orders
they're,
just
literary,
for
example,
lubrication
codes
and
boom.
B
C
C
C
Just
one
we
discussed
yeah
last
week
was
no
one
is
currently
providing
a
good
documentation,
or
example
on
how
to
create
a
library
which
is
compatible
both
with
esm
and
ncgs,
which
I
think
should
be
our
because
you
don't
rely
on
library
on
other
tooling
or
packages
or
library
to
do
so.
It
should
be
handled
by
us
to
have
this
kind
of
I.
Don't
know
tutorial,
I
I,
don't
know
the
name
you
want
to.
Well,
you
give
it,
but.
B
B
You
know,
publish
both
on
CJs
and
esm,
but
I
think
the
the
moment
that
you're
talking
about
the
package
you're
not
talking
about
nodes,
just
node
itself,
anymore,
you're
talking
already
npm
or
pnpm
yarn
car
pack-
please
don't,
but
whatever
you
know,
you're
talking
more
like
a
maintainer's
perspective
and
or
docs
or
not
maintainer
dogs
right
I
mean
I
I'm,
not
saying
that
we
should
not
have
a
good
maintainer
docs,
but
that's
ad
hoc
on
top,
for
example,
they're
they're
conducts
that
that
are
not
API
docs,
but
I
still
feel
that
they're
interesting,
for
example,
how
a
synchronous
works
for
them,
the
difference
between
blocking
and
blocking
on
node.js.
B
This
is
not
an
API
doc,
but
there's
a
documentation
called
in
your
systems
of
node.js
works.
This
is
something
that
definitely
personally
makes
sense
to
have.
But
then,
if
you're
talking
about
maintainers
guide,
you
know,
and
even
collaborators
developers-
and
we
have
we
just
talked
before
you
know-
Michael
shown
this
dark
stash
contributing
which
is
a
folder
for
anybody
that
collaborates
the
node
core.
B
B
For
example,
I
made
a
survey
and
a
lot
of
people
use
the
new
website,
which
is
to
a
draft
to
learn
how
to
use
npm,
because
the
npm
box
right
now
works
peer
references
and
even
though
you
can
actually
find,
for
example,
how
to
create
a
package
how
to
install
things.
How
to
you
know,
I
mean
those
are
issues
on
npm
dogs
and
you
could
try
to
solve.
For
example,
this
is
from
npm
in
or
Internet
docs.
Wouldn't
that
be
I
could
try
to
cover
the
whole
universe.
A
I
did
open
up,
we
do
have
a
package
maintenance
team
and
one
of
the
things
that
that
team
worked
on
over
the
years
is.
We
do
have
some
docs
for
maintainers
and
that's
a
group.
A
B
A
Yeah
and
like
how
do
we
make
them
visible?
Is
the
next
challenge
you're
right
like
we,
we
created
these.
We
had
them
in
drafts.
We
published
them
here
at
some
point
we
thought
like.
Maybe
we
would
promote
them
to
one
of
the
websites
or
something
like
that,
but
we've.
Never
we
never
pushed
it
that
far
right,
so
that
might
be
again
something
to
push
on
a
bit
I.
B
Mean
it
goes
sorry,
just
one
second,
but
it
goes
I
think
something
the
I
think
you
John
said
on
the
club,
Summit
I'm,
not
sure
if
it
was
you
but
documentation
for
three
different
kind
of
audiences
user.
B
You
know
a
contributor,
a
maintainer.
You
know
so
you
know
again
visibility
to
take
this.
Maybe
it
could
make
sense
for
us
to
alongside
having
the
API
docs
in
newcomers.
You
know
user
documentation
to
also
maintain
on
the
website.
Even
if
this
is
just
generated,
support
is
just
a
scripted.
Whatever
markdown
goes
to
the
website
for
maintainers
and
collaborators
on
node.js,
because
a
person
that's
part
of
Doc
contribution
that
would
be
really
cool
if
we
could
actually
have
that
generated
on
our
website.
You
know
why
not.
A
If
anything,
at
least
like
an
entry
point
that
says
like
hey,
there's
these
kinds
of
different
documentation
and
here's
how
you
find
the
different
ones
like
they
don't
all
have
to
be
directly
on
the
website
and
generated
like
even
if
there's
like
the
entry
point
that
says
like
here's
to
the
API
docs,
if
you're
this
kind
of
user,
oh
and
there's
a
package
maintenance
team.
So
if
you
want
you're
looking
for
this
kind
of
guidance,
here's
the
place
you
can
go
and
so
forth.
So.
C
Yeah
I
I
think
just
a
way
to
I
found
that
to
be
able
to
be
found
just
by
someone
searching
something
on
Google
and
even
to
follow.
A
link
which
will
link
to
some
repository
inside
the
node.js
organization
would
be
great
because
today,
like
yeah,
like
Claudio,
this
package
maintenance
team
with
some
documentation
or
stuff
like
that
I
wasn't
even
aware
that
it
was
existing
pretty
much
the
same
as
the
node
API
team,
I'm
aware
that
there
is
some
documentation,
because
I
mainly
look
at
them
when
I
do
I,
try
to
find
examples.
C
Some
use
case,
because
everything
else
on
internet
is
deprecated,
not
working
not
up
to
date
or
any
other
reason.
So
we
should
try
to
find
a
way,
and
maybe
it
could
also
be
something
we
can
be.
We
could
be
main
maintain
I
would
say
Slowly
by
every
different
kind
of
working
group
every
time,
because
we
already
have
the
way
that
when
you
you
add
something
or
you
publish
something
or
change
something
in
not
core.
You
have
to
update
everything
linked
to
the
function.
C
We
should
also
try
to
find
a
way
to
have
people
also
providing
some
example
on
some
use
case
because
having
a
feature
which
is
not
which
which
cannot
be
understandable
or
usable
by
someone
which
don't
Deep
dive
into
the
JavaScript
engine
or
Libre
or
something
else
it's
just
mainly
use
less
for
for
us
and
for
maintenance,
which
spend
time
adding
some
new
video.
B
Yeah
just
wanted
to
say
that
I
need
to
support
in
a
few
minutes,
because
I
need
to
go
to
the
gate.
I'm
still
in
an
airport,
but
I
just
wanted
to.
If
you
follow,
I
know
that
we
have
women
again
but
just
hijacked
the
meeting
for
one
minute,
because
Joe
will
not
be
able
to
attempt
the
website
meeting
I'm,
just
basically
just
quickly
say
a
few
things
for
him,
so
Joe,
basically
in
terms
of
current
priorities
for
the
for
the
new
website.
B
Awesome
basement.
You
know
cool.
A
Okay,
so
I
think
we
can.
We
should
look
at
the
I-18n
initiative
documentation
anything
we
should
discuss
this
week
on
that.
One.
A
C
About
everything,
because
yeah,
because
the
documentation
and
the
international
edition
part
are
really
linked.
Okay
I
see
the
main
point
which
was
raised
during
the
collaborative
Summit
I
would
say:
2.1.
It
will
be
quite
hard
to
do
so,
but
if
we
are
able
to
automatize
to
to
add
some
automation
to
it,
it's
easily
a
predictable
for
every
long
wages.
Let's
say
which
is
so
it's
a
really
the
hard
part,
but
the
iron
reward
part
also,
we
I
think
on
my
part.
C
This
is
a
lot
about
how
we
can
maybe
have
the
community
involved
on
helping
on
that
and
that's
also
linked
to
to
the
automation
part,
because
we
don't
have
just
basically
the
manpower
to
have
one
maintenance
in
every
language
is
following
and
doing
it
for
everything,
and
also
from
what
was
saying
material.
Let's
say,
the
secret
part
and
stuff
like
that
mainly
China
is
a
big
is
really
asking.
C
Yeah,
but
if
we
are
able
to
do
one,
we
should
find
a
way,
even
if
it's
a
bit
harder
to
find
a
way
to
just
have
everything
automatized,
and
that
way
we
don't
have
to
manually,
follow
everything.
B
C
Finish:
okay,
no
I
was
just
going
to
say
if,
even
if
we
try
to
do
something
from
one
language
like
Chinese,
no
one
here
will
have
the
time
just
to
do
the
peer
or
replicate
it
manually.
We
will
forget
him.
It
will
be
different
version
or
pretty
much
everything
how
we
can
work
with
that
without
human
people
doing
some
I,
don't
know
a
transfer
between
the
official
English
documentation
and
the
one
in
the
another
language.
B
Yeah
another
important
thing,
for
example,
that
exactly
is
because
you
know
in
any
moment
that,
for
example,
the
English
version
get
updated
because
in
an
API
change
you
know
the
metadata
changes
or
whatever
you
know,
it's
really
hard
to
keep
track,
which
translations
into
outside
of
data,
for
example,
on
the
new
website.
In
theory,
you
can
already
translate
the
the
apis
because
it
supports
already.
B
You
know
the
generated
version,
no
support
translation,
but
you
know
there
was
a
person
who
was
already
eager
to
circumstick
the
whole
thing
friendship
was
like
hold
on,
even
though
it
works.
You
know
the
thing
is
that
every
time
the
API
changes
you
know
we
need
to
update
the
whole
thing
again.
You
know
not
the
whole
thing,
but
you
know
pinpointing
the
the
diff.
B
It's
it's
very
hard,
hence
where,
for
example,
that
metadata
proposal
where
the
metadata
separated
from
an
example
description,
introduction
Etc,
is
ready
to
go
drastically
reduce.
You
know
the
return
of
this
problem
because
by
removing
the
metadata,
the
actual
API
part
of
the
equation,
it
means
that,
for
example,
you
know
for
some
description
and
examples.
It
is
something
way
more
easy
to
update
because
examples
you
just
copy,
you
know
and
description.
B
A
I'd
suggest
we
close
out
for
this
week.
We've
got
some
good
next
actions
if
people
can
work
on
any
of
those
before
next
time,
that'd
be
great
or
at
least
be
prepared
to
next
time
to
like
review
some
of
the
brainstorming
from
the
the
previous
the
collaborator
session,
and
then
we
can
sort
of
dig
into
that
those
details
next
time.
I
think
that's
our
next
steps.
C
Yeah
and
I
think
it
should
be
great
to
us
next
time
to
after
we,
we
work
on
that
to
really
find
some
time,
maybe
before
the
end
of
the
year,
to
really
have
a
deep
dive
on
the
documentation
on
what
we
discussed
today
and
what
will
we
will
have
walked
next
time.
This
is
a
great
project
which
will
require
a
lot
of
time
and
effort
from
I
think
a
lot
of
people
also.
A
Right,
I
think
if,
if
cardio
is
going
to
put
together
that
that
top
level
issue,
that
sort
of
like
here's,
the
output
from
the
collaborator
Summit
and
even
if
it's
like
the
high
level
proposal,
we
can
I
type
that
I
think
I
tagged
that
for
the
agenda.
So
we
can
make
sure
to
cover
that
and
once
I
think
there's
enough
there.
We
can
maybe
schedule
like
another
Summit
to
get
people
involved
and
sort
of
validate
and
brainstorm
and
hopefully
get
more
people
involved.
B
I'll
just
say
really
quickly
too:
at
IBM.
We
have
this
sort
of
Jumpstart
program
where
we
try
to
get
young
devs,
newer,
devs
into
open
source
and
I.
Have
someone
who's
interested
in
contributing
to
node.js,
and
you
know
helping
on
Doc's
work
could
be
something.