►
From YouTube: Open RFC Meeting - Wednesday, March 18th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we're piloting an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.
A
Awesome
and
we
are
live
on
UT
YouTube,
thanks
again
for
the
folks
that
are
joining
this
is
the
MPM
open,
RC
call
I've
posted
the
notes
and
agenda
link
in
the
chat.
If
you
like
to
add
yourselves
as
attendees
that'd,
be
great
and
I.
Think
today,
Mike
you've
agreed
to
take
notes,
potentially
yep,
awesome.
I
know,
claudia,
has
been
taking
them
the
last
few
times,
or
at
least
the
last
time
we
did
the
call
so
again
we'll
be
following
along
the
agenda.
A
That's
in
that
doc
we
do
our
best
to
post
the
agenda
actually
in
the
our
C's
repo
of
the
NPM
mark.
As
soon
as
we
can,
we
are
now
doing
weekly
calls
essentially
alternating
between
the
open
RC
call
that
you're
in
today
and
then
a
more
deep
dive,
topical
discussion
that
will
alternate
same
time
same
day
of
the
week,
but
it
usually
focused
on
one
specific
target.
So
today
we
can,
towards
the
end
of
the
call,
decide
what
we
would
like
to
be
queuing
up
for
next
week.
A
The
reason
for
this
call,
and
the
reason
that
we
you
know
get
together,
is
ideally
to
be
moving
forward.
Our
C's
initiatives
bringing
up
and
bubbling
feedback
from
the
community
and
working
closely
with
community
collaborate
on
NPM,
open
source
software
and
pushing
through
initiatives
and
features,
and
that
the
community
wants
to
see
from
us
click
code
of
conduct,
acknowledgement
as
well
all
interactions
on
the
RCS
repo
and
also
in
this
call,
are
under
code
of
conduct,
which
is
linked
actually
in
the
our
C's
agenda
issue.
A
So
if
you're
wondering
where
that
is,
it's
actually
pointing
at
the
comm
code
of
conduct,
policy
that
we
have,
and
so
just
being
mindful
and
be
respectful
in
these
calls,
is
what
we're
aiming
for
and
allowing
folks
to
speak,
and
you
know
ensure
that
you
know
it's
just
a
really
welcoming
atmosphere
that
we
create
here
again.
The
desired
outcomes.
Intentions
is
to
ideally
be
moving
through
new
features
and
queuing
things
up
that
we
know
the
community
wants
I
guess
there
is
a
bit
of
an
announcement
for
this
RFC
call.
A
B
Npm
is
getting
bought
by
github
weird.
This
is
not
you
got
a
done
deal
in
the
sense
of
being
like
officially
closed.
So
that's
why
you're
seeing
is
all
very
carefully
talking
the
present
tense,
rather
than
the
past
tense,
but
it
is,
it
is
in
process
now
and
and
it's
publicly
known
and
announced
and
I'm
pretty
excited
about.
It
I
think
it's
a
really
good
outcome
for,
for
NPM
and
and
for
the
community
and
for
this
team
and
and
just
our
ability
to
keep
doing
stuff
with
less
distraction
and
less
stress.
A
A
If
not,
we
can
queue
up.
The
first
issue
so
I
know
Isaac.
You
created
this
sort
of
last
minute.
I
am
lost
there
so,
and
we
were
talking
about
it
internally,
a
bit
before
the
call
and
I
know
here's
ago
yeah
exactly
so
issue
113,
so
retro
and
cleanup
of
the
actual
RFC's
repo
itself
and
actually
the
RFC's
that
we've
previously
ratified.
B
What
we
don't
have
is
as
good
of
a
process
for
sort
of
circling
back
on
things
that
you
know
maybe
no
longer
make
sense
like
if,
if
the
context
change
between
when
we
proposed
that
RFC
and
discussed
it
versus
now,
you
know
that
it
comes
time
to
implement
it,
and
I
think
the
worst
thing
we
could
do
is
just
sort
of
take
any
accepted
RFC.
As
a
like.
You
know,
a
rule
written
in
stone
that
we
have
to
implement
it
exactly
like
this,
like
sometimes
that
just
doesn't
make
sense,
and
so
there's
there's
a
handful.
B
Now
that
have
kind
of
accumulated
in
the
in
the
accepted
folder,
where
either
we
have
decided
to
go
to
a
different
direction
or
the
the
implementation
subtly
or
somewhat
differs
from
sort
of
what
is
in
the
RFC
and
so
I
wanted
to
just
kind
of
mention
here
that
we're
we're
going
to
be
working
out
sort
of
what
the
process
looks
like
for
that.
My
my
goal
is
to
is
to
balance.
You
know.
B
The
and,
on
the
other
hand,
you
know
I
know
that
I
know
that
people
sort
of
treat
RFC's
as
something
like
a
commitment
once
they're
accepted-
and
you
know
like
some
folks
on
this
call
like
will
start
building
other
sort
of
outside
of
the
NPM
CLI
will
build
tooling.
That
relies
on
that,
eventually
being
the
way
that
it
gets
implemented.
B
So
I
want
to
minimize
the
amount
of
time
that
you
know
the
amount
of
cases
where
people
are
kind
of
left,
stranded
or
left
hanging
with
a
broken,
broken
promise.
With
respect
to
that,
so
I
don't
have
like
a
firm
proposal
about
how
we
go
about
doing
that.
But
I
do
think
that
that
might
be
like
just
sort
of
figuring
out
what
the
processes
might
be,
something
that
we
do
put
in
an
RFC
and
have
some
discussion
around
I
posted
the
issue,
so
that
I
wouldn't
forget
it.
B
Unless
everybody
here
just
says
yeah,
you
know
what
Isaac
just
just
cut
stuff
out.
It's
fine
I
can
do
that,
like
that's
kind
of
been
our
process
for
updating
these
things
with
implementation,
details
thus
far
and
I.
Think,
mostly,
that's
fine,
especially
in
small
cases
where
it's
like
something
subtle
like
oh,
you
know,
we
thought
it
would.
B
We
thought
the
file
would
be
named
this
and
we
actually
settled
on
this
other
thing,
we'll
just
update
the
accepted
RFC
and
you
can
look
at
the
gate
history
if
you
want
to
see
how
it
changed,
but
I
think
for
for
more
major
things.
One
example
that
came
to
mind
or
that
popped
out
at
me
is
the
handling
of
root
permissions
and
the
the
handling
of
Linc
packages.
So,
as
we've
been
going
through
the
implementation
with
arborist
the
the
RFC,
which
was
the
link,
one
was
probably
the
most
egregious
11
and
so
yeah.
C
B
Yeah
I'm,
looking
at
number
11
and
12
11
like
that's
just
not
how
we're
gonna
be
doing
and
Kim
like
like
it's.
It
was
a
good
idea.
It
seemed
reasonable
at
the
time
given
the
the
refactoring
and
rewriting
the
top
it
in
the
last.
You
know
six
seven
months.
This
decision
that
made
sense
14
months
ago
kind
of
longer
does
so
similar
with
number
12
broadening
his
route.
We've
kind
of
settled
on
within
Jim.
B
Six
on
this
approach
that
that
more
sort
of
you
know
more
somewhat
focus
way
targets
the
the
actual
problem
that
people
were
running
into
and
we're
gonna
continue
that
with
NPM
seven.
So
this
somewhat
more
disruptive
approach
that
number
twelve
suggests
is
not
something
we're
going
to
do
so
like
I
can
just
delete
those
files.
I
can
move
them
to
a
like.
You
know
archive
or
reconsidered
the
folder,
or
something
like
that
and
I.
Think
in
you
know
one
thing
that
the
Darcy
brought
up
when
I
mention
this
to
him.
B
A
You
know
in
terms
of
terminology
I
what
came
to
mind
was
remediation
or
remediated
RC
or
something
that's
like
pulled
out
essentially,
so
we
don't
lose
track
of
in
terms
of
the
way
we
want
to
phrase
or
like
look
at
these
things
again.
We
sort
of
change
paths
around
the
implementation.
If
we
want
to
pull
out
on
RC
in
its
entirety,
then
I
still
think
it
should
live
as
an
artifact
somewhere
and
pulling
it
a
out.
Just
by
removing
the
file
doesn't
seem
right,
I
think
it
should
go
somewhere.
B
B
Archivist
archive
is
probably,
you
know,
a
little
bit
less
of
a
ten-cent
word
for
people
who
don't
speak
English
as
their
first
language,
but
yeah
you
know
we
could.
We
can
create
an
archive
folder
there
pretty
easily
and
just
move
those
things
over
to
it,
and
then
then
the
assumption
is
basically
everything
that
gets
into
accepted
either
eventually
in
the
fullness
of
time,
ends
up
in
the
implemented
folder.
Potentially
with
some.
You
know,
smaller
minor
updates
or
gets
moved
into
the
archive
with
some
notes.
A
You
know,
are
these
artifacts
about
decisions
we've
made,
but
we
want
like
pull
them,
pull
them
out
in
in
a
way
that
we're
also
communicating
why
we're
we're
gonna,
pull
them
out
or
we're
gonna
change
them.
So
obviously
this
would
come
with
a
pull
request
right,
like
so
to
move
the
file
into
that
archived,
folder
or
remediate
or
whatever
we
want
to
call
it
and
I
think
would
be
smart
to
each
time.
A
That's
happening
that
there's
an
individual
call
request
that
we
can
point
to
you
that
says
why
you
know
this
is
happening,
and
then
we
can
actually
reference
that
in
these
calls
going
forward.
So
I
think
that
makes
sense
to
me.
I
think
it's
addressing
something.
That's
happened,
based
on
the
fact
that
you
know
certain
things
were
accepted
almost
a
year
ago
or
more
that,
obviously,
our
focus
or
the
way
that
we're
gonna
actually
execute
on
those
things
has
changed
so
to
me
it's
makes
sense.
D
Like
to
see
you
mention
that
it
comes
with
PR
and
a
reason,
I
think
would
be
beneficial
to
add
the
reason
to
the
document
in
the
PR
so
like
if
you
have
the
RFC
and
it's
merged,
maybe
when
you
archive
it
put
a
section
at
the
top,
that's
a
so
that
folks
don't
have
to
like,
go
and
find
the
PR
that
moved
it
from
accepted
to
archive
if
they
could
just
see
like
right
at
the
top
of
that.
Here's.
The
reason
why
you
know
it
was
good
yeah.
A
I
think
that's
great,
and
actually
you
were
just
as
we're
saying
this
and
I
know
Mike's
taking
notes.
A
good
action
item
here
is
to
actually
to
put
that
into
the
readme
on
the
RCS
repo.
Just
to
say
this
is
the
practice
that
you
know
if
we're
gonna
pull
something
out,
it's
going
to
go
into
this
folder
and
it
should
be.
The
actual
RFC
should
be
updated.
With
a
section
about
the
reasoning.
Why
and
then
yeah?
That's
that's
perfect.
I
think
awesome.
A
Good
good
to
go
awesome
so
moving
forward
the
issue
number
one
10
remove
at
the
F
store,
which
I
pulled
this
into
the
agenda.
This
is
something
that
I
think
ties
in
nicely
with
other
issues.
We've
seen
prop
come
up
about
certain
things:
finding
them
their
way
into
releases
or
finding
themselves
into
you
unpack
the
you
know,
distros.
A
We
need
to
be
mindful
of
this,
and
so
yeah
I
just
wanted
to
put
on
a
radars,
specifically
my
really
radar
I'm
kind
of
euro
nice.
Today,
we
should
go
out
probably
shortly
after
this
call.
This
is
just
something
we
need
to
be
super,
mindful
of
Roy
I.
Think,
actually,
you
had
cued
up
a
ticket
previously
about
identifying
what
those
files
were,
or
what
that
you
know.
A
A
B
Sorry
on
this
there's
there's
little
that
we
can
do
without
it
being
a
breaking
change
right.
If
you
have
and
the
problem
that's
been
brought
up
a
couple
of
times
in
the
past.
Now
is,
if
you
have
a
files
declaration
in
your
package,
JSON
that
says
live,
and
you
have
a
bunch
of
files
in
lib
and
you
just
want
to
include
them
all.
B
We
don't
kind
of
reapply
the
default
ignore
rules
within
those
included
folders,
so
anything
in
that
Lin
folder,
including
a
dot
git
folder,
including
you
know,
des
tour
or
anything
like
that,
will
be
included,
and
that
sort
of
that
is
a
breaking
change,
because
people
may
rely
on
that
right.
If
you
include
a
folder
and
we
say
all
right,
I'm,
including
this
whole
folder
and
everything
in
it
like
you've,
declared
it
in
files,
that's
sort
of
backward
thing,
I.
A
I,
don't
know
if
it's
gets
when
we
pack
it
for
node
I'm,
not
sure
if
there's
certain
files
that
are
getting
picked
up
when
we
generate
Docs,
specifically
I
think
there
might
be
some
crafty
crafty
files.
That's
that
that's
what
I
took
that
as
just
to
be
mindful
for
our
our
team.
Specifically
what
you're
saying.
C
A
Is
a
bit
more
about
creating
a
standard
that
I'm
when
packing
would
ignore
about,
say,
PS
store
files
which
you
want
to
be
as
you're
saying
be
explicit
about?
You
know
that
would
be
a
brilliant
change
if
we
implemented
something
to
ignore
a
file
that
you've
included
explicitly
in
the
past
right
yeah.
B
A
So
moving
on
issue
you
know,
for
this
was
the
scheduling
of
the
I
think
this
got
pulled
in
box.
Then
just
the
agenda
label
hasn't
be
removed,
so
I'll
do
that
right
now,
but
again,
this
was
a
poll
that
we
ran
previously
for
the
alternating
deep-dive
conversation
and
what
might
be
good
just
at
this
time
is
to
potentially
if
we
can
look
into
the
future
see
if
there
is
a
specific
topic,
we
would
want
to
queue
up
for
next
week's
deep
dive
call.
A
C
A
A
A
So
if
your
CI
runs
wild,
there's
a
sort
of
safe
place
to
be
staging
and
publish
and
then
and
then
eventually
still
manually
having
to
do
a
step
up
which
still
would
require
you
know
to
factor
off
to
essentially
promotes
a
a
package
to
be
published
right.
So
the
these
two
things
are
I
think
very
much
linked.
B
I
was
gonna,
say,
I,
think
stage.
Publishers
makes
the
most
sense
of
the
deep
dive
and
I'd
almost
prefer
to
just
not
go
into
it
here
and
into
much
greater
detail,
because
it's
something
we
should
tackle
next
week
and
and
really
go
through
all
of
the
the
use
cases
that
that
we
hope
that
it
addresses-
and
you
know,
make
sure
that
there
are
all
getting
addressed
because
there's
some
there
are
some
interesting
trade-offs.
We
made
we're
doing.
B
D
C
D
Wondering
if
mate,
because
that
this
one
also
has
a
lot
of
contentious
details,
it
might
be
valuable
to
refine
the
talk
like
what
we
want
to
discuss
a
little
better
than
we
did
last
week,
because
I
think
last
week
we
didn't
quite
end
on
resolved
issues
either,
which
is
maybe
not
a
bad
thing
when
they're.
Just
not
you
know,
gonna
be
resolved,
but
still
it
would
be.
You
know,
I,
think
I
think
we
could
do
a
slightly
better
job
of
staying
close
to
topic
than
we
did.
D
A
A
A
C
A
Being
bailed
out
so
and
and
going
forward,
I
think
again,
it's
just
that
that
we
bi-weekly
cadence
is
just
an
open.
Let's
say
like
an
open
hour
of
time
that
we
are
queuing
up
something
and
if
it
just
happens
to
be
workspaces
again
that
that's
what
we
can
do,
but
I
think
in
this
call
I
think
we're
at
least
a
consensus
or
the
majority
of
folks
I
think
are
agreeing
right
now
that
we'd
like
to
deep
dive
next
week
for
yes,
yeah
one
question.
C
About
it
bill
like
if
we
are
to
do
let's
say
staging,
we
should
probably
run
a
poll
like
for
every
one
of
these,
because,
depending
on
the
topic,
we
want
certain
people
to
attend
right.
People
that
have
had
been
already
engaged
with
the
RFC,
so
we
should
probably
paying
them
like
get
their
feedback
on
what
time
works
best
for
them.
C
A
That
sounds
good,
so
takeaway
there
is,
let's
paying
folks
that
we
know,
would
be
good
to
have
on
that
call
as
soon
as
possible,
just
double
check
at
the
it's
gonna
work
for
them,
so
we
ensure
that
attendance
will
be
good
and
then,
let's
ensure
you
know,
based
on
having
effective
meetings,
let's,
let's
make
sure
that
we
have
some
actionable
items
at
the
end
of
these
deep
dives,
just
to
make
sure
that
there's
gonna
be
follow-up
either
in
the
RFC
or
we're
actually
making.
You
know
we're
moving
forward
appropriately.
A
It's
that
good
cool,
good
and
another
thing
to
do.
We
are
now
posting
Wes,
just
it's
a
so
you
know
we
are
now
posting
the
meeting
notes
back
into
the
actual
RFC's
repo,
so
we'll
do
a
better
job
at
cross,
linking
with
the
closed
agenda
topic,
but
also
trying
to
promote
that
you
know
there
are
artifacts
and
there
are
potentially
actions
in
that
artifact,
for
maybe
yourself
or
even
other
folks,
to
take
on
again
Mike's,
taking
notes
right
now
impact
in
the
hakka
FD
document.
A
D
To
be
clear,
I
have
no
problem,
I.
Think
we've
been
it's
been
going
really
well,
the
artifacts
I,
don't
personally
read
them,
but
I
come
to
the
call.
So
it's
not
you
know
that
doesn't
necessarily
matter
too
much
to
me.
I
was
just
hoping
not
to
have
sorry.
I've
got
a
lot
of
things
going
on,
I
got
the
baby
and
everything
yeah
not
to
and
because
we're
we
kind
of
ended
last
time
was
okay.
We
had
a
bunch
of
really
good
discussions,
but
we
didn't
even
like
have
a
really
good
next
steps.
D
B
I
think
that
I
think
the
next
steps
from
the
from
the
workspaces
deep
dive
was
essentially-
and
we
didn't-
we
didn't
document
or
clarify
this
as
as
clearly
as
we
should
have.
Obviously,
because
we're
talking
about
it,
but
I
think
that
the
main
takeaway
that
we
had
was
you
know
we're
going
to
do
we
got
had
some
discussion
got
some
buy-in
on
like.
B
So
you
know
I
think
that
that's
it's
probably
would
be
good
to
circle
back
and
maybe
make
that
more
clear
like
when
that
has
happened
when
in
a
when
an
action
item
has
been
action,
but
oh
baby,
hi
baby,
but
but
yeah,
and
we
can
do
the
same
thing
with
with
the
stage
publishes.
I
think
the
the
main
thing
that
I
want
to
get
out
of
that
that
kind
of
high
bandwidth
conversation
is
like
what
are
you
know?
What
are
the
trade-offs
that
were
that
we're
all
comfortable
with?
B
A
C
No
I
about
that
deep
dive,
like
I
I,
didn't
work
of
like
cleaning
up
the
the
RFC
making
sure
it
was
up
to
date
with
what
we
discussed
and
also
like,
adding
the
dictionary
that
Darcy
suggested
like
it
made
tons
of
sand.
So
now
like
it
uses
the
same
words
everywhere
to
define
the
specific
concepts
and
they
are
all
defined
at
the
bottom.
In
the
dictionary
section
that
like
describes
it's
one
of
them's
likes
it's
it's
very
scientific
now
and
you
read
like
it
actually
makes
sense,
there's
no
more
room
to
like
lose
language.
B
B
A
C
A
C
What
we
have
here
currently
today
when
you
have
to
fracture,
are
enabled
you
have
this
unintended
user
experience
where
you
get
to
kind
of
review
the
company's
your
package
before
publishing
them,
and
this
desire
sees
about
making
that
like
moral
issue,
so
the
feedback
we
gather
from
all
the
discussion
is
that
we
should
implement
it
behind
a
nut,
same
experimental
flag
for
NPM,
seven
and
ninety
two
I
like
to
just
kept
the
prompt
altogether
since
there's
doesn't
really
make
sense
to
have
it
there.
So
we
have
this
small
example
here.
C
B
But
essentially
then,
when
we
drop,
you
know
when
we
make
it
when
we
make
it
a
flag
that
is
no
longer
experimental.
Now
we
have
two
names
for
the
same
thing
in
our
config
stack,
which
is
already
kind
of
a
mess,
and
we
the
simpler
way,
is
to
say
well,
if
you
do
NPM,
publish,
confirm
or
whatever
right
now,
then
that
will
continue
working
exactly
the
same
when
we
defaulted
to
on
or
default
until
you
off
or
whatever,
then
we
just
basically
have
a
boolean
flag
in
it
and
kim
7.1
or
mk8.
D
My
only
question
there
is
and
I'm
pretty
sure
this
is
the
reasoning
behind
adding
experimental
is
that
if
the
behavior
changes
when
it
becomes
non
experimental,
you
have
a
clear
way
to
implement
that
without
breaking
everybody
who
is
using
the
experimental
version?
Maybe
this
won't
change
since
it's
so
simple,
but
you
know
yeah.
B
The
argument
for
an
experimental
flag
is
it's
something
that
you
intend
to
to
no
longer
have
configurable
at
some
point
in
the
future.
Right,
so
like
experimental
module
system
or
whatever
is,
is
actually
intended
to
be
a
preview
of
nodes,
eventual
final
module
system,
the
understanding
that
there's
going
to
kind
of
be
an
instability
between
here
and
there.
In
this
case,
it's
a
little
different
like
because
I
want
to
someday,
say
no
confirm
and
have
that
just
not
confirmed,
and
it's
similar
to
how
we
switched
the
save
from
equal,
false
to
defaulting.
True.
So.
A
I
I
think
I
have
a
tangible
example
or
an
algae
or
a
reference
to
where
this
is
caught.
Let's
say
the
development
community
in
past,
so
if
anybody's
ever
done,
front-end
development
at
all
and
had
to
deal
with
vendor
prefixes
and
now
has
to
maintain
all
the
vendor
prefixes
in
the
CSS
world.
You
understand
why
you
may
not.
We
may
want
to
think
twice
about
you
know
creating
two
different
flags,
because
everybody
will
eventually
want
to
maintain
the
experimental
flag.
A
A
B
B
We
were
just
we
would
just
use
it
as
a
treated
as
a
boolean
flag.
So
there's
the
same
as
like
save
sure
I
mean
technically,
you
can
do
Y
for
yes,
just
automatically
approve
the
confirmation,
but
if
we're
gonna
have
it
be
a
thing
that
you
opt
into,
then
it
should
probably
be
a
boolean
flag
and
it
we
should
just
give
it
a
permanent
name.
C
B
Problem
is
that
like,
or
one
problem
is
that,
yes,
it's
kind
of
like
for
right?
It's.
It
says
yes
to
everything,
so
you
know
if
you
have
I,
don't
know
why
you
would
do
this,
but
if
you
have
an
NPM
an
it
as
part
of
your
published
flow,
then
that
that
yes
is
going
to
apply
to
that
as
well,
and
you
know
you
might
want
to
just
sort
of
more
more
surgically
say.
This
is
the
thing
that
I'm
saying
yes
and
not
that
anything
else.
B
I
mean
we
could
we
could
support
it
as
well,
but
you
know
or
make
a
mention
that,
like
oh
and
also,
if
you
have
n
p.m.
config
yes
set,
then
it
will
it'll.
Also
just
Auto
approve
the
kind
of
confirmation
but
I
think
if
we're
gonna
have
it
be
a
flag
that
you
opt
into,
which
I
think
is
a
really
safe
way
to
go
about.
It
should
be
a
boolean
flag
that
defaults
to
false,
and
then
we
make
it
start
defaulting
to
true
sure.
B
C
E
So
it's
just
always
automatic,
no
matter
what,
if
you're
a
TTY,
okay,
yeah,
so
I
think
there
was
feedback
last
week
about
I,
think
it
was
from
West
actually
about
anyway,
so
there's
feedback.
Last
time
we
talked
about
this
about
I'm,
still
seeing
it
in
the
logs,
no
matter
what,
even
though
it's
you're
saying
yes,
they
wanted
to
see
that
like
it
presented
they're
like.
Are
you
sure
you
want
to
do
this?
Yes
or
no,
and
then
it
was
like
yes
was
confirmed
because
it
was
a
flag
that
was
passed
in
as
I.
B
Well,
we
have
a
flag,
and
if
you're
in
a
non
TTY
environment,
then
it
defaults
to
false
wearing
people
to
true
I.
Don't
know
we've
got,
we
do
have
a
boolean,
not
not
don't
not
stop
for
confirmation
kind
of
thing
happening
here,
but
the
basic
is
like
we
default
it
one
way
if
you're,
if
you're
an
on
TTY
and
we
default
the
other
way.
If
you
are.
A
So
just
the
time
box
this,
because
we
have
about
15
minutes,
left
any
other
feedback
that
we
want
to
give
feel
free
to
make
it
against
that
I
think,
with
a
few,
just
like
very,
very
small
changes
where
we
can
just
potentially
ratify
this
between
now
and
the
next
call,
potentially
asynchronously,
so
cool
yeah.
If
you
want
to
stop
sharing,
unless
you
want
to
show
us
all
the
code,
that's
happening
in
there
or.
A
C
C
A
C
But
yeah
I,
don't
know
you
know.
I
know
we're
also
missing
a
bunch
of
the
regular
folks,
especially
Daniel,
that
I
had
more
experience
on
it
and
might
have
opinions,
but
basically
the
way
to
filter
out
from
the
set
up
workspaces.
You
have
to
find
filter
out
the
ones
you
want
to
render
this.
Is
it
command
again
right?
We
had
an
internal
brainstorm
in
your
slack
channel
that
maybe
will
be
nice
to
also
share
folks
hear
about
different
ways.
A
C
So,
basically
like
we
want
a
way
of
just
filtering
out
or
opportunity
to
a
set
up
the
workspaces
you
have
defined
on
your
current
workspace
and
so
basically,
instead
of
using
like
in
the
RFC
right
now
here
we're
only
proposing,
like
this
filter
option
that
you
can
define
and
like
potentially
describe
some
names
of
workspaces
in
here,
but
this
was
like
I.
This
is
one
of
the
comments
in
the
PR
that
this
is
the
the
part
that
is
still
very
fluid.
There's
no
definition
on
it.
C
So
some
of
the
proposals
we
had
it's
about,
maybe
just
like
having
a
name
space
workspace,
so
basically
NPM
workspace.
You
define
the
name
of
the
workspaces.
You
want
to
apply
that
command
on,
and
then
you
specify
the
command
pretty
much
like
yarn.
Girls
today
and
also
like
I,
was
trying
to
have
more
fancy
ideas
way
of
doing
this,
so
basically
having
a
column
to
describe
the
name
of
each
workspaces.
A
A
C
A
C
A
E
A
E
So
I
part
of
that
deep
type
of
the
ties
explained
earlier
I
thought
we
had
sort
of
discussed
that,
like
first
pass
was
gonna,
be
like
X,
Y
Z
and
in
from
what
I
understood
from
the
deep
dive,
X
Y
Z
did
not
include
aliases
or
like
running
scripts
and
in
some
folders
it
was
just
like.
Let's
make
work,
spaces
work,
so
I
I,
don't
understand
why
this
would
be
a
blocker
for
workspaces.
One
is
an
RFC
like,
especially
since
we
just
decided
the
beginning
of
this.
E
B
E
Then
I'm,
very
okay,
with
like
our
initial
RFC,
like
when
we're
moving
when
we're
critical
or
press
to
like
move
it
to
accept
it.
It's
like
this
is
a
week
so
or
rather
to
say,
like
implemented
and
wanted
like
updating
the
I've
seen
like
this
is
how
we
implemented
it.
This
is
how
it
actually
works.
This
is
the
thing
perhaps
I'm.
A
Just
gonna
double
say:
I'm
gonna
double
down
on
I.
Don't
think
we
noted
that
the
implementation
details
were
like
Darcy
is
definitely
supposed
to
be
where
we
saw
so
how
we're
gonna
implement
this
and
then
what
it's
gonna
look
like.
So
I.
Don't
think
that
we
said
at
the
beginning
of
this
call
that
we
were
changing,
try
and
change
course,
and
that
we're
gonna,
true
from
the
actual
like
implementation
in
RFC.
So
much
as
we
were
saying
that
there's
certain
things
that
we
may
not
execute
on
and
that
we
would
try.
A
So
I
don't
want
to
make.
It
seem
that
that
we're
out
here
trying
to
communicate
with
the
community
and
trying
to
figure
out,
you
know,
api's
and
way
that
these
things
are
gonna
be
implemented
like
trying
to
suck
so
those
details,
and
then
I've
heard
from
that
in
any
manner.
So
just
want
to
be
mindful
that
that's
not
what
we
were
talking
about
at
the
very
beginning
in
this
call.
No.
B
It's
not
it's
more
like
occasionally
that
occasionally,
that
is
inevitable
right
like
we
will.
If
we
have,
if
we
have
90%
coherence
between
our
plans
and
reality,
we're
probably
the
the
most
predictable
software
team
in
the
world,
so
100
percent
is
right
out,
but
you
know
I
think
that
I
think
that
we
should.
We
should
try
to
maintain
credibility
through
that,
rather
through
those
changes
and
updates,
rather
than
you
know,
sort
of
just
throw
it
away
and
say:
well,
you
know
yeah,
we
said
it,
but
that's
not
what
we're
gonna
do.
Yeah.
C
E
A
B
This
is,
this
is
actually
already
it's,
it's
I
think
implemented
in
the
v7
beta
so
already
know,
and
it's
it's
pretty
uncontroversial
yeah.
We
we
may
as
I
think.
The
only
thing
that's
controversial
is
like
should,
should
the
save
logic
be
different
for
peer
dependencies
versus
regular
dependencies
and
there's.
C
B
Some
interesting
subtlety
there
Jordan
was
pushing
for
it
to
to
only
add
to
the
to
the
to
the
range
rather
than
rather
than
replacing
it
like.
If
you
npm,
install'
Fuat
latest
save
it
saves
whatever
the
version
was
you
got
with
a
you
know,
carrot
in
front
of
it
for
peer
dependencies.
You
may
want
to
have
a
a
somewhat
more
loose
dependency
range,
so
it
might
make
sense
to
either
you
know
to
have
that
save
logic
be
kind
of
custom
for
peer
deaths.
B
A
A
And
we
can
always
add
it
back
on
just
to
be
mindful
of
it
and
keep
it
on
our
radar.
So,
with
about
five
minutes
left,
we
have
the
pr
essentially
for
staged,
publishes
PR
number
92,
which
is
at
a
meet
in
our
agenda.
That
RC
is
essentially
the
one.
I
think
that
we've
got
consensus,
that
we'll
do
a
deep
dive
on
next
week.
A
So
for
any
folks
that
really
have
feedback
there
either
feel
free
to
join
next
week
or
please,
you
know
give
updates
or
feedback
in
the
actual
RFC
itself
and
moving
on
number
nine
on
our
agenda
is
PR
number
76
sign
documents
again.
This
is
something
that
has
be
on
agenda
for
a
while,
I'm
not
sure
if
we
want
to
pull
it
off.
At
this
point,
though,.
B
Actually,
I've
kind
of
been
going
back
and
forth
with
will
Blankenship
retro
hacker
on
this
PR
in
the
last
week
or
so,
and
essentially
I
think
that
there's
I
think
we
were
we
worked
out,
was
a
pretty
good
series
of
steps
to
to
get
us
to
something
like
what
he's
asking
for
first
of
all
and
I
in
the
interest
of
time.
B
Maybe
we
should
just
kind
of
go
to
that
RFC
and
read
the
discussion
there,
but
the
we
kind
of
need
to
split
this
up
and
do
a
handful
of
things
that
that
take
actionable
steps
towards
the
kind
of
securing
over
overarching
kind
of
security
and
signature
stuff.
But
the
main
thing
is
we
need
to
start.
We
need
to
like
design
and
implement
a
way
to
actually
do
signature
checking
of
just
the
NPM
registry
signatures
that
are
already
on
packing.
A
B
A
D
A
I'll
follow
up
with
that.
It's
definitely
in
my
my
court.
I've
I've.
It's
now
at
the
time
for
our
policy
is
four
week
grace
period
for
for
the
existing
author
of
a
name
dispute
to
respond
right
now,
essentially
that
that
package
is
being
squatted
on
there's
no
actual
real
software
associated
with
that.
D
A
A
If
there's
been
nothing
that
I'd
like
to
poke
the
folks
that
are
on
that
thread
before
our
next
call
just
to
ensure
we
have
the
right
people
in
that
call.
So
if
we
can
note
that
as
an
action
item
that
will
poke
the
folks
that
have
been
active
there
and
then
the
last
item
on
our
agenda
was
issue.
Number
506
against
the
CLI
repo
was
Corey.
Farrell
joins
I.
B
So
we
we
literally
just
discussed
in
our
stand-up
this
morning,
kind
of
audit
and
sort
of
next
up
on
the
on
the
v7
to-do
list.
So
we're
going
to
the
first
pass
with
the
within
the
end.
Mv7
beta,
like
basically
replicate
the
current
functionality,
and
then
we
can
also
once
that's
done.
We
can
take
a
look
at
updating
the
the
way
that
we
report
these
things
and
that
may
potentially
be
something
we
can
also
land
in
v6
prior
to
going
out
as
part
of
v7.
A
B
Could
yeah
I
mean
I
I'm,
not
I'm,
not
a
hundred
percent
sure
this
is
even
really
RFC
worthy
like
we
could
just
sort
of
improve
the
way
that
we
report
like.
Essentially,
what
he's
saying
is,
like
you
have
a
dependency,
you
have
a
meta
dependency,
which
is
has
an
advisory
against
it,
and
the
thing
that
you're
actually
depending
on,
would
pull
in
the
newer
version.
You
just
have
you
just
installed
it
or
updated
it,
but
you
know,
as
the
as
the
maintainer
of
that
that
top-level
DEP
right
somebody
comes
to
me
and
says:
hey
tap.
B
How
come
tap
is
depending
on
this
out-of-date
version
and
I'm
like
well.
It's
not
it's
a
it's
a
version
range.
If
you
install
tap
today,
you
get
the
new
version,
but
because
they
have
a
package
lock
it
never,
it
doesn't
update
that
nested
dependency,
and
so
there's
a
couple
of
things
that
are
changing
in
v7
anyway,
like
the
way
that
we
do
update
is
different.
If
you
just
ran
and
can
update
it
would
update
everything
on
it.
Fixed
will
be
a
little
bit
more
comprehensive
as
result
and.
B
Then
also
on
top
of
that,
what
we
can
do
is
we
can
say,
like
yes,
you're
getting
handlebars
as
a
sub
dependency
of
NYC,
but
NYC
is
already
updated
and
you're
only
getting
the
old
version,
because
it's
in
your
package
lock.
So
it's
actually
your
fault,
not
NYC
fault.
Don't
go
bug
Korey
about
it.
You
know
or
don't
bug,
go
bug,
Isaac
about
the
tap
tap
being
the
reason-
and
you
know
I've
gotten
bitten
by
this
like
users.
B
Meanwhile-
and
they
come
to
your
repo
and
they're,
like
you
know,
why
are
you
forcing
me
to
have
something?
That's
out
of
date
or
they
send
you
a
bunch
of
pull
request
to
update
dependency
ranges
and
really
like
liner,
trivial
ways,
so
I
think
we
should
just
do
it
like
I,
don't
know
if
I
would
call
it
a
bug
or
an
enhancement
request,
but
it's
a
it's
a
good
one.
It's
one.
A
If
we
can
just
comment
on
it,
I've
removed
as
agenda
item
hokum
and
I
think
that's
that's
good
enough
to
make
sure
that
it's
off
our
radar
for
next
week
didn't
appreciate
folks
staying
an
extra
five
minutes
here.
I
apologize,
we
got
about
five
minutes,
started
about
five
minutes
late,
but
yeah,
hopefully
again
we're
gonna
open
up
an
issue
for
next
week's
deep
dive.