►
From YouTube: Node.js Foundation Modules Team Meeting 2019-01-15
Description
A
We
are
now
live
with
the
January
15
2020
meeting
of
the
node.js
modules
team.
We
are
a
group
of
seven
people
are
on
the
call
right
now,
although
only
five
of
them
are
active
members
of
the
team,
meaning
that
we
do
not
have
quorum,
although
I
do
not
believe
that
that
will
block
any
of
the
decisions
or
discussions,
but
we'll
cross
that
bridge
when
we
get
there.
A
We
have
a
handful
of
things
on
the
agenda
today,
so
you
know,
let's
start
with
the
with
the
talk
work
our
way
down
and
then,
if
there's
extra
time
for
other
things,
we'll
add
it
as
we
go,
I
guess
one
thing:
yeah
we'll
get
to
it
well
of
time.
So
the
first
thing
that
we
have
on
here
from
upstream
is
3
1
2
to
9,
which
is
movie
SM
loaders
to
worker
threads.
This
is
a
work
in
progress
PR
by
Bradley
mech
who's,
not
on
the
call
right
now.
B
B
A
My
understanding
that
it
could
be
wrong
is
that
the
intention
was
always
to
move
this
stuff
to
the
worker
threads.
So,
barring
you
know,
like
any
strong,
read
not
too
I.
Think
from
like
a
performance
perspective
that
was
kind
of
like
a
long-term
goal.
So
if
there
are
things
in
the
implementation
which
don't
reconcile
with
that,
I
think
it
is
prudent
for
us
to
do
that
sooner
rather
than
later,
my.
C
D
A
D
E
Guy
to
you
yes,
so
we
discussed
this
one
last
week
deciding
if
this
is
an
api
that
we
want
to
start
shipping
as
an
experimental
API,
the
hesitation
to
shipping
something
straight
off,
but
I
believe
people
were
open
to
shipping,
something
that
applies
here
and
then
miles.
I
think
you
did
mention
that
you
were
possibly
going
to
see
if
you
could
follow
it
up
with
Dominic
and
I
had.
A
A
Dynamic
in
or
the
result
of
resolve,
and
whether
or
not
that
could
change
behavior,
which
seemed
like
an
inadequacy
in
the
import
map
proposal.
So
he
was
gonna,
go
back
and
look
at
that
and
we're
gonna
like
really
like.
Look
at
your
comment,
one
more
time,
because
for
those
who
are
following
the
the
idea,
would
be
import,
maps
were
kind
of
like
one-to-one,
so
like
the
thing
on
the
Left
maps
to
the
thing
on
the
right.
So
if
you
have
a
specifier
URL
on
the
left
and
maps
to
you
know
a
URL
on
the
right.
A
But
what
happens
if
that
URL
also
maps
on
the
left
to
another
different
URL
on
the
right,
I
think
based
on
the
way
the
import
map
spec
is
currently
like
symlink
cos,
but
I
think
that,
as
import
maps
are
currently
specified,
I
don't
think
it
follows
all
of
those
recursively
which
my
gut
is
that
it
should
the
important
map
spec
itself
should
so
like.
If
someone
something
on
the
left
is
mapped
to
the
right,
and
that
thing
on
the
right
also
has
a
mapping
from
the
light
left
like
it
should
be.
A
A
E
A
Yeah
I
think
staying
is
having
it
be.
A
sync
was
important.
We
did
not
get
into
the
implementation
details,
but
the
impression
that
I
got
was
that
as
long
as
it
was
by
behind
a
flag.
That
was
something
that
we
could
kind
of
like
hash
out
through
the
spec
process.
Just
like
you
would
with
anything
else
as
you
bring
more
stakeholders
to
the
table.
F
I'm
not
sure
if
I
posted
in
the
PRI
definitely
meant
to
I
do
have
some
concerns
about
the
second
argument,
especially
because
it
how
it
relates
to
loaders
doing
context-sensitive,
mapping
or
specifically,
not
mapping
of
URLs,
because
having
the
second
argument
means
that
during
resolution
you
cannot
do
access
control
because
anybody
can
impersonate
any
other
URL
doing
resolution
and
then
during
fetching,
we
currently
don't
pass
the
original
specifier
the
original
base.
So
you
can't
also
not
block
there.
E
F
A
F
A
Cool
looks
like
Wes,
had
some
good
comments
in
the
chat,
so
specifically
just
we
can
get
in
the
notes.
It's
about
string
path,
not
being
a
reliable
source
from
module
identity
and
so
yeah.
What
import
import,
meta,
resolved
path,
you're
gonna
like
resolve
twice
and
that
I
think
comes
back
to
the
concern
around
import.
A
E
So
yeah
we've
been
discussing
this
one
for
a
little
while
now
it's
from
the
previous
meeting,
where
we
had
just
merged
the
logical
conditional
ordering
at
the
moment
on
13
exports
are
shipped
and
he
will
work
as
objects,
they
will
just
always
select
the
default
key,
and
so
as
soon
as
we
unflagged
conditional
exports,
we
get
the
required
of
the
input
and
the
node
keys
and
opening
all
those
doors
to
get
it
out.
I
mean
it's
an
experimental
feature.
An
experimental
branch
expects
you
know.
Third,
in
what
do
you
call
it?
E
A
A
D
A
D
That's
that's
the
issue
I
have
like.
Yes,
you
are
correct
in
saying
that
we
can
add,
require
of
esm
with
the
default
condition
after
this,
and
so
like.
The
timeline
of
the
two
can
be
independent,
but
encouraging
shipping
to
implementations
is
itself
problematic
for
the
ecosystem
as
a
whole
and
I've
already
voiced
that
concern.
So.
A
D
Don't
look
forward
to
the
people
who
write
like
a
server-side
react,
rendering
apps
where
like
because
of
how
their
libraries
are
set
up.
They
end
up
including
two
separate
copies
of
react:
one
ESM
copy
and
one
CJ
s
copy
running
two
separate
renderers
they're
each
trying
to
render
different
fragments
of
the
tree.
D
C
I
mean
would
I
assume
that
they
will
do,
though,
is
do
it
correctly,
where
it's
in
the
SM
wrapper
as
opposed
to
duplicating
it,
because
the
the
their
current
approach
that
you're
describing
is
one
that
was
architected
long
before
node
zsm
implementation
was
finalized.
So,
like
I,
it's
a
good
illustration,
I,
think
of
type
of
problem
that
could
happen,
but
I
think.
D
C
C
My
very
strong
expectation
is
that
all
of
the
popular
frameworks,
as
well
as
all
of
the
popular
tools
are
going
to
start
adapting
to
match
what
node
ships,
and
so
the
problems
you're
describing
are
real,
but
they
are
caused
by
early
adoption
of
non
existent
standards
and
they
will
be
fixed
by
using
approaches
not
likely
approaches
that
fit
with
nodes.
Implementation
now,
I
agree
that
all
the
hazards
you're
talking
about,
are
conceptually
valid
and
absolutely
will
happen
somewhere,
but
I,
don't
think
they're
gonna
happen
at
a
large
enough
level
that
we
argued
I.
Think.
A
I
guess
I
guess
two
things
that
I
could
throw
out
there
that
I
think
are
worth
considering
here,
and
this
is
one
that,
like
not
allowing
this
very,
very
specific
behavior
could
still
result
in
the
same
kind
of
dual
graph
stuff.
If
there's
manual
entry
points
that
people
had
to
do,
which
was
like
more
than
likely
this
solution
that
people
would
land
on.
That
was
one
of
the
points
that
Yann
raised
that
like
really
convinced
me
to
edge
towards
not
being
too
protective
over
this.
A
The
second
one
is,
you
know
all
of
this
is
still
experimental
and
subject
to
change,
not
that
we
want
to
pull
the
rug
under
from
people,
but
you
know
things
like
require
ESM
lending
in
the
future.
If
we're
able
to
reach
consensus
on
an
implementation,
could
relieve
the
need
for
you
to
utilize
in
this
pattern
better
best
practices?
Could
you
could
utilize
it
and
further?
A
If
you
know
over
the
next
six
months,
we
start
getting
a
lot
of
reports
before
we
stabilize
modules
as
much
as
it
would
be
painful
to
do,
we
could
remove
the
behavior
so
I,
you
know.
Obviously,
that
is
not
the
preferred
way
of
doing
it,
but
I
do
think
that
this
offers
enough
convenience
and
enough
of
a
mechanism
for
the
ecosystem
to
align
along
patterns
that
aren't
just
about
node,
that
the
benefits
outweigh
the
potential
concerns.
A
D
A
D
But
those
were
packages
that
were
flagged
as
experimental,
even
though
they
were
like
effectively
shipped
we're
talking
about
a
resolver
in
a
module
runtime
that
wants
its
own
flag.
Even
if
we
say
it's
experimental
and
it
starts
getting
used,
I'm,
not
sure
that
whether
we
say
it's
experimental
will
change
the
reality
of
the
situation.
That's.
A
A
So
Wes,
what
I
do
think
could
split
the
difference
here
and
thank
you
for
being
like
flexible
and
open
is
removing
the
flag
on
13,
but
it
will
still
remain
behind
the
experimental
modules
flag
on
12
does
give
us
and
I
know.
This
is
not
preferable,
but
it
does
give
us
until
14
to
make
a
drastic
change.
A
I
personally
would
advocate
that,
if
we're
having
massive
ecosystem
problems
around
anything
in
the
module,
loader
that
doing
so
like
making
drastic
changes
prior
to
April
before
we
unflagged
on
12
and
before
we
cut
14
are
things
that
should
still
very
much
be
on
the
table
for
this
group
and
open
to
being
explored,
and
that
includes
changes
to
the
resolver.
In
my
personal
opinion,
you.
D
A
I
think
that
we
can
work
very
closely
with
them
and
if
you
have
concerns
about
some
of
the
peer
dependency
stuff
that
they've
got
going
on,
I
would
say
we
should
spend
up
a
separate
issue.
But
we
do
have
a
direct
line
to
quite
a
number
of
the
people
in
the
project
there,
and
we
can,
you
know,
schedule
a
call
with
them
to
discuss
concerns
I'd.
C
D
It's
just
like
like,
like
so
I
guess.
This
is
skipping
ahead
and
the
agenda
to
our
chartering,
the
modules
team
area
I
does
like
it
is
our
Charter
supposed
to
include
just
the
being
the
custodians
of
like
the
coding
core
or
the
custodians
of
like
the
ecosystem
as
a
whole.
Like
are
we
supposed
to
care
about
how
things
are
constructed,
using
the
module
system
that
we
maintain
I.
A
Would
say
that
that
is
a
great
question.
I
would,
if
you're,
okay
with
it
like
to
punt
it
to
the
chartering
discussion
which
I'll
make
that
we
have
time
for
today
and
I
would
say
that
that
is
the
kind
of
question
that
we
would
answer
in
the
process
of
chartering
and
part
of
the
reason
why
I
actually
think
chartering
would
be
so
valuable
because
we
could
come
up
with
that
scope
because
within
no
there's
also
the
there
are
a
couple.
Other
initiatives
that
have
to
do
with
like
ecosystem
maintenance
and
I'm.
A
Trying
to
remember
the
name
of
the
particular
team
will
come
to
me,
probably
in
seven
minutes.
That's
what
my
brain
works,
but
there
is
a
team.
That's
specifically
focused
on
maintain
maintainer
needs
that
that
may
intersect
with.
So
you
know
lots
of
different
options
there.
As
far
as
what
we
could
do
and
Wes
I
would
say,
the
scope
of
the
group
could
be
as
large
as
we
would
like
to
try
to
charter
it
to
be
Willie
as
long
as
the
TSC
is
willing
to
agree
to
that
charter.
A
A
Absolutely
and
then
really
quickly.
If
we
look
at
the
agenda
items
for
the
rest,
we
have
type
detection
stabilizing
the
resolver
unflagging
12
LTS,
our
people.
Okay
with
you
know
it.
Let's,
let's
do
unflagging
12
LTS,
really
quickly
right
now,
because
I
think
that's
more
of
an
update
and
then
maybe
follow
it
with
the
require
ESM,
because
that's
time-sensitive
and
then
I
would
say
chartering
after
that
before
we
get
into
stuff
such
as
state
tabeling,
source
types
stabilizing,
the
resolver,
loader
hooks
or
patch
instrument
are
people.
Okay,
with
that
change
of
order.
A
Okay,
cool
I'm
so
up
first
unflagging
12x,
LTS,
so
I
think
that
we
can
drop
this
from
the
modules
agenda.
As
long
as
people
don't
see
any
problems
as
a
quick
update,
tar
goes,
did
some
work
and
got
the
v8
7.8
back
port
against
No
12
node
12
up
I
work
through
getting
it
tested
and
landed
the
12
x
branch.
There
is
now
an
open
pull
request
for
the
next
version
of
12.
Let
me
get
that
pull
request
into
the
chat
for
you
all
that
is
for
12.15
0.
A
Now
this
release
is
still
tentative.
It
is
scheduled
for
the
28th,
but
it's
possible
that
that
date
will
change,
has
over
250.
It
has
a
447
commits
on
it
right
now,
but
this
weekend
I
spent
some
time
and
got
the
module
loader
implementation
on
there
as
close
to
the
implementation
on
13
as
possible.
It
is
my
belief,
but
I
could
be
wrong,
that
the
only
primary
differences
right
now
are
internal
behavior.
A
There
was
one
refactoring
that
was
done
by
Joey
to
remove
cycles
that
I'm
unsure
if
it
got
back
ported
or
not,
but
other
than
that
all
the
behavior
should
be
exactly
the
same.
The
inning
it
still
has
the
experimental
modules
flag,
but
once
you
include
that
flag,
everything
else
is
the
same
as
13.
So
right
now,
conditional
exports
needs
to
land
on
the
next
13,
but
we
will
back
port
that
part
that
PR
removing
the
flag
so
conditional
exports
self-referential
modules,
exports.
Everything
is
behind
the
experimental
modules
flag
now
without
the
experimental
modules
flag.
A
E
E
A
Check
to
see
if
there's
an
RC,
yet
there
isn't
I'll,
get
an
RC
built
and
I'll
drop
the
link
into
our
tracking
issue,
therefore
unflagging
on
twelve,
but
it
would
be
really
great
if
people
could
test
it
both
with
and
without
the
flag.
I
mean
we
have
a
lot
of
tests
on
there,
but
like
this
kind
of
QA
would
be
really
great
so
test
it
with
your
modules,
make
sure
that
a
it
doesn't
break
existing
modules,
because
without
the
flag
there
should
be
zero.
A
Behavioral
changes,
aside
from
just
the
changes
that
are
introduced
in
twelve
with
new
libuv
and
new
v8,
and
all
that,
but
none
of
the
changes
that
we've
done
to
the
loader
should
be
present,
especially
since
we
have
included
the
bootstrap
refactor
outside
of
that.
It
would
also
be
good
to
test
all
the
things
with
the
flag
off
with
the
flag
off
the
module.
Loader
should
behave
identically
to
how
it
behaves
on
their
team
is
at
least
the
intention.
A
It
is
very
possible
that
there's
a
committer
to
that
maybe
got
missed
in
the
process,
and
that's
why
you
know
manually
checking
this
stuff
would
be
good.
The
intention
now
would
be
to
continue
updating
the
implementation
in
the
monthly
releases
between
now
and
April
and
then
in
the
April
release,
which
would
be
the
next
scheduled
semver
minor
release
that
we
would
remove
the
flag,
barring
any
unexpected
ecosystem
problems
that
rise
between
now
and
then
does
anybody
have
any
thoughts
or
concerns
or
just
questions
about
the
current
state
of
things
in
plan.
C
Is
there
so,
just
if
we
decide
on
new
features
like
let's
say,
let's
say
we
decide
on
a
set
like
a
sigil
first
self-reference
right
between
now
and
that
time,
obviously,
the
lack
of
that
wouldn't
block
anything.
But
if
that's
something
like
that
were
to
land
in
13,
what
are
the
odds
of
it
being
back
portable
to.
A
12
100%,
unless,
unless
they're
relying
on
changes
in
v8
itself,
so,
for
example,
a
bunch
of
the
updates
that
we
had
to
do
this
time
relied
on
the
synthetic
modules
that
landed
in
v8
78.
So
we
waited
because
back
porting
them
without
that
would
have
involved,
unlike
unwinding
a
ton
of,
and
would
have
just
created
a
lot
of
extra
work
and
made
ongoing
maintenance,
a
problem.
So,
barring
you
know,
being
blocked
on
something
else.
The
rules
for
LTS
essentially
are.
We
can
make
changes,
including
breaking
changes
to
flagged
experimental
things
in
a
patch
release.
A
C
A
Say
no
okay,
which
both
to
backporting
any
of
this
stuff?
Ten
number
of
different
reasons
like
it
was
a
ton
of
work
just
to
get
it
to
twelve.
To
be
honest
with
you,
you
rely
on
a
whole
bunch
of
v8
related
stuff,
that's
not
on
no
tenth
and
then
further
no
10
goes
into
maintenance
mode
in
April
and
I
would
be
at
least
with
12.
We
have
quite
a
bit
of
time,
inactive
LTS
to
patch
any
bugs
or
any
problems
as
they
as
they
rear
their
heads,
which
can
sometimes
take
months.
A
Me
double-check
the
dates
that
make
sure
I'm
not
wrong
on
this
so
like.
If
we
look
at
10
yeah
12
10
maintenance
starts
in
April
2020
in
his
end
of
life
in
April
20-21.
So
to
me,
especially
if
this
stuff
is
introducing
instability,
I
actually
think
there's
value
in
maintaining
an
LTS
release
of
10.
That
hasn't
been
touched
by
any
of
this
work.
Alright,.
C
So
the
reason
I'm
bringing
it
up
is
because,
just
an
hour
ago
and
like
some
community
somewhere,
somebody
was
pointing
out
how
exports
isn't
in
node
10,
even
which
is
you
know,
not
at
e
end-of-life
until
next
year,
and
they
were
using
it
as
a
reason
why
they
have
they
prefer
to
use
like
roll-up
or
something
on
their
package,
but
with
exports
they
won't
have
to.
But
then
I'll
have
to
wait
until
it
co
else.
So
I
was
if
we
can
back
for
it.
If
we
could
have
back
ported
that
yeah.
A
A
But
I
think
with
that
said,
and
then
I
see
your
hand
core.
You
know
I'll
get
to
in
just
a
second
I
think
that
that's
the
whole
purpose
of
having
that
main
fallback.
So
yeah
like
it's
not
ideal
that
they
still
need
to
use
roll-up
and
all
that,
but
like
you
still
can
support
exports
and
support
and
on
export
versions
through
the
main
entry
point
and.
C
A
C
All
right,
I
mean
the
feature
that
we're
I
was
specifically
talking
about.
Is
the
inability
to
require
things
that
aren't
in
the
export
map?
Like
the
it's?
It's
it's
like
an
encapsulation
feature.
Yeah
I
see
what
you're
saying
that
that's
the
part
that,
if
it
were,
if
it
could
be
backported
as
far
back
as
possible,
then
that
drastically
accelerates
when
the
ecosystem
can
start,
considering
that
as
an
encapsulation
barrier
for
all
its
supported
nodes,
no.
A
I
I
think,
with
that
in
mind,
we
could
potentially
explore
doing
that,
although,
like
the
concern
that
I
would
have,
is
that
with
ten
going
into
maintenance
in
April,
we
don't
and
with
this
month's
Enver
minor
release
already
kind
of
lined
up.
Unless
we
were
pushing
to
kind
of
do
that
and
like
we
are
not
even
unflagging
exports
on
12
until
April.
It
just
feels
it
feels
odd
to
me.
I,
like
wes's
suggestion
here
that,
like
10,
could
potentially
use
a
userland
polyfill
to
replicate
that.
C
Yeah
I'm
already
in
progress
and
working
on
that
polyfill.
So
certainly
that's
what
I
will
recommend
in
the
meantime,
but,
like
the
you
know,
everyone's
comfortable
comfort
level
with
that
sort
of
thing
is
different.
So
obviously,
if
we,
if
it's
not
practical
to
back
work
to
10
for
all
sorts
of
reasons
that
you've
mentioned
so
be
it
then
I
can
recommend
people
use
the
polyfill
I'm
in
the
process
of
making.
And
if
not,
then
you
know
people
will
just
have
to
support,
have
to
do
what
they
feel
comfortable
doing
for
the
capsule
encapsulation.
A
B
A
A
G
A
A
G
A
Through
the
combination
of
v8
and
the
timeline
on
10
I,
don't
think
that
it's
valuable
for
us
to
be
spending
time
on
that.
But
if
someone
wants
to
open
an
issue
to
discuss
it
separately,
I
think
that
it's
very
reasonable
to
have
a
more
open
discussion
about
it
and
not
just
kind
of
take.
My
word
at
it
right
now
sure
anyone
else
on
this
topic
before
we
move
on.
A
Yeah,
so
what
I'll
do
really
quickly
and
I
think
we
should
move
on
to
the
next
I'll?
Go
and
I'll
click
leery,
run
branch
diff
and
find
out
like
what
commits
haven't
landed.
My
understanding
is
that
unless
something
was
explicitly
landed
to
labeled
to
not
land
on
twelve,
it
should
be
back
ported
and
similarly
to
what
I
was
saying
with
Cori.
If
you
have
a
CR
in
mind,
if
you
dropped
the
PR
in
the
chat,
I
can
quickly
check
to
see
if
that
has
been
back
ported
yet
are.
E
A
13
release
no
I
think
it
should
be
in
the
next
one.
Then
it
possibly
has
not
gotten
there
yet,
because
it
is
not
gonna
in
a
13
release,
because
we
don't
tend
to
back
port
things
until
they
have
gone
out
of
a
release.
And
if
those
loader
changes
get
missed
in
12.15,
they
will
be
able
to
land
in
12.15
one
yawn
and.
F
A
Think
that
it's
absolutely
fine
I
think
that
in
I
think
that
in
as
long
as
these
things
are
flagged,
we
can
change
absolutely
everything
until
it's
unflagged
as
long
as
they're
experimental,
we
can
continue
to
change
them.
I
think
that
the
biggest
thing
that
we
do
need
to
figure
out-
and
this
was
something
that
I
noticed
we
didn't
do
for
experimental
conditionals
or
for
I'm-
not
sure
self
resolved.
A
So
this
is
something
I
just
need
to
double
check,
and
maybe
we
want
to
fix,
but
like
we
did,
I
don't
know
if
we
left
aliases
for
old
Flags,
just
as
no
ops,
which
is
what
we
tend
to
do,
to
make
sure
that
there
aren't
like
see
that,
like.
If
people
had
the
flags,
they
don't
need
to
remove
them,
but
we
can
include
like
silent
aliases
as
well
if
it
changes-
and
we
want
to
just
be
a
little
bit
more
conservative
with
the
change.
A
A
A
E
If
you
try
to
require
MJS
file
that
you
get
an
error
and
secondly,
if
you
try
to
acquire
a
J's
file
and
a
type
module
scope,
you
get
an
error
and
when
we
do
the
back
port,
those
are
now
errors
that
are
gonna
hit
on
the
top
release
right.
So
if
a
user
was
doing
either
of
those
things,
it's
I
think
it's
that
every
now
so
just
wondering.
If
that's
something
that
we
need
to
be
concerned
about,
should
we
listen
to
warnings?
Should
we
make
them
apply
behind
the
flag?
E
Some
things
to
bear
in
my
peer
is
the
reason
why
it
would
user
would
ever
get
an
error
I
today
just
and
tested
it
against
requires
them
and
some
other
things
it
all.
We
explain
the
the
only
time
you
really
get
the
the
issue
is,
if
you
happen
to
sink
type
module
or
an
MJ
s
file
in
your
profile,
even
though
you
weren't
quite
using
them
properly,
and
it
was
sort
of
working,
but
not
quite
so.
E
It's
it's
really
the
early
adopters
who
gonna
be
hit
an
unfortunate
pain
of
of
that
process
and,
ideally
would
have
got
the
errors
out
even
earlier.
So
I
tend
to
think
that
maybe
we
just
need
to
bite
this
one
and
accept
it,
but
yeah
just
to
have
a
discussion
around
that
and
and
be
aware
that
we
may
get
bug
reports.
E
A
Okay,
very
cool,
so
the
next
thing
that
we
have
on
the
agenda
here,
looking
really
quickly
is
chartering.
The
modules
team
eight
minutes
doesn't
seem
like
a
lot
of
time
to
work
on
this.
How
do
people
feel
about
any
future
meeting,
potentially
in
two
weeks
time,
since
the
release
schedule
seems
to
finally
have
been
stabilized
that
we
scheduled
like
half
the
meeting
to
focus
on
this
topic?
Do
people
feel
good
about
that.
G
A
F
Yep
I
think
what
I
would
say
is
that
we
had
been
kicking
around
the
idea
of
chartering
for
many
many
weeks.
So
I
was
wondering
if
there's
a
more
aggressive
thing
where,
if
there's
not
nobody
right
now,
that
has
strong
feelings
against
chattering.
To
make
the
proposal
more
concrete,
before
we
have
to
have
a
beating
that.
A
Okay,
so
maybe
we
should
move
the
conversation
to
github
and
have
more
of
an
explicit
conversation
about
about
the
scope
or
maybe
even
like
I
can
try
to
do
it,
but
my
time
is
limited.
Does
somebody
want
to
pair
with
me
I'm,
putting
together
like
a
high-level
list
of
the
things
that
we
need
to
do
maybe
on
do
you
want
to
work
with
me
on
that
and
perhaps
hoping.
E
A
A
A
G
Mean
I
think
it's
done,
I
guess
just
does
anyone
object
to
tabling
it?
You
know
that's
what
the
PR
does.
So
it's
like
a
one-sentence
PR.
If
anyone
doesn't
think
we
should
table
it
or
wants
to
discuss
it
further
week,
I
can
leave
it
open,
but
it's
been
kind
of
no
progress
since,
like
April,
so
I'm,
assuming
we're
done
on
that
one
yeah.
A
G
Was
that
that
was
that
PR
that
were
not
PR
I
think
it
was
an
issue
that
it
was
quarry
or
Derek
opened.
You
know
how
like
get
package
type
that
definitely
I
could
see
the
value
of,
and
maybe
we
should
add
that
to
the
list.
I
don't
know
yeah,
but
music.
We've
moved
talked
more
towards
that
away
from
like
source
detection.
So
that's
why
I
was
thinking
of
closing.
This
was
okay.
A
If
that's
the
case,
then
I'm
plus
one
on
at
least
removing
that
from
the
timeline
and
I
think
in
in
general.
Maybe
this
could
be
a
larger
conversation
about
like
how
we
work
and
that
can
be
part
of
the
the
chartering
discussion
because
I
don't
know
if
roadmap
bastes
timelines
make
sense
anymore,
but
we
should
kind
of
think
of
ways
of
like
properly
consulting
the
team.
So
maybe
that's
something
we
can
talk
about
in
that
chartering.
Discussion,
yeah,
I,
I,.
G
A
A
So
quickly
did
a
group.
Does
anyone
object
to
landing
this
change
to
the
roadmap,
cool
Jeff
I?
Guess
you
can
move
forward
with
that
with
landing?
That
I
would
just
want
to
make
sure,
and
maybe
this
can
come
in
an
additional
PR
that,
like
ideas,
that
we're
still
exploring
or
something
like
that
should
be
documented
in
the
roadmap,
because
I
would
not
want
to
lose
the
intention
of
they
like
get
package
type
API,
for
example,
yeah.
G
A
G
We
still
need
to
kind
of
figure
out
the
remaining
use
cases
for
loaders
that
the
current
API
doesn't
support,
like
I.
Think,
the
all
the
all
the
things
like
stubs
and
the
stuff
that
the
testing
like
folks
are
coming
at
us
with,
like
we
need
to
kind
of
figure
out
either
solutions
for
those
or
these
two
explanations
for
why
they
won't
be
supported.
But
one
way
than
other
I
think
we
kind
of
need
to
deal
with
the
biggest
of
those.
A
A
Well,
thank
you,
everyone
for
joining.
You
know.
I'd
say
this
was
one
of
our
more
productive
meetings
feels
like
we
got
a
lot
done.
I'm
really
excited
before
we
go.
I
just
dropped
the
gist
into
the
chat
for
those
who
are
following
along
at
home.
If
you
just
go
to
just
you
know,
comm
flash
miles
Barnes,
it's
my
most
recent
jest.
This
is
a
run
of
branch
tips,
so
these
are
all
the
commits
are
on
13
that
aren't
on
12.
A
B
E
A
E
G
Miles
one
more
thing:
when
you're
gonna,
when
you're
gonna
look
at
your
and
yawn
schedules
to
open
the
doodle
for
that
other
meeting,
could
you
maybe
open
a
doodle
for
discussing
what
would
be
the
best
time
for
everyone
in
the
group
for
this
our
regular
meeting
in
case?
We
want
to
move
it
it's
worth.
If
you
want.