►
From YouTube: Node.js Foundation Modules Team Meeting 2019-03-27
Description
A
Okay,
we
are
live
on
YouTube
with
the
March
27th
meeting
of
the
node.js
module
steam,
we're
joined
by
13
different
members,
including
12
voting
members.
So
we
have
an
overwhelming
amount
of
consensus
going
on
at
quorum,
hopefully
consensus
as
well,
so
with
that
Freudian
slip
out
of
the
way,
let's
chop
right
into
things
we
have
we,
we
have
for
those
of
you,
following
along
at
home,
an
implementation
upstream
that
we're
working
on
with
the
phase
2
implementation
that
we've
reached
consensus
on
within
the
group.
A
Changed
has
been
changed
to
entry
type
to
be
more
explicit
to
the
behavior
that
exists
right
now,
which
is
that
with
that
flag,
we
only
change
the
behavior
for
like
how
we
assume
a
module
is
when
we,
when
we
try
to
run
it
with
node,
it
doesn't
make
any
sort
of
recursive
changes
to
subsequent
imports.
We
have
a
bunch
of
things
on
the
agenda
about
digging
into
that
behavior
and
maybe
changing
it.
But
are
there
any
objections
to
the
change
that
we
made
to
making
an
entry
type.
A
Okay,
cool,
so
there's
no
objections
to
moving
forward
with
that.
The
other
one
was
the
upstream
objection,
including
M,
without
digging
too
much
into
it.
The
simple
thing
that
we
did
for
right
now
is
just
assume
we
do
not
have
consensus
on
m,
we
removed
it
from
the
current
implementation
and
we
can
revisit
adding
m
as
an
alias
and
a
follow-up
PR.
Does
anyone
have
any
problems
with
with
that
substantive
change.
B
A
Now
the
only
other
thing
in
the
upstream
bit
that
got
changed
kind
of
into
zero
is
our
right
now
and
Jeff
and
I
were
commenting
on
it
is.
There
was
a
request
from
upstream,
because
we
renamed
type
2
entry
type
to
rename
the
type
per
type
mismatch
error
to
our
entry
type
mismatch,
which
itself
is
maybe
not
entirely
accurate
because,
as
Jeff
pointed
out,
it's
possible
that
this
would
throw
based
on
other
cases,
I
did
change
it,
based
on
the
upstream
request
and
I
figure
that
this
is
an
easy
thing
for
us
to
iterate
upstream.
C
D
E
A
Yeah
so
there's
an
error
called
earth
type
mismatch
which
throws,
when
you
have
a
mismatch
between
the
type
itself
and
the
the
type
that's
passed
to
type
or
the
type
that's
in
the
package.json
and
what
you're
importing
and
how
you're
using
it
I
believe
that
that's
only
for
the
entry
point,
but
there
there's
like
subtlety
to
it.
That
I
think
I
think
the
argument
is
that
neither
name
is
really
entirely
accurate.
A
B
A
Okay
cool,
so
with
that
being
said,
then
I
think
we
can
move
on
from
that
item
and
move
on
to
the
next
agenda
item,
which
is
tracking
upstream
PR.
This
is
just
a
really
really
quick
one,
just
as
a
heads-up
to
everyone.
What
I
have
done
is
what
was
originally
in
our
fork
about
like
30
to
33,
commits
I
folded
down
into
about,
like
I
think
was.
Maybe
10
commits
to
make
reviewing
a
bit
easier.
Those
commits
kind
of
changed
over
the
last
two
weeks
as
we
made
specific
changes
as
of
today.
A
A
co-author
Jeffrey
booth
is
the
co-author
and
Michael's
a
so
is
a
co-author.
Those
are
all
the
individuals
who
had
explicitly
like
sent
commits
our
people.
Okay,
with
that,
should
we
add
everyone
from
the
team
as
co-authors,
potentially
or
I.
I
was
kind
of
keeping
it
to
the
people
who
actually
had
substantive
code
that
went
in
there.
Does
anyone
object
I'll
just
make
it
really
simple
and
I'll
drop
that
commit
into
the
chat
right
now?
Does
anyone
object
to
the
commit
that
I
just
posted
landing
on
nodejs
master.
A
Ok,
cool
we've
done
it.
The
the
PR
has
no
current
upstream
objections.
It
has
a
conversation
of
a
hundred
and
ninety
different
messages
and
it's
currently
sitting
with
one
two,
three
four:
five:
six
seven
upstream
approvals,
including
multiple
TLC
members,
I,
have
one
last
CI
job,
that's
running
right
now,
which
hopefully
may
even
wrap
up
before
the
end
of
this
meeting,
in
which
case
I
will
screen,
share
and
ceremoniously
land
the
commit,
and
we
can
all
celebrate
with.
That
being
said,
congratulations
everyone!
We
have.
We
have
done
the
first
bit.
A
A
E
A
Let's
just
get
to
the
names
that
were
listed
in
there,
because
those
are
people
who
had
commits
that
got
squashed
in
I
think
that's
pretty
fair,
so
kind
of
the
first
thing
I
wanted
to
get
into
here
is
what's
next
for
the
team,
so
the
first
bit
that
I
want
to
kind
of
bring
up
is
the
moratorium
and
I
would
like
to
propose
that
we
drop
the
upstream
moratorium
for
right
now.
We
now
have
these
changes
that
have
landed.
A
It's
highly
highly
likely
that
there's
going
to
be
quick,
iteration
that
we're
going
to
want
to
do
especially
leading
up
to
12
for
bugs
that
are
found.
I
personally
make
a
pledge
to
not
allow
large
substantive
changes
to
the
implementation
itself
through
without
bringing
it
to
the
team
to
discuss
it.
But
I
do
think
now
that
we
have
landed
these
changes
and,
for
the
most
part,
part
the
work
that
we've
done
on
the
fork
has
been
up
streamed.
A
C
F
C
A
Think
just
gets
into
a
bit
of
a
deeper
question
for
us
and
have
about
the
role
of
this
team
moving
forward.
So
you
know
I
think
it
goes
without
saying
that
there
has
been
friction
the
last
couple
weeks
in
kind
of
getting
this
over
the
finish
and
I
personally
have
been
a
little
bit
disappointed
with
the
way
in
which
things
have
had
to
move
enabled.
You
know,
in
order
for
us
to
reach
some
degree
of
consensus.
A
Perhaps
this
discussion
about
the
moratorium
is
part
of
a
bigger
conversation
about
what
is
our
role
as
a
team
moving
forward
now
and
what
are
the
expectations
so
perhaps
without
me
kind
of
airing
the
conversation
in
a
particular
direction,
based
on
on
my
bias
to
the
team
itself,
so
those
of
you
have
been
doing
the
work
and
want
to
continue
doing
the
work.
What
do
you
think
the
role
of
the
module's
team
should
be
now?
C
You
had
your
hand
up
yeah,
so
he
has
two
things
that
with
that
clarification
and
I'm
Jeffrey
your
next.
So
the
first
thing
is
with
that
clarification
like
I,
that's
just
how
the
work
is
done
like
or
which
github
repo
is
done
in
or
whatever,
and
when
I,
when
I'm
thinking
a
moratorium.
I'm,
not
thinking
of
nothing,
can
land
and
master
as
much
as
I'm.
Thinking
of
it
would
be
ideal
if
the
modules
team,
as
by
whatever
process,
we've
already
deemed
fit
we're
required
to
approve
of
any
modules
changes
in
master.
C
Happening
has
been
in
good
faith
right
so
and
that's
I
realized
that
by
not
being
charted,
the
moratorium
is
essentially
a
gift
that
no
decor
has
given
us
I'm
saying
it.
Could
we
perhaps
ask
for
a
similar
gift
of
pretending
were
chartered
until
you
know,
there's
a
reason
why
we're
not
so
that
we
don't
have
to
iterate?
You
know
Fork
we
can
iterate
in
core
but
continue
I
guess
that
kind
of
leads
into.
My
second
point,
which
was
the
original
question
of
like
the
role
of
group
moving
forward.
C
That
typically
represents
a
larger
constituency
and
it's
useful
to
have
that
feedback,
and
even
even
if
we
get
better
at
not
having
not
being
lone
objectors
or
we
get
better
at
persuading
lone
objectors
and
so
on
and
so
forth.
But
so
I
think
it
would
be
a
loss
if
this
group
did
not
continue
to
contribute
those
perspectives
and
the
and
support
and
represent
those
users
and
use
cases
moving
forward,
regardless
of
where
the
work
is
done
and
regardless
of
charter
status
and
so
on.
C
B
C
B
I,
don't
have
something
so
abroad
is
not
to
say:
I
was
just
gonna
say
like
my
only
concern
about
this
would
be
like
I
think.
That's
some
value
that
this
group
adds
is
debating
design
decisions
like
how
we're
gonna
handle
Interop,
how
we're
gonna
handle
file
extensions.
You
know
all
those
types
of
things
and
like
if
anyone
just
starts
throwing
pr's
against
core
to
change
things
with
with
regards
to
ESM
it.
B
We
have
no
idea
that
it's
gonna
be
within
the
like
design
parameters
that
we
have
in
mind
or
that
we've
fought
so
hard
to
reach
a
consensus
on
so
I
guess
that's.
My
question
is
like:
is
there
some
way
we
can
kind
of
limit
the
scope
of
like
if
we
drop
the
moratorium?
Is
there
some
way
we
can
limit
the
scope
of
like
no
that
doesn't
fit
into
the
plan
or
something
like
that.
A
So
I
mean
a
few
things
that
I
can
think
of
right
off
the
top
of
my
head
as
a
way
of
like
working
so
just
kind
of
like
reviewing,
what's
in
the
modules
of
the
modules
refill
itself
right
within
our
I.
Believe
it's
in
our
governance
talk
right
now.
It
says:
consensus
seeking
process,
merging
PRS
into
this
repository
or
nodejs
second
script
modules,
and
this
is
kind
of
what
we're
talking
about
it
says
this
month.
This
is
not
applied
to
Noches
core.
It
only
applies
to
the
modules,
repo
and
expert
modules.
A
Pull
requests,
not
included
under
the
special
exemptions
below,
must
reach
consensus
any
meeting
in
order
to
be
merged
into
the
repository.
The
special
exemptions
were
a
rata
editorial
meeting,
minutes
updates
to
the
team,
doc
fixes
tests
and
fixing
rebased
conflicts.
So
we
didn't,
for
example,
in
there
have
bug
fixes.
We
didn't,
for
example,
in
there
have
aramis
exchanges
or
other
type
things
I
think
that,
like
overall
I
guess
what
I'm
suggesting
is
that
we've
removed
the
nodejs
/xo
script
modules
bit
from
here
altogether.
A
We
pare
down
the
special
exemptions
to
be
other
changes
to
the
modules
repo,
which
is
much
more
about
like
our
processing
governance
and
a
lot
less
and
about
what
we
reach
consensus
on
about
what
we're
going
to
work
on,
and
perhaps
what
we
could
even
do
is
make
it
as
simple,
as
the
request
could
be
a
moratorium
on
not
straying
from
our
main
dock,
which
is
like
the
phases
dog.
Would
people
be
okay
with
that,
as
perhaps
an
intermediary?
A
So
we
have
this
plan
for
new
modules,
implementation
we
have
phase
3
and
in
phase
3
is
pretty
explicit
about
the
things
that
we
have
consensus
on
as
well
as
what
we
need
to
reach
consensus
on.
So
perhaps
what
we
could
do
and
like
we
could
do
this
between
now
and
the
next
meeting
is-
and
maybe
the
moratorium
actually
could
be
even
more
explicit.
A
Please
don't
land
anything
that
is
related
to
the
things
that
need
consensus
in
our
dock
and
I.
Think
it's
pretty
reasonable
to
assume
as
well.
That,
like
the
number
of
members
that
we
have
in
this
group,
that
have
commitments
upstream,
will
act
in
good
faith,
just
as
Gus
says,
put
a
red
X
on
pr's.
That
perhaps
are
not
in
line
with
this,
and
we
could
wait
between
meetings
to
handle
those
things
that
are
that
are
kind
of
out
of
line.
E
Okay,
I
just
want
to
mention
really
quickly
so
I'm,
not
sure.
If
that
really
answered
Jeffrey's
questions,
so
I
want
to
do
it
a
little
bit
more
directly.
So
nerdcore
doesn't
really
have
a
way
of
owning
like
a
subsystem
in
in
that
kind
of
way
where
you
can
wear
it
like
it
needs
to
go
through
like
separate
process
per
se.
E
You
can
do
that
with
with
working
groups,
but
it's
still
a
little
hand
wavy,
and
we
can
well
there's
things
well,
naturally
evolve
a
little
bit
of
our
kind
of
like
the
idea
is
that
we've
had
over
over
a
long
period
of
time
pretty
much
regardless
of
what
we
do.
But
you
know,
there's
people
also
like
are
also
gonna
like
respect
the
people
that
come
in
and
and
contribute
the
code
and
talk
about
things
and
all
the
issues.
H
There's
a
PR
happening,
and
we
are
not
aware
is
not
the
same
thing
as
being
aware
and
choosing
to
be
okay
with,
and
not
even
you
know,
have
a
anything
to
object
about
or
bring
to.
You
know
to
the
attention
of
the
core
team
working
on
the
PR,
like
just
keeping
us
in
the
loop
in
a
structured
way
is
something
that
I
cannot
imagine
how
it's
gonna
pan
out
when
we
change
some
structure
and
I'm
concerned
about
that
part.
H
A
I
mean
that's
it
so
what
you're
saying
they're
like
and
then
Gus
you
can
chime
in
next
generally.
The
way
the
Corps
works
is
people
are
constantly
triaging
a
barrage
of
issues
and
pull
requests
that
are
coming
in
and
adding
the
teams
that
are
experts
in
that
space,
and
it
is
highly
unlikely,
but
it
is
possible,
but
it
is
highly
unlikely
that
something
would
go
through
on
the
tracker
that
involves
ESM.
That
would
not
add
modules.
A
It's
just
like
you
defer
to
the
experts
in
a
space
and
if
it
added
modules,
all
of
us
would
get
a
pang
and
I'm
sure
that
if
it
was
something
that's
controversial
myself
or
Gus
or
guy
or
any
of
you
that
have
the
ability
to
would
put
a
clear
red
X.
If
this
is
something
the
team
should
talk
about,
and
that
is
a
little
bit
more
in
line
right.
How
upstream
currently
works
even
for
things
that
are
not
necessarily
working
groups
so
like
just
for
there
with
me,
while
I
give
a
small
example.
A
There's
a
v8
inspector
team
with
five
members
and
if
something
came
in
that
was
a
pull
request
against
inspector.
That
team
is
getting
added
just
because
we
want
the
people
who
are
considered
to
be
the
experts
to
be
chiming
in
and
not.
Everyone
on
that
team
is
necessarily
always
a
member
of
core.
But
there's
kind
of
just
this
unspoken
expectation
that
those
that
are
will
make
sure
that
they
are
operating
in
good
faith
and-
and
this
isn't
a
huge
difference
from
how
we
have
done
things.
A
H
A
For
example,
if
we
can
work
from
where
we
are
right
now
to
Phase
three
a
ton
flag
and
not
have
you
know
the
kind
of
conflicts
and
problems
that
are
arisen
to
get
to
phase
two
I
would
be
more
confident
and
it
doesn't
even
mean
we
need
to
get
there
and
I
want
to
apologize.
But
that
is
a
very
carrot.
Stick
model
of
doing
it,
and
that's
not
my
intention
but
I'm.
Just
trying
to
like
set
really
clear
like
goals
of
things
we
could
do
and
it's
possible
that
we
get
there
sooner.
A
Another
thing
would
be
potentially
re-examining
our
governance
and
restructuring
our
governance
to
be
one
that
works
for
this
problems.
Based
on
this
group,
for
example,
I
was
recently
informed
about
governance
methodology
known
as
rough
consensus.
The
idea
with
rough
consensus
is
that
if,
as
a
group,
we
cannot
reach
consensus
on
an
issue,
we
try
to
figure
out.
If
we
have
rough
consensus,
which
is,
then
you
have
a
separate
conversation
about.
A
And
so
there
may
be
really
a
possibility
that
we
explore
new
governance
models
that
allow
us
to
handle
some
of
these
consensus
problems
that
we
have
had
and
to
be
honest,
these
are
problems
that
exists
in
kind
of
all
groups
that
have
lots
of
different
people
with
different
needs,
and
you
know
it
could
be
really
cool
if
we
couldn't
go
and
start
like
exploring
rough
consensus
as
a
model
documented
as
governance
start
doing
it
and
find
hey.
Actually,
we
can
get
through
all
these
decisions
that
used
to
be
extremely
contentious
and
make
it
work.
A
I
would
feel
totally
totally
confident
in
chartering
us
and
not
only
that
I'd
probably
go
and
take
this
idea
of
rough
consent,
so
we
can
bring
it
back
to
court
and
be
like
hey.
Is
this
a
model
we
want
to
explore?
In
fact,
we
may
even
go
to
tc39,
who
has
had
constantly
consensus
issues
and
say:
hey?
Is
this
something
you
want
to
explore?
It
doesn't
mean
these
other
groups
would
want
to
do
it,
but
I
mean
like
for
me
to
feel
comfortable
chartering.
A
There's
a
document
that
I
can
send
us
other
people,
and
perhaps
perhaps
we
want
to
explore
a
different
consensus
model
as
a
group,
because
perhaps
it
has
just
been
our
governance.
That
has
also
failed
us,
because
consensus
seeking
as
a
whole
is
fairly
rigid
and
in
a
space
we
were
talking
about
this
over
lunch.
Today.
Modules
is
one
of
those
things
where
it's
like.
You
change
one
small
thing
and
the
calculus
for
everything
else
changes.
A
So
it's
it's
really
hard
to
maintain
consistent
consensus
and
it's
really
exhausting
when
you
need
to
just
consistently
be
riveted,
revisiting
things
and
relitigated
things,
but
it's
also
impossible
to
kind
of
avoid
it.
So
I
think
there
was
a
really
long-winded
way
of
saying
we
can
do
better
and
I
think
that
we
can
and
I
inflected
upwards
on
by
is
that
answer
your
question
fill
up.
Oh
definitely,.
H
A
And
perhaps
maybe
a
way
of
framing
this
and
it's
a
kind
of
just
last
comment
here:
he
was
thinking
about
PRS
from
people
outside
our
group
and
he's
fine.
What
I
proposed
the?
Perhaps
we
can
direct
out
people
who
aren't
part
of
the
group
to
open
an
issue
in
modules
if
it
had
involves
kind
of
changing
the
proposal.
A
Perhaps
what
we
can
think
of
ourselves
as-
and
this
is
just
a
framing-
is
stewards
of
the
roadmap
and
if
things
stray
from
that
roadmap,
that
is
when
we
as
a
group
get
together
to
make
sure
that
we're
augmenting
the
roadmap
to
map
to
match
the
changes
that
are
happening.
Is
that
something
that
people
feel
comfortable
with.
B
C
But
like
yeah,
but
but
but
I
think
that
the
larger
that's
implementation
details
the
roadmap
as
it
you
know,
which
to
me
describes
be
like
future
plans
as
well
as
semantics,
as
well
as
the
implications
of
decisions
like
that's
the
sort
of
thing.
I
think
we
should
be
directing
and
stewarding
as
you
put
it.
Okay,
cool
I.
A
B
A
More
explicitly
knock
the
rough
consensus
side
of
things
more
than
updating
to
reflect
kind
of
the
new
non
moratorium
that
we're
discussing.
So
we
need
to
update
the
governance
documents
to
no
longer
refer
to
atmospheric
modules,
and
we
need
to
likely
change
what
the
scope
is
and
document
that,
like
changes
that
are
in
line
with
the
roadmap,
don't
require
our
group
to
intervene.
Is
there
anyone
who
would
like
to
take
on
kind
of
documenting
that
okay
I'll?
Do
it.
A
H
A
A
Thank
you
all
for
kind
of
you
know,
listening
and
being
open
to
feedback
and
being
mature
about
the
iterations
here,
I'm
feeling
really
positive
about
the
direction
that
we're
pointing
towards
so
the
first
issue
that
I
wanted
to
bring
up
for
us
to
discuss
today,
because
this
is
one
that
is
time
sensitive,
is
locking
down
the
process
and
buffer
Global's
guy.
Do
you
want
to
introduce
this.
D
Yeah
we've
discussed
it
times
before
so
I
had
a
PR
up
on
node
core
and
a
approach
that
works
to
deprecate.
These
Global's
within
Eggman
script
modules
only
and
what
we
did
to
just
kind
of
get
something
through
when
now
was
just
pushed
up,
making
the
process
and
buffer
Global's
guesses
in
node.js,
which
is
effectively
just
about
the
the
breaking
change
part
of
that
entire
proposal.
D
A
A
China
and
then
Jordan
has
a
question.
I
just
quickly
took
a
pee,
a
peek
at
canary
in
the
gold
mine,
and
it
does
not
appear
like
there's
any
ecosystem
breakages,
at
least
in
our
smoke
testing.
Suite
related
to
this,
it
looks
like
and
I'm
just
double-checking
that
in
general,
the
breakages
that
we
were
seeing
are
the
same
ones
for
like
there's
no
difference
between
the
breakages
on
master
412
and
changing
these
two
objects
into
getters,
also
just
kind
of
like
some
historical
context
for
people
we
have
made
several
major
changes
before
that
have
landed.
A
A
C
C
Kept
the
process
global
out
of
esm,
while
we
worked
on
deprecating
the
SE
of
the
dangerous
parts
so
that
we
could
put
a
process
without
the
dangerous
parts,
any
SM
like
I
would
be
fine
with
that
plan
to
I.
Just
think
that
it
would
be
a
wiser
long-term
thing
to
persist.
The
process
global,
but
individually
addressed
the
unsafe
parts.
A
C
Totally
to
make
any
few
Tricia
yeah
and
I'm,
not
a
I,
don't
I
have
because
spiritual
concerns
about
the
PR
because
of
the
direction
it
implies,
but
not
because
of
that
specific
PR.
The
what
the
PRA
is
evolved
into
is
something
that
does
not
trigger
the
concerns
that
I
have.
It
is
initial
form
it
did
yeah.
B
C
So
I'm
not
suggesting
that
that
PR
not
be
merged
or
anything
like
that,
but
I
would
really
encourage
guy.you
in
particular,
but
the
group
in
general
and
the
TSC
you
know
there
are
the
collaborators
on
the
call
to
consider
the
very
potentially
wide-ranging
ecosystem
impacts,
not
just
in
node
but
in
browser
bundles
that
have
relied
on
processes.
Existence
to
make
websites
work
and
documentation,
as
well
has
pointed
out,
like
I,
think
that
that's
just
a
really
like
it's
a
really
fundamental
core
thing
to
strip
off.
C
D
These
are
firstly
web
sites
that
expects
much
more
backwards
compatibility
and
there
it's
it's
running
code.
This
change
does
not
affect
any
running
code
in
the
wild
no
exist.
A
J's
code
is
affected
by
this
change.
It's
only
the
pneumo
and
that's
kind
of
the
whole
point
is
that
we
can
jump
on
to
these
these
new
semantics.
It's
a
great
point
that
Jordan
raises
about
the
process:
environment,
checks,
process,
toad
environment,
that
node
environment.
D
It's
not
even
is
he
at
the
breakfast
table,
and
these
are
the
sort
of
checks
that
we
can
think
about
doing
once
we
create
our
own
person's
label,
that's
different
in
ism.
That
is
a
new
object
that
just
has
the
bare
minimum
like
test
our
platform
and
then
it's
a
secure
process.
That's
or
we
could
do
things
like
have
imported
metadata
from
import
and
then,
if
you
do
direct
equality
with
it,
you
can
X
against
that
or
import
that
meta
dot,
node
environments
and
these
kinds
of
things
I
can
see.
D
Wesley
is
typing
away
here
about
the
point
I
made
about
things
that
are
really
written
as
yes,
module
syntax
that
relies
on
process.
I.
Think
we
can
accept
that
there's
gonna
be
some
kind
of
first
some
kind
of
stage
where
code
that
previously
like
one
example,
is
the
module
field
and
package.json
a
whole
bunch
of
things
expected
to
work,
and
it's
not
gonna
work
and
that's
something
that's
gonna
have
to
hit,
and
people
are
gonna
have
to
hit
that
and
realize
it,
and
unnamed
exports
is
another
one.
D
A
A
H
Yeah,
so
just
before
we
move
on
I
think
it
would
be
very,
very
fair
to
say
that
this
group
has
to
come
up
with
an
agreed
approach,
moving
forward
for
simplex
detection
of
node
in
ESM,
without
relying
on
process
also
I'd
like
to
a
second
guy
mentioning
that
is,
does
not
break
CJ
s
in
the
wild
today.
Definitely
I
attended
the
SES
presentation,
I
looked
into
it.
H
A
A
F
A
Only
hesitation
that
I
have
with
it
is
that
there
are
people
who
are
running
things
in
production,
potentially
on
11
that
are
relying
on
ESM
and
even
though
we
have
said
yes,
this
can
change
at
any
time.
The
difference
that
we're
talking
about
is
like
a
certain
number
of
weeks
and
I
think
that
it
might
be
better
to
not
pull
the
rug
out
from
underneath
people
at
the
very
least.
We're
gonna
have
another
11
release
before
then
and
I.
Think
I
would
like
this
to
bake
on
master
a
little
bit
beforehand.
C
Things
it's
useful
to
pull
the
rug
out
for
people
and
remind
them
that
that's
what
experimental
means
like
not
capriciously
but
like
this
is
ours
yeah!
It's
fine
and
it's
way,
like
you
know,
more
versions
of
node
will
have
the
ability
for
people
to
experiment
with
the
latest
implementation.
Yeah
waiting,
a
release
for
it
to
bake
seems
fine
to
me
too.
Okay,.
A
A
B
C
B
A
I
I
think
we
should
just
end
on
this
positive
note.
I,
don't
know
if
there's
too
much
more,
that
we
can
really
dig
into
Jeffery
was
talking
about
the
tight
stuff
and
how
we
all
have
opinions
I
think
we
should
maybe
try
to
do
an
out-of-band
neck
meeting
next
week.
People
have
time
Jeff.
Would
you
like
to
maybe
make
a
doodle
for
that
and
open
an
issue.
B
Yeah,
if
I
could
just
say
one
thing
about
that,
that's
you
know:
I'm
surprised,
no
one
or
not
surprised,
I'm
glad
no
one
from
upstream
blocked
on
it,
but
there
were
several
comments
on
the
upstream
PR
of
people
confused
by
it
and
not
in
it
not
behaving
the
way
they
expected.
So
I
think
we
need
to
address
that
one
way
or
another,
and
so
yeah
I
think
we
should
have
a
meeting
dedicated
to
that
and
figure
out
what
we
want
to
do.
I
think.
C
H
Can
we
distill
that
feedback
next
week
and
make
it
so
that
when
we
get
user
feedback
were
able
to,
you
know
validate
what
we
heard?
What
Jeffrey
is
concerned
about
I
think
it
you
know
framing
what
we
would
expect
this
user
people
that
can
help
us
actually
look
for
the
right
to
user
feedback
in
the
right
way.