►
From YouTube: 2020-10-28-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
A
A
So
three,
five
two
three
was
an
issue
that
was
around
adding
tweaking
the
values
that
we'd
worked
on
before
and
I
guess
there's
been
some
discussion
back
and
forth.
I
know
wes
you've
been
involved,
I've
been
involved
a
little
bit.
I
guess
it's
around
how
strongly
the
to
balance.
B
Yeah
we've
sort
of
gone
back
and
forth
on
this
quite
a
bit.
I
think
jeffrey's
point
is
sort
of
the
same
one
I
think
we
had
talked
about
on
our
calls
right
I
mean.
B
A
B
Is
doing
and
and
he's
I
think,
trying
to
kind
of
the
the
goal
here
is
to
make
it
a
little
bit
stronger
than
that
by
calling
by
saying
maximizing
compatibility,
and
that
to
me
means
like
this
is
number
one
like.
If
it's
right,
it's
an
option
to
be
compatible.
We
have
to
take
it
which,
to
me
is
like
that's
pretty
dangerous.
Personally
yeah.
B
B
A
A
B
Yeah
and
I'm
rereading
some
of
this-
and
it
just
reminded
me
so
he
did
in
response
to
the
comment
I
was
saying-
he
did
actually
say
that
he
thinks
the
bar
for
breaking
compatibility
should
be
very
high
higher
than
anything
in
priority
two
or
below.
Obviously,
because
if
it's
higher
than
priority
two-
and
I
think
that's
where
we
had
it
right-
was
in
the.
A
Yeah
we
had
it
in
one
of
the
you
know.
We
did
have
some
coverage
for
it,
but
later
on
in
the
in
the
priority
lists,.
C
Yeah,
that's
the
point
I
was
going
to
make
too
was
like
it's
it's
if,
as
a
developer
who's
used
to
the
web
apis,
it's
really
confusing
if
node
just
slightly
diverges,
so
it
makes
for
really
bad
usability.
A
B
So
so
this
is
one,
that's
really
interesting.
I
think.
That's
probably
why
we've
gone
back
and
forth
on
it,
because
exactly
part
of
like
every
single
one
right,
so
the
developer
experience
is
the
people
coming
from
the
web
apis.
The
stability
is,
do
we
break
a
bunch
of
things
to
keep
compatibility?
Because
right
now,
we
kind
of
have
or
to
maximize
compatibility,
because
we
might
have
to
in
order
to
achieve
that
goal.
Maintainer
experience
be
is
affected,
because
if
we
had
that
as
an
as
an
ultimate,
you
know
high
level
goal.
B
We'd
have
to
make
a
ton
of
different
decisions,
including
refactoring.
A
ton
of
you
know
existing
apis
and
then
it's
in
number
five
as
well,
so
this
particular
one
kind
of
spans
all
of
them,
whereas
some
of
the
other
ones
are
a
little
bit
more
like
siloed
in
one,
which
I
think
makes
this
conversation
much
right
harder,
because
it's
like
well
yeah.
It
is
a
part
of
that.
So
we
put
it
as
number
one.
A
D
I
I
think
I
I
think
that
those
could
be
compatible
in
the
sense
that,
like
the
node.js
context,
is
greater
than
the
web
in
a
lot
of
cases
like
file
system
stuff,
at
least
for
now,
like
some
of
the
crypto
things
that
we
have,
that
isn't
aren't
necessarily
available
in
the
web
or
wouldn't
be
needed
in
the
web.
Cli
stuff
like
that
kind
of
stuff.
So
perhaps
the
the
that
could
be
tweaked
to
address
that
we
we
do
care
about
this.
D
A
lot
but
like
there
are
cases
where
node
nodes
base
is
diverges
because
of
it
being
a
server,
sider,
client
tool.
B
I
have
an
idea
here
because
I
think
that
what
brought
up
is,
I
think,
really
interesting.
What
if
we
actually
made
a
separate
section
to
talk
about
interoperability
in
the
priority
list,
and
we
just
made
a
venn
diagram
and
we
said
like
look,
we
overlap.
We
know
that
there
are
places
that
there
it
makes
a
lot
of
sense
to
have
apis
that
are
shared
between
the
two.
B
B
What
we're
saying
is
we
understand,
there's
overlap
where
there's
overlap
will
strive
for
compatibility,
you
know
and
and
make
concessions
where
necessary,
but
also
you
know
that
doesn't
mean
that
you
know
when
something's
over
on
the
left
side
in
the
browser
of
the
venn
diagram
that,
like
we
have
to
implement
it.
Just
because
does
that
sound
like
an
a
good.
A
B
Yeah
pretty
much
we
could
just
like
link
to
it
in
the
doc
from
the
one
right
right
or
more
on
our
stance
on
web
interop
or
you
know,
interrupt
or
something,
and
would
that
tyranny
help
address.
What
you're
saying
which
is
like
you
know
that
there's
just
different
scopes,
because
that's
just
not
captured,
I
think,
in
the
in
the.
C
B
D
If,
if
you
would
like
to,
I
would
probably
prefer
that
just
because
I
think
you
have
a
little
bit
more
context
on
this
one
but
yeah
I
I
if
needed,
I
can.
A
Okay,
he'll
do
both
perfect
okay,
so
we'll
leave
that.
Where
is
my
notes
now,
okay
discussed
a
bit.
A
A
Okay,
so
then
we
can
move
on
to
the
next
issues.
There
are
three
issues
that
were
tagged:
one
revisit
time
slots
next
year
for
10
years
for
collaborators,
which
I
think
mary
had
opened
and
I
think
would
be
good
to
to
make
sure
we
wait
until
she's
here.
I
think
in
the
past,
we'd
also
agreed
that
we
were
going
to
start
out
with
the
needs
and
wants
of
constituencies
which
is
number
20..
A
So
we
can
flip
back
to
that
oop.
I've
got
an
attendee
to
promote
sorry.
A
Welcome
jean
sorry,
for
it
took
me
a
little
bit
to
recognize
that
you
need
to
be
promoted,
but
it's
okay.
Thank
you
very
much.
Thanks
no
problems.
Okay,
so
I'm
going
to
pull
up
the
fun
retro
again,
so
this
is
the
link
which
I
will
paste
into
the
chat.
A
So
these
were
the
constituencies
we
had
now.
I
think
what
I
realized
is
that
we
actually
had
a
constituency
which
there
was
a
pending
pr
for
so
let
me
just
that
we
didn't
have
in
the
list,
so
I
think
that
one
I
want
to
look
at
our
constituencies
and
we
have
direct
template
application,
application
developers,
large
packages,
node.js
core
maintainers
and
organizations
with
investments
in
node.js,
so
that
I
want
to
add
new
column.
A
A
Well,
we're
not
going
to
do
that
today
right,
we
have
40
minutes,
so
we
could.
I
think
I
think
we
could
spend
like
five
minutes,
adding
in
more
things,
probably
five
to
ten
minutes
grouping
and
then
based
on
that
we'd
still
have
a
little
bit
of
time
to
figure
out
what
to
like
we.
I
agree.
We
won't
close
on
this
necessarily
in
that
time,
but
I
think
we
can
make
some
progress.
B
Okay,
I
mean
I'm,
I'm
not
opposed,
since
we
don't
really
have
much
else
to
talk
about.
A
Yeah,
I
think
I
mean
that
that's
like
this
is
our
it's
kind
of
like
it
seems
like
what
we
when
we
get
into
the
other
discussions,
we
always
fall
back
to
well.
We
need
the
this
baseline,
so
we
needed
the
values
now
we
want
to
know
the
needs,
and
so
I
think
it's
worth
spending
all
of
our
time
on
this
before
we
dive
into
the
other
discussions
right,
because
otherwise
they
sort
of
fall
back
to
what's
it
based
on
right.
B
A
B
A
A
A
A
B
I
think
ability
to
advocate
for
work
is
pretty
much
the
same
as
a
seat
at
the
table.
Right,
hey
these
two,
the
one
is
phrased
as
more
big
picture
and
then
the
others
phrases
more.
You
know
yeah,
maybe
small,
but
I
think
the
same
ideas
is
there.
B
B
A
A
C
A
B
B
A
A
A
D
One
of
the
things
that
I
I
found
useful,
I
I
built
a
a
basically
a
blog
mega
blog
post
of
all
of
the
releases
between
10
and
12
lts,
so
like
10,
lts
and
12.
Lts
less
is
like
a
this.
Is
our
road
map,
but
more
of
a
this
is
what's
changed
between
these
two
and
like
here's,
all
the
stuff
so
like,
for
example,
with
14
lts
that
took
a
lot
of
work.
D
I
don't
know
if
I'm
gonna
do
it
manually
again,
and
I
probably
don't
have
time
to
automate
it
right
now,
but
like
doing
something
around
that
of
like
hey,
here's
all
of
the
notable
changes
plus
all
of
the
commits
it.
It's
big
and
it's
very
achievable
but
like
having
something
like
that
is
maybe
a
way
to
kind
of
address
that
without
having
a
forward-looking
roadmap.
A
You
know
like
the
individual
changes
can
be
quite
overwhelming,
sometimes
right
and
if
there's
like
a
new,
if
there's
a
new
command,
a
new
option
on
a
command
line
or
on
one
of
the
apis
or
something
you
know,
that's
going
to
be
too
low
level
to
really
be
useful
to
a
broad
audience
yeah,
but
having
that
sort
of
like
here's,
the
trend
and
here's
the
progress
like
we
have
the
challenge.
I
think
in
that
we're
very
aggressive
of
moving
things
back.
A
So
when
you
come
to
an
lts
release,
we
struggle
a
little
bit
to
sort
of
hype.
What's
there
because
well,
it's
already
available
in
12.,
but
it
wasn't
actually
available
in
12
when
12
came
out
right
and
right.
So
like
having
a
little
bit
more,
you
know
having
having
some
of
that
communication,
which
is
like
hey
here.
Here's
here's,
the
things
we
think
are
important
and
then
here's
what
we've
progressed
we've
made
during
this
release
time
span
might
help
to
address
some
of
that.
C
A
Right
right
like
if,
through
this,
we
can
kind
of
come
up
with
you
know.
If
you
read
through
this,
and
you
said
okay,
I
can
understand
what
people
think
are
in
is
important
now,
because
it's
open
source,
you
know
we
it's
not
like.
We
then
say:
well,
okay,
you
and
you
and
you
go
work
on
this,
but
we've
highlighted
it
and
as
a
project
we
should
be
looking
to
see.
Well,
are
we
making
progress
on
that
and
then
we
can
talk
about
what
progress
we
have
made.
D
C
D
Potentially
one
thing
we
could
do
there
to
like
do
that
less
manually
is
exclusively
use,
those
as
a
way
to
kind
of
collect
that
stuff
and
that
that
would
be
a
way
to
kind
of
like
say:
hey,
here's
all
the
things
that
have
to
do
with
file
system
and
that
are
notable.
A
In
this
period
it
is
certainly
something
like
when
I
you
know,
if
I'm
writing
a
blog
post
or
something
about.
What's
the
new
release,
I
go
back
and
look
through
the
change
log
for
say
say
for
the
14
one.
Even
you
can
look
through
the
changeable
like
the
when
it's
gone
lts
you
can
look
through
the
notable
changes
for
all
of
the
14
releases
and.
C
A
Yeah,
and
so
maybe
actually
yeah-
that
could
actually
be
automated,
like
show
me
all
the
notable
changes
since
since
release
now,
it
still
takes
some
interpretation
to
put
them
in
the
context
of
the
sort
of
you
know
what
we
think
is
important,
but
at
least
this
does
give
you
some
data,
something.
B
That
fits
in
to
this
is
not
only
hey.
Here
is
a
notable
change,
but
a
little
bit
more
robust,
and
this
is
what
that
notable
change
means
to
you
right
like
as
an
end
user
or
library,
author
or
something
because
unless
you're
really
plugged
in
you
might
say,
oh
great,
like
you
know,
I'm
trying
to
think
of
one,
that's
coming
down
the
pipe
right
now.
What's
that
the
the
audit
events,
the
performance
hooks
or
whatever
it's
like,
okay,
cool,
like
once
that
lands,
that's
a
notable
change.
B
A
B
Yeah,
I
just
for
some
reason
couldn't
remember
the
name
like
when
that
lands-
it's
great
but
then
you're
gonna.
Like
most
end
users
are
gonna,
say:
okay,
cool.
B
What
do
I
do
with
that
right
and
feel
like
there's
a
gap
there
between
the
change
logs
and
and
all
that
and
what
the
project
provides
to
tell
an
end
user?
What
it
right.
A
B
A
Yeah,
I
guess
it's
the
we
rely
on
the
individuals
to
promote
those
things
that
they
think
they're
important.
So,
like
the
diagnostics
working
group,
I'm
sure
we'll
try
and
promote
that
and
we
would
likely
write
a
blog
post
on
the
node
medium.
But
I
think
what
you're
saying
is:
that's
not
necessarily
everything
we
should
do
or
effective.
A
B
D
A
B
B
A
A
D
A
question
I
have
is
like,
I
feel,
like
direct
users,
is
foundational
for
application
operators,
application
developers,
library,
package,
auth
and
library,
slash
package.
Authors
like
the
ones
there
now
currently
apply
to
all
of
those
and
like
those
are
branches
of
that
is.
Does
that
kind
of
make
sense
to
others?.
B
Yeah
this
is
where
there's
these
cross-cutting
things,
I
actually
so
what
the
I
think.
The
reason
why
we
decided
to
break
those
three
out
separate
from
even
though
they
are
to
all
direct
end
users
in
some
way
is
that
it's
also
like
partial
overlap,
but
not
complete.
So,
for
example,
an
application
developer
may
actually
never
interact
directly
with
most
node
apis.
They
may
be
doing
it
through
a
framework
or
a
build
tool,
or
you
know
whatever,
and
so
they
have
different
concerns.
C
A
A
B
Like
the
way
I
was
seeing,
it
is
they're
actually
saying
require
path
require
fs
like,
whereas
a
application
developer
may
be
saying,
require
you
know,
fs
extra
and
then
building
something
on
top
of
that,
because
they
needed
you
know.
Well,
that's
maybe
a
bad
example.
Http
is
probably
a
better
one
right
require,
http
would
be
like
a
direct
end
user
require
express,
would
be
an
application
developer
right
and
they
may
interact.
A
D
I
had
a
really
interesting
experience.
The
other
day
where
one
of
my
peers
was
is
working
on
an
internal
thing.
That's
probably
going
to
end
up
becoming
a
product,
but
he
is
not
like
a
node
person
and
it's
a
node
app
and
the
socket
io
site
was
just
like
oh
yeah.
If
you're
using
express
just
do
this
and
he's
heard
of
express,
for
he
knows
what
express
is
so
he
just
reached
for
express
when
he
only
he
he
didn't
need
express.
D
He
just
needed
http,
and
I
I
think
that's
something
to
consider
there
like
in
that
framing.
Is
that,
like
there
are
things
that
are
the
behemoths
in
node
that
people
will
always
reach
for,
even
if
they
don't
need,
and
I
I
think
that
in
the
framing
things
like
that
we
do,
we
should
take
that
into
account
too
of,
like
the
community.
D
Push
is
toward
express
or
whatever
like
commander
or
request,
or
you
know
different
examples,
but
I
think
that's
something.
We
should
also
keep
in
mind
in
situations
like
that,
or
in
framing
things
like
that
is
like
just
because
someone
is
using
express,
doesn't
mean
that
they
actually
need
it.
B
B
B
What
is
the
reason
why,
in
the
past
those
you
know
they
are
using
socket
io
on
top
of
express
on
top
of
http
when
really
all
they
needed
was
like
you
know,
maybe
http
or
or
then
even
you
know
the
net,
I
don't
know
or
maybe
websocket
should
have
been
built
in
and
then
that's
the
direct
end
user
story
right
like
there's
a
lot
of
things
there,
where
I
think
there's
gaps
specifically
because
we've
addressed
application,
operators,
developers
and
library
authors
a
lot
more
than
we've
addressed
direct
end
users.
A
The
way
we
wrote
up
direct
end
users
was
users
who
run
tools
themselves.
Install
node.js,
run
tool
deal
with
errors,
so
I
don't
know
if
we
need
to
expand
that,
but
I
think
that
that's
still
in
the
flavor
of
what
we've
talked
about
right
like
it
doesn't
talk
about
whether
you
write
code
or
not,
but
you're
basically
running
it
yourself.
A
B
I
think
we
should
flush
that
description
out,
at
least
to
say,
like
this.
Maybe
an
example
of
like
this
could
be
somebody
running
a
node.
You
know
application
where
they
install
node,
then
install
the
application
and
they
run
it,
but
it
could
also
be
somebody
doing
just
like
some
scripting.
You
know
local
scripting,
something.
C
A
B
A
D
Yeah,
I'm
more
meant,
like
you
know,
tommy
is
a
x
developer,
working
at
x,
company
doing
x,
thing
type
of
a
user
user
profile.
B
A
A
A
And
then
the
next
thing
would
be
to
try
and
and
try
and
get
broader
input.
So
I
don't
know
I
mean
so
I'll
I'll
volunteer
to
try
and
take
this
list
and
build
that.
Here's,
the
the
sort
of
macro
list,
with
the
check
boxes
for
which
ones
want
which.
A
B
I
think
opening
a
pr
with
that
will
draw
some
feedback
just
naturally,
okay,
but
I
do
think
it
would
not
hurt
before
we're
done
with
this.
I
don't
think
this
is
a
next
step,
but
I
think
at
some
point
or
the
end
of
this
process
doing
some
sort
of
user
survey
would
probably
be
good
and
just
say:
look
here's
what
we've
got
right
have
things
like
you
know?
Do
you
agree
with
this
on
a
scale
of
one
to
five
or
like
there's
a
lot
of
ways?
B
We
could
structure
a
survey
that
would
not
be
totally
open-ended
because
that
would
be
really
hard
to
go
through
but
like
that,
could
help
us
narrow
in
what
we
want,
and
especially
if
we
can
let
people
bucket
themselves
into
these
different
user
groups
right.
So
we
can
see
if
like
what
we
got,
aligns
with
what
they
think.
B
B
A
B
A
B
Needs
yeah,
okay,
anyway,
again,
not
not
really
next
step,
because
I
think
that
we'd
be
we
we
would
struggle
to
get
a
meaningful
survey
result
out
of
like
more
open-ended
things
like
we've
been
discussing
on
these
calls
right,
but
I
think
at
the
end
you
know
just
to
do
like
a
sanity
check.
Does
this
align
with
what
our
users
really
think
would
be
valuable.
C
A
Okay,
so
what
what's
the
like
in
terms
of
like
to
do
something
similar
to
in
terms
of
needs
or
to
review
what
we've
got?
What's
the?
A
B
We
go
forward.
I
have
an
idea
this.
What
if
we
brought
one
from
each
group
together,
all
at
once,
and
basically
we
all
just
kind
of
sat
back
and
said,
like
hey
discuss
these
things,
we've
brought
one
one
from
each
group.
You
know
cross
cross
pollination
of
these
ideas.
I
think,
is
really
valuable
there
and
then
we
just
sort
of
let
them
go
for
you
know
15
or
20
minutes
where
we
kind
of
are
probing
questions,
because
that
would
be
both
a
slightly
more
efficient
use
of
time.
B
I
think,
and
also
would
get
people
across
these
different
groups
talking
which
might
spur
more
interesting
things
than
just
like:
hey
you're,
our
you're,
our
end
user.
Tell
us
what
you
think
right,
which
might
be
like
a
little
overwhelming.
B
One
of
each
to
yeah,
sorry,
the
way
you
phrased
it
I
was
it's
invite
one
person
from
each
of
the
constituencies,
all
at
once
right
schedule,
a
time
where
they
can
all
come
together
and
then
and
then
we
just
sort
of
say,
here's
the
here's,
the
list
the
table
come
up
with
like
discuss,
and
maybe
we
have
to
come
up
with
some
like
discussion
points
to
get
them
started.
A
A
D
I
mean
I
could
definitely
pull
in
application
operators
that
one
would
be
super
easy
but,
like
I
could
probably
pull
in
some
either
front
end
folks
or
package
maintainers.
C
D
D
In
their
perspective,
I
could
potentially
pull
someone
from.
What's
it
called
puppeteer,
no
wait
is
that
it's
the
lighthouse,
wait.
What's
what's
the
google?
What's
the
microsoft,
the
microsoft
version
of
that.
B
B
A
B
B
Yeah,
that's
specifically
what
I'm
thinking
like
there's
you
know.
The
the
boots
on
the
ground
you
know
perspective
is,
is
basically
all
the
other
categories,
but
the
organizations
we
really
need
somebody
who's.
Looking
at
it
from
the
you
know.
What
would
my
whole?
What
if
my
whole
team
was
was
javascript
engineers?
C
Might
be
interesting,
I
could
probably
ask
someone
from
the
cloud
google
cloud
functions
team
to
join
because,
because
that's
that's,
one
of
our
main
products
is
node
on
cloud
functions.
B
D
Yep
and
for
what
it's
worth,
that
blog
post,
I
was
talking
about
earlier,
where
I
collected
all
of
the
differences
between
like
112,
lts,
shipped
and
14,
lts
or
sorry.
I
was
10
lts
and
12
ltfs,
but
same
thing.
That
was
for
that
team,
specifically
because
that
was
a
request
from
them
of
like
hey.
What
are
the
differences,
and
so
I
pulled
together
all
the
notable
differences.
B
C
A
A
I
was
just
like
that's
surprising
because,
like
I've
heard
that
the
the
feedback
I
get
is
like
three
quarters
of
the
major
use,
cases
for
functions
are
all
written
end
up
people
using
and
people
using
note.
But
I
can
understand
the
as
an
organization
there's
more
history
with
other
languages.
A
B
B
Well,
so
I
think
there's
something
there's
slightly
different
things
right,
so
operators
would
be
something
like
running
a
service
got
to
look
at
metrics.
They
get
alerts
when
a
service
goes
down
like
they
need
to
debug
those
those
kind
of
things.
Whereas
I
see
the
platform,
as
should
we
make
support
for
node
in
our
cloud
functions
first
class
right
and
that
to
me
is
like
the
organization's
decision
and
then
there
will
be
a
bunch
of
boots
on
the
ground.
B
B
Yeah
and
that's
kind
of
what
I'm
thinking
right
here
is
like
the
nice
thing
about
adding
it
here.
First,
let's
be
real
like
this
is
like
four
companies
right,
like
four
major
players,
I'm
sure
there's
a
ton.
You
know
we
could
probably
go
deep
and
say:
look
everybody
who
has
a
some
sort
of
cloud
infrastructure
is
in
this
category,
but
I
don't
think
that
their
needs
are
going
to
be
drastically
different
from
the
you
know.
B
Should
we
make
it
a
gold
language
or
whatever
I
don't
know,
is
that
the
right
term
from
google
like
at
netflix,
it's
the
paved
path
right.
So
we've
like.