►
From YouTube: Open RFC Meeting - Wednesday, August 26th 2020
Description
In our ongoing efforts to better listen to and collaborate with the community, we run 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
A
Let
me
start
by
sending
out
minutes
to
the
zoom
participant
so
that
you
can
add
your
name:
cool
nice
exhaust,
open
there,
cool,
yeah
and
yeah.
Let
me
start
by
the
code
of
content
acknowledgement.
This
call
and
all
the
interactions
are
on
the
record
of
conduct.
So
you
can
also
take
a
look
at
the
link
here
for
the
zoom
participants
and
yeah.
So
any
announcements
today
from
anyone
here
in
the
zoo.
A
Oh
awesome,
cool
yeah.
So
with
that
we
can
maybe
start
going
through
the
agenda
here
and
the
first
item.
Oh
I
see.
The
very
first
item
is
a
audit
in
which
I
was
kind
of
expecting
zb
to
show
up.
So
maybe
we
can
put
that
to
last
see
if
it
gives
him
some
time
to
maybe
jump
up
during
the
call-
and,
let's
maybe
start
with
a
question
pr
for
parent
package,
jason.
D
D
Yeah
so
last
time,
jordan,
I
think
made
the
comment
that
changing
the
way
package
jason
behaves
is
very
much
undesirable
for
existing
tooling.
So
I
tried
to
adapt
the
the
way
the
parent
package
package.json
works.
D
So
the
idea,
basically,
is
that
you
can
inherent
overrides
dependencies
and
scripts
for
now,
maybe
in
the
future
we'll
add
more,
but
that's
kind
of
the
basic
list
I
want
to
start
with.
So
the
idea
is
that
you
can
specify
a
file
source
dash
package,
dot
json
and
you
can.
You
can
specify
dependencies
apparent
package.json
that
you
want
to
inherit
from,
and
you
can
specify
scripts
and
overrides
and
npm,
with
just
on
every
install
and
pack
override
these
things
in
the
package
json.
D
So
that
tooling
could
just
read
package
json
like
it
has
always
done.
That's
the
idea.
Please
have
a
read.
D
If
you
have
some
comments,
please
leave
them
in
the
pr
or
tell
me
now.
One
of
the
problems
that
I
saw
was
what
happens
if
I'm
just
an
ordinary
user
and
decide
to
change.
Package.Json
myself
and
then
I
install
again,
my
changes
could
potentially
be
lost,
which
is
a
bit
of
a
bummer.
So
maybe
we
would
have
some
way
to
detect
that
I
don't
know.
B
One
one
possible
way
we
could
detect.
That
is
just
you
know,
look
at
the
the
m
times
of
the
files
and
if
the,
if
the
package.json
is,
is
newer
than
the
packagesource.json,
then
we
don't
do
that
thing.
D
B
I'll
try
to
put
that
in
it's
a
little
bit
flaky
and
you
need
to
kind
of
have
some
some
buffer
like
give
it,
because
there's
going
to
be
situations
where,
like
you,
do
a
get
checkout
and
one
file
gets
written.
You
know
one
second,
after
the
other
yeah,
but
if
you
give
it,
you
know,
do
you
figure
like
a
human
being,
is
not
going
to
probably
open
a
file
and
edit
it
with
let
you
know
less
than
10
seconds
of
lag.
B
So
if
you
give
it
10
or
even
100
second
buffer,
then
if
it's
newer
than
that,
you
ignore
it,
we
use
the
same
trick
with
the
the
hidden
lock
file
right
now.
So
if,
if
any
of
the
contents
of
the
node
modules
folder,
are
I
forget
what
the
the
timeout
is?
I
think
it's
10
seconds
or
you
know
more
than
10
seconds
or
less
than
10
seconds
older
gosh.
B
Now
I
forget
now
because
I'm
I'm
phrasing
this
wrong,
but
basically,
if
the
contents
of
node
modules
are
newer
than
the
hidden
package,
lock,
that's
in
the
node
modules,
slash
dot
packet
lock.json,
then
it'll
just
ignore
the
the
hidden
lock
file
and
do
a
normal
load
actual.
D
Okay,
that's
a
cool
idea,
I'll
I'll,
try
to
put
it
in
there.
That's
basically
all
I
have.
However,
I
do
have
some
kind
of
a
gut
feeling
that
it's
getting
cleaner
with
every
iteration,
so
yeah.
I
think
it's
slowly
crawling
there.
It's
not
getting
there.
It's
crawling
there,
but
that's
fine.
So
here's.
B
I
I
gotta
say
I
like
this.
I
like
this
idea
for
a
lot
of
reasons.
One
is
that
it.
It
simplifies
out
a
lot
of
the
concerns
that
we
brought
up
before
right,
like
the
the
the
issues
with
like
what
do
we
do
if
we
see
a
parent
declaration
in
a
node
modules
package,
json,
making
sure
that
we
always
flatten
it
prior
to
putting
it
in
the
tarball
was
going
to
be
a
little
a
little
flaky.
B
You
know,
or
just
just
an
easy,
an
easy
thing
to
get
wrong
right,
the
the
one,
the
one
concern
that
I
do
have,
and
I
don't
know
if
this
is
kind
of
a
bug
or
a
feature.
Is
that
we'll?
I
suspect
that
we
will
inevitably
have
people
who
want
to
do
more
stuff
with
that
packagedsource.json
right,
so
not
just
not
just
specify
a
parent
but
even
like
build
it
dynamically
or
have
a
script
that
runs
kind
of
to
figure
out
what
your
dependencies
should
be.
B
Or
what
have
you
and
again
I
mean
you
know
this
is
kind
of
like
down
this
down.
This
road
leads
auto
conf
right
so
yeah,
I'm
not
I'm
not
sure
if
that's
a
bad
thing
per
se,
but
it
is
certainly
it's
certainly
going
to
be
like
an
invitation
to
add
ever
more
complicated
foot
guns.
B
Yeah,
I
think
it's
more.
I
think
it's
probably
more
feature
than
bug
that
concern
right,
because
there
are
probably
some
valuable
things
that
will
come
out
of
that
and
we'll
just
have
to
continue
to
be
to
be
thorough
and
careful
about
evaluating
them.
So
we
don't
end
up
with
you
know,
just
decreeing
every
feature
under
the
sun.
Absolutely
yes,.
B
But
yeah
I'm
fine
to
move
on.
I
think
this
is.
I
think
this
is
a
good
direction.
I
agree
it's
getting
cleaner,
it's
a
it's
a
tricky
thing
to
implement
and
get
right.
So
I'm
you
know
it's
also
a
hard
one
to
come
back
from
if
we
get
it
wrong.
So
I
think,
being
thorough
here
makes
a
lot
of
sense.
Yeah.
A
Yeah
cool
and
I
also
isaac-
I
also
mentioned
to
kristen
before
we
start
the
call
that
this
is
probably
a
very
good
one
for
us
to
hold
on
on
just
ratifying
it
and
rather
waiting
for
the
work
on
the
implementation
to
start
and
kind
of
follow
up,
bring
some
feedback
into
the
rfc
before
reading.
B
Kind
of
like
overrides
is
in
sort
of
a
similar
state
right
it.
We
all
think
it's
good,
but
once
we
implement
it,
we
might
change
our
minds.
D
Cool,
so
how
would
you
go
about
that?
Would
you
well,
I
mean
this
is
kind
of.
I
don't
know
this
feels
like
a
stupid
thing
to
ask,
but
would
like
the
npm
folks
go
into
like
a
secret
hideout
cabin
and
just
try
to
implement
it
or
would.
B
I
so
I
don't
think:
well,
we
don't
have
a
secret
hideout
cabin,
but
unless
you
participate
slack
channels,
if
we
do,
we
probably
wouldn't
shouldn't,
say
it
in
public.
D
But
what
what
I'm
saying
is
I
would
love
to
offer
my
help,
but
I
have
like
zero
knowledge
of
npm.
B
So
I
I
think
the
next
step
here
is
probably
because
we're
we're
only
going
to
be
doing
this
at
pac
and
publish
time
so
effectively.
Now
we
we
have
two
I'll
just
kind
of
give
you
some
brief
guideposts.
We
have.
B
We
have
effectively
two
two
modules
that
read
package
jsons,
which
are
which
are
called
read:
package
json
and
read
package
json
fast,
and
I
think
both
of
those
so
read
package
json
fast,
is
used
when
we
when
we're
reading
package
jsons
that
are
in
the
node
modules
folder,
because
and
in
other
cases
where
we
don't
care
about
getting.
You
know
every
every
possible
bit
of
sort
of
implied
metadata
right,
we're
don't
we're
not.
B
Look
at
the
look
for
a
git
repo,
we're
not
going
to
you
know,
infer
like
the
all
the
different
things
and
all
that
stuff
is.
You
know,
ads
work
and
it's
slow.
So
when
we
have
to
read
like
2
000
package
jsons,
we
try
to
just
go
as
fast
as
possible,
but
read
package
json
fast
is
going
to
have
to.
B
That
is
the
thing
that
we
use
during
install
because,
again
during
install,
we
don't
care
about
all
that
extra
metadata.
It's
it's
really
only
for
publish
time
that
we
that
we
get
that
kind
of
full
pretty
duck
manifest.
B
So
both
of
these
need
to
have
the
the
added
feature
to
to
you
know,
look
at
the
the
package.
Source.Json
and
repackage.json
fast
needs
to
only
do
it
if
it's
the
root
package.json
file,
so
I
think
the
the
place
to
start
since
we
need
to
have
it
in
two
places
is
to
actually
just
create
a
new
standalone
module
that,
like
you,
you
give
it
a
give
it
a
package.json.
B
It
looks
for
a
source
if
it
finds
the
source,
it
runs,
the
you
know
the
extension
and
the
fetching
and
everything,
and
if
it
doesn't,
then
it
just
returns
that
data
and
then
we
can
use
that
to
you
know
to
read
the
the
package
json.
A
Plan
awesome
yeah,
but
also
maybe
for
the
rfc
itself
kristen.
I
know
you've
been
here
for
the
last
few
months,
so,
if
you
want
to,
we
can
just
like
move
it
out
of
the
agenda
for
now
and
of
course,
you
can
follow
up
with
the
items
that
we
just
mentioned,
maybe
checking
for
the
time
and
that
those
feedback,
but
maybe
just
wait
for
some
implementation
to
start
now,
you
can
be
from
either
you
someone
else
from
the
community.
Someone
from
the
team.
D
Yeah
definitely
like
you
can
definitely
put
it
off
the
agenda,
but
I
still
will
try
to
make
it
next
week,
so
not
going
anywhere
awesome
which
which
I
might
write
an
rfc
for
shortly
but
yeah.
Let's
move
on.
D
Yeah,
that's
that's
what
I
mean,
because
I
kind
of
feel
that
I'm
using
npm
so
much
that
it's
valuable
to
give
some
feedback
or
like
a
different
view,
on
what
I
would
like.
A
Come
awesome
all
right,
so
I
guess
with
that
we
can
move
on
to
the
next
item.
We
have
here
the
npm
front
depth,
it's
one.
I
know
we
discussed
this
before
and
I'm
pretty
sure
we
come
to
a
conclusion
last
time.
I
just
wanted
to
make
sure
it
is
the
case
so
that
we
can
properly
follow
up
with
the
rfc
itself.
A
So
isaac
do
you
wanna
or
maybe
I
can.
I
can
just
talk
about
this
one
sure
yeah,
because
if
I
remember
correctly,
the
the
place
we
landed
up
last
time
is
that
we
are
moving
away
from
that
as
a
flag.
We
don't
we
want
to
use
less
that
and
more
the
all
flag
instead.
So
I
think
for
the
purpose
of
npm
fund.
A
The
thing
to
do
here
with
this
rfc
is
to
tweak
it
to
use
dash
dash
all
instead,
but
for
npm
fund.
We
want
it
to
default
to
true,
unlike
ls,
that
we
are
tweaking
for
v7,
so
here
in
this
case,
I
think
it
will
be
support
to
dash
dash
all
false,
and
then
you
would
get
only
the
first
level,
the
top
level
dependencies.
B
Yeah,
that
does
mean
setting
depth
changing
or
changing
the
all
config
to
so
it's
like
very
inside
baseball.
It
means
changing
the
all
config
to
from
a
binary
to
a
trinary.
So
if
it's,
if
it's
undefined,
we
use
the
default
behavior
and
if
it's
explicitly
false,
then
it's
always
false,
and
so
there's.
B
For
other
commands,
but
then
fund,
if
it's
undefined,
it'll
use
it
as
true.
A
Right
right
makes
sense,
yeah
see
cool,
so
I
think
it's
fine
to
just
take
the
action
item
off
following
up
with
the
pr
there.
A
B
Yeah,
I
did
I'm
not
sure
what
this
is.
I
think
this
is
complaining
about
a
problem
in
npm
six,
where
it
doesn't
perform
the
the
engine
check
when
installing
from
an
empty
node
modules
folder
with
a
lock
file,
because
the
v6
log
file
did
not
include
that
metadata
in
npm.
Seven,
the
the
log
file
does
include
that
metadata
and
if
it's
missing,
we
actually
recheck
for
it.
So
I
think
it's
probably
mostly
fine.
B
The
only
situation
in
which
we
won't
check
is,
if
you
have
a
module
in
your
node
modules
folder,
and
it's
in
the
lock
file
that,
because
we're
not
even
going
to
re-evaluate
that
additional
metadata
or
if
you
have
a
module
in
node
modules
and
one
of
its
subdependencies,
which
satisfy
their
requirements,
you
know,
are
have
some
invalid
engines
and
input
engines
restriction,
that's
not
met,
because
in
those
cases
we
don't
actually
explore
that
part
of
the
the
dependency
tree
right.
B
We
say:
okay,
well,
these
depths
are
all
met,
so
I
don't
even
need
to
look
at
them
any.
You
know
any
more
closely
than
that.
I
think
that
might
be
fine,
and
if
so,
this
is
like.
Yeah,
that's
how
it
works
in
v7.
So
there's
not
much
to
say
about
this.
B
If
we
do
need
to
do
that,
full
recheck,
I
don't
think
it's
something
we
can
do
in
at
install
time
because
it'll
really
slow
down.
You
know
adding
a
new
depth
when
you
have
an
existing
node
modules
tree,
but
we
could
maybe
add
it
to
like
npm
doctor
or
some
other
command
that
just
checks,
you
know,
does
a
scan
of
your
whole
node
modules
tree.
F
F
B
B
We
could
do
that
relatively
easily,
and
I
know
people
run
npm
ls
to
kind
of
like
a
sort
of
a
a
faster
form
of
a
doctor
command.
B
Well,
so
I
think
adding
it
to
ls,
wouldn't
be
so
bad.
We
would
just
you
know,
run
the
run
the
checks
and
emit
the
warning.
We
still
wouldn't
actually
like
change
any
behavior
or
break
anything,
so
it
had
some.
It
had
some
code,
but
it
doesn't
add
a
lot
of
like
changes
to
user
experience.
C
If
it's
just
gonna,
be
like
a
warning,
just
like
a
little
bit
of
copy
to
std
out
was
that
still
something
that
would
be
like
super
disruptive
for
install.
C
B
Yeah
so
anyway,
comment
already
put
on
the
on
the
pr
we'll
see
where
that
goes.
Awesome
move
up
here.
A
Yeah
yeah:
let's
move
on
to
the
next
one.
We
have
a
few
more
items
today
so
right
we
have
this
large
one
on
open
source
paid
forward
system
number
197,
and
I
think
it's
is
it
for.
Is
it
yours,
a
part.
A
Okay,
cool
all
right,
so
maybe
you
can
make
an
introduction,
also
introduce
yourselves.
We
had
no
introductions
today
so
feel
free
to
also
introduce
yourself.
E
E
So
I
wrote
one
of
those
era
of
rfcs
for
solving
an
issue
with
with
funding.
Currently
people
can
put
a
fund
property
and
package.json,
but
that
requires
companies
to
to
see.
Oh,
this,
this
package
has
a
fund,
so
I'm
gonna
check
the
link
and
then
go
to
their
patreon
and
give
them
this
much
money
every
month,
but
that
requires
to
do
that
for
every
package.
So
it's
it's
not
it's
very.
E
It's
high
friction
for
for
a
company
to
do
that
for
all
of
the
packages
that
require
a
fund-
and
this
is
trying
to
solve
that
so
essentially
there's
a
kind
of
broker
in
between
where
you
say
I
want
to
give
back
to
the
open
source
community,
like
I
don't
know,
to
two
euros
a
month
ten
euros
a
month
and
then
that
broker
works
as
a
proxy
during
an
npm,
install
or
yeah.
Let's
keep
it
simple
to
begin.
E
They
work
as
a
proxy
and
they
see
what
packages
you
install
and
then
they
divvy
up
the
funds
that
you
allocate
like
that
two
euros
a
month.
They
divvy
that
up
to
how
many
times
you
install
every
package
that
has
a
fund
property
in
their
package.json
and
all
those
little
bits
add
up
and
then,
at
the
end
of
the
month
the
broker
says:
okay
for
this
package,
you
get
500
euros
for
this
package.
You
get
a
thousand
yeah,
that's
the
gist
of
it
and
yeah.
E
E
We
will
provide
these
services
for
for
the
open
source
community,
so
companies
can
hire
us
to
to
divvy
up
the
funds
for
them
and
we
use
ai
or
we
use
number
of
installs
or
we
use
number
of
installs,
but
combined
with
how
many
stars
it
has
on
github
or
something
like
that,
like
every
comp,
every
broker
could
decide
how
they
divvy
up
the
funds
and
then
people
can
or
companies
can
choose
which,
which
broker
they
use
to
view
up
the
funds
and
then
one
additional
one
was
to
to
give
more
of
an
incentive
for
companies
to
do
this.
E
You
could
have
another
license.
So
like
a
package
or
a
library
could
up
there
update
their
license
to
say
it's
a.
E
I
think
I
called
it
like
a
pay
it
forward
license
or
something
where
they
say
you
can
use
my
you
can
use
my
library
for
free,
it's
open
source
if
you
use
it
for
non-commercial
use,
but
if
you
want
to
use
it
for
commercial
use,
you
need
to
at
least
pay
two
euros
back
to
the
open
source
community,
not
to
me
specifically
the
the
library
owner,
but
to
the
open
source
community,
and
since
that
is
part
of
the
license.
E
A
So
awesome
I
I
see,
I
see
wes
had
his
hand
raised.
F
F
D
F
F
Okay,
it's
initiative
by
oh
now,
I'm
blanking
on
the.
F
Yes,
that's
the
one
yes,
so
they
have
they're
doing
something
kind
of
like
what
you're
talking
about
operating
as
like
the
broker.
I
guess
is
what
your
you
know
terminology
is.
It
would
be.
F
E
F
No,
I
so.
I
so
anyway
check
that
out,
because
I
think
it's
really
cool
and
I
totally
am
on
board
with
the
big
picture
ideas
you
presented
here,
and
I
think
so
is
that
so
is
the
open,
collective
and
their
back.
Your
stack
thing,
I
think
it's
sort
of
alignment,
so
it
might
might
be
worth
your
time
just
do
some
research
there.
B
F
Here
is
just
so
bad,
so
anyway,
I
was
just
saying,
I
think,
if
you
could
focus
a
little
bit
more
on
the
technical
aspects
like
if
npm
had
metrics
hooks
that
could
report
to
multiple
endpoints
or
something
that
something
that
was
a
little
bit
more
meaty
on
the
stli
implementation.
F
That
would
make
me
feel
a
lot
more
comfortable
talking
about
this
rfc,
because
this
rfc
covers
just
a
ton
of
stuff
like
you
would
need
to
say,
here's
a
broker
willing
to
imp.
You
know
because,
like
getting
npn
anyway,
that's
where
it
goes
into
the
I
don't
want
to
speak
for
npm,
but
like
I,
I
think
that
this
is
a
great
idea
where
there's
a
lot
of
merits,
but
there
needs
to
be
some
some
focus
on
technical
features.
F
E
It's
a
good
point
for
the
the
metrics
one
of
the
things
we
taught.
I
think
you
can
do
that
right
now
have
is
like
have
a
a
proxy
to
npm,
where
you
cache
packages
and
stuff
on
on
your
own
local
network.
That's
something!
That's
currently
possible
right.
E
B
So
yeah,
so
this
is,
I
mean
this
just
to
kind
of
echo.
Some
of
what
wes
was
saying.
This
is
a
very
broad
rc
and
I
the
way
that
I
read
this.
I
don't
think
that,
like
there's
nothing
for
the
cli
to
do
differently
right,
it's
essentially
all
happening.
E
One
side,
yeah,
one
small
part,
I
think,
is
where
it
installs
packages
it
it
would.
It
would
check
if
the
license
is
in
agreement,
so
so,
if
the
like,
it
would
check
if
the
company
pays
enough
pays
enough
monthly
to
cover
the
requirement
of
the
licenses
as
an
opt-in.
B
Yeah,
even
that
could
be,
you
know
a
server-side
thing
or
it
might
be
overly
sort
of
overly
tied
to
one
particular
provider
to
do
in
the
cli
right.
You
kind
of
you
kind
of
want
that,
because,
if
it's,
if
it's
doing
the
the
license
enforcement
client
side
a
like
it's,
it's
easy
to
circumvent.
B
E
If
somebody
wants
to
get
a
next
license,
yeah,
we
thought
about
that
as
well.
It's
it's!
Never
we're
never
trying
to
force
companies
to
do
anything.
It's
just
they
want
to
be
in
in
accordance
with
their
licenses.
Otherwise,.
B
Right
so
the
other
I
mean
the
bigger
thing.
Even
you
know,
if
you
don't
worry
about
people
circumventing
it,
we
you
know
assume
we're
all
acting
honorably,
even
if
you
make
it
just
a
warning,
you're
kind
of
you're
putting
the
warning
in
front
of
the
person
who
can't
really
solve
the
problem.
B
So
you
know
I
I'm
a
developer
at
netflix
and
I
run
npm
install
and
I
get
this
thing
and
it
says
oh
you're,
out
of
compliance
with
the
license
and
I
go
okay.
Maybe
I
should
email
somebody
about
that
and
then
I
go
back
to
work,
a
more
effective
approach
which,
from.
F
Personal
experience
there
pushing
through
strong
support
for
open
source
funding,
as
I
see,
is
difficult,
so
I
just
totally
agree
with
isaac
here.
Being
that
engineer
at
netflix
and
and
wanting
to
fund
open
source,
it
doesn't
mean
I
can
just
flip
a
switch
and
we're.
Suddenly
you
know
compliance
with
the
license
requirement.
There.
B
Yeah,
it
very
much
sounds
like
somebody
else's
problem
right,
and
I
mean
this
is
different
from,
for
example,
security
notifications,
where
a
warning
at
install
time
is
putting
it
right
in
front
of
the
person
who's
like
in
the
middle
of
this
thing
and
ready
to
fix
it
right.
So
the
and
also
understands,
what's
being
asked
of
that
or
is
more
likely
anyway,
to
understand,
what's
being
asked
of
them
and
so
on.
So
I
think
that
the
a
better,
a
more
effective
approach
is
probably
to
do
that.
B
You
know
do
that
tracking
and
and
compliance
verification,
server
side
and
then
like
send
an
email
to
the
to
the
operator.
That's
like
hey
you're.
You
know
you
basically
only
only
chase
down
the
the
big
offenders.
So
if,
if
google
is
installing
your
thing
enough-
and
they
they
owe
you-
you
know
ten
thousand
dollars
a
month-
well,
you
go
after
them
and
you
don't
worry
about.
You
know
the
some
tiny
startup.
E
B
B
There's,
there's
really
no
way
to
like
to
require
that
people
only
go
through
your
proxy
in
order
to
get
your
package
unless
you
only
publish
it
in
that
proxy,
which
is,
you
know,
presents
some
challenges
right
now.
You.
E
E
Let
me
give
a
counter
example
there:
if
someone
puts
a
license
and
says
you
cannot
use
it
commercially
but
pushes
it
to
github,
then
that's
exactly
the
same.
The
same
thing
right:
if
someone
still
uses
it
commercially,
they're,
just
not
in
accordance
with
the
license,
that's
their
problem,
if,
if
there's
ever
an
audit
from
their
company
or
from
a
company
that
looks
to
acquire
them
and
they
see
oh
you're
using
software
without.
F
B
It's
just
no,
but
I'm
it's
more,
it's
more
about
the
accounting
getting
out
of
whack
right.
So
you
know
if
the
the
default
place
where
I
install
packages
from
is
not
going
to
be
tracking
this
info,
then
that's
kind
of
that
makes
the
whole
accounting
process
challenging.
B
So
I
think
that
you
know
the
the
the
answer
here
or
maybe
kind
of
the
next
steps
or
the
direction
is
that,
like
this
is
really
a
more
of
like
a
a
business
partnership
proposal
between
github,
you
know
github
or
like
the
github
npm
product
team
and
open
source
pay
it
forward
or
open
collective
or
some
other
group,
and
I
know
I
mean
I
know
that
there
are
conversations
around
this
like
there's
a
lot
of
ideas
and
product
stuff,
that's
kind
of
already
in
process
of
being
ideated
and
developed
and
tested
for
github
sponsors
and,
for
you
know,
hooking
that
into
the
npm
npm
funding
info.
B
B
B
And
then
license
zero
kind
of
acts
as
like
the
the
license
license
broker.
B
But
there's
no,
you
know,
there's
no
tracking
or
accounting
and
the
the
the
payment
requirements
are
subtly
different
from
open
source
pay
it
forward,
because
you're
not
you're
not
requiring
that
they
pay
into.
You
know
a
proxy
that's
going
to
get
allocated
or
distributed
you're
requiring
that
they
pay
you
yeah,
but
that.
B
E
B
On
my
radar,
but
it's
similar
in
structure,
but
the
the
the
payment
allocation
is
different.
There's
no
reason
why
now
the
thing
with
that
I
like
about
license
zero
is
the
the
licenses
are
created
by
are
have
been
crafted
by
some
of
the
like
honestly,
like
the
most
experienced
legal
minds
in
open
source,
so
they're
they're,
pretty
airtight.
B
The
the
other
thing
is
it's
very
flexible
about
like
what
counts,
what
counts
as
adequate
payment
in
order
to
get
an
exemption,
so
you
could
take
license
the
license,
zero
license
and
say:
well
we're
going
to
be.
You
know
this.
The
the
way
that
you
get
an
exemption
is
by
paying
into
this
sort
of
broader
fund,
which
then
gets
allocated
based
on
reasons,
but
in
both
of
these
cases,
so
I
mean
I
would.
B
I
would
explore
that
as
just
kind
of
a
a
particular
legal
instrument
for
for
how
the
license
works
and
like
what
something
that
is,
you
know
likely
to
be
enforceable
and
and
kind
of
has
a
at
least
a
little
bit
of
analysis,
but
put
in
it,
maybe
more,
maybe
less
than
what
you've
already
done.
B
I
don't
know
exactly,
but
the
the
bigger
the
bigger
issue
is
that,
like
this
is
probably
something
to
take
to
kind
of
the
the
github
github
sponsorship
team
or
or
like
the
npm
product
managers,
rather
than
because
I
don't.
I
don't
see
much
that
the
client
has
to
do
differently
here
right.
I
see
miles
you're.
C
Raising
yeah
just
hi,
I'm
a
product
manager
over
at
github
who
works
on
npm.
If
you
want
to
find
time
to
chat
one-to-one
I'd,
be
happy
to
chat
with
you.
I
will
be
honest.
I
do
a
lot
of
my
work
in
open
source
foundations
and
you
know
have
a
very
different
idea
of
sustainable
open
source
than
many
folks
do.
But
I
also
recognize
I've
worked
for
many
corporations
on
open
source,
so
I'm
also
coming
from
a
very
different
place,
but
just
kind
of
throwing
my
bias
up
there
to
start
with.
C
But
one
thing
that
I
think
is
important
to
point
out
here
as
well,
is
like
there
is
ongoing,
contentious
debate
around
the
definition
of
open
source
which
is
currently
owned
by
the
osi,
and
whether
or
not
some
of
these
licenses,
which
you
know
require
payment
for
certain
things
like
these
licensed
zero
licenses.
That
isaac
is
talking
about
whether
or
not
they
qualify
as
open
source.
C
That's
not
to
say
that
they're
good
or
bad.
It's
not
a
value
judgment,
but
I
do
think
it
would
probably
be
good
to
if
you
haven't
yet-
and
maybe
you
have
do
some
research
into
like
kind
of
the
the
existing
debates,
discussions
and
and
where
that's
landing.
C
And
if
you
ping
me
it's
just
my
name
at
github.com,
I
can
try
to
dig
some
stuff
up
for
you,
but
how
you
frame
it
will
be
important
here,
especially
like
if
you
want
to
be
talking
to
lawyers
or
folks
who
are
working
on
this
stuff
at
a
professional
level,
because
if
you
frame
it
as
open
source,
you
may
get
a
lot
of
pushback.
C
Now
with
that
being
said,
there's
lots
of
people
who
still
think
that
this
can
be
open
source,
but
there's
a
whole
process
of
going
through
and
having
a
license
and
be
accepted
as
official
by
the
osi
I'll
stop
rambling.
But
but
that's
something
that
might
be
good
to
do
some
more
research
into
and
I'm
happy
to
point
some
resources
in
your
direction.
B
So
I
mean
I
I
like
this,
because
it
is
at
least
sort
of
aiming
at
what
I
call
like
the
20
bill
problem
with
github
sponsors
and
with
kind
of
the
npm
funding
and
a
lot
of
the
patreon
stuff
like
because
we're
just
sort
of
sharing
the
it's
like
developers
asking
for
payment
from
other
developers
and
with
very
rare
exception.
It
ends
up
being
a
relatively
small
pool
of
people
passing
the
same
money
around
you
know.
B
So
I
get
I
get
20
a
month
for
my
open
source
and
then
I
take
that
and
I
spend
it
on
somebody
else's
open
source
and
they
take
it
and
they
spend
it
on
somebody
else's
like
nobody's
actually
getting
their
rent
paid,
except
for
like
two
or
three
people
at
the
very
top
right-
and
I
mean
like
cinder.
Sorghus
is
probably
one
of
the
only
npm
users
who's
actually
paying
his
bills
with
open
source
donations.
B
There's
this
small
number
of
others
who
you
know
maybe
supplement
or
able
to
kind
of
justify
working
more
on
open
source
than
they
would
otherwise.
But
it's
not
it's
not
actually
paying
like
tax
salaries
that
you
could
get.
If
you
were
to
not
work
on
open
source
right
so
like
the
financial
decision
is
still
like,
I
should
just
be
working
on
proprietary
products,
or
I
should
find
a
company
that
wants
to
fund
the
project.
B
I
want
to
work
on,
like
you
know,
like
my
case
the
so
the
only
you
know
and
part
of
the
challenge
here
is
that
the
companies
with
the
most
the
groups
with
the
most
money
to
spend
on
this,
like
figuring
out
what
open
source,
microsoft
or
google
or
or
whoever
else
are
even
using,
is
really
challenging
and
then
figuring
out
how
much
they
should
spend
on
each
one
is
challenging
and
now
you've
got
the
procurement
problem
of.
Like
you
know,
are
we
really
going
to
go
through
this?
B
Our
bulky
procurement
department's
process,
for
you
know
30
a
month
bill
like
no
just
throw
it
in
the
trash
like
it's
not.
You
know
it's
not
worth
the
time,
so
you
basically
have
to
come
to
them
with
like
okay,
here's
here's
like
two
grand
a
month
that
you
need
to
be
spending
and
we
will
figure
it
we'll
make
sure
that
it
goes
to
the
right
places
and
this
this
will
get
you
into
compliance
on
these.
You
know
5
000
packages
you're
using
so
like.
B
If
you
don't
have
that
kind
of
roll-up,
it's
it's
really
really
hard
to
make
any
progress
in
a
meaningful
way.
Yeah.
E
That's
exactly
what
we're
trying
to
solve
like
lower
the
friction
for
companies
to
to
give
back
and
and
get
everyone
a
piece
of
the
pie.
B
And
also
inc,
you
know
the
the
the
license.
Change
also
increases
the
friction
for
them
not
to
give
back,
which
is
important
because
they
have
you
know
they
can't
just
do
spend
money,
because
it's
the
right
thing,
because
they
have
shareholders
who
have
invested
their
money,
and
you
know
like
unless
there's
a
financial
reason
to
do
it.
They
a
lot
of
companies
actually
have
kind
of
an
ethical
obligation.
B
Not
to
you
know
we
could
not
not
ethics
in
the
sense
of
like
broadly,
what
is
right
and
wrong,
but
ethics
in
the
sense
of
like
they've,
made
an
agreement
to
do
a
certain
thing,
and
now
they
have
to
follow
that
if
you,
if
you
give
them
a
license
like
hey,
look
you're
in
you're
in
danger
of
being
sued,
and
so
now
like
the
fiscally
responsible
thing
is
to
pay
this.
This
bill.
E
Definitely
if
the
bill
like
what
we're
proposing
is
that
some
library
owners
might
put
one
one
dollar
a
month
in
there
and
then
the
company
is
only
obliged
to
pay
one
dollar
a
month.
But
if
every
company
that
ever
uses
that
package
pays
one
dollar
a
month,
it's
still
a
large
amount.
B
B
E
Oh
yeah,
the
proposal
does
not
require
them
to
to
add
up,
but
that
we
could
still
look
at
that
if
that's
needed
or
not,
but
it
would
just
be
one
dollar
a
month
and
it
just
gets
them.
It's
a
bit
like
getting
your
credit
card
information
into
your
app
store
once
you
once
you
went
through
the
process
of
paying
something,
then
the
whole
payment
process
is
set
up
and
then
it's
a
lot
easier
for
the
company
to
say.
E
B
Exactly
exactly
but
yeah,
I
think
I
think
next
steps
here
is
to
kind
of
pursue
more
of
like
the
server
side
and
corporate
angle.
A
B
D
I
am
kind
of
going
off
the
rails
here,
but
I
would
say
it's
hard
to
convince
my
boss
to
give
a
certain
sum
of
money
to
open
source
every
month,
even
though
we
do
contribute
to
open
source.
It's
just
I
don't
know
I
would
imagine
it
would
also
lead
to
a
lot
of
interesting
questions
like.
D
Why
do
you
use
so
many
packages,
blah
blah
blah?
That
kind
of
thing
and
the
thing
that
I'm
kind
of
wondering
is
first
of
all,
does
this
need
to
happen
in
npm?
Maybe,
like
I
don't
know
a
github
action
or
something
would
be
just
as
nice
or
what
I'm
also
thinking
is
like
when
you
have
like
the
launch
party
or
like
the
go
live.
D
Maybe
you
could
get
some
kind
of
like
report
like
the
packages
you
benefited
the
most
from
and
then
maybe
companies
for
just
one
time
would
be
willing
to
give
a
significant
amount
of
money.
I
don't
know
just
my
thinking
when
everybody
is
kind
of
like
we
launched
it's
cool,
it's
a
one-time
commitment.
We
can
see
it
helped
us,
I
don't
know
just
a
thought
because,
like
sometimes
I
just
install
a
package
to
try
something
and
I
get
rid
of
it
immediately
because
I
notice
it's
not
the
thing.
E
Yeah,
that's
also
a
good
point.
Number
of
installs
would
then
be
a
metric
for
that.
I
guess
and
that's
also
a
good
argument
that
you
give
for
not
adding
up
the
amounts,
because
then
you
put
the
burden
on
the
developer,
hey.
Why
are
you
installing
that
this
much?
If
you
don't
do
that,
then
it
just
stays
at
the
the
most
expensive
package
that
you
installed.
That's
the
the
upper
limit
of
how
much
you
have
to
pay
and
then
they
can
still
go
for
hey.
E
A
I
see
you
wanna,
I
just
I
just
noticed
miles
had
raised
his
head
for
it.
Do
you
have
anything
else
to
add
mouse.
C
Very
quickly
and
we
don't
need
to
dig
into
it-
I
just
want
to
prod
that
installs
are
not
necessarily
the
best
metric.
Some
people
install
something
once
and
then
have
it
running
for
millions
and
millions
of
requests
in
a
month.
So
just
something
to
think
about
people
who
are
testing
locally
may
install
a
whole
bunch
of
times.
I
don't
think
it's
necessarily
the
best
metric.
The
other
thing
to
consider
is
perhaps
separating
how
payout
happens
and
how
collection
happens.
C
As
isaac
was
saying
for
some
companies
a
single
contract
for
a
large
sum
of
money
once
a
year,
maybe
a
better
way
to
pool
resources.
So
you
know,
especially
if
it's
not
tied
to
a
license.
It
could
be
hey
we're
funding
this
organization
that
funds
open
source
just
another
angle
to
think
about
it.
A
I
appreciate
the
birth
yeah
and
we
can
follow
up
in
the
the
rfc
itself,
all
right
yeah,
let's
just
move
on
to
at
least
the
next
one.
I
know
it's
an
important
one
that
isaac
wants
to
talk
about,
which
is
rfc
number
210,
rfc
pure
specific
overrides.
I
know
kitten
just
joined.
A
I
wonder
if
maybe
killing
want
to
make
an
introduction.
Otherwise
I
think
it's
fine
to
let
isaac
go
over
yeah.
G
G
Basically
it's
about
the
I'm
sorry
yeah
give
me
one.
Second,
it's
about
the
old
like
anik,
with
how
the
pure
installs
weren't
really
mandatory,
that
all
you
got
was
message
and
that's,
basically,
it
the
rest
of
the
program
and
now
new
way
of
working,
and
there
are
actual
issues
raised
and
no
proper
installs
formed.
If
the
peers
don't
match
and
depending
on
the
development
environment,
you
have,
you
can't
match
those
peers
or
the
mechanism
to
get
those
peers.
G
That
mpm
does
will
reject
development
versions
and
prereleases,
which
I
don't
think
is
bad,
but
which
can
cause
problems
like
that,
so
the
basic
idea
is
of
a
way
yeah
to
have
an
override
specific
to
to
peer
dependencies.
G
B
So
yeah,
so
I
think,
if
we're,
if
we're
gonna
contemplate
this,
the
the
main
thing
that
I
would
want
to
dig
into
is
figure
out.
What
like
what
is
a
peer-specific
override
feature,
have
that
the
sort
of
core
overrides
feature
doesn't
because
I
I
do
think
that
we're
we're
going
to
have
an
implementation
soon
of
of
overrides,
not
not
super
soon.
B
But
you
know
in
early
early
7.x
release,
that's
kind
of
the
plan
and
what
I
don't
want
to
do
is
get
into
a
state
where
you
know
that
somehow
conflicts
or
or
is
an
over
confusingly,
similar
to
peer
overrides.
B
B
B
This
is
this:
is
the
pure
depth
that
conflicted
here's,
what
it's
a
dependency
of
you
know,
here's
the
thing
that
you
depend
on
like
these
are
the
two
things
that
are
colliding
with
each
other:
go
fix
it
or
run
with
legacy
pure
depths,
so
my
yeah
so
then
kind
of
the
the
other
thing
that
I
was
wondering
is:
if
there's
some
other,
you
know
maybe
subtler
way
that
we
can
solve
this
problem.
B
For
example,
if
we,
if
we
resolve
pure
depths
in
such
a
way
that
we
allow
pre-releases,
that
might
actually
fix
the
whole
typescript
issue
that
you
just
brought
up
and
since
pure
depths
do
tend
to
be
or
ought
to
be
sort
of
a
broader
dependency
range
anyway.
You
know,
if
you
specify
appeared
up
of
12.x
and
my
root
dependency
is
12.1.2
dash
beta,
then
right
now,
it'll
treat
that
as
a
conflict,
because
that
that
beta
tag
will
not
match
on
12.x.
B
However,
I
think
it's
this
is
actually
already
brought
up
in
in
another
channel.
I
don't
recall,
I
think,
on
slack
somewhere,
but
if
we
allowed
pre-releases
in
pure
depth,
then
that
would
actually
make
things
a
lot
easier
and
somber.
You
know
that
that's
a
relatively
easy
thing
to
to
add.
Obviously
that
will
be
a
problem
if,
if
there
is
no
other
pure
depth,
no
other
thing
depending
on
that
pure
dependency.
B
So,
for
example,
I
have
you
know
this
pure
depth
of
12.x
and
then
a
beta
ships
and
let's
say
that's
the
only
reason
it's
being
brought
in
is
because
of
the
peer
dep
and
then
a
beta
ships.
Now
I'm
going
to
start
pulling
in
the
beta
version
that
I,
that
might
be
sort
of
unstable,
so
there's
a
little
bit
of.
I
have
a
pending
task
to
write
up
an
rfc
for
that
just
so
we
can
kind
of
dig
into
that.
Some
of
those
concerns.
B
F
Yeah,
I
hesitate
with
my
bad
internet,
but
it
might
be
worth
taking
a
quick
look.
I
know
this
is
something
I've
talked
about
with
my
java
colleagues
about
you
know.
Gradle
has
a
bunch
of
features
around
dependency
resolution
like
this,
because
they
have
a
much
worse
dependency
resolution
story
than
node,
but
you
might,
you
might
want
to
check
out
some
of
the
stuff
that
they
have
and
I
think
that
overrides
actually
solves
all
of
those
problems.
I've
been
comparing
it
to
their
platform
and
I
think
what
you
know.
F
They
don't
have
the
peer
dep
problem,
but
it's
the
same
style
of
problem
that
they
have
when
they
need
to
provide.
Basically,
an
alignment
rule,
I
think,
is
what
they
call
it
right,
which
is
where
two
things
depend
on
slightly
different
sunburies
and
I
say
several
ranges,
but
it's
not
always
even
sunburns,
but
two
different
ranges
and,
and
they
need
to,
they
want
to
align
them
right,
which
is
really
what
you're
saying
is.
I
have
a
bunch
of
things
with
typescript
with
a
whole
ton
of
slew,
of
different
peer,
dep
ranges.
F
What
I
want
to
do
is
align
them
all
to
be
one
right
and
I
think
the
override
spec
actually
allows
for
that.
It
might
be
a
little
verbose
because
you
may
have
to
like
call
out
a
bunch
of
specific
dependencies,
but
even
the
way
it
stands,
I'm
pretty
sure
you
at
least
can
do
it.
B
Well,
with
the
overhead
spec
as
it
in
the
rfc
right
now,
it's
you
could
just
say:
typescript,
you
know
version
x
and
it
will
be
anything
that
depends
on
typescript
anywhere
in
your
project.
We'll
get
that
version.
Yeah.
F
I
guess
type
scripted
is
maybe
a
bad
exam,
because
you'd
only
want
one
yeah.
I
guess
I
meant
like
if
there
was
situations
where
you
needed
multiple
for
some
reason
like
typescript
and
react,
are
probably
bad
examples
here,
even
though
those
are
the
most
common
peer
deps,
but
something
where
it
was
like.
It
was
all
right
if
you
had
multiple,
but
you
would
like
to
prefer.
B
Right
so
eslint
and
babel,
or
some
other
ones
where,
where
we
see
a
lot
of
peer
depths
that
are
just
using
it
as
a
library
and
the
pure
depths
are
actually
kind
of
overly
strict
in
a
bunch
of
these
cases,
and
I
think
overrides
would
would
solve
those
problems.
You
know
another
way
you
said
gradle
doesn't
have
the
pure
depth
problem.
I'd
actually
phrase
that,
as
gradle
only
has
the
pure
depth
problem,
because
all
of
their
dependencies
are
flat.
B
Yeah.
True.
A
Yeah
awesome
so
yeah
killian.
Do
you
have
any
more
thing
anything
else
to
add
before
we
close
our.
G
Topic,
the
overrides
would
certainly
solve
this
issue.
It's
like
the
just
depends
how
long
like
this,
the
estimated
time
is
for
each
for
just
the
other
overrides
to
arrive.
G
B
Yeah,
I
think
I
mean
I'm
I'm
eager
to
I'm
eager
to
get
it
get
to
overrides
as
soon
as
possible
it.
It
doesn't
just
solve
this.
It
actually
solves
a
handful
of
other
kind
of
very
sticky
problems
where,
where
users
do
want
to
be
able
to
override
things-
and
it's
it's
similar
to
like
the
yarn
resolutions,
which
is
a
very
popular
feature
there,
the
yeah
and
I
have
a
I
have
pages
of
like
diagrams
and-
and
you
know,
pseudo
code
from
our
previous
discussions
of
override.
B
So
I
think
we're
actually
in
a
pretty
good
place
to
start
to
start
implementation
on
it.
It's
just
that
we've
been
fixing
beta
bugs
instead,
which
is
sort
of
higher
priority
once
the
once
v7
goes
to
ga,
probably
sometime
in
early
mid
september,
like
the
next
couple
of
weeks.
Overrides
is
kind
of
the
next
big
feature
that
that
we're
going
to
start
tackling.
G
I'm
just
like:
is
there
a
way
to
contribute
like
directly
to
overrides
in
or
is
there
a
preferred
way?
Let's
say
that
way.
B
Yeah,
I
think
it's
it's
going
to
be
pretty
like
in
the
weeds
in
arborist,
which
I
mean.
I
see
that
you've
already
kind
of
kind
of
dived
into
that
that
code
base
a
bit
so
yeah,
I
would
say,
I'd
recommend,
let's
sync
up
on
either
the
the
dojs
or
node,
tooling,
slacks
or
the
openjs
slack
anywhere
anywhere.
You
can
find
me
and
we
can,
you
know,
try
to
sort
of
figure
out
like
what's
what's
a
way
to
start
tackling
it.
B
I
I
honestly
haven't
even
begun
like
slicing
up
how
the
implementation
would
actually
work
because
sort
of
the
the
the
spec
for
the
algorithm
needs
to
be
worked
out
first,
but
you
know
I
would
suspect
it's
a
couple
of
weeks
of
work.
It's
not
it's
not
months.
F
So
I
just
want
to
say,
though
I
think
killing
brings
up
a
great
point-
that
as
soon
as
you
go
general
access
with
installing
pure
depths,
all
these
people
are
going
to
come
out
of
the
woodworks
and
be
like
hey,
hey.
I've
got
all
these
conflicts,
it
tells
me
I
have
30.
what
am
I
supposed
to
do
and
you
are
going
to
get
a
pretty.
I
would
bet
a
pretty
big
influx
of
support
requests
so
it
might.
F
B
Yeah
I
mean
that's.
The
the
nice
thing
is
like
about
kind
of
what
the
functionality
that
we
have
right
now
when
we
have
an
error
message
that
explains
it
in
a
little
bit
more
human,
understandable
terms
than
just
unable
to
resolve
peer
to
unable
to
resolve
package
tree.
That
will
make
things
a
little
bit
better
and
having
that
error
message
also
print,
you
know,
look
you
can
run
with
this
flag
and
you'll
be
fine.
B
I
think
the
majority
of
the
of
the
people
who
encounter
that
will
just
take
that
advice
right,
they'll,
just
add
that
flag
and
they'll
go
on
with
their
work
and
assume
that
everything's,
okay,
which,
honestly,
if
everything
was
fine
in
npm
six,
then
it
will
keep
being
fine
with
legacy
peer
dapps
because
that's
exactly
how
it
works.
This
is
auto.
B
Installing
pure
depth
is
really
more
of
an
issue
for
like
new
projects
that
have
a
pure
dependency
or
have
an
old,
outdated
dependency
they're,
not
even
using
so
a
couple
of
the
cases
where
you
know
where
we
found
those
conflicts
in
our
early
testing.
B
We
reached
out
to
the
package
authors
and
like
hey,
I'm
getting
this
error.
What
do
you?
What
do
you
say
and
they're
like?
Oh,
I
don't.
I
shouldn't
be
depending
on
that
and
remove
it.
So
I
think
the
the
you're
right
like
we
will
get
people
complaining.
There
will
be
more
call
for
overrides
as
soon
as
seven
goes.
Ga,
but
a
better
error
message
will
do
an
awful
lot
to
switch.
That.
A
Right
so
with
that
being
mindful
of
time
here,
I
think
we
have
to
wrap
up
the
discussion,
but
thank
you
killing
for
for
showing
up
and
talking
about
that.
We
appreciate.
E
A
Contribution
all
right
and
sorry,
I
know
meta
a
proposed,
a
couple
of
issues.
We
were
eager
to
discuss
and
been
following
on
youtube,
but
there's
yeah
time's
up
there's
no
more
time,
but
I
think
we're
gonna
try
to
put
that
in
the
beginning
of
the
agenda
for
next
week.
So
to
all
of
you,
you're
all
welcome
to
come
back
again
next
week
and
any
anyone
else
like
meta.
That
was
just
following
on
youtube.
A
B
One
so
the
ad
registry
identifier
to
publish
prompt
and
the
new
command
npm
clone
that
I
know
that
I
was
following
I've
posted
comments
on
both
of
those
which,
and
I
think,
they're
they're.
All
probably
we
can
move
forward
with
most
of
them.
Their
registry
per
package
on
the
same
organization
is
is
also
really
interesting.
Expect
some
some
notes
on
that
and
I'd
love
to
talk
about
next
time.