►
From YouTube: Node.js Foundation Modules Team Meeting
Description
A
A
A
A
We
want
to
use
the
hand
raising
as
a
way
to
organize
the
conversation
with
so
many
people
involved.
So
if
you
would,
if
you
have
something
you'd
like
to
say,
please
raise
your
hand
and
I'm
going
to
moderate
the
conversation
in
the
spirit
of
moderation.
Tim.
Do
you
have
anything
to
say
right
now?
Can
you
hear
me
I
can
hear
you
all
right.
That's
all
I
got
wonderful.
Thank
you,
I'm
able
to
lower
people's
hands.
So
if
you
raise
your
hand,
don't
worry
about
it,
I'll
dismiss
it,
but
just
wanted
to
make
that
clear.
A
So
everyone
knows
what's
going
on
so
then
what
else
do
you
have
going
on?
I
could
use
someone
to
help
with
taking
notes
for
me
just
kind
of
if
I'm
going
to
be
managing
the
hand,
raising
and
moderating
I'm
not
gonna
have
the
ability
to
take
notes.
So
if
we
have
anyone
who
is
good
at
taking
notes,
we
would
appreciate
that
Wes,
you
have
your
hand
up,
yeah,
I,
Daniel
there
I
can
take
notes.
Okay,
wonderful,
thank
you,
Daniel
and
then
laughs.
A
A
A
B
B
There
is
a
doodle
for
selecting,
which
date
you
want
the
summit
to
be
it's
all,
gonna
be
remote,
so
online.
Only
and
we'll
set
up
a
very
long,
zoom
call
and
schedule
around
that.
The
time
will
probably
be
closer
to
UTC
than
USA
time,
because
we
have
a
diverse
group
so
expect
to
get
up
early
that
day.
If
you
are
in
the
USA,
we'll
try
to
be
as
accommodating
as
we
can.
B
If
you
haven't
filled
out
the
doodle,
there
are
several
people
who
haven't
be
sure
you
do
so
I'm
going
to
probably
have
to
cut
off
the
doodle
selection
and
select
a
date
fairly
soon,
so
that
we
can
actually
set
up
a
schedule
and
figure
out
who
can
speak
in
that
issue.
There's
also
a
way
to
submit
a
topic.
You
want
discussed
I'm,
not
doing
a
call
for
presenters
in
any
way,
because
we
have
a
fairly
large
group
and
it's
still
going
to
be
limited
time
if
we
only
do
one
day
for
the
module
summit.
B
How
long
we're
going
to
associate
with
each
discussion
point
I
would,
like
the
schedule,
be
solidified
two
weeks
ahead
of
time,
maybe
not
the
people
speaking
about
it,
but
the
times
at
least
so
that
people
can
actually
get
involved
in
organize
their
stuff
that
they're
gonna
be
talking
about.
So
that's
it.
A
A
A
B
So
last
meeting
we
discussed
that
we
are
going
to
seek
quorum
during
meetings
in
order
to
merge
PRS,
which
is
what
we're
doing
currently
James,
has
some
disagreement
on
this,
because
he
feels
that
we
shouldn't
need
to
wait
for
a
meeting
in
order
to
merge
PRS.
We
actually
have
a
fairly
small
distance
between
each
meetings,
so
I
think
it's
okay,
especially
in
the
beginning
and
I.
Think
that's
what
we
agreed
upon
in
the
last
meeting
to
have
where
we
always
agree
in
a
meeting
for
quorum
to
land
a
PR.
B
A
D
A
B
A
E
F
Just
gonna
add
that
you
know
it
was
what
we
agreed
last
time
and
I
understand
the
concerns
that
it's
different
from
the
other
projects,
but
I
think
it
was
based
on
the
fact
that
we
don't
think
that
the
things
that
need
to
go
into
this
repo
are
urgent
and
that
it's
better
to
get
more
discussion,
at
least
in
the
initial
phases,
so
I'm
still
plus
one
on
landing
it
as
well.
Okay,.
A
B
D
Think
work
specifically
on
the
modules
project
has
a
high
chance
of
being
wasted.
If
we
don't
have
consensus
about
what
we're
building
in
particular,
I
believe
that
the
code
part
of
this
project
is
going
to
be
the
straightforward
part,
they're
going
to
be
very
few
things
that
are
actually
tricky.
The
hard
part
is
going
to
be
identifying
use
cases
coming
to
consensus
on
them
and
documenting
them.
Clearly
and
I
suggest
that
work
before
we
have
that
is
problem
is
likely
to
be
premature
work
and
to
need
to
be
backed
out
vision.
D
A
I
could
shine
into
one
second
before
we
dig
too
much
into
this
problem,
which
I
think
is
really
important.
We
have
three
or
four
other
items
on
the
agenda
that
will
directly
touch
this,
so
I
would
like
us
if
people
are
okay
with
it
to
move
forward
with.
You
know
the
process
of
landing
these
pr's
and
revisit
the
specific
discussion
when
we
hit
the
points
in
the
agenda
that
that
have
to
do
with
it
sure,
okay,
awesome
and
thank
you
CJ
for
raising
those
points.
A
A
Do
see
Michael
you
had
just
made
a
comment
about
forgot
to
push
I'm,
not
sure
what
that
means,
but
since
I
have
just
landed
this,
perhaps
this
needs
to
be
followed
up
with
an
errata
correction.
Thankfully,
that
is
covered
by
this
pull
request.
So
we
shouldn't
have
to
wait
for
the
next
meeting.
The
next
one
up
should
be
really
quick.
It's
number
34.
It
is
indeed
errata,
which
was
a
Poe
request
to
change
the
Google
Hangouts
to
zoom.
Are
there
any
concerns
with
us
landing?
This
I
will
take.
A
The
silence
is
the
ability
to
land
it.
We
have
landed
it
so
now
that
we
are
there
up
next
on
the
agenda,
we
have
an
issue
in
a
pull
request
that
are
paired
together.
The
first
is
an
issue
about
governance
and
membership
requirements,
and
the
second
is
a
pull
request
to
use
the
NNC.
You
team
sync
command
and
node
core
utils
to
update
our
readme
to
represent
the
current
state
of
the
organization.
So
for
a
quick
update
on
context.
A
A
It
is
possible
that
we
should
revert
that
decision
and
move
forward
with
keeping
everyone
as
members,
considering
that
we
have
had
no
problem
reaching
quorum
this
week
and
two
weeks
ago.
Perhaps
we
want
to
do
this
and
reevaluate
what
our
membership
requirements
are
so
I
leave
it
to
the
floor,
for
people
to
you
know,
discuss
and
make
suggestions.
A
Assuming
that
with
you
two,
so
we've
got
five
more
than
quorum
all
right
cool
earlier,
we
only
had
21
and
I'm
like
make
quorum,
barely
barely
mm-hmm,
and
that
was
that
was
genuinely
one
of
the
concerns
with
keeping
the
group
so
large
was
that
if
it
becomes
hard
to
reach
quorum
and
we
have,
for
example,
our
pull
request
require
quorum
to
to
land
one
meeting
with
a
quorum
could
block
pull
request
for
a
month.
Now,
with
that
being
said,
we
haven't
reached
that.
A
So
perhaps
it
was
premature,
so
perhaps
what
what
would
maybe
make
this
conversation
move
a
little
bit
faster,
considering
that
we
have
things
set
up
right
now,
do
people
object
to
landing
this
poll
request
as
it
currently
exists
and
does
anyone
who
is
on
the
call,
who
is
moved
to
an
observer
status,
have
an
issue
with
having
been
moved
to
an
observer
status
or,
alternatively,
is
anyone
who
is
not
an
observer?
Have
a
problem
with
other
members
of
the
group
being
moved.
I
If
something
unavoidably
prevents
someone
from
attending
a
meeting,
you
know
what,
with
time
zones
and
personal
lives
and
stuff,
it
may
be
tricky
for
everyone
to
actually
make
every
meeting
so
I'm.
You
know
III
if
it.
If
the
PR
Lanza's
is
that's
fine,
but
it
might
be
worth
considering
a
more
comprehensive
criteria
for
participation
than
somebody
was
on
a
call
for
an
hour.
Every
two
weeks
and.
A
B
Muted,
so
in
our
quorum
pure,
we
actually
did
have
a
timeline
mandated
for
how
quickly
we
can
merge
pillars.
So
maybe
that
addresses
your
concerns.
I
would
go
reread
it
if
it
doesn't
address
your
concerns
about
the
timeline
and
missing
a
meeting
and
things
landing.
I
think
a
follow
on
PR
could
probably
amend
that,
but
that
will
require
quorum.
Okay,.
A
J
J
Okay,
not
forgetting
to
you,
I,
definitely
think
that
the
current
list
of
observers
is
was
generated
in
a
unfortunate
fashion.
Like
I
was
on
that
note,
Diagnostics
workshop
work
working
group
meeting
like
many
others,
and
it
was
really
hard
to
keep
track
of
the
module
stuff
that
was
going
on.
J
Basically,
everything
was
happening
during
that
time
as
a
there
really
a
group
of
note
collaborators
that
just
did
have
little
chance
to
actually
correctly
act
on
the
doodle
and
on
the
first
meeting,
so
I
think
that
that
decision
point
for
moving
stuff
to
people
to
observe
us
was
not
a
great
one.
So
I
would
much
rather
undo
that
decision,
then
to
now
quotation
marks,
bother
people
so
that
they
need
to
reach
out
wait
a
couple
of
weeks
and
then
maybe
get
reinstated.
It
seems
like
a
weird
process.
J
A
A
K
Yeah
I
think
there
is
some
usefulness
in
not
having
to
rely
on
people
who
are
not
attending
meetings
in
the
voting
and
like
I
like
the
idea
of
moving
people,
if
they
don't
participate
for
a
given
amount
of
time.
If
they're,
given
the
ability
to
rejoin
which
I
like
I
think
is
the
important
part,
maybe
we
can
keep
people
on
the
team
but
like
if
someone
has
not
attended
like
let's
say
two
meetings
and
I
hasn't
left
a
comment
like
explain
it.
K
We
can
not
count
them
towards
the
voting
like
towards
the
quorum
in
in
like
in
meetings
until
they
attend
again
or
leave
a
comment
explaining.
It
would
like
very,
like
unoffensive,
maybe
way
in
which
people
can
still
participate
like
a
smashes
day,
they're
able
because
I
realized
like
we
all,
have
busy
schedules
and
still
not
have
to
rely
on
them
when
voting.
Okay.
F
I
was
just
gonna
add
to
Jan's
comment
like
I.
Think
my
suggestion
would
be
one
or
two
things:
one,
either
completely
reverse
it
or
if
it's
gonna
be
something
where
we
want.
A
confirmation
of
some
sort
of
would
just
be
send
an
email
to
the
list
saying.
Do
you
wish
to
continue
as
long
as
you
get
an
answer?
Just
they
move
back.
A
A
A
What
excellent
thank
you
and
I
think
building
on
that?
What
I'd
like
to
propose
if
everyone
is
on
board
I
would
like
to
make
a
proposal
that
we
do
not
land.
This
poll
request.
We
move
everyone
who
was
moved
to
observers
back
to
collaborators
and
we
in
the
issue
tracker
think
about
a
way
in
which
we
can
have
some
sort
of
attendance
or
some
sort
of
engagement
policy
and
have
a
PR
that
we
aim
to
open
before
the
next
meeting,
so
that
we
can
discuss
that
Jeremiah.
You
have
your
hand
up
yeah,.
L
A
I
think
what
that
means
regarding
quorum
is
that
we
have
the
same
like
since
that
PR
had
not
landed.
Yet
officially,
we
counted
all
of
the
members
for
quorum
today.
Quorum
for
future
meetings
will
involve
all
41
members,
so
quorum
would
be
21
people
for
future
meetings.
If
we
find
ourselves
in
a
position
where
that
is
a
problem,
then
we
can
escalate
when
we
get
there
is,
is
my
personal
thought.
A
Okay,
considering
that
there's
no
objections,
I'll
take
the
action
item
of
closing
that
out
fixing
the
administrative
stuff
with
the
with
the
groups
and
submitting
a
new
poll
requests.
I
would
like
to
ask
everyone
that
is
here:
can
we
reach
consensus
that
we
can
land
this
poll
requests
without
waiting
for
the
next
meeting?
I
would
like
to
have
that
list
of
members
updated
as
soon
as
possible
and
and
not
have
to
wait
two
weeks
to
be
up
to
date.
So
does
anyone
object
to
us
landing
this
new
poll
request
without
waiting
the
two
weeks.
A
Excellent,
thank
you
very
much
and
I
think
this
is
a
really
great
example
of
how
our
process
is
a
guideline,
but
not
law
and
in
in
the
future
I'd
like
to
implore
others
to.
Similarly,
you
know
request
of
the
group
if
you
think
that
things
do
not
add
up
properly
so
I'm
gonna
go
ahead
and
and
erase
the
use
nuc
to
sync
team
members
from
the
agenda
and
we'll
move
on
to
the
next
item.
I'd,
like
the
time
box.
A
M
Hello
sure
so,
basically,
as
I've
gotten
involved
with
this
I've,
noticed
that
the
community
as
a
whole
seems
to
be
very
disengaged
from
what's
going
on
here,
I
mean
as
this.
These
conversations
have
been
going
on
for
over
two
years,
and
people
still
seem
like
it's
very
hard
to
follow
these
things
between
OD
peas
and
all
those
other
things
so
I
found
building
on
this
es6
modules,
nodejs
repo,
which
is
that's
linked
in
my
issue,
basically
maintaining
something
similar
with
the
same
level
of
introduction,
etc.
M
B
During
the
EP
process,
we
did
actually
try
to
maintain
a
wiki
thing,
but
every
every
idea
of
how
to
do
Interop
kind
of
it
became
a
dumping
ground.
So
if
we
do,
this
I
could
probably
write
books
on
this.
Multiple
I'd
prefer
we
limit
it
in
some
way.
So
we
only
focus
on
very
select
few
things,
I'm
also
a
little
bit
concerned
that
we
have
some
people
not
wanting
us
to
discuss
information
yet
so
that
seems
in
conflict,
and
we
should
address
that
before
making
such
a
website.
N
So
Tim,
you
have
your
hand
up
just
a
quick,
qualms
and
kind
of
echoing
what
he
was
Brian
was
saying,
I
think
I,
don't
know
who
is
just
speaking
to
Bradley
sorry,
yeah,
just
I.
Can
we
kind
of
off
of
that?
What
I've
seen
on
a
lot
of
specs
is
just
an
FAQ
where
it's
like.
Why
did
you
not
use
private
why'd?
You
use
a
hash
symbol.
Can
we
just
have
like?
Maybe
a
quick
go
to
just
looking
up
the
common
things?
Why
do
you
have
to
use
MJS?
Why
can't
the
browser
parse?
O
I
would
second
Bradley's
comment
that,
like
leaving
leading
the
website
until
we've
come
to
like
and
a
decision
about
how
we
want
to
implement,
everything
is
probably
for
the
best
I
think
having
a
guide
to
the
decisions
that
were
made
accorded
after
after
that
process
is
done.
Is
would
be
excellent
that
contains
things
like.
Why
did
we
do
this
hurt?
Why
did
we
do
that?
It's
mostly
a
like
sequencing
thing.
If
we
try
to
capture
as
we're
working
on
it,
then
we'll
have
people
hop
into
the
conversation
with
like
sort
of
a
date.
B
Want
to
clarify
that
I
have
a
disagreement
with
what
Chris
said.
So
maybe
I
was
misunderstood
and
I
want
to
clarify
I.
We
did
reach
consensus
in
the
past
during
the
EP
process.
So
what
we
are
discussing
I
think
we
should
go
over
the
scope
of
the
team,
the
goals
and
stuff
I.
Don't
actually
think
we're
going
to
get
to
implementation
discussion
for
several
months,
because
I'm
going
to
want
to
go
over
everything
before
them,
so
we're
still
on
the
months
before
I
even
want
to
try
to
make
such
a
website.
B
O
A
One
thing
that
I
do
want
to
add
really
quickly,
and
then
you
know,
Chris
or
or
Brad
or
Gus.
You
may
have
thoughts.
Do
you
think
that
it
makes
sense
for
us
to
start
thinking
about
where
we
want
that
site
to
live?
Maybe
how
that
site
will
be
designed
starting
to
put
together
copy,
or
do
you
think
that
that
is
all
at
this
point
like
really
premature,
I,
guess
you
have
your
hand
up
yeah.
M
I'm,
the
website
wasn't
really
like
a
priority.
I
just
know
it's
the
previous
person
who
had
been
maintaining
this
had,
you
know,
thought
to
generate
a
website.
It's
really
like
a.
We
can
just
point
some.
If
we
just
have
like
a
you
know,
a
markdown
file
in
our
repo
I
think
that's
absolutely
good
enough
to
carry
us
all.
The
way
to
you
know,
implementation,
if
necessary,.
E
And
so
I
there
is
a
need
in
the
ecosystem
by
the
community
to
know
the
status
of
this
and
what
type
the
problems
that
we
are
facing
and
and
so
on
so
I
think
a
document
where
at
least
we
list
the
problems
and
together
with
the
our
goal
document
like
those
things
together,
can
kind
of
represent
our
our
approach.
If
there
is
somebody
willing
to
maintain
it
and
keep
going
because
that's
that's
also
a
very
odd
thing:
okay,
but
subjected
to
the
same
process
of
our
quorum
and
so.
A
One
thing
that
that
I
would
just
like
to
suggest
is
maybe
kind
of
a
partway
point.
The
TSC
didn't
update
on
modules
that
I
helped
draft,
maybe
about
two
months
or
so
ago.
Now,
maybe
three
would
it
perhaps
make
sense
to
as
a
as
a
team
draft
a
similar,
a
similar
document
that
at
least
says
you
know
what
are
the
knowns?
What
are
the
known
unknowns
like?
Q
Think
it's
a
good
idea.
The
problem
is
that
if
we,
we
also
discussed
that
as
people
requests,
then
we'll
we'll
have
basically
two
discussions.
One
on
the
issue
at
hand
and
the
other
on
the
interpretation
of
that
in
that
community
document,
so
I
think
it
will
slow
us
down
so
as
much
as
I
want
that
I
think
it
will
close
them.
Wes.
H
Yeah
I
just
wanted
to
say
that
like
stating
what
is
and
what
isn't
is
almost
less
important
than
the
rationale
for
why
what
is
and
what
isn't?
Because
that's
where
the
stumbling
point
when
we
have
discussions
and
new
people
come
into
those
discussions
and
so
including
that
in
such
a
document,
is
very
important.
In
my
opinion,
okay.
C
Jeremiah,
yes
or
Wes,
said
so:
I
think
it
might
be.
Maybe
okay
for
us
to
to
like
do
an
addendum
to
what
the
TSC
put
out
as
a
first
step
and
basically
point
to
okay.
We
have
a
working
group.
That's
discussing
these
things.
We
have
this
goals
document
and
the
I
don't
like
high
level
objectives,
whatever
we're
calling
it
that
that
stuff
might
be
good
to
put
out
there
in
that
fashion.
I
think,
okay,.
A
A
Okay,
so
the
next
three
items
are
all
kind
of
you
know
part
of
the
same
thing.
The
first
is:
what
is
the
scope
of
the
team?
The
second
is
like
what
our
guiding
design
principles
are
and
then
the
third
is
a
pull
request
that
was
open
for
our
initial
goals.
There's
been
a
lot
of
conversation
around
that
I
would
like
to
scope
this
conversation
to
ten
minutes,
as
we
do
have
a
pull
request:
encore
for
ESM
mode
flag.
A
D
Absolutely
I
apologize
in
advance
for
my
voice,
which
is
quite
bad.
Today,
I
suggest
a
little
bit
of
a
reset
of
the
goals
process,
I
see
in
the
goals
document
a
lot
of
assumptions
about
implementation
and
I
think
we
are,
as
a
group
of
engineers
falling
far
too
quickly
into
implementation
discussion,
which
is
very
tempting
and
very
delicious
trap
for
us
all.
I
would
like
us
as
a
group
to
back
up
a
little
bit
and
take
a
more
user
centric
approach.
D
I
would
like
us
to
talk
about
the
use
cases
that
we
wish
to
support
for
node
users
using
modules
to
do
things.
This
might
start
with
a
simple
the
listing
of
the
use
cases.
The
commonjs
supports
that
we
wish
to
continue
supporting
with
the
SM
and
then
a
list
of
use
cases
in
the
up
in
Interop
that
we
think
our
users
are
likely
to
encounter.
D
This
focuses
us
on
the
problem
we're
actually
solving,
which
is
how
node
users
are
going
to
use
ESM
to
get
work
done
with
node,
to
write
javascript
programs
and
this
implementation
and
I
found
when
I
did
this
exercise
with
one
set
of
answers?
You?
Don't
have
to
be
the
answer
to
the
script
regions,
but
the
implementation
falls
out
fairly
straightforwardly
once
we
have
user
focus
and
I
would
like
the
goals
document
to
start
with
that,
I
think
it
that
will
be
a
revealing
discussion.
That
will
focus
us
quite
well.
E
Yeah
I
completely
agree
with
CJ,
with
one
big
note
and
which,
to
some
extent,
will
create
some
friction
in
that
process.
There
is
a
speck
as
much
as
I
my
personal
opinion
on
respect.
If
it's,
whatever
that
doesn't
matter,
we
have
a
speck
okay.
So
this
patch
gives
us
a
little
bit
of
leeway
or
now
implement
things,
okay,
but
a
lot
of
things,
a
lot
of
a
lot
of
the
behaviors
and
big
date
and
bye-bye
this
packet,
okay.
E
So
that
is
if
we
want,
if
we
start
with
with
that
approach,
there
is
a
central
point
of
view.
We
will
end
up
with
babel
modules.
As
far
as
I
am
concerned:
okay,
we
listen
to
to
two
users
and
what
they
want
right
now
and
what
they
would
create.
Less
friction:
okay,
I'm
just
I'm,
just
noting,
because
it's
there
is
I'm
okay
with
the
approach,
but
with
this
belief
that
this
bad
government
should
be.
B
Okay,
I'm
gonna
keep
these
very
brief
and
I'm
not
going
to
go
into
detail
on
them,
because
we
have
a
lot
of
hands
up
so
I
just
want
to
bring
a
few
discussion
points
that
when
we
talk
about
user
centric
goals,
I
do
want
those
to
be
the
case
in
our
goals
document.
We
should
remove
anything
that
is
implementation
specific,
that
we
cannot
isolate
to
a
use
case.
So
I
agree,
we
should
add
use
cases.
We
should
remove
any
goals
that
are
absolutely
only
about
implementation
details
and
do
not
map
to
a
use
case.
B
I
would
like
also
to
kind
of
discuss
that
when
we
are
talking
about
user
centric
things
I
don't
want
to
talk
purely
about
how
commonjs
works.
I
want
to
talk
about
how
web
browsers
work
because
we're
trying
to
work
in
a
system
where
people
are
using
this
module
system
in
multiple
ecosystems.
We
cannot
mandate
any
action
by
web
browsers
in
this
working
group,
but
I
want
to
even
table
the
fact
that
we
might
have
user
centric
cases
where
we
intentionally
are
not
as
compatible
with
common
jeaious
for
a
different
future.
I
I
This
has
been
touched
on
a
few
times
in
this
call
it'll
be
great
to
be
able
to
have
a
comprehensive
resource,
either
now
or
eventually,
to
point
people
to
to
explain
why
things
are
the
way
they
are
and
use
cases
is
probably
the
best
way
to
I
think
draw
it.
You
know
to
explain
that
and
also
to
inform
our
implementation.
The
one
thing
I
wanted
to
comment
on
was
she
said.
I
The
word
reset
use
cases
have
been
motivating
like
years
of
module
discussions
already
so
I
would
you
know
I
would
see
it
more
of
as
a
review.
It's
great.
We
should
definitely
enumerate
them
and
make
sure
we
haven't
forgotten
any,
but
there's
plenty
of
use
cases
that
the
current
like
use
cases,
what
drove
the
current
state
of
things,
and
so
as
long
as
we
can
review
those
as
well,
then
I
I
think
will
end
up
in
a
very
good
place.
Okay,.
D
Think
if
you
have
a
link
to
nodes,
current
modules,
use
cases,
nodes
use
cases,
not
the
browser's.
These
cases
I
would
be
absolutely
delighted
to
redo
that
I've
have
not
managed
to
find
such
a
thing.
I
note,
however,
that
the
spec
is
a
living
document
and
many
people
here
are
part
of
tc39
and
part
of
the
specification
process.
The
spec
absolutely
has
to
shape
how
we
implements
and
what
we
end
up
doing.
D
D
Think
node
is
important
enough
to
JavaScript
now
to
justify
a
little
pushback
if
we
need
it
and
I
would
encourage
us
to
use
that
in
cases
where
we
think
it's
really
going
to
pay
off
for
our
users
and
otherwise
to
stay
with
the
spec
as
it
stays
now,
we
we
the
end.
We
have
to
be
a
server-side
JavaScript
program.
That's
what
note
is
so
we
have
to
solve
that
problem.
Keep
the
eyes
on
it.
Thank.
A
J
Super
quick,
I
think
kind
of
echoing
what
other
people
have
said,
but
I
really
would
like
us
to
not
necessarily
focus
on
how
to
rename
able
college
assimilation
and
more
like.
If
we
think
about
use
cases,
they
should
be
more
common
than
people
do
something
with
comment
yesterday.
It's
let's
react,
replicate
that.
R
Hi
so
I'm
kind
of
here
coming
from
the
web
point
of
view
and
I
just
wanted
to
basically
echo
what
CJ
just
said
that
you
know
a
lot
of
us
in
the
chrome
and
other
browsers,
I
think
are
trying
to
think
about
how
to
make
modules
more
usable
and
ergonomic
on
the
web
than
they
are
now
and
I
think
you
know.
Hopefully,
one
of
the
goals
here
is
to
generate
feedback
towards
that
process,
like
as
we
develop
proposals
to
expand
module
support
on
the
web.
R
C
A
A
So
if
we
whoever's
taking
notes,
you're
gonna
need
to
scroll
up
quite
a
bit,
but
the
guy
has
a
pull
request
that
he
wanted
to
discuss
around
ESM
mode
flag.
It's
open
right
now
and
ready
for
review
guy.
If
you
could
try
to
keep
this
to
around
five
or
seven
minutes,
we
also
have
one
for
Lin
around
importing
labs
and
modules
that
I'd
love
to
get
to
before
we
wrap
up.
S
Sure
so,
I'm
just
posting
a
link
to
a
Google
presentation.
I,
basically
I've
been
working
on
this
PR
trying
to
get
towards
a
place
where
we
can
have
a
flag
based
Interop
for
modules,
and
this
has
kind
of
come
out
of
a
number
of
wrong
pods
that
are
proven
that
they,
you
know
from
the
various
proposals.
This
is
what
has
kind
of
been
etched
out
as
sort
of
what's
left.
If
that
makes
sense,
we
already
have
users
today
using
common
jeaious
importing
common
J's
from
ETS
modules.
S
A
S
Wondering
where
I
went
full
screen
there,
okay
yeah,
so
you
can
go
into
the
next
slide
Minh.
So
it
builds
on
the
previous
proposal
when
we
first
had
MJS
and
we
were
potentially
losing
the
jeaious
extension
for
the
ecosystem,
Jay
Perman
and
Cara
Dee
and
I.
Think
yahuda
wrote
this
proposal
in
defense
of
Jay
s
and
that
kind
of
triggered
this
module
field
that
is
now
used
quite
widely
in
the
ecosystem,
where
people
a
module
name
and
then
Martin
Heidegger,
who
is
in
this
group
I,
don't
think
he's
here
today.
S
S
So
if
we
use
the
module
property
as
a
sort
of
a
flag
as
well,
there's
confusions
about
what
you're
learning
so
and
then
there's
also
sorry
I,
don't
really
have
enough
time
to
go
through
all
the
details
on
these
points
in
five
minutes
to
be
honest,
but
people
can
can
read
those
details
and
it
was
a
little
bit
more
time.
So,
basically,
the
idea
is
to
simplify
it
even
further
and
just
have
a
mode
as
a
flag.
So
this
way
you
can
tell
if
a
J's
file
is
an
es
module
or
a
common
J's
module.
S
S
They
can
potentially
be
shared
with
the
common
Jayesh
resolver
as
well,
and
that
then
it
allows
the
sort
of
external
information
to
tell
you
is
the
package
containing
J's
files
that
contain
years
modules
or
common
J's
modules,
and
we
avoid
all
the
problems
that
we
had
with
things
fragments
trying
to
detect
from
the
syntax
and
all
the
other
detection
methods
that
were
difficult.
So
it's
a
simplification
of
what's
come
before
and
just
trying
to
whittle
it
down
to
something.
That's
that's
fairly,
straightforward
to
explain.
S
I,
know,
I'm,
explaining
it
pretty
badly
at
the
moment,
but
hopefully
gets
the
gist
we
can
head
on
to
the
next
slide.
So
it
really
is
it's
it's
an
approach
to
allow
us
to
keep
js4
in
that
that
can
easily
be
distinguished
between
J's
files
that
are
years
modules
and
J's
files
that
are
common
J's
modules.
S
S
So
that's
packages
that
want
to
updates
from
common
J's,
yes,
modules,
consumers
of
those
packages,
don't
need
to
change
the
way
that
they
use
those
packages
in
if
they're,
already
importing
it
as
a
common
J's
module,
so
they're
importing
with
import
syntax
common
tests
and
then
the
package
of
jetzt
es
modules.
The
the
author
can
just
add
this
flag
and
export
a
default
that
has
the
same
shape
and
then
the
user
doesn't
have
a
breaking
upgrade
path.
S
S
The
two
major
concerns
that
I
can
see
for
it
are
resolver
performance.
Is
it
a
problem
doing
all
these
package.json
lookups?
We
already
do
package.json
lookups
when
looking
up
the
main
poor
resolution,
so
per
package
loaded,
we're
looking
at
maybe
one
to
two
extra
FS
stat
calls
and
then
also
what
are
those
failure
cases.
So
if
a
user
tries
to
import
something
and
it's
actually
common
jeaious,
they
can
get
a
reference.
S
Error
requires
not
to
bind
I
guess
whatever
approach
we
use,
there's
going
to
be
the
failure
cases
so
just
trying
to
think
through
those
four
locations
and
then
I'll
skip
the
the
last
slide.
But
there
is
a
path
towards
getting
to
a
place
where
the
mode
ism
could
actually
be
something
that
isn't
necessary
in
future.
Where
we
could,
we
could
sort
of
switch
the
default
if
we
can
get
package
managers
onboard
and
that's
what
I
wanted
to
bring
it
up
now,
because
I'm
really
interested
to
hear
what
the
NPM
folks
think
on
this
one.
A
S
Or
yes
right,
so
one
of
the
important
things
about
this
is
that
build
tools
already
work.
This
way,
people
already
import
common
Jess
from
ES
modules,
so
by
codifying
a
way
that
they
already
do
this
and
making
it
possible
in
a
way
that
node
can
do
while
working
with
the
spec
I
think
that's
gonna
help
the
ecosystem
in
terms
of
making
builds
feeling
continued
to
work.
A
I
So
the
implementation
part
I've
already
commented
on
the
PR.
The
overarching
comment
I
want
to
make
is
that
I
don't
want
us
to
proceed
too
rapidly
or
I
would
like
to
not
see
us
proceed
to
rapidly
in
a
way
that
assumes
that
there's
only
two
module
systems-
CJ
s
and
the
SM,
considering
that
there's
Wisie
modules
coming
in
the
future
and
possibly
HTML
modules
and
other
kinds
so
I
want
us.
It
would
be
great
if
we
were
cautious
about
having
too
small
a
view
of
the
future
when
we
ship
things.
Okay,.
P
We
should
probably,
as
a
group,
be
discouraging
more
changes
to
modules
in
core
I
I.
Think,
since
the
whole
point
of
this
working
group
is
to
rework
that
possibly
having
continuing
work,
there
seems
like
a
with
it.
At
least
it
needs
to
be
communicated
to
the
people
who
are
providing
work
there,
that
if
they
are
not
having
the
discussions
here,
that
they
they
may
end
up
overridden
in
the
future
and
it's
what
it
becomes
wasted
work
and
that
would
feel
feel
very,
very
bad.
If
you're,
that
contributor.
B
Want
to
make
the
counter-argument
that
I've
spent
more
than
four
actual
years
trying
to
work
on
this,
so
I
think
there
is
something
to
be
said
about
stopping
work
that
might
be
wasted,
but
at
more
than
four
years
mark
already,
I
expect
things
to
take
a
very
long
time
and
I
expect
there
to
be
wasted
work
and
we
get
rewards
for
wasted
work.
We
get
to
see
the
actual
problems
of
use
cases
that
aren't
satisfied
that
we
thought
would
be,
and
we
also
get
to
see
you
know,
there's
an
implementation
problem.
B
Q
O
Say
hi
every
time
so
I'd
like
to
make
a
distinction
here
well
I
think
we
would
like
to
see
so
some
of
us
would
like
to
see
maybe
a
reset
of
goals
like
them
and
make
sure
that,
like
we're
going
through
and
fulfilling
our
user
goals
here,
I,
don't
think
that
means
that
we
don't
want
concrete
implementations.
I
think
it's
important
to
write
this
code
and
to
have
an
a
working
example
of
it.
O
So
we
can
sort
of
model
what
it's
like
to
use,
but
I
think
the
thing
that
I
take
I
object
to
is
merging
into
node,
because
that
kind
of
signals
that
like
this
is
what
we
were
planning
to
do.
I
wholly
encouraged,
getting
like
implementing
these
things
and
having
builds
available
for
people
to
play
with
in
advance
of
a
decision
being
made,
because
that
will
help
inform
the
decision.
B
Think
we
can
bring
that
up
to
node
itself
when
we
charter
or
something
but
for
now,
I
completely
disagree,
because
we
did
have
consensus
in
the
past
at
least
so
I
I'm,
I'm
kind
of
torn
about
it.
But
I
don't
know
I,
don't
want
that
reset,
which
is
exactly
what
it
sounds
like
people
are
wanting
to
do
by
making
all
the
previous
things
that
have
been
discussed,
moved
out
of
Cour
moved
back
to
the
starting
point.
B
A
A
One
thing
I
want
to
just
add
really
quickly.
We
have
run
over
by
five
minutes.
I
want
to
just
suggest
I.
Think
what
we've
gotten
to
the
heart
of
here
is
a
conflict
and
a
conflict
for
this
group.
To
make
sure
that
everyone
in
here
is,
you
know
feeling
like
they're.
What
they're
working
on
is
going
to
be
figured
out.
That
note
is
not
going
to
move
ahead,
ignoring
what
this
group
is
doing,
but
people
who
are
doing
work,
who
don't
want
to
feel
like
I'll
rephrase
it.
A
We
have
a
lot
of
opposing
viewpoints
and
all
of
them
are
completely
valid.
I,
don't
think
we're
gonna
solve
this
in
the
next
five
minutes.
I'm
gonna
open
an
issue
specifically
to
discuss
how
we
can,
as
a
group,
come
to
a
place
that
we're
comfortable
with,
and
you
know
this
is
going
to
be
a
somewhat
uncomfortable
conversation,
but
I
think
that
we
need
to
come
up
with
ground
rules.
A
It's
also
something
the
project
is
gonna
have
to
agree
to
as
well,
because
as
it
is,
we
are,
we
are
just
a
team
right
now
we're
not
chartered,
and
so
I'm
gonna
I'm
gonna
get
guys
last
point
in
and
then
we
should
wrap
up,
but
I
just
want
to
say,
like
you
know,
I
think
everyone
here
has
really
really
valid
points,
and
you
know
finding
the
compromise
here
where
no
one,
no
one
feels
like
they're
spinning
wheels
is
kind
of
where
we're
gonna
find
success.
Guy.
S
So
certainly
from
a
discussion
point
of
view,
there
can
be
a
lot
of
value
in
trying
to
have
fresh
discussions
against
these
things,
even
if
things
have
been
rehashed
many
times
going
through.
Those
discussions
again
can
never
lead
to
problems,
especially
when
you've
got
all
the
right
people
together.
S
The
other
thing
I
wanted
to
just
quickly
mention
was
that
on
that
PR.
The
current
model
in
in
node
is
that
if
there's
no
disapprovals
that
something
can
get
merged
and
I
haven't,
had
any
really
critical
feedback
of
this
approach,
and
that's
why
I
wanted
to
bring
it
to
this
group,
because
by
seeking
that
feedback
from
from
the
wider
group
here
that
has
such
differing
opinions,
I
was
hoping
that
we
could
start
a
larger
feedback
process
about
it
and
I'm,
not
gonna
I'm,
not
going
ahead
with
merging
it
at
all.
S
E
And
so
I
just
want
to
say
that
it's
a
it's
very
important
that
whenever
a
PR
in
core
against
the
SM
is
is
raised,
you
should
we
should
tag
the
team,
okay
and
ever
chance
to
everybody
to
know
that
that's
going
on,
because
watching
core
is
impossible.
Okay
tell
somebody
on
the
TSC
its
completing
possible
you,
you
can't
keep
up.
That
is
too
much
too
much
activity.
So
I,
don't
know
somebody
does,
but
it's
they're
superheroes.
E
So
it's
it's
very
important
that
the
team
is
stacked,
so
people
can
actually
complain
okay
or
say
no.
This
should
be
discussed
in
a
meeting
or
something
and
for
sure
the
PRI,
presumably
I
will
not
be
landed
and
the
the
feedback
will
be
valued
even
if
the
person
does
not
making.
It
is
not
elaborate.
Okay,.
A
Ass
in
the
tail-
and
you
know
Rebecca
to
your
comment
that
you
have
in
the
chat
what
I'm
probably
going
to
propose
in
the
issue
that
I
open
is
that
perhaps
we
have
a
feature
freeze
in
the
meantime.
Well,
this
group
is
figuring
out
what's
going
on
and
we
could
discuss
that
in
the
issue
and
the
implementation
of
this
because
yeah
finding
the
balance
here
is
gonna
is
really
important.
So
we
are,
we
are
10
minutes
over.
I
cannot
be
as
proud
of
running
a
tight
ship
this
meeting,
but
we
got
through
a
lot.