►
From YouTube: Node.js Foundation Modules Team Meeting May 23 2018
Description
A
B
Can
you
hear
me
great
sweet
cool
I've
had
to
switch
the
client
to
the
the
other
computer
instance,
so
I
could
save
on
resources.
So
it
looks
like
we
we
don't
have
quorum
yet
so
the
current
PRS
for
members
were
will
have
to
defer
until
either
later
on,
in
the
meeting,
probably
towards
the
end,
to
see
if
we
reach
quorum
then
so
then
that
leads
discussion
of
time
boxed
items.
C
So
like
basically,
but
the
initiative
like
I
may
be
a
shoe,
basically
I'm
struggling
to
catch
up
with
what
I
miss
over
the
past
three
weeks.
So
if
they
may
realize
that
a
lot
of
terminology
is
what
is
intended,
but
then
that
gets
miscommunicated
walk,
so
I
think
putting
some
terminology
in
place
can
help.
You
know
in
the
future,
and
it
could
also
help
with
the
discussions
so
that
you
know
saying
one
word
means
something
we
agree
upon
so
so
yeah
like
definitely
I'm
willing
to
be
part
of
this
initiative.
C
It
would
be
a
document,
so,
whatever
format
the
team
prefers
I
think
it
could
be
a
markdown
file,
part
of
the
repo,
and
we
can
all
collaborate,
but
I
do
recommend
at
least
two
human
beings
work
on
it,
because
that
tend
to
not
make
sense.
If
they're,
you
know
just
written
by
one
individual
and
they
make
a
lot
more
sense.
If
more
people
are
in
boy.
Okay,.
B
A
A
B
E
I
was
just
gonna
add
historical
decisions
can
easily
be
obviously
a
source
of
contention
if,
like
obviously
people
disagree
with
whatever
decision
was
made,
so
we
might
want
to
just
tread
carefully
there
of
like
you
know,
this
is
what
was
discussed.
This
is
what
was
decided,
but
you
know
basically
until
I'm,
assuming
until
until
something
is
released,
any
decision
could
be
revisited,
so
it
shouldn't
be.
It
shouldn't
be
presented
like
this
was
decided
three
years
ago
and
we
almost
abide
by
it.
So.
C
C
A
B
B
B
Good
then,
we'll
move
on
to
the
next
one,
which
is
Kevin
Smith,
so
this
is
number
88
Kevin
Smith
would
like
to
be
moved
would
like
to
be
added
to
an
observer
observer.
So
again
the
questions
raised
if
everyone's
okay
with
that
and
I,
don't
see
any
comments
here,
which
means
that
it's
going
to
be
it's
going
to
be
okayed,
so
Kevin
will
be
added
as
an
observer
and
Jeffrey
will
be
moved
to
an
active
member
cool,
okay,
great
now,
on
to
developer
survey.
A
Well,
I'm
gonna
keep
talking
the
the
should
idea
that
I
had
here
is
you
know
one
thing
that
we've
talked
about
a
couple
times
when
going
through
stuff
here
has
been
discussing
users
and
discussing
you
know
what
are
the
expectations
of
people?
What
would
they
like?
What
would
they
not
like?
How
would
they
want
things
to
be
done?
A
We
represent
a
number
of
different
communities
and
we
have
a
number
of
different
use
cases
and
individuals.
So
you
know
we
do
have
a
group
within,
though
that's
doing
active
user
feedback
and
the
foundation
itself
has
done
a
number
of
different
things
regarding
outreach
and
user
feedback.
So
I
was
thinking
that
perhaps
we
could
put
together
a
survey
we
could
put
it
out
and-
and
you
know,
I
think
the
balance
will
be
coming
up
with
questions
that
are
not
to
leading,
but
essentially
trying
to
get
some
questions
out
there.
A
So
we
can
test
some
of
our
hypotheses,
a
really
great
example
of
the
transparent
Interop.
You
know
a
lot
of
us
think
it
will
be
better
for
some
experience,
something
who
will
be
worse
for
others,
I
think
doing
some
actual
user
research.
There
and
could
show
some
some
good
stuff,
I
guess
I'll,
just
leave
it
to
the
floor.
I
don't
know
if
we
really
need
to
discuss
at
length.
A
F
Let
me
know
if
you
can
hear
me:
okay,
as
well,
I'm,
also
on
a
fire
connection
here.
Just
with
regards
to
that.
Just
saying
that
it's,
it
would
be
good
that
we,
as
you
mentioned
with
the
example,
understand
what
goals
we're
looking
to
achieve
from
the
survey
and
and
have
some
idea
of
this
sort
of
objectives
we
have
in
mind,
and
maybe
just
a
part
of
the
process.
H
So
you
briefly
mentioned
bias.
I
do
agree,
it's
gonna
be
extremely
hard
to
not
create
biased
questions
or
a
lot
of
this
a
decent
amount
of
stuff
we're
starting
to
talk
about
it's
getting
too
technical
causes
of
why
some
things
are
difficult
in
the
same
thing,
I
want
to
know
kinda
of
the
overall
effect
that
this
survey
will
have.
Are
we
bound
by
this
survey
or
we
kind
of
beholden
to
do
whatever
the
most
popular
opinion
is.
A
Yeah
I
mean
I'm
imagining
that
this
isn't
something
that
will
be
bound
to
I'm,
imagining
that
this
is
primarily
going
to
be
something
I
just
want
to
like
when
we're
talking
about
users
and
when
we're
going
to
discuss
users
and
use
users.
Opinions
as
a
mean
to
discuss
an
argument.
I
want
us
to
have
something
physical
that
we
can
use.
It
doesn't
mean
that
that
makes
us
beholdin
to
it,
but
I
just
want
to
use
act
like
I
want
to
use
evidence
and
user
research
rather
than
exposition,
and
you
know
feelings.
H
If
that's
so
so
you
used
a
slightly
different
word
than
I
did
I'm
more
concerned
with
expectations.
A
lot
of
the
opinions
that
are
going
to
be
coming
out
are
actually
just
going
to
be
their
expectations.
I
believe,
unless
we
are
very,
very
careful
about
how
we
do
this
and
expectations
are
very
different
from
opinions,
expectations
are
oh,
it's
going
to
work
a
specific
way.
Not
oh
alternatives
are
bad
yeah
they're
their
existing
knowledge,
not
a
survey
of
all
possibilities.
H
A
And
I
was
imagining.
It
would
be
a
question
like
yeah,
and
maybe
we
need
to
spin
off,
like
a
separate
group,
to
put
together
a
proposal
as
to
what
this
survey
could
look
like,
and
the
biggest
challenge
will
be
keeping
these
questions
from
being
leading
and
I.
Think
by
avoiding
leading
questions,
we
can
avoid
the
questions
themselves,
setting
expectations.
E
If
I
could
just
second,
this
I
think
it's
way
better
to
find
out
users
expectations
before
you
release
something
rather
than
after
putting
something
out
there
in
beta
or
otherwise,
and
getting
a
torrent
of
criticism
pack
so
I
mean
yes,
I,
agree,
there's
there's.
Obviously
this
could
be
fraught
with
peril,
if
not
handled
well,
but
also
the
the
you
know
alternative
or
not
doing.
It
can
also
be
pretty
bad
mmhmm.
C
B
A
With
the
biggest
reason,
I
thought
to
put
this
on
the
agenda
was
you
know,
we
still
have
some
time,
there's
a
dinner
tonight
and
there's
a
whole
day
of
meetings
tomorrow.
So
if
there's
specific
questions
that
people
would
like
me
to
socialize
or
talk
to
people
about,
I
definitely
can
Linda.
Clark
just
gave
a
really
great
talk
about
loading
different
runtimes,
so
there's
a
whole
thing
that
they're
looking
into
for
wasm,
specifically
in
potentially
creating
a
second
instantiation
sub
phase.
A
B
B
Is
there
been
discussion
on
avoiding
that
in
the
first
place,
through
either
built-in
modules,
which
I
think
Dominic
tentacle
has
been
against
or
like
scoped?
It's
like
safe
modules
for
prototypal
additions
or
some
kind
of
mechanism
to
avoid
this,
like
new
tools
biting
us
again
for
these
things,
and
if
so,
could
could
something
be
mirrored
for
for
the
node
ecosystem,
for
things
like
impe
attaches
that
they'll
be
run
into
collisions
with
as
well.
A
A
Essentially,
it
doesn't
seem
like
it's
moving
forward,
but
there
is
an
interest,
but
the
recommendation
that
was
given
to
node
was
to
just
move
forward
with
it
and
I.
Think
with
the
discussion
over
having
in
the
pull
request
for
broadly
I,
think
we
just
want
to
move
forward
with
an
at
node.js
namespace.
A
That's
something
that's
like
mirrors,
what's
being
used
in
the
ecosystem,
anyways
right
now
and
if
built-ins
end
up
in
the
platform
using
a
different
identifier,
we
can
support
both
it's
you
know
not
the
most
elegant
way
to
move
forward,
but
I,
don't
think
we
need
to
block
our
movement
on
the
ecosystem.
Moving
forward,
Brad.
H
H
So
there
that's.
We
looked
at
it.
One
way
for
the
poisoning
problem.
We've
spent
several
talks
today
kind
of
about
purity,
which
is
somewhat
related
to
robustness
and
we're
talking
about
re
reinitializing,
the
frozen
realms
route
by
moving
forward
with
realms,
and
that
would
be
a
way
to
prevent
prototype
poisoning
and
that
sort
of
stuff.
It
still
won't
prevent
mootools
from
shooting
themselves
in
the
foot,
because
we
can't
the
outer
most
realm
be
frozen,
but
for
a
variety
of
avenues
being
looked
at
yes,
nice.
A
Hasan
did
mention
before
jumping
like
it
sounds
like
they're
running
low
in
network,
but
they
just
want
to
say
they
regarding
the
developer
survey
stuff
earlier,
that
it
will
perform
us
a
platform,
tour
elaborate
more
and
how
users
will
really
work
with
modules.
I
I'll.
Add
that
to
the
notes,
I
think
that's
a
great
point
of
soon.
B
If
you
could
reply
to
that
issue
and
just
let
what
folks
know
in
the
module
working
group
that
you
are
a
member,
so
that
will
know
who
to
to
ping
in
or
ask
questions
to
I
guess
they
could
also
here's
ask
questions
in
the
thread,
but
it's
nice
to
let
folks
know
who's
in
what
groups
the
next
feature.
The
next
thing
is
a
transparent
interrupt
for
ESM
importing
comment.
Yes,
and
this
was
and
transparent,
transparent
or
not
interrupt,
which
was
the
issue
I
opened.
A
E
Yeah
so
sorry
I
have
to
I
have
to
leave
right
at
one
o'clock
or
one
o'clock
Pacific
in
30
minutes,
so
yeah,
the
only
thing
I
added
the
only
thing
I
wanted
to
talk
about
this
at
the
meeting
was
just
about
splitting
this
into
multiple
features.
I
feel
like
15
minutes
his
way
to
a
little
time
to
even
begin
to
go
into
transparent
Interop.
But
I
mean
this
since
this
cause.
If
you
want
to
go
to
the
number
100
JD
data
show
people
this
covered
like
15
or
maybe
a
dozen
use
different
use
cases.
E
A
E
A
A
A
J
I
want
to
add
is
that
it
might
make
sense,
especially
for
these
bigger
discussions
to
have,
for
example,
per
get
have
issue
a
Google
Doc
that
just
captures
the
discussions
that
have
been
going
on
in
the
current
state
so
that
we
can
capture
the
different
aspects
of
it.
In
one
document
that
has
like
a
table
of
contents,
see
it
a
lot
better,
I,
think
and
if
it
would
have
been
still
have
about
to
be
that
it
is
always
one
single
issue.
C
A
So
adding
adding
on
to
you
know,
it's
Sailaja
said,
which
is
something
that
I
think
could
be
really
helpful,
and
it
was
something
I
tried
to
propose.
You
know,
is
you
know
each
of
these
features
by
themselves
and
like
specifically,
the
underlying
mechanism
of
how
they
work
in
a
really
great
example.
A
And
how
does
that
user
experience,
how
do
I
as
a
developer
approach
it
and
engage,
and
the
user
experience
that
we
discuss
will
in
turn
create
a
feature
set
which
will
in
turn
serve
to
the
use
cases
that
we've
served.
I
just
think
that
they're
breaking
it
down
and
digging
in
per
use
case
before
we
know
per
feature
before
we
know
which
features
we
actually
are
engaging
in
is
premature.
Sorry,.
C
A
Or
I
mean
personally
domain,
and
mostly
I'm,
actually
thinking
about
like
a
proposal
of
user
experience,
because,
like
the
if
we
use
transparent
Interop
as
an
example,
transparent
interrupt
is
part
of
a
larger
user
experience
with
which
also
involves
how
do
we
use
multiple
modules?
It
also
involves
how
do
we
transition
packages?
It
also
involves
how
do
we
have
custom,
loaders
and
I?
Don't
know
how
we
talk
about
the
implementation
of
transparent
and
drop
by
itself
without
all
that
contacts,
a
guy.
F
Yeah
I
mean
it
sounds.
It
sounds
like
a
sensual
approach
because
up
in
with
these
relatively
complex
things
you
you
know
that
there's
so
many
implicit
in
like
implications
of
implementation
decisions.
That's
like
one
technical
thing
that
we
can
be
discussing
can
I.
Have
you
know
a
myriad
of
different
implications
from
the
way
that
we're
clothes
are
going
to
work
on
the
web,
to
the
way
that
bundlers
have
to
work
to
the
way
that
NPM
workflows
are
going
to
work
or
whatever
so
I
think
you
know
fleshing
out.
F
F
The
only
thing
to
be
careful
about
that
is
that
we
can
very
quickly
then
end
up
with
like
three
islands
that
don't
really
go
here,
and
then
it
becomes
sort
of
a
process
of
sort
of
trying
to
push
one
of
these
visions
that
we've
created,
when
maybe
they're,
on
middle
grants
to
be
found
as
well.
When
you
go
back
to
that
feature
level,
but
definitely
the
approach
down
sensible
to
me,
Jeffrey.
E
So
I
think
most
of
the
features
are
already
written
from
a
like
user
story,
perspective
and
I
think
the
ones
the
ones
that
aren't
you
know
probably
should
be,
and
then
I'm
thinking
like.
Maybe
what
we
could
do
is
like
just
maybe
try
to
avoid
like
I'm,
sorry
after
who's
saying
it
to
try
to
avoid
discussing
implemented
whenever
possible
in
these
features
and
just
be
like
this
is
the
user
story
and
then
maybe
open
new
features
for
kind
of
like
how
we
open
features
for
proposals
and
then
it's
like
here's
a
proposal.
E
I
think
I
can
do
this
basically
describing
and
implement
a
and
then
it
can.
We
can
like
reference
like
okay,
so
which
of
the
features.
Does
this
support
or
not
and
why
it
cetera
that
might
be
better
and
lead
to
less
noise
in
the
features
themselves,
and
then
the
fee
for
the
discussion
of
the
features
themselves
can
be
centered
around
more.
Like
you
know,
do
we
want
to
support
this
or
not?
Is
this
a
user
story
that
we,
you
know,
consider
valid
or
not,
yeah,
just
a
thought.
A
Jeff,
would
you
be
able
to
expand
on
that
thought?
Just
in
the
notes,
a
I
didn't
fully
get
it
out
as
much
as
I
would
have
liked
to
of
looks
like
guy
is
so
Jeff
and
in
responding
to
your
point
there.
How
about
opening
it,
like
the
one
thing
that
I
really
want
to
stress?
You
know
like
from
my
personal
experience:
I'm,
not
looking
at
github
too
much
on
the
weekends
and
stuff
and
I
guess
some
people
only
get
to
look
at
on
the
weekend.
A
So
that's
fine,
but
when
close
to
30
issues
get
opened
over
the
weekend
and
each
of
those
issues
start
creating
their
own
conversations
and
going
down
their
own
path
of
discussion.
And
then
we
talk
about
opening
more
I
can't
keep
track
of
it.
I
can't
participate
in
the
conversation
and
it
actually
creates
an
island
where
the
only
people
who
are
actually
able
to
participate
are
those
who
can
keep
up
with
all
the
different
threads
and
have
the
time
to
and
I
don't
want
to
push
this
so
far
that
we
find
ourselves
limiting
the
discussion.
A
We
definitely
don't
want
to
do
that.
We
want
to
keep
the
discussion
moving
forward,
but
I'm
concerned
that
the
approach
that
we're
taking
right
now
is
going
to
a
drive
away
a
whole
bunch
of
members
that
we
have
that
don't
have
time
to
engage
in
all
of
these
different
threads
and
be
is
setting
us
up
for
large
disagreements
and
and
turtley,
and
that's
what
I've
observed
over
the
last
couple
days,
I've
observed
a
lot
of
conversations
that
are
going
into
teeth.
Deep
technical
discussion.
Not
talking
about
you,
know
the
really
high-level
stuff
and
I've.
A
F
I'm
sorry,
I
I'm,
just
thinking,
maybe
that
you
know,
if
there's
a
way
to
focus
these
discussions,
because
we
can't
expect
I
mean
well.
Some
of
the
most
fruitful
discussions
can
happen
when
we
have
people
being
able
to
respond
offline,
putting
sorts
of
things
and
having
these
kind
of
detailed
discussions
in
the
issue
queues.
F
So
it
seems
like
a
really
fruitful
way
to
move
discussions
forward
between
these
meetings,
but
but
maybe
if
we
just
try
and
guide
the
focus
of
those
discussions
during
the
periods
between
the
meetings
and
and
think
clearly
about
what
we
want
to
prioritize
every
two
weeks
or
some
way
to
kind
of
restrict
that
scope
and
guide.
It
definitely
sounds
sensible.
F
A
And
to
be
explicit,
I
don't
want
to
see
those
conversations,
stop
what
I
do
want
to
see
if
we
can
try
to
avoid-
and
this
is
a
problem
that
we've
had
in
note
in
general-
is
that
it
can
end
up
becoming
in
a
game
of
who
can
talk
the
longest
and
then
that's
who
wins
and
people
just
slowly
back
out,
who
aren't
able
to
keep
up
with
the
pace
and
that's
not
necessarily
always
a
bad
thing.
It's
just
like
I,
don't
know!
B
Okay,
we
have
15
minutes
left
and
there's
a
topic
to
be
discussed
which
is
non-transparent,
intro
I
figured
this
would
be
a
good.
It
comes
up
from
time
to
time.
There
was
a
blog
post
about
six
eight
months
ago.
That
mentioned
it,
but
I
don't
know
if,
if
members
have
a
full
understanding
of
it,
so
I
think
it
would
be
nice
if,
if
miles
or
or
anyone
else
wants
to
jump
in
and
just
kind
of
give
a
description
about
what?
What
is
that
and
why
is
it
important
to
have
non
transparent
or
transparent?
B
A
Since
you
volunteered
me,
I
can
I
can
pick
it
up,
although
I've
been
walking
a
lot
this
meeting.
So
if
anyone
else,
please
do
and
I'd
like
to
suggest
really
quickly
that
perhaps
we
drop
the
use
cases
and
just
use
the
rest
of
our
time
to
talk
Interop
does
that
seem
reasonable
to
everyone.
Yeah
yeah,
I.
H
A
A
If
you
want
to
import
ESM,
it
must
be
MJS
and
that
part
is
a
little
bit
less
transparent,
whereas
I
believe,
like
the
NPM
proposal,
had
you
know
a
way
of
allowing
GIS
to
work
for
both
runtimes,
but
it
involves
dual
parse
or
something
like
that.
I'm,
not
I,
can't
recall
exactly
how
they
implemented
it.
G
Wesley
I
mean
so
earlier.
You,
you
asked
what
transparent
interrupt
means
to
different
people
for
me
like,
but
that's
supposed
to
admit,
and
what
the
use
cases
that
I
submitted
were
for
were
for,
like
just
substitute
ability.
The
ability
to
like
have
an
existing
common
Janus
package
that
has
a
reasonable
API
and
be
able
to
rewrite
it,
and
he
asked
them
and
not
break
all
of
my
consumer.
G
K
G
Honestly,
from
ESM
I
care
a
little
bit
less
I
mean
it'd,
be
nice
NES
em,
just
because
use
a
new
savings.
Poor
syntax
for
multiple
things
is
a
nice
to
have
but
incomes.
Yes,
it's
a
little
bit
more
important
because
in
you
want
to
be
able
to
keep
using
the
same
libraries
and
colleges
even
as
they
update
underneath
you.
G
It
needs
to
have
one
update
where
they
add
an
additional
entry
point
where
you
don't
have
to
use
the
replace
to
namespace
that
you
can
migrate
to
that,
and
then
they
can
swap
their
implementation
gsm
and
remove
the
replaced
namespace
entry
point
where
they
use
the
function
as
their
route.
But
the
point
is
that
migration
path
needs.
K
To
exist,
it
shouldn't
be
a
hard
cut.
Okay,
so
then
I
feel
like
my
conclusion.
From
hearing
just
just
a
small
selection
of
definitions
of
you
know,
what
does
transparent
and
drop
mean
to
each
of
us
is
that
we
don't
have
one
single
definition,
and
yet
we
we
throw
around
the
term
a
lot
and
what
do
people
think
about
creating
a
glossary
so.
A
G
K
A
Think
one
of
the
interesting
things
about
this
too,
based
on
what
you're
saying
Wesley
it
is
that
like-
and
this
has
been
one
of
my
critiques
of
transparent-
interrupt
for
a
little
while-
is
that
we
only
really
have
like
unidirectional,
transparent
Interop
in
the
sense
that
we
can
only
transparently
import
right
now,
whereas
in
the
common
j/s
world,
the
only
way
we
have
to
get
common
J's
packages
is
via
dynamic,
import
right.
That's
right!
That's
what
I
was
trying.
G
A
H
Can
I
just
hold
back
we're
getting
in
into
a
lot
of
technical
detail
and
we
haven't
even
agreed
on
terms
we're
discussing
and
they're
they're
good
things
here.
We
we
do
need
to
talk
about
the
transitions
but
yeah
right
now,
I'm
just
trying
to
get
people
to
like
talk
about
what
it
is.
So
we
can
define
these
terms
offline
because
we're
here
in
a
meeting
we
have
limited
time
yeah.
C
F
I
lowered
it
because
I
didn't
want
to
distract
but
I
I,
think
I
mean
if
we're
talking
about
terms
in
transparent
in
syrup
I,
think
it's
very
important
that
we're
we're
super
clear
on
on
these
terms
and
I
like
that.
We
can
define
it
in
in
a
technical
way
as
opposed
to
you
know
some
kind
of
user
story
way.
I
guess
I
would
side
with
the
first
two
definitions
of
transparent
aren't
interrupt
and
what
was
was
describing
sounds
a
little
bit
more
to
me.
E
Yeah
I
think
it's
more
like
it's
really
a
family
of
issues
or
family
of
features
like
you
were
saying,
like
ESM
importing
comment,
yes
comment,
you
have
some
pretty
yes,
some
blah
blah
blah
a
lot.
You
know
it's
a
whole
set
of
things
that
probably
are
a
whole
bunch
of
different
things
to
define
in
which
we
should.
This
would
be
good
to
have
them
all
listed
out
rather
than
one
huge
definition
of
you
know,
transparent,
Interop.
Well,
you
know
all
these
subcategories
of
it,
but
the
other
thing
I
was
going
to
say
is
I.
E
A
But
one
thing
I'm
hearing
right
now-
and
maybe
this
is
a
good
meta
issue
that
we
can
open
is
what
is
our
transition
story
like
because
I
think
the
biggest
thing
that
everyone
wants
to
avoid
is
fragmenting
our
ecosystem
and
so
all
of
these
features.
All
of
these
approaches
that
we're
talking
about
are
really
all
serving
the
ultimate
use
case
of
a.
How
do
people
who
are
using
ESM
continue
to
consume
common
j/s
modules
that
have
not
upgraded
and
on
the
flipside?
A
A
We
actually
have
a
lot
more
flexibility
in
doing
things,
because
we're
not
adherent
to
the
standard
of
the
ESM,
but
we
are
limited
by
fundamental
technological
barriers,
but
we
don't
need
to
dig
into
those
immediately
right
now,
but
perhaps
that
can
be
kind
of
the
meta
thing
that
consumes
a
handful
of
these
use
cases.
If
people
think
that's
reasonable.
H
H
B
A
I'll
have
my
computer
will
have
internet
I'll,
try
to
set
it
up
so
that
people
can
dial
in.
We
can
use
a
hangouts
or
something
I'll
post
it
on
the
modules
issue,
tracker
to
be
honest,
I've
just
been
running
around
and
super
busy,
so
I
haven't
planned
it
out
too
much,
but
it's
gonna,
be
you
know
a
bunch
of
us
will
be
there.
We
do
have
the
time
I.
Will
that
on
the
issue,
tracker
basket
is
meeting.