►
From YouTube: 2022-10-26-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
26
2022
we'll
follow
the
agenda,
which
was
tagged
in
the
issue
in
the
repository
it
was
issue
number
169
and
I'm
just
opening
up
the
agenda.
C
A
A
Okay,
so
the
we'll
start
off
with
looking
at
the
things
that
are
tagged
with
the
agenda
and
then
we
can
go
from
there.
First
one
is
get
the
collaborator
Summit
attendee
list,
so
we
can
do
some
follow-on
discussions.
I
still
I
I,
just
I
think
like
yesterday,
sent
an
email
asking
for
that,
because
I
know
there
was
a
follow-on.
That's
that
Anthony
wanted
to
start
so
anyway,
I'm
Michael
has
asked
for
it.
C
A
A
I,
don't
know
if
this
this
time
do
you
you
know,
does
it
make
any
sense
to
do
a
quick
run
through
or
do
people
have
questions?
What's
the
best
way
to
kind
of
discuss
that
one.
C
Yeah
I
think
I
could
give
a
quick
run
through
and
you
know
have
questions
shot
good.
B
C
Cool
it's
a
little
bit
of
context
for
the
ones
that
are
hearing
about
this
for
the
first
time
his
introduction,
but
basically
this
is
a
proposal
for
changing,
slash,
updating
the
whole
structure
of
how
or
API
docs,
or
you
know,
structured
how
you
have
the
metadata
of
them,
how
we
structure
the
photo
structure,
how
the
docs
get
generated
and
the
building
around
it,
and
also
you
know,
navigation
internationalization.
It's
basically
a
you
know
a
whole
proposal
trying
to
create
a
specification.
C
You
know
of
how
or
API
docs
can
be
better
introduction.
It
basically
says
the
current
problems
such
issues
that
or
current
API
ducts
have
I
would
not
go
through
them
here
because
very
easy
to
read
on
the
issue
itself.
C
But
basically
the
proposal
is
about
four
major
changes.
There's
separating
what
we
call
the
metadata,
the
actual
definition
of
a
module
from
the
markdown
file,
so
you
have
a
dedicated
emo
file
which
defines
this
and
what
are
the
methods?
What
are
the
constants?
You
know
what
are
the
return
types?
You
know
what
is
the
stability
Etc
and
then
you
have
a
respective
markdown
file,
which
is
like
description.
Examples
which
notes
or
anything
that
you
know
is.
You
know
relevant
for
the
humans
reading.
It.
A
C
C
So
basically,
if
I'm
writing
a
section
on
a
market
on
file
or
I'm,
talking
about
a
specific
method
of,
for
example,
FS
promises,
basically,
everything
that
is
needed
is
for
me
to
create
a
reference
of
what
is
the
metadata
entry
for
it
and
automatically.
Supposing
that
this
is
the
name
of
it
will
append
after
the
section.
So,
basically
in
terms
of
generation,
you
have
the
title:
The
Heading,
then
you
have
the
metadata.
C
You
know
how
tidy
nicely
Etc
on
the
way
how
we
have
in
the
website
today,
for
example,
then
everything
that
is
extra
like
subscription
examples,
blah
yeah
and
I-
was
important
to
mention
that
this
is
also
what
is
used
for
as
the
hash
on
the
URL
or
the
Royal
itself,
depending
if
the
level
does
it
answer,
your.
A
C
Yeah,
so
suppose
you
have
I
didn't
write
anything
about
this
specifically,
but
this
is
something
we
can
definitely
add
on
it
like
it's
an
ad
hoc,
but
suppose
we
have
a
linking
tool
and
they
add
a
new.
Let's
see
message
here,
for
example,
new
method
and
if
I
didn't
write
anything
in
the
magnifier
with
coordinate
or
worrying
hey.
We
have
an
orphan
method
on
the
metadata.
That
is
not
in
the
markdown
a
warning,
because
you
know
you
might
still
be
writing
the
method.
C
It
might
still
be
a
draft,
so
you
don't
necessarily
want
it
to
be
in
the
markdown.
So
that's
another
I.
Think
Niche
thing
is
that,
of
course,
in
in
the
best
world,
you
want
to
have
a
one-to-one
match,
but
you
don't
necessarily
need
to
have
so
it
allows
you
to
you.
You
know
to
write
things
in
the
metadata
and
not
have
anything
generated
on
the
final
docs
if
they're
not
ready
yet.
A
C
Yeah
I
think
one
of
the
important
tools
that
will
be
here
is
documentation
so
for
explanation
of
what
it
is
and
how
the
guides
adding
a
new
method.
You
know
we
should
have
proper
documentation
about
things
and
a
Reviewer
is
God.
You
know,
like
checklist
of
everything
that
we
can
give
to
the
newcomer
and
also
for
the
reviewer,
so
they're
like
oh
okay,
I
added
this
I.
Did
this
oh
I
didn't
do
this!
Okay,
I
didn't
do
this,
so
let
me
do
that.
I
think.
A
I,
just
like
is
it:
is
it
like?
If
you
look
at
that
heading
will
the
tool?
Basically,
you
know
if
you
so
I've
added
that
so
I
forget
to
put
that
in
yeah.
The
tool
will
easily
tell
me
that,
like
hey,
you
forgot
to
put
that
in.
C
If
you
put
the
heading
ID,
then
it
will
correlate.
The
thing
is.
B
C
And
one
of
the
things
that
I
definitely
want
to
have
in
the
future
on
PRS
is
review
branches
automatically
like
Ci
like
we
have
node.js
adapt.
It
gives
you.
This
is
a
preview
of
your
change
set
on
your
view,
change
set,
and
then
you
will
see
wait.
Where
is
that
metadata
that
should
be
related
to
this,
and
then
you
know,
oh
I,
probably
forgot
to
add
the
heading,
which
is
one
of
the
bullet
points
list,
but
automatically.
C
You
know
it's
a
thing
that
reviewers
you
know,
because
we
are
all
human
in
the
end
to
be
like.
Okay,
this
is
missing.
This
is
not
missing,
but
I
think
with
the
structure
it
it
eases
the
process.
It
makes
it
harder
for
you
to
forget
something.
But
in
case
of
you
forget
you
know,
if
you
actually
forget
something,
you
know
it
would
be
easy
to
know
at
all.
I
forgot
something.
A
Yeah
I
just
wonder
if,
like
maybe
and
I'm,
taking
it
down
too
much
too
far
but
like
maybe
it
should
be
that,
like
for
any
heading,
you
have
to
put
something
even
if
it's
like
does
not
need
any
metadata
or
something
I.
Don't
know
that
way.
You
can't
forget
to
do.
You
know
to
do
something
like
that,
but
sorry.
C
A
A
And
I
can
easily
see
somebody
doing
that:
okay,
blah
blah
blah
I'm,
just
I
I'm,
just
focused
on
my
task,
I'm,
adding
my
section
I,
don't
know
anything
about
the
docs.
Where
is
it
if
there
had
to
be
a
if,
like
for
every
heading
there
had
to
be
an
entry,
then,
when
you
ran
the
check
dock,
it
could
tell
you
a
wait:
a
sec.
You
added
this.
This
heading
there's
no
tag,
you
know
if
you
don't
need
any
metadata
just
put
in
this
no
metadata
tag
or
something
right.
C
Well,
the
thing
is
that
the
heading
IDs
are
always
used
for
the
your
Our
Generation.
So
if
you
forcefully
added
no
metadata
metadata
hashtag,
that's
like
what
will
be
the
like
HTML
ID
of
that
heading
ID.
So
what
we
can
do
you
know
is
if,
for
example,
add
a
heading
that
doesn't
has
an
ID,
you
know,
I
mean
that's
also
pretty
much
valid
demo.
C
Oh
sorry,
Mark
Zone,
I
think
it's
something
that
we
can
definitely
come
up
and
discuss
like
as
we
go
because
they're
a
bunch
of
solutions
from
LinkedIn
from
enforcing
and
if
the
heading
ideas
no
metadata
then
ignore.
For
example,
I
mean
there
are
a
bunch
of
things
we
can
do,
for
example,
to
enforce.
You
know
that
things
are
consistent,
but
I
believe
those
are
like.
This
is
just
a
draft
proposal.
A
Yeah
yeah
no
I'm
just
asking
because
I
know
I
know
one
of
the
things
that
people
have
sort
of
raised.
The
concern
of
it's
like.
If
you
have
to
know
too
much
like
you,
have
to
be
an
ex
an
expert
on
the
documentation
structure
to
contribute.
That's
not
so
good,
so
it's
like
I
think
the
moral
story
can
be
is
like
you
really
don't
need
to
understand
anything,
and
if
you
miss
it,
we
can
easily
help
you,
then
you
know
definitely
yeah.
C
It's
coming
from
another
thing
that
I
also
want
to
leverage.
You
know
the
DX
here
is
there's
a
feature
that
both
Json
files
and
emo
fails
can
use,
which
is
actually
it
is
what
will
be
a
similar
of
a
typescript
type.
It's
like
XML
and
S
like
a
namespace,
or
something
that
you
actually
say.
This
kind
of
VMO
file
follows
this
structure
so
as
they
write
in
the
ammo,
they
have
intellisense.
You
know,
and
this
is
cool
because
then
they
automobile
and
show
description.
What
is
this?
C
Which
automatically
is
like
the
reference
of
the
stable
right?
What
what
is
it's
like?
You
have
type
definition
for
your
emo
file
or
something
like
that
of
a
sort
but
yeah
I.
Think,
of
course,
to
reduce
the
entry.
You
know
barrier
here,
it's
very
important
that
we
have
nice
documentations,
and
you
know
this
thing
doesn't
get
too
convoluted
and
I.
Imagine
that
if
a
person
that
I'm
just
adding
something
new
I
would
just
like
copy.
C
A
A
We
catch
that
and
help
them
and
say
well
and
here's
the
documentation
I
think
like
that.
Even
it's
just
that
anyway,
I'll
I
think
you
we're
on
the
same
wavelengths
all
so
just.
C
Yeah
it
is,
it
is
an
important
Point.
Definitely
I
will
try
to
remind
myself
of
writing
something
about
this
thing
or
interest
just
on
my
on
a
text
file
here,
so
I
remember
later
cool,
so
going
back
to
the
proposal.
Okay.
C
The
second
item
is,
you
know
a
new
photo
structure
so,
instead
of
having
you
know
how
the
documentation
files
on
one
big
message
directory,
which
even
for
indexing
you
know-
or
you
know,
reading
you
know
it
gets
too
big.
You
have
for
the
structure
that
is
like,
for
example,
API
v18
modules,
name,
the
module
name
of
the
import.
You
know
you
have
a
more
like
structured,
folder
directory,
which
is
as
shown
below.
So
this
is
an
example
how
it
could
look.
C
So
basically,
this
is
an
example
for
the
structure.
I
will
always
explain
how
the
navigation
Works,
which
is
the
third
item.
C
Basically
you
have
a
more
nested,
you
know
photo
structure,
you
know,
if
you
say
so,
which
is
more
organized.
You
have
things
separated
nicely
and
that's
it
basically
and
actually
to
be
very
honest.
The
building
tool
doesn't
rely
on
your
photo
structure
like
it
doesn't
matter.
The
name
of
the
folders
on
in
the
level
that
something
is
and
that's
where
the
navigation
system
kicks
in
here,
where
I
leverage
a
concept
of
actually
you
have
a
main
navigation,
enter
with
the
modeling
file.
Right
where
you
can
refer.
C
You
know,
for
example,
specific
interest,
and
then
you
can
reference
order,
navigation
files.
Imagine
this
is
as
a
dynamic
imported
navigation.
So
every
time
that
you
refer
to
an
aggregation
file
that
Imports
the
contents
of
data
navigation
entry,
you
know
file
and
like
Maps.
So
suppose
you
have.
You
know
here:
navigation
entry
for
modules,
right,
which
is
this
file
here,
and
then
you
have
file
system
streams.
C
C
C
So
the
idea
here
is
to
you
know,
be
simple:
you
know
on
something
that
is
already
easy
for
people
to
do
in
general,
which
is
markdown
yeah
and
here's.
Basically,
you
know
the
bullet
points,
explain
how
the
navigation
system
works,
but
let's
visit
the
third
thing
you
know,
so
you
have
the
new
metadata
system.
You
have
a
different
project
structure
right
on.
You
have
a
new
navigation
system.
C
And
finally,
you
know
you
have
the
Buicks
process.
So
the
idea
here
is
a
decor
build
tools
for
documentation.
They
will
basically
aggregate
everything,
of
course
everything
and
then
it
will
just
split
it
out.
You
know,
for
example,
in
an
MDX
or,
for
example,
Json.
It
depends
like
you.
Basically,
everything
is
in
a
buffer
and
then
you
can
pipe
different
output.
Generators
like,
for
example,
Json
MDX
HML.
C
So
you
know
you
could
kind
of
say
it's
like
a
plugin
based
system,
and
this
is
cool
because
you
can
have
many
different
outputs
Json
for
the
Tasker
team,
mgx
for,
for
example,
for
node.js
Dev,
pure
HML,
for
legacy
stuff.
If
you
need,
for
example,
or,
for
example,
Branch
preview,
when
you
just
want
to
have
the
pure,
you
know
HTML
Auto
product,
that's
dark,
you
know
with
basic
styling,
if
you
say
so
yeah
and
basically
you
know
short
term.
This
is
what
the
whole
proposal
is.
C
It's
it's
very
well
documented,
including
the
trans
translation,
Parts.
You
know
the
types
you
know
what
each
one
of
those
fields
are
is
whatever
everything
is
very
well
documented
and
I
really
invite
anybody.
You
know
to
either
read
a
note
and
make
questions
I.
C
A
final
example
no
but
I
could
say,
for
example,
imaginable
FS
promises.
You
would,
for
example,
have
here
navigation,
MD
promises,
yaml
promises.mg
I
can
maybe
create
just
a
final
example
how
it
would
look,
but.
A
You
know
so,
for
the
like,
say
the
internationalization
part
that
might
help
like
I
guess,
I've
seen
a
bunch
of
internationalization
cases
where,
like
the
contents,
look
significantly
different
than
they
do
today
and
again
it's
one
of
those
things
that
requires
more
people
like
people
who
are
writing
to
that.
To
know
what
they're
doing
versus
just
writing
the
text
right.
So
that's.
C
A
C
I
think
there's
a
few
things
that
internationalization
here
so
first
we
have
what
we
will
call
call.
You
know
ICU,
which
is
you
know
you
have
translation,
keys
and
basically,
by
default,
when
you
know
we
make
the
first,
you
know
Mass
run
moving
from
the
old
infrastructure
to
the
new
one,
which
is
basically
our
automated.
Like
I
explained
like
it's
explained
below
you
know
it
will
all
default
to
English.
C
So
you
know
it
would
create
tags
based
based
on
this,
if
you
say
so,
and
then
generate
the
default
English
files
for
all
these
things.
Of
course,
a
few
things
cannot
be
generated
like
present
Tags
by
default
is
something
that
probably
will
be
empty.
I
mean
I
could
probably
leverage.
You
know,
you
know
tax
extract
extraction
tools.
You
know
like
iftf
to
generate
those
tags
right,
it's
not
complicated.
C
We
do
that
unknown,
Jazzy
Dev,
but
for
the
pure
Magnum
files,
it's
like
each
Magnum
file
like
is,
for
example,
something.n.md
or
in
Holland,
which
is
a
default
English
language
people
can
translate
those
files,
but,
of
course,
just
by
separating
the
metadata
from
the
markdown
file,
which
is
like
the
description
examples
doesn't
mean
that
it
makes
it
very.
It
doesn't
remove
the
technicality,
which
is
a
translating
technical
content,
so
give
the
directions
that
I
think
that
still
need
to
understand
what
like
the
technical
terms
and
what
they're
translating
and
that
kind
of
complication.
C
B
C
Are
just
for
the
metadata,
and
the
thing
is
that
we
want
to
remove
maximum
amount
of
taxes
possible,
for
example
from
the
metadata.
What
their
case
is
that
we
need
to
give
details
so,
for
example,
think
about
the
history
of
changes
of
a
method,
for
example,
added
new
new
parameter
or
this
method
was
removed
on
this
version.
Etc
we
have
that
history
table.
You
know
on
our
API
docs.
That
thing
tends
to
be
in
the
markdown:
it's
the
internet
data,
but
still
really
cool.
C
If
Co
translate
so
here
you
can
either
provide
you
know
a
translation
tag
or
just
write
in
English.
It's
up
to
you.
I
would
recommend
to
be
a
translation
tag
and
this
translation
tags
for
the
metadata
for
the
initial
run,
they
will
be
generated,
so
it's
like
it
won't
extract
the
content
from
the
original
change,
lock
tables
that
we
have
on
our
current
apis.
It
would
create
a
tag
based
on
you
know.
You
know
the
naming
of
the
files
in
ETC
to
have
an
initial
run.
C
C
A
C
C
And
it's
just
something
to
be
honest,
you
take
time
but
I
think
it's
it's
good
that
you
know
the
translation
happens
only
on
not
on
you
but,
like
you,
have
other
metadata
removed
from
the
actual
markdown
file,
because
I
believe
that
you
know
description,
introduction
and
example
is
something
that
changes
slower.
You
know
it's
not
something
that
will
require
that
many
translation
updates
over
the
time,
at
least
that's
what
I
imagine
you
know,
for
example
the
boat
file.
C
Here
you
know
this
is
the
same
text
for
many
years
right
I
mean,
of
course
it's
a
completely
unrelated
example,
but
it's
not
like,
for
example,
every
change
new
version
of
nausea
as
we're
going
to
change
the
description
of
what
the
file
system
module
is
like
introductory
text
or
the
examples,
and
if
the
examples
change,
I
I
suppose
it's
like.
C
Maybe
if
it's
a
new
field
here
or
whatever
you
know,
it's
something
that
then
on
the
other
Transit,
you
know
translated
text
you
just
copy
paste,
because
we
don't
translate
Snippets
right,
so
I
I
believe
at
least
in
terms
of
translating
you
know
the
actual
human
readable
text.
The
actual
thing
that
you
know
introduces
someone
to
a
module
or
to
whatever
will
become
easier
because
we
don't
have
all
the
stuff
on
there
yeah,
but
that's
my
take
at
least
it's
also
important
to
mention
that
API
docs
are
not
just
pure
module
documentation.
C
C
Yours
so,
for
example,
you
have
a
page
which
is
like
it
has
classes
also,
but
it's
not
just
a
both
classes.
I
think
I
mean
there
are
a
bunch
of
pages
here
that
present
diagnostic
channels.
You
know
this
is
not
a
module
right
yeah,
it
is
a
module,
but
it's
I
mean
it's
not
just
about
the
module.
It's
like
more,
like
a
Discraft
like
descriptive
way
of
talking
about
a
module.
Okay.
My
point
here
is
that
you
know.
C
This
is
C
plus
plus
add-ons
okay
yeah,
exactly
like
API
docs
orange
juice,
about
modules
yeah.
So
that's
why
not?
Every
modem
file
needs
also
a
yaml
file,
but
it
just
you
can
leverage.
You
know
your
markdown
with
the
metadata
right.
So
that's
why
the
heading
IDs
are
also
like
something
that
you
add.
If
you
want,
no,
if
it
makes
sense
yeah
it's
basically,
that's.
C
So
I
think
making
incremental
will
create
a
you
know,
a
lot
of
complexion
or
ex
infrastructure.
C
The
idea
here
was
to
be
a
like
a
big
bang,
but
in
the
sense
that
creating
a
tooling
that
can
make
this
transition
from
all
the
existing
files
to
the
new
format
is
not
hard.
Actually,
there
is
something
similar
already
in
place
for
node.js
the
dev
and
basically
would
require
a
few
tweaks
here
and
there
and
Etc
I
mean
it's
something
that
would
take
a
few
months
to
be
worked
on.
C
You
know
to
iron
out
all
bugs
or
the
edge
cases
if
you
know
any,
but
even
if
it's
a
big
bang,
what
we
could
do
is
we
have
this
new
temporary
repository,
which
has
all
the
new
things
or
we
could
have.
You
know
a
bunch
of
different
PRS.
You
know
first
FS
Mojo,
then
this
module,
then
this
module.
Then
this
module.
So
people
proof
read,
you
know
proofread,
you
know
each
of
the
changes
no
and
then
they
just
emerged
right.
C
So
basically,
twinning
code
make
a
big
bang
but
creates
a
bunch
of
different
PRS,
and
then
we
go
on
each
on
them
right
and
then
only
when
we
have
everything
merged,
then
we
create
another
PR.
That
is
deleting
the
old,
replace
it
for
the
new,
for
example,
so
that
we
don't
need
to.
You
know,
review
Everything
at
Once,
because
I
think
that
the
issue
with
big
big
bang
changes
is
just.
We
will
have
a
massive
PR
word.
A
C
Yeah,
so
it
doesn't
make
sense
to
you
know:
have
you
know
the
building?
You
know
the
tooling
that
moves
from
the
old
Neo
code
basically
just
use
the
GitHub
API
to
create
a
bunch
of
PRS
right
and
then
we
could
even
have
a
play,
a
repository.
You
know
to
test
this
thing,
so
we
don't.
Actually,
you
know
accidentally
create
thousands
of
PRS
and
no
djis
node.
It
would
not
be
nice,
but
yeah
I.
C
Imagine
that
if
we,
you
know
decouple
instead
of
being,
you
know
having
one
big
PR
having
smaller
per
yards,
maybe
for
each
class,
even
you
know,
or
each
file
I,
don't
know
each
combination
of
five,
for
example,
one
PR
profile
that
we
have
inside
the
current
API
folder
I,
don't
know
that
could
always
be
feasible
in.
A
C
Yes,
I
think
that
when
we
click
into
tuning
so,
for
example,
not
only
the
tuning
for
migrating
this
stuff,
but
also
the
tuning
that
will
be
the
build
tuning
for
the
new
stuff,
it's
very
important
that
we
have
constant
examples
being
generated
that
we
can
have.
You
know
continuous
interaction
on
the
spec,
for
example.
Okay.
This
is
how
this
looks
now.
C
Maybe
we
should
change
it
yeah,
so
you
know
we
don't
have
in
the
end,
without
the
files,
even
if
it's
many
different
PRS
been
generated,
but
then
the
issues
actually
on
the
specification
itself
and
then
everything
needs
to
run
again,
so
definitely
something
that
we
need
to
be
continuously
iterating
and
reviewing.
Why
we're
creating
the
specification
which
will
be
originally
created
by
the
migration
script
right
and
also
the
book
and
the
building
Tool.
A
A
C
C
There
are
many
steps
that
are
here.
You
know
from
beginning
to
end
so
first,
this
is
a
drought,
so
first
we
need
to
iterate
and
the
specification
itself
start
creating
the
migration
script.
C
C
And
then
yes,
we
call
generate
modern
module
and
see
how
how
it
looks
and
more.
If
you
do
this
path,
which
is
completely
fine,
I'm
more
concerned
how
we
merge
those
things
on
the
existing
websites,
because
I
have
no
idea
where
actually
the
HTML
on
the
website
is
generated
like
there's,
not
a
GitHub
action
inside
node,
so
I
should
know.
C
You
know
that
I
actually
pushes
to
the
website,
I,
don't
know,
and
basically
what
we
need
to
override
for
hey
for
this
file
actually
picked
this,
which
no
called
create
complications,
because
you're
mixing
different
things
together
on.
A
C
C
Yeah,
that's
why
you're,
having
a
play
repository
where
you
can,
even
you
know,
build
you
know
HTML
or
MDX.
You
know
like
I
said:
if
the
issue
is
generating
a
module
and
reviewing
it,
I
mean
to
be
very
honest,
we
could
do
everything
on
a
play
repository,
so
we
can
review
things
there.
So
once
we
created
the
pr
on
node.js,
slash
node,
it's
basically
just
like
yeah
how
the
review
happened
on
the
play
repository
because
the
content
is
the
same.
C
Then
we
can
safely
merge
a
node
if
that's
the
place
where
we
want
to
keep
the
docs,
because
there
was
another
thing
that
we
also
told
here,
which
is
worsening
the
docs,
which
is
basically
right
now
I
mean
we
have
a
little
issue
with,
as
we
have
only
one
stage
for
API
docs
right.
C
So
of
course
everything
is
version
and
git,
and
you
know
we
can
just
push
to
a
tag,
but
the
thing
is:
even
if
you
push
a
tag,
the
docks
there
get
generated
at
the
time
that
you
know
less
published
so
like.
If
you
update
an
existing
dock
for
older
version,
you
will
never
get
published
or
anything
mainly
like
somehow
sent
to
the
archive
like
publishment
into
the
archive,
and
the
idea
here
is
that
from
now
on
to
docs
they
have
their
own
Repository.
C
A
A
A
Hearing
you
sorry
I
was
just
saying
like
I,
think
today,
being
all
together
has
some
advantages
in
that,
like
you
know,
if
you
want
to
find
the
version
of
the
doc
that
was,
that
was,
as
of
a
certain
version
It's,
just
in
the
same
tag
in
the
repo
versus
somewhere
else
that
you
might
get
out
of
sync,
and
so
like
keeping
things
together,
has
some
benefits.
On
that
perspective,.
C
C
Of
course
you
can
navigate
through
the
history
and
Etc
yeah
and
maybe
just
because
I
don't
understand,
you
know
how
the
build
process
works,
but
if
I
make
an
update,
for
example,
to
previous
version
of
the
dock,
for
example
for
B18,
oh
yeah,
V12,
suppose
I,
don't
know
security
patch
happened
and
you
know,
and
we
need
to
play
that
version
that
is
already
end
of
life.
I,
don't
know.
A
It
should
like
there's
no
reason
why
that
can't
happen
right
like
we
should
have
on
our
like,
though
the
way
I
I
don't
know
but
like
in
my
mind,
the
way
that
works
is
like
if
something
checks
out
a
particular
branch,
and
so
it
can
always
check
out
the
latest
14
16,
whatever
it
runs.
The
process
like
there's
a
make
dock
make
file
Target
that
generates
the
output,
which
then
gets
sucked
into
what's
published,
and
that
gets
copied
to
a
certain
directory
somewhere
on
the
website
that
is
for
14..
A
A
A
C
A
Right
right,
that's
got
that's
our
current
model
right,
it's
like,
even
even
if
they
didn't
change
the
method,
but
you
realized
the
doc
was
wrong.
You
would
have
a
so
it
would.
It
all
starts
in
May
in
the
main
branch
and
then
things
flow
backwards,
which
is
again
something
you
know
people
may
may
raise
as
a
concern
is
like.
If
we
change
the
world
there'll
be
a
break
point
where
like.
If
you
change
something
in
Maine,
it
can't
flow
back
easily
right.
A
A
A
C
A
C
A
Because
things
like
the
the
the
least
change,
we
can
do
at
a
time
like
if
we
propose
changing
the
whole
structure.
Changing
where,
like
you
know,
is
it
together
or
apart,
like
the
more
that
is
the
more
discussion
there
is
some
possibility
of
concerns
and
stuff,
so
like
keeping
the
docs
in
with
the
code
would
would
be
my
suggestion
to
start
no.
That
could
be
completely
wrong
for
whatever
reason,
but,
like
you
know,
just
changing
the
structure,
but
keeping
it
all
together
seems
like
a
big
enough
step
on
its
own
right.
A
C
C
And
check
where
is
existing
documentation,
product
I,
don't
I
can
mention
I,
don't
think
I
saw
any
anything
on
on
nodes.
Regarding
present
patching
docs
for
older
versions.
A
Yeah
I
know
like
it's
always
it
would
always
right
like
how
would
you
or
even
maintaining
the
docs?
Is
there
a
doc
in
there
I
don't
know
or
how
the
how
the
doc
generation
process,
like
mainly
maintaining
the
doc
generation
I,
don't
think
we
have
a
document
there,
but
that
would
be
quite
good
to
have
yeah.
That
explains
the
flow
right
in
like
the
yeah,
because
my
understanding
is
based
on
just
what
you
know.
Having
actually
you
know
used
the
dock
sometimes
and
stuff,
and.
A
C
C
Sense,
definitely
that's
that
I'm
not
questioning
this.
What
I
wonder
is
since
now
19
is
the
latest.
If
I
make
a
push,
you
know
assember,
you
know
to
1813.
Will
then
it
update
in
the
website.
You
know
to
be
when
I
go
here,
1813
that
that
was
the
my
curiosity.
That's
why
I
boarded
version
I
think
it
should.
A
A
That's
maybe
a
mistake
that,
let's
see
when.
C
Me
just,
but
if
you
go
to
node.jsa
Dev,
it
doesn't
do
the
mistakes.
So,
if
you
go
to
download
it
knows
that
18
is
already
doing
your
Otis,
but
that's
just
because
how
we,
how
we
get
the
information
is
differently,
but
it
should
on
node.js.dev.
We
also
have
this
thing
that
it
will
always
update
to
the
latest.
As
you
can
see
here,
president
18
12
right.
Oh.
C
A
A
18
18
needs
to
be,
but
18
actually,
like.
That's
probably
just
I-
think
it
went
out
yesterday.
A
A
C
A
Here,
anyway,
we're
kind
of
getting
into
the
weeds
but
yeah,
there's
like
a
web
hook
or
something
sorry
push.
A
B
C
Oops
I
lost
the
issue
but
yeah
my
last
issue,
but
it's
somewhere
but
yeah
the
things
that
I
think
next
step
would
be
to
get
more
attraction
like
more
people
from
the
TSC
to
actually
review
that.
You
know
take
time
when
they
have
because
no
rush
on
my
side,
to
be
honest,.
A
I
I
personally
think
like
having
that,
like
an
actual
rendered
example
like
what
would
that
directory
look
like,
would
help
a
lot,
because
you,
you
read
through
the
very
good
proposal,
but
like
just
being
able
to
open
a
few
files
and
see
oh
well,
what
does
the
for
an
existing
one?
What
does
the
text
look
like?
Oh,
that
still
looks
like
what
I
wrote:
Today
comfortable
yeah.
C
I
could
definitely
make
even
a
mock
repository
on
my
own
personal
GitHub,
just
inventing
how
it
would
look
or
something
like
that.
Just.
C
B
Has
his
hand
up
yeah
I
know
just
Justice
League.
If
you
do
that,
I
would
love
to
piggyback
on
that
to
try
to
find
a
way
also
to
have
a
good
way
to
enter
internet
yeah.
Yeah
internationalization
part
because
doing
everything
and
every
language
is
the
same.
Repository
will
be
quite
hard,
I,
think
and
if
we
are
able
to
just
split
every
file,
I
think
in
the
build
part
we'll
be
able
to
pull
everything
from
other
repository
quite
easily.
C
A
B
Just
because
we
do
have
like
nine
minutes
left
eight
just
for
next
time,
I,
try
to
add
some
document.
Some
idea
of
question
for
this
survey,
the
issue
which.
B
Yeah
next
10
next
survey,
right;
okay,
sorry
so.
B
Right
I
think
so,
let's
move
find
it
yeah.
B
B
Yeah
enjoy
the
ID,
because
we
wanted
to
try
to
send
the
survey
to
before
the
end
of
the
year
could
be
great
to
have
at
least
a
full
list
of
questions.
We
can
review
for
the
next
next
10
meeting.
That
way,
we'll
be
able
to
send
it.
Let's
say
current
mid-november
around
that
part
and
be
able
to
have
a
feedback,
Before
Christmas.
A
B
Yeah,
because
around
the
20th
20th
of
December,
everyone
will
be
doing
something
else,
so
it
could
be
great
to
to
to
send
it
before
and
also
on
almost
the
same
matter.
It's
a
bit
linked
I,
also
dated
a
quick
way
and
I
will
have
a
better
way
to
visualize
that
on
a
multiple
feedback
during
the
Dublin
Colorado.
A
B
On
both
both
easy
ritual,
we
did
and.
A
B
C
A
B
Yeah
yeah
yeah,
also,
and
just
basically
on
some
part,
which
very
great
we
did
work
on
a
lot
of
issue
which
were
some
thing,
which
was
a
feedback
from
the
community
and
collaborator
during
last
year.
So
like
HTTP
and
the
and
the
level,
and
only
yeah
also
started
to
discuss
about
type
and
typescript,
which
are
great
and
also
we
did
push
a
lot.
Our
trainer.
B
At
least
we
have
a
starting
conversation
about
improving
everything
around
diagnostic,
but
I
think
it
still
remains
some
core
issue
and
we
want
to
I
think
it
would
be
great
for
us
to
focus
on
this
kind
of
area
for
the
technology
platform,
because
it's
really
maybe
blocking
for
some
people
also
great
stuff.
We
started
the
next,
the
working
group
around
Asia,
what
the
name
binary
stuff
I
remember,
don't
remember
the
name
of
the
group,
sorry,
which,
whose
stuff,
as
a
new
working
group,
around
binary
and
compiler.js
right.
B
A
B
Yep
basically
do
that
for
this
one
and
also
for
the
community
one.
So
it's
almost
the
same,
and
this
one
is
more
dived
into
how
a
good
thing
about
a
lot
of
core
butter
and
one
I.
Think
key
point
which
is
not
really
shown
here
is
I.
Think
we
did
a
lot
of
discussion
about
basically
how
to
have
cooperation
being
involved
in
node.js
and
how
to
bring
collaborative
from
companies.
So
I
think
we
should
need
and
I
think
we
discussed
a
bit
with
some
people
also
during
the
cover
Summit
and
the
conference.
B
Just
after
that,
how
we
can
work
with,
maybe
the
openjs
foundation
to
even
even
the
Linux
Foundation
how
to
have
a
good
way
for
a
company
to
see
the
benefit
of
working
with
us
having
people
maybe
contributing,
and
how
we
can
support
that
right.
A
A
Makes
sense
but
yeah
I
think
we're
down
to
three
minutes,
so
we
don't
have
time
but
I
think
maybe
next
time
we
should
plan
to
make
that
our
topic
for
like
the
first
topic
we
go
into.
That
makes
sense.
B
I
think
second,
one
first
one
should
be
the
survey
and
this
one.
A
Okay,
so
if
everybody
can
think
about
the
survey
comment
there,
then
we
could
jump
into
that
and
then
second,
we
can
do
the
follow-on
from
the
collaborator
Summit
and
it
was
great
to
get
into
the
docs,
because
you
know
Claudio
looks
like
you
well,
you
did
put
a
lot
of
effort
into
that.
It
was
good
to
spend.
A
Okay,
anything
else
we
should
discuss
or
talk
about
before
we
close
out
for
today.