►
Description
A
We
are
now
live
on
YouTube
with
the
March
4th
2019
out-of-band
node.js
modules
team,
extended
meeting
to
resolve
resolution
of
extensions,
we're
joined
by
nine
members
of
the
team.
Right
now
we
are
just
shy
of
one
voting
member
for
quorum.
I
will
try
men
if
someone
else
joins
and
we
reached
quorum
in
the
meantime
to
kind
of
get
people
up
to
date
on
where
we're
at.
A
We
had
been
recently
going
through
figuring
out
what
an
implementation
that
we
would
be
comfortable
up
streaming
to
node.js
core
would
look
like
I've,
just
posted
a
link
to
that
in
the
chat
here,
but
it's
HTTP,
github
comm,
no
GS
modules,
blah
blah
blaster.
Actually,
you
know
what
I
could
do
really
quickly.
Let
me
go
ahead
and
just
share
that
screen
with
everyone.
Just
bear
with
me
for
one
second:
okay,
just
making
sure
I'm
not
leaking
anything.
A
Okay,
so
this
is
the
plan
for
the
new
modules
implementation.
We
have
now
three
phases
before
we
had
four
phases.
The
biggest
changes
here
were
phases,
zero
and
one
kind
of
being
broken
out
to
see
how
we
got
to
the
minimal
kernel
phase
to
fleshing
out
everything,
that's
needed
for
us
to
upstream
the
implementation
and
phase
three
being
everything
that
we
will
do
on
that
upstream
implementation
in
order
to
drop
the
experimental
flag.
A
A
Although
there's
some
other
patterns
that
works,
exploring
defining
semantics
for
when
to
load
sources
as
command-j
Asturias
modules,
this
is
also
using
the
file
specify
our
resolution
proposal.
This
is
introducing
type
field
into
the
package.json.
Oh
we've
got,
we
got
Salah,
we
did
it
and
Gus
okay,
so
we've
got
quorum
for
what
it's
worth.
Oh
we've
got.
We
got
quorum,
yay,
then
defining
semantics
for
enabling
ESM
treatment
of
source
code
loaded
via
about
Sdn
and
extension
lists
extension
lists
files
both
with
and
without
shebang
lines.
A
Click
through
and
this
landed
in
accra
script,
modules,
pull
32
and
then
there's
kinds
of
loaders
is
here
right
now,
although
you
know,
if
we
have
time
during
this
call,
we
may
dig
into
that
because,
as
I
said,
we
have
quorum,
there
may
be
a
different
path
will
take
there,
but
specifically
the
one
that
we
have
highlighted,
that
we
really
need
to
dig
into
and
find
consensus
on
is
add
or
decide
not
to
support
file
extension
and
directory
index
search
and
in
ESM.
Then
we
have
a
variety
of
things
that
are
inside
of
Phase
three.
A
Those
have
been
deemed
out
of
scope
for
the
upstream
implementation,
but
definitely
things
that
need
to
be
sorted
out
between
now
and
when
we
remove
the
flag
for
the
sake
of
keeping
things
simple.
Let's
just
not
dig
into
this
today,
although
those
are
you
know
they're
to
have
so
we
have
this
thread,
which
is
a
long,
intense
debate
and
discussion
I
mean
by
the
by
our
team
standards.
It's
actually
not
that
long.
A
A
I
want
them
to
be
able
to
play
with
it
to
be
able
to
see
what
works
and
what
doesn't
and
I
also
want
to
be
able
to
have
responses
from
the
community
to
let
us
know
how
much
or
how
little
they
they
want.
This
feature,
which
I'm
sure
we
will
hear
from
people
once
this
lands
and
they
get
their
hands
on
it
and
get
to
play
with
it.
A
My
concern
is
that
if
we
do,
if
we
just
don't,
have
it
in
there
at
all
so
no
flag
and
no
implementation
that
we're
not
giving
people
any
sort
of
opportunity
to
experiment
and
actually
play
with
this
workflow
or
else.
Alternatively,
if
we
put
it
in
without
a
flag
I,
don't
think
anyone
will
actually
experiment
with
the
workflow
without
the
extension
searching.
B
Hi,
okay,
so
I
had
a
couple
thoughts,
while
you
were
talking,
one
was
most
of
the
controversy.
Typically
is
around
things
that
are
defaults
and
not
so
much
capabilities,
so
I
suspect
that
if
we
all
were
convinced
that
it
did
not
alter
the
likelihoods
of
what
would
ship
as
default
and
what
would
not
that
it
would
be
completely
uncontroversial
to
ship
extension
resolution
behind
a
flag.
B
However,
because
I
think
it
does
alter
the
calculus
of
what
you
know,
what
what
gets
shipped
behind
flags
does
alter
the
calculus
of
what
is
likely
to
be
shipped
by
default
or
not
so
I
think
that
that
may
be
the
difficulty
there.
The
other
question
is
if,
if
we
shipped
extension
resolution
off
by
default
and
on
with
a
flag-
and
you
think
that
will
encourage
both
experimentations,
but
you
think
that
shipping
it
on
by
default
and
off
with
a
flag
would
not
say
people
would
not
experiment
with
the
flag
version.
A
That's
expect
expecting
the
the
flag
to
be
on
and
I
think
one
of
the
things
that
we
you
don't
have
as
a
disagreement
is
how
much
people
really
want
that
how
much
work
flow
that's
going
to
break,
and
you
know
whether
or
not
it's
going
to
be
totally
controversial.
So
I
think
you
know
to
that
point
that
you
were
asking
about
what
people
would
choose.
A
My
gut
is
that
we
don't
really
know
and
to
me
off
by
default.
Upstreaming
seems
to
be
make
the
most
sense.
I
also
think
that
there's
design
space
that
we
haven't
figured
out
yet
and
one
in
particular
being
dual
mode
modules.
If
we
ship,
as
it
is
right
now
with
file
extension
resolution
on
by
default,
then
we
are
shipping
with
a
method
of
doing
dual
imports
through
leaving
out
the
file
extension
in
the
main
field.
D
D
E
E
D
Base
to
fix
things
results
it
resulting
in
that
that
was
my
first
point.
Oh
you.
You
consider
that
to
be
unacceptable
or
reasonable,
I
I,
don't
know
what
other
workflows
it
exists
for
this,
but
I
found
it
to
be
close
to
unn
close
to
unacceptable,
like
I
mean
obviously,
I
was
able
to
do
it,
but
it
was
terrible,
terrible,
terrible.
A
A
My
concern
is
that
we're
gonna
get
extreme
pushback
from
the
community
and
potentially
even
upstream,
when
we
try
to
land
this
upstream
that,
like
it's,
just
not
acceptable
to
not
have
it,
or
you
know
like
really
really
strong
pushback,
similar
to
like
in
defense
of
j/s
and
some
of
the
other
stuff
I.
Think
shipping,
with
a
flag
early
on
makes
it
really
easy
for
people
to
opt-in
to
the
experience
they
want,
and
they
can
give
us
that
feedback
that
you
know
they
prefer
that
that
use
case.
A
The
flip
side
is
if
we
just
ship
with
it
on
I,
don't
think
that
we
will
be
able
to
get
that
feedback
and
I'm
I.
Think
that
that
that
doing
it,
this
way
is
an
opportunity
for
us
to
essentially
do
what
we
talked
about
doing
with
with
the
ecosystem.
Poles
that
we
weren't
really
able
to
be
super
successful
with
I.
Think
the
when
we
want
when
we
do
our
upstream
implementation,
we
will
kind
of
have
this
one
shot
to
do
kind
of
a
bit
of
a
bit
of
a
press.
A
A
I
actually
think
that
friction
is
a
feature
from
a
user
design
and
research
perspective,
because
it
will
give
us
that
explicit
feedback
and
if
we
do
it
and
we
find
that
we
have
tons
and
tons
of
pushback,
it
may
only
be
you
know
a
couple
weeks
when
we're
at
the
point
that
we
decide
to
maybe
remove
the
flag
and
make
it
the
default.
If
that's
the
direction
that
we
decide
to
go
Jay
Dalton.
G
H
I
A
So
we
definitely
could
do
some
digging
with
bigquery.
We
could
definitely
do
like
user
outreach,
there's
like
the
community
committee
that
does
their
user
outreach,
but
yeah
JD.
It's
it's
not
really
on
the
on
the
table
to
do
telemetry
right
now,
I
think
that
that's
a
great
thing
to
bring
up
and
discuss
upstream
but
I
think
any
sort
of
thing
like
that
is
going
to
be
controversial
and
require
lots
of
work
and
won't
really
work
with
our
timeline.
Oh
that's.
A
J
Yeah,
so
I
would
simply
caution
that
the
design
space
I,
don't
think,
is
quite
as
open
as
we
may
like
it
to
be.
So
what
I
mean
by
that
is,
there's
a
lot
of
different
choices
that
you
can
make
for
doing
resolution,
but
once
you
start
making
choices
that
make
it
similar
in
some
ways
to
the
current
resolution,
semantics
then
I
think
you'll
find
you
know
in
your
design.
B
So
what
are?
What
are
you
expecting
to
get
I
mean
the
I
can
imagine
that
one
outcome
could
be
a
bunch
of
people
complaining,
but
another
outcome
could
be
there's
a
bunch
of
people
saying
well.
This
is
fine.
My
workflow
is
not
impacted,
but
zero
of
them
like
it
doesn't
matter
how
many
of
people
say
their
workflow
is
not
impacted
that
doesn't
alter
in
any
way
how
many
people's
workflow
is
impacted.
So
I
guess
I'm
just
curious.
What
are
we
expecting
to
get
out
of
this
feedback
class
so.
A
My
my
my
intention
and
like
thoughts
here
would
be
that
we
would
see
how
strong
the
reaction
from
both
the
community
and
upstream,
is
you
know
if
you
looked
at
something
like
MJS,
for
example,
you
know
I
think
it's
extremely
clear
how
people
feel
about
it,
but
with
that
being
said,
as
a
group
we've
reached
consensus
that
it's
needed
for
our
design,
so
we've
moved
forward
with
it
anyways,
but
also
felt
found
ways
to
appease.
You
know
the
complaints
that
people
brought
forward
and
and
I
think
it's
pop.
It's
possible
and
I
think
this
is.
A
This
is
what
you're
alluding
to
that?
The
feedback
that
we
get
may
not
really
be
entirely
actionable,
but
I
do
think
that
it
will
be
give
us
more
information
to
work
on
than
what
we
have
today
and
we
may
see
also
positive
feedback
for
the
change
if
people
are
really
in
support
of
it,
so
I
think
I
think.
B
Right
but
but
no
amount
of
positive
feedback
will
change
the
fact
that
there
are,
it
will
change
the
number
of
people
that
complain
that
their
workflows
don't
work
and
it
doesn't
matter
how
many
people,
like
the
feature
being
off.
If
there
are
people
who
say
if
this
feature
is
off,
I
can't
get
my
work
done.
Yes,.
H
Okay
can
I
respond
to
that
sure
I
think
there's
also
people
whose
workflow
is
impacted
by
this
feature
being
on,
and
those
are
the
people
who
are
trying
to
use
NPM
modules
on
the
web
like
something
like
lo,
yes,
etc.
All
the
NPM
models
that
are
publish
to
the
web.
With
this
that,
therefore
can't
be
used
directly
in
a
web
ESM
environment
without
some
kind
of
build
staff.
You.
H
B
D
I'm
just
Jeffrey
so
about
this.
This
thing
where
there
could
be
like
some
future,
where
your
node
modules
can
be
served
directly
from
like
without
like
I,
don't
even
like
directly
off
a
web
server.
I,
don't
think.
That's
like
possible.
You'll
always
need
to
at
least
scan
over
your
node
modules
because
there
could
be
common
jsn
or
there
could
be.
You
know,
node
native
modules
in
there
I
don't
think,
there's
a
future
where
you
can
consider
node
modules
safe.
There.
D
I'm
jumping
yeah,
but
it's
there's.
It's
never
going
to
be
nonzero
they're,
like
750,000
modules
on
on
NPM,
and
so
there's
always
a
chance
you're
going
to
need
to
bundle
it
I,
don't
think,
there's
a
point
in
designing
like
pushing
the
ecosystem
into
this.
This
flow.
That's
never
going
to
be
possible,
like
I,
with
with
my
like
being
a
spec
person
hat
on
I
would
love
if
everyone
used
the
same
thing
but
as
like
a
node
user,
it's
just
like
impossible.
B
And
more
the
point:
I,
don't
think
it's
our
place
to
try
and
impose
that
change
on
the
ecosystem.
By
way
of
getting,
you
know
like
sneaking
that
in
alongside
a
new
module
system
like
that's
something
that
if
we
should
eat,
if
we
can't
persuade
to
everyone
like
a
critical
mass
of
people
to
go
in
that
direction
already,
then
it
probably
doesn't
deserve
like
first-class
support.
A
J
Right
yeah,
so
the
feedback
that
that
we
may
get
from
this
might
depend
on
might
depend
to
a
high
degree
on
the
messaging
like
around
it.
So
I
think
you
pointed
that
out
but
like
if
the
messaging
is
oh,
you
know,
we've
redesigned
module,
support
in
node
and
I
hope
you
like
it,
and
if
you
want
try
out
this
other
thing,
here's
another
flag,
I
think
we
can
kind
of
predict
that
they'll
take
a
look
at
it
and
they'll.
Compare
it
to
the
experience
that
they
get
with.
J
You
know
the
ESM
package
or
or
babel
and
they'll
feel
like
things
are
missing.
Based
on
that
comparison,
you
know,
and
I
was
kind
of
like
to
try
to
to
make
some
sort
of
attempt
to
get
away
from
that
comparison.
Was
you
know,
part
of
the
part
of
the
draw
up
to
to
create
the
web
modules
fir
note
idea,
which
is
like
telling
you
kind
of
telling
a
different
story
about
it
to
try
and
get
around
some
of
those
expectations.
J
C
Guy
yeah,
a
couple
of
things
perfectly
on
the
user
feedback
points.
I
think
it's
worth
noting
that,
as
as
you
mentioned
miles,
the
the
feedback
we
get
is
what
drives
this
decision
like
with
MJS.
It's
our
decision
as
a
group
how
things
go
forward
here,
but
the
point
is
that
we
will
have
more
information
at
that
time
when
we
make
that
decision-
and
there
are
many
other
factors
that
play
into
this
decision
and
to
to
state
a
strong
argument
like
gustas-
that
it
is
impossible
to
make
node
modules.
D
B
D
A
A
Anyway,
thank
you,
I
think
you
missed
the
point
that
I
was
trying
to
get
across
there.
It
was
not
about
how
one
package
does
it
or
how
other
we'll
do
it?
Who
is
that,
if
I'm
writing
code
locally
and
npm
install
the
module,
I
can
have
a
fallback
to
unpackage
to
allow
a
non
build
based
tree
that
just
works
for
the
modules
that
that
do
not
work
properly
due
to
local
dependencies.
A
D
Like
no,
your
app
does
not
need
to
bundle
to
be
deployed.
If
it's,
some,
someone
is
still
doing
the
bundling
for
these
packages
that
won't
by
default
working
here.
So
so
I
don't
understand
how
that
is
some
kind
of
like
getting
getting
rid
of
the
problem.
You've
just
pushed
the
problem
on
to
some
service
service,
yeah.
C
Get
back
to
my
point
as
well
there
when,
when
I
was
making
that
point.
My
point
was
that
it's
not
an
obvious,
it's
not
an
point
and
that
we
we
should
be
careful
when
dealing
with
such
a
complex
design
space
where
we're
moving
into
new
workflows
that
we're
all
working
out
collectively
and
these
workflows
are
being
worked
out
every
day.
New
things
are
happening
on
the
web
that
are
affecting
the
way
that
the
entire
ecosystem
is
going
to
work
and
to
deny
that
the
entire
ecosystem
is
shifting
is
also
a
mistake.
C
So
we
have
to
keep
an
eye
on
where
things
are
going.
We
have
to
keep
an
eye
on
where
things
are,
but
where
we
sit
in
the
middle
is
a
very,
very
difficult
thing
to
predict
and
I
guess.
The
point
is
that
we
will
have
more
information
in
three
to
six
months
time
to
be
able
to
fully
investigate
these
kinds
of
problems.
I'm
sure
I
mean
there's
projects
coming
out.
You
see
like
pika
things
like
that.
C
A
You
know,
I
I,
think
I,
think
that
choosing
to
put
it
on
does
make
certain
decisions
about
the
design
space
about
things
that
we
haven't
explicitly
figured
out
and
one
in
particular,
being
dual
mode
modules
and
so
I
think
that
including
it
behind
a
flag
for
this
iteration
and
keeping
it
very
very
clear
that
we're
exploring
that
this,
that
we
have
not
made
a
decision
that
it's
something
that
we
can
add
later
allows
people
to
experiment
with
all
of
the
different
workflows
and
allows
us
to
keep
the
most
design
space
open.
Sola.
I
Yeah
so
I'm
just
gonna
bring
one
example,
my
own
personal
experience
with
requiring
dot,
MJS
and
experimental.
So
the
way
resolutions
worked
with
a
loader
is
you
could
do
whatever
you
want?
You
could
bring
in
extension,
matching
you
could
do
whatever
you
want.
You
didn't
before
it
was
possible
to
do
that
in
experimental.
D
A
Okay,
I
personally
prefer
us
not
making
any
changes
to
that
loader
with
our
implementation.
It
seems
like
that
may
be
controversial
upstream,
but
that's
just
you
know
my
personal
opinion
on
it.
You
know
we're
40
minutes
into
the
meeting.
We
have
20
minutes
left
and
since
we
do
have
quorum
here,
it
would
be
nice
to
dig
into
some
other
stuff
if
it's
possible,
based
on
the
conversation
that
we've
had
do
we
have
consensus
on
moving
forward
with
with
this
behind
a
flag
for
the
upstream.
Does
anyone
object
to
that
as
an
approach.
B
A
But
this
will
be
kind
of
one
of
the
highest
priority
items
for
us
to
dig
into
and
I
think.
It's
also
like
cross
like
it's
interconnected
with
a
lot
of
thing
like
like
the
exports
proposal.
Jordan,
like
you,
are
extensions
resolution
proposal.
I
think
I
think
that
there's
kind
of
like
this
whole
other
wave
of
changes
that
we're
going
to
need
to
make
that
are
all
interconnected
here.
That
making
a
decision
on
this
in
particular,
will
inform
so.
B
Could
we
ship
two
flags,
one
that
explicitly
turns
the
resolution
on
and
one
that
explicitly
turns
it
off
and
that
way
like
that's
a
path
for
if
we
change
the
default,
anyone
who
depends
on
not
having
resolution
can
have
already
opted
into
that.
So
that
brings,
if
you
don't
pass
either
by
yeah,
then
then
it
would
be
the
default
which
at
the
moment
would
be
none
I
suppose
we
could
make
it
throw,
but
that
seems
unnecessarily
restrictive.
So.
B
B
H
B
H
A
I
was
just
asking
to
make
sure
because
I
think
it
would
be
probably
more
flexible
to
have
a
single
flag
with
multiple
options
than
multiple
fives
but
yeah.
Let's
kick
that
to
the
issue.
So
no
one
objects
to
us
moving
forward
with
this,
assuming
that
the
flag
that
we
choose
puts
things
on
at
least
an
equal
footing
from
a
from
like
a
compatibility
standpoint.
A
Excellent,
thank
you
all
so
much
for
being
very
reasonable
about
all
of
this.
I
we're
actually
going
to
ship
something
with
basically
no
votes,
which
is
like
absurdly
awesome.
The
last
thing
that
I
wanted
to
get
into
right
now.
If
people
have
time
in
the
last
couple
minutes,
is
there
was
kind
of
two
issues
that
got
opened
recently.
One
is
against
Eknath
script
modules,
and
this
is
a
whole
request
from
guy.
It's
specifically
number
47
I
just
dropped
that
into
the
chat,
and
then
we
can
also
talk
about
number
286
afterwards.
A
That
Brad
would
not
really
have
time
to
reflect
on
or
be
having
something
that
we
want
to
implement
that
we
don't
really
have
you
know
the
time
or
volunteers
to
implement.
So
what
we,
what
we
suggested
was
moving
the
new
loaders
implementation
to
phase
3,
and
we
have
this
that
removes
that
adds
back
the
old
loader
implementation
that
currently
exists
upstream,
but
will
introduce
an
extra
warning
when
you
use
it.
The
first
time
similar
to
like
using
FS,
not
promises.
That
kind
of
screams
at
you
and
says:
hey
you're,
using
a
deprecated,
loader
implementation.
A
It
will
be
replaced
so
that
you
know
people
know,
but
we're
not
breaking
current
workflows
that
people
are
using
that
way.
We
can
start
iterating
on
the
loaders
API
that
I
know
guy
and
Jana
and
Brad
and
people
have
been
implementing
and
working
on
without
rushing
it
or
without
kind
of
you
know.
I
just
want
to
make
sure
that
we
have
time
for
forgetting
the
right
consensus
around
it
before
we
change
things.
A
A
A
If
we
can
reach
consensus
around
this,
because
if
we
can,
we
may
be
in
a
really
really
great
place
to
meet
the
timelines
that
we're
talking
about
so
I
I
went
through
and
worked
backwards
from
the
targeted
release
date
of
V
12
to
come
up
with
hey.
What
should
we
do
and
what's
the
timeline
that
we're
looking
at
so
we
have
a
targeted
release
date
for
V
12
of
April
23rd,
based
on
that
I
set
April
11
as
a
go
no-go
date.
A
Essentially,
if
we
can't
reach
consensus
upstream
on
landing
it
by
April
11th,
it
likely
won't
be
able
to
go
in
12.
This
is
a
pretty
big
change
and
we
likely
want
to
have
enough
stuff.
You
know
enough
time
for
that
to
sit
before
landing.
I
said
a
target
date
of
April
4th
as
the
date
that
we'd
like
to
land
in
upstream
and
that's
based
on
April
20th
as
the
date
that
we
actually
open
it.
So
coming
rolling
back,
I
went
kind
of
backwards.
Let's
start
from
forward
today
is
the
4th.
A
This
is
say
that
marks
13th,
which
is
next
Wednesday.
We
should
have
everything
in
including
I
guess
the
two
pull
requests
that
we
talked
about
the
one
that's
open
right
now
to
reel-to-reel
and
loaders,
as
well
as
the
other
one
that
we
need
to
land.
Add
the
the
modules
and
we'll
get
down
to
like
exactly
what
needs
to
be
done,
but
that
essentially,
we
should
try
to
get
all
that
work
done
for
the
most
part
by
the
13th,
or
at
least
enough
by
the
13th
that
we
can
in
a
group
just
say
hey.
A
This
is
what
we're
sending
then
on
the
20th.
We
would
open
the
pull
request
upstream
and
begin
getting
reviews
that
the
27th
would
be,
which
would
be
our
next
modules
meeting.
We
could
review
the
upstream
concerns
if
necessary
and
come
up
with
a
plan
to
iterate.
That
would
then
give
us
until
April
4th,
which
is
the
following
date-
to
target
to
land
it
upstream
with
April
11th
a
week
following
that
be
kind
of
the
cutoff
date,
so
that
gives
us
more
or
less.
A
B
So
I
be
type
equals
es
m
or
mo
Deus.
Whatever
that's
called
now
that
thing
was
emerged,
but
I
tried
to
make
it
pretty
clear
during
that
that
I
still
wanted
a
more
general
solution,
and
it
would
be
great
if
we
could
include
some
can
agreed-upon
version
of
the
extensions
map
thing
I
posted
you
know
within
the
next
few
weeks,
but
in
general
the
dates
seem
fine,
I,
don't
know.
If
that's
something
you
want
to
talk
about
later
or
not
your.
E
A
A
We
can
still
add
that
I
see
no
reason
why,
if
it's
implemented,
if
we
have
consensus-
and
we
want
to
land
it
before
upstreaming-
that
we
couldn't
on
the
same
note,
I
see
no
reason
why
we
couldn't
upstream
without
it
and
then
immediately
iterate
and
try
to
get
it
in
as
soon
as
possible.
Afterwards,
because,
especially
once
we
have
that
new
implementation,
we
may
still
want
to
work
on
our
fork
to
reach
consensus
before
sending
things
upstream,
but
we
may
not
have
to
wait.
E
B
A
Imagining
a
couple
breaking
changes
between
now
and
then
I'm,
just
hoping
that
they
are,
you
know
at
a
faster
pace
and
a
faster
waterfall
than
we've
done
for
this
first
batch,
but
I
think
there
was
a
lot
of
consensus
seeking
that
we
needed
to
do
to
reach
here.
I
think
future
iterations
are
gonna
happen.
You
know
far
faster
than
the
iteration
cycle
that
we've
had
just
now.
A
That
appease
your
concern.
Hopefully
it's
fair
enough.
So
what
I
have
outlined
here
is
what
we
need
to
get
done
before
us.
Training
up
Street
streaming
has
finalized
phase
two
in
the
planning
document,
so
that's
sending
the
updates
from
moving
loaders.
The
update
for
how
we're
handling
extensions
and
moving
those
that
need
to
be
moved
to
phase
three
and
reaching
consensus
on
that
in
the
next
meeting,
so
Jordan
for
what
it's
worth.
Also,
if
you
think
that
we
need
to
add
this
to
Phase
two,
this
is
your
opportunity
to
try
to
do
that.
A
You
know
I
think
that
we
can
make
this
work
either
way,
though
we
needed
an
implementation
of
loaders
for
Phase,
two,
which
I
believe
we
have.
You
know
simple
requests
in
place
to
try
to
implement
and
I'll
add
those.
We
need
a
decision,
an
implementation
of
file,
extensions
which
I
think
that
we
reached
a
decision
today,
but
we
need
an
implementation
for
that
tool
and
we
need
to
update
all
the
documentation
to
reflect
the
latest
implementation.
A
A
We
need
to
do
a
final
code
tested
and
doc
review,
which
will
also
include
deciding
hey.
Do
we
want
to
squash
this
all
into
one
commit?
Do
we
want
to
break
it
up
into
multiple
commits
and
just
kind
of
figuring
out
what
the
final
you
know
what
we
actually
upstream
looks
like
in
keeping
it.
You
know
reasonable
from
a
review
standpoint.
We
want
to
we're
going
to
need
to
work
and
determine
the
messaging
around
the
upstream
p-pull
request
and
how
we're
going
to
be
presenting
it
to
the
team.
A
We
need
to
open
the
upstream
pull
request
and
we
also
need
to
write
copy
about
what
our
group
has
been
doing
and
all
the
current
progress
and
status
for
public
blog
posts
and
communications.
You
know
we
like
if
we
want
to
do
something
through
the
Foundation's
medium
will
potentially
want
to
like
tweet
about
this.
We
want
to
get
the
word
out,
so
you
know
we're
going
to
want
to
have
a
collective
message
that
we're
all
in
the
same
page
about.
B
A
B
A
H
So
I
think
that
we
we
already
had
the
PR
to
update
the
booth,
the
loaders
to
Phase
three
I,
think
that
the
planning
doc
then
needs
just
an
update
to
change
the
file
extension
resolution
thing
to
say
that
we're
adding
it
but
behind
a
flag.
Is
that
my
correct
and
some
assuming
that
and
if
I
were
to
put
put
up
such
a
PR,
you
know
I'm,
assuming
that
would
have
consensus
from
everybody.
That
seems.
B
H
B
B
A
A
Okay,
great
y'all,
we
literally
just
reached
consensus
and
although
we
did
kind
of
a
kind
of
up
before
it
was
then
I'm
gonna
pretend
that
vote
didn't
happen.
Cuz
it
didn't
really
affect
things
too
much.
We
did
it
without
without
votes.
We
did
it
with
consensus.
You
all
should
be
really
proud
of
yourselves,
because
we
all
have
a
lot
of
different
opinions
and
it's
required
everyone
to
make
concessions
and
to
work
within
everyone
else's
with
having
everyone
else's
stuff
in
mind,
and
you
know
this
is
easy
to
do.