►
From YouTube: 2020-10-20-Package Maintenance Team meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
welcome
to
the
node.js
package
maintenance
team
meeting
for
october
20th
2020.
we'll
follow
the
agenda
that
was
generated
in
the
repo
in
issue
417..
Before
we
get
started,
does
anybody
have
any
announcements
they'd
like
to
share.
B
Right
would
like,
would
you
like
to
share
what
we
just
did
about
five
minutes
ago.
C
Oh
yeah,
we
just
got
a
new
patch
release
for
npm
cli,
we're
yeah
we're
following
up
with
patches
for
v7,
and
I
guess
the
big
announcement
for
today
is
v15
right
for
node.js
right
yeah.
Thanks
bet,
that's
right!.
A
A
Okay,
let's
move
on
to
the
first
issue,
then
so
the
suggested
list
of
modules
to
get
help
to
help
get
support
info
into
that
one
oops.
Sorry,
I'm
just
trying
to
open
that
up
that
one
we
opened
after
discussion
last
time.
I
meant
I
thought
I'd
commented
in
that
I'm
going
going
to
work
on
node
add-on,
node,
add
on
adding
it
to
a
node,
add
on
api.
E
A
A
Basically,
you
know
the
idea
is:
is
you
know
if
we
can
get
volunteers
or
among
ourselves,
work
on
different
ones
to
start
moving
that
forward
just
comment
in
there:
the
the
module
that
you're
gonna
you're
gonna
work
on,
so
that
we
avoid
overlapping
or
make
suggestions
of
ones
we
think
are
important,
and
so
I
don't
know
if
there's
anything
more
to
talk
about
that
one
this
time
other
than
just.
If
people
have
time
it'd
be
great.
If
we
could
start
working
that
forward.
A
E
Yeah,
I
think
the
the
discussion
was
sort
of.
We
have
a
scope,
we
have
to
manage
the
user
permissions.
I
I
just
wanted
to
make
sure
we
had
the
discussion
and
we
sort
of
have
had
the
discussion
and
I
think
dom
it
looks
like
you
were
the
last
one
and
said:
can
we
close,
I
think
so
I
think
maybe
we
can
close.
I
mean
I
I'm
not
I'm.
We
don't
really
have
it
yeah
do
we
have
us.
Did
we
arrive
at
the
conclusion?
That
was
the
question.
F
Yeah,
from
my
perspective,
yeah,
we
discussed
the
pros
and
cons
and
we
said
that
I
don't
know,
I
know
what
did
we
say?
Did
we
arrive.
F
That
publishing
in
two
namespaces
in
the
global
namespace
and
in
the
scope,
namespace,
is
extra
work
and
a
bit
wasteful
with
unclear
benefits.
Does
that.
E
F
F
There
was
it
does,
it
does
work,
but
it
has
a
gotcha
in
that
if
your
scoped
name
matches.
So
if
you
have
something
which
is
at
scope,
slash
pkg
and
you
have
a
binary
which
is
called
pkg.
Then
npx
will
happily
execute
that,
regardless
of
of
that,
so
there
is
a
namespace
collision
in
terms
of
naming
the
package
when
it's
installed
in
dot
bin.
F
E
But
that
is
independent
of
our
strategy
here
right,
so
it
was
just
sort
of
like
do.
We
want
to
risk
pushing
people
toward
that
particular
gotcha,
and
I
think
the
answer
is
no,
but
also
now
that
npm
7
is
out.
Maybe
have
you
all,
I'm
looking
at
darcy
murray,
I
sort
of
tested
those
workflows
to
see
if
those
bugs
have
been
fixed
in
seven,
because
if
they
have
maybe
we
you
know.
G
I
mean
it's
worth
following
up
with
darcy
and
folks,
I
think,
to
make
to
ensure
that
that's
fixed,
but
even
if
it's
not
it's
going
to
be
a
long
time
before
everybody
upgrades
to
npm
7
or
later
so
I
don't
know
if
that
really
resolves
the
issues
it
just
kind
of
is
a
good
thing
to
fix.
E
Yeah,
I
guess
most
of
our
target
audience
are
probably
people
who
are
excited
about
mpm7
and
probably
have
installed
it
already.
So
I'm
not
super
concerned
for
our
packages
anyway.
Totally.
This
is
maybe
a
digression
on
on
the
issue,
so
I
think
you
know,
I
guess.
If
we
we
agree,
dual
publishing
is
not
not
going
to
go
where
so
that
oh,
the
other,
only
other
thing
right.
The
added
step
is
anytime.
Anybody
publishes
a
non-scoped
package.
E
H
H
F
F
Either
it's
under
a
next
this
tag
right.
Can
I
have
a
quick
question
regarding
npx,
then
so
that
we
can
close
that
side?
Is
there
a
plan
for
npx
on
six,
the
backboard,
either
backport
or
whatever?
Is
there
any
kind
of
plan
any
specific,
I'm
just.
B
The
issue
should
probably
go
against
the
the
cli
repo
today,
so
there's
a
deprecation.
We've
got
a
backlog
ticket
to
actually
put
a
deprecation
notice
on
the
readme
for
mpx,
but
yeah.
That's.
This
is
sort
of
tangential
to
I
think
yeah,
yeah
yeah,
sorry.
E
F
E
And
I'll
make
a
quick
comment
on
this
issue.
Just
saying
the
only
remaining
thing
is
document
that
the
the
when
you
publish
a
non-scope
package
you
have
to
transfer
ownership,
I'm
not
entirely
sure
where
that
gets
documented,
probably
in
the
charter
doc
or
something
but
I'll
I'll.
Try
to
find
it.
E
No,
no,
the
answer
is,
do
what
you
want
when,
as
the
maintainers
of
the
project?
Okay,
that's
what
you
think
is
best
so
like
we're
not
going
to
move
pkg.js
whatever
those
couple
other
random
ones
that
are
published
under
the
scope,
like
there's
no
point
in
moving
them,
it's
just
if
it
makes
sense
for
will
I
break
you
to
publish
under
w-I-b-y,
then
then
that
makes
sense
for
that
project
and
we'll
just
move
forward
with
the
sort
of
freedom
to.
B
Yeah,
so
I
saw
that
chris
was
the
last
to
comment
on
this
in
terms
of
the
question
for
like
why
we
even
want
to
do
this,
or
why
this
is.
Is
that
right,
chris.
B
Yeah
yeah
no
problem.
I
I
think
that
this
came
out
of
over
a
year
ago,
when
the
support
spec
support,
json,
spec
and,
and
that
discussion
came
around,
we
were
talking
about
how
npm
in
it
could
potentially
help
support
the
adoption
of
that
and
from
that.
B
Like
the
the
support
schema
and
the
recommendations
in
terms
of
that
so
support
team,
I
think
is-
is
has
a
whole
bunch
of
information
about
it
that
which
is
almost
like
a
quasi-sla
and
that's.
G
B
Yeah,
so
that's
like
historical
like
how
this
came
about
was
oh,
how
can
npm
help
to
support
pushing
forward
like
best
practices
and
standards
that
this
group
decides?
It
is
and
and
sort
of
like,
and
also
broadly
like?
How
can
we
do
a
better
job
with
npm
to
almost
like
privilege,
this
in
a
more
meaningful
way
and
the
create
pkg
package
came
up
because
it
aligns
with
essentially
package
maintenance
and
like,
as
you
can
see,
like
the
way
that
it
could
be
executed
and
ron
looks
very
much
like
it's.
B
It's
like
a
privileged
package
template
or
in
it.
So.
E
And
there
was
a
couple
of
other
examples
other
than
just
what's
coming
out
of
this
group.
We
were
thinking
of
things
like
the
type
field,
so
that
got
brought
up
as
an
npm
rfc
to
add
to
a
knit
there's
the
exports
and
the
general
idea
is
relying
on
npm
to
scaffold
to
do
all
that
work
and
keep
up
with
it
is
more
difficult.
E
You
know
as
an
approach
and
it'd
be
better
if
it
was
community
owned.
So
like,
as
you
know,
the
modules
team
decides
to
roll
out
exports.
They
in
theory
could
come
to
us
and
say
here's
a
here's,
a
package
that
that
implements
scaffolding
up
the
exports.
Can
we
just
pr
it
into
the
pkg
js
create
repo,
and
then
that
would
be
what
we
point
people
to
and
then
they
get
the
the
benefit
of
all
those
new.
E
E
Like
look,
we're
gonna,
give
you
some
some
good
things
that
we,
as
the
package
maintenance
team,
have
vetted
and
worked
with
the
rest
of
the
you
know,
node
project,
to
provide
to
you,
but
you
can
also
go
and
add
you
know
your
own
and
that's
where
you
know
the
architecture
proposed
in
the
in
that
document
is
sort
of
to
like
help.
This
be
a
better
foundation
than
npm.
Init
is
today
for
those
kind
of
workflows.
D
Okay,
that
makes
sense.
I
think
you
answered
questions
I
was
going
to
ask,
but
but
didn't,
but
yeah
community
owned
seems
like
a
good
idea.
B
E
Would
is
useful
and
also
there's
things
like
you
know
if
we
follow
a
model,
like
crate,
react
depth,
there's
no
reason
it's
not
usable
totally
outside
of
you
know,
npm
or
whatever
you
know
so
that
so
that
people
can
start
integrating
more
deeply
into
their
tooling,
but
still
have
that
sort
of
kernel
at
the
foundation,
which
is
what
we
say.
Okay,
look.
These
are
the
things
coming
out
of
the
node
project
that
are
best
practices.
These
are
what
you
should
be
following.
E
B
Yeah,
so
that's
that's
to,
I
think,
give
an
update
of
why
we're
doing
this
and
why
this
like
looks
advantageous
in
terms
of
an
update.
I
haven't
had
any
time
based
on
recent,
doubling
down
of
efforts
to
get
get
npm
out
the
door
to
work
on
this,
I'm
not
sure.
If
wes,
you
have
any
updates.
E
I
I
do
and
they're
all
sitting
on
my
local
machine.
I
just
need
to
push
the
stupid
code.
I
went
through
and
I
got
a
functional
version
of
that
package
that
I
had
already
started
and
then
wrapped
it
up
into
this.
You
know
this
name
and
then
I
think
I
tried
I
should
have
just
pushed
the
code.
Instead,
I
tried
to
write
some
tests
to
prove
that
it
actually
was.
E
And
then
you
know,
I
that's
how
it's
been
sitting
so
maybe
maybe
maybe
I
can
carve
out
some
time
for
that
real
soon.
I
I
feel
bad
because
I
was,
I
said
I'll
just
set
the
foundation.
I
just
need
to
push
the
code
even
if
it's
broken,
somebody
else
can
fix
it.
If
they
have
time.
B
You
actually
try
to
cut
like
a
first,
even
if
it's
I'm
not
sure
what
version
we're
at
based
on
the
fact
that
we've
transferred
over
ownership
of
the
create
package.
But
could
we
even
try
to
get
like
a
first
version
like
published
or
like
a
pre-release?
Maybe.
E
Yeah,
technically,
that's
what
I
have
that
I
just
I
like.
I
said
I
sort
of
left
off
with
incomplete
tests
and
I
was
being
a
perfectionist
when
I
probably
shouldn't
have
been,
but
I
think
probably
it
was
functional
before
I
even
I
mean
I
all
this
code
was
stuff.
I
wrote
a
couple
years
ago,
mostly
so
like
it
was
pretty
functional,
so
we
could
probably
just
push
it
as
a
as
a
beta
and
and
get
you
know.
The
ball
rolling
sounds
good.
D
Real
quick
was
this
intended
to
be
like
an
interactive
tool
or
yeah.
Okay,.
E
Well,
a
little
bit
of
both
so
the
way,
specifically
the
problem.
The
code
that
I
have
that
is
there
is
specifically
to
solve
the
fact
that
it
should
be
invokable
by
in
ci.
It
should
be
something
you
could
integrate
into
your
m
or
your
own,
more
robust
scaffolding.
Suite
so
say
you
have
like
a
yeoman
generator
that
your
team
uses
instead
of
you
having
to
like
re-implement
what
we
provide.
E
E
A
Okay,
so
let's
move
on
to
the
next
one,
which
is
suggest
ignoring
a
vulnerability
by
the
package,
maintainer
number
386..
I
think
this
actually
wes.
You
wanted
to
talk
a
little
bit
about
the
collaboration.
Space
is
a
good
time
to
jump
in
there.
E
Yeah
good
point,
so
there's
been
a
bunch
of
discussions
around
this
historically
like
for
years,
and
this
is
sort
of
the
culmination
of
a
lot
of
those
discussions,
so
some
of
them
are
happening
in
npm,
specifically
I'll,
probably
maybe
let
darcy
talk
a
little
bit
about
that
side,
but
the
collaboration
space
and
the
goal
so
michael
proposed
this
to
the
open
jazz
foundation.
E
The
idea
is
there's
certain
times,
there's
these
cross-cutting
issues
and
we
don't
really
have
like
a
good
place
to
host
those
conversations.
This
particular
one
in
theory
should
touch
npm
yarn
sneak.
You
know
the
package
maintenance
working
group
like
a
bunch
of
different
groups,
other
security,
researchers
and
and
reporting
companies.
E
E
Can
we
find
some
proposal
that
everybody
can
get
at
least
a
little
bit
behind
and
we
can,
then
you
know,
help
improve
the
situation,
so
outcomes
from
the
collaboration
space
that,
I
think
would
be
sort
of
goals
would
be
like
getting
npm
yarn
sneak.
Whoever
else
runs
a
pnpm.
Whoever
else
runs
like
an
audit
call
to
sort
of
buy
into
some
sort
of
proposal
for
how
we
would
change
reporting
that
to
the
user.
Another
viable
option
would
be.
E
We
actually
go
and
talk
with
some
of
the
major
players
here
and
get
them
to
agree
to
change
their
entire
reporting
ecosystem
practices.
Right,
like
there's
a
lot
of
things,
we
could
have
as
an
outcome
from
the
collaboration
space,
but
the
the
real
goal
is
like
just
reduce
the
frustration
that,
like
maintainers,
are
taking
the
brunt
of,
but
then
even
for
end
users,
when
they
see
you
know,
40
000
audit
results
in
a
project
they
haven't
touched
in
six
months
and
and
they're
like
what?
What
what
am
I
supposed
to
do?
E
So
that's
the
goal
of
the
collaboration
space,
I'm
trying
to
think
what
is
the
next.
Oh,
the
next
step
is,
we
have,
I
think,
we're
trying
to
set
up
our
first
quick
discussion
meeting.
Is
that
going
to
be
open?
How
what's
the
structure
I.
A
Think
I
think,
like
I
darcy
and
wes,
have
champ
had
volunteered
so
far
to
be
champions,
so
just
we're
setting
up
on
on
friday
at
a
time,
for
you
know,
wes,
darcy
and
myself
to
write
up
the
proposal
for
the
collaboration
space.
Anybody
else's
who's
interested
is
welcome
to
join
as
well.
A
You
know,
and
then
that
will
you
know,
I
think,
we'll
get
reviewed
fairly
quickly
by
the
cpc
and
then
you
know
we
will
have
a
repo
in
the
open
gs
foundation
where
we
can
set
up
meetings.
We
could
have
like
an
auto
meeting
scheduler,
just
like
we
have
for
this
one
and
and
so
forth.
A
B
Yeah,
I'm
just
gonna,
say
plus
once
everything
was
said
and
then
also
to
what
michael
said
so
yeah
I've.
I
guess
to
top
that
up.
You
know.
We've
definitely
had
these
discussions
for
over
a
year
now
over
in
the
npm
rc
calls,
but
I've
also
been
having
internal
discussions
at
github
with
security
folks,
including
dependable
ems
and
and
other
folks.
There
and
they're
interested
in
participating
in
this,
so
yeah
bring
more
people
in
and
and
again
like
moving
the
discussion
to
something
like
the
clap
space.
B
I
think
makes
sense
so
yeah
make
sure
that
we
we
do
something
that's
impactful
here
and
I
I
think
that
it
could
be
multi-faceted
too,
like
I'm
not
looking
for.
I
don't
think
we
should
be
trying
to
create
like
a
silver
bullet,
because
there
isn't
one
to
this
problem,
but
yeah
I'm
excited
to
to
move
this
forward.
So
thanks
for
the
help
michael
and
pushing
this.
A
Yeah
and
thanks
definitely
to
weston
and
darcy
for
volunteering
to
champion,
because
that's
that's
very
important,
so
yeah.
I
think
in
terms
of
the
message
if
anybody
would
like
to
be
invited
so
chris
you'd,
like
if
anybody
like
to
be
invited,
just
shoot
me
a
message
and
I'll
invite
you.
So
I
see
chris
who
I'll
add
and
if
anybody
else
wants
to
to
join.
Just.
Let
me
know.
A
B
A
Exactly
like
it's
like
here's,
here's
the
explanation
for
why
the
collaboration
space
makes
sense,
here's
the
champions
and
here's
what
we
want.
You
know
here's
what
the
the
group
needs
to
move
forward
like
a
repo
or
the
zoom
meeting
or
whatever
you
know
that
just
a
quick
outline
of
the
resources
that
we
think
makes
sense
to.
A
If
not,
let's
move
on
to
271.
271
is
pkgs
org
for
workgroup,
supported,
tooling,
opening
that
up
I'll
just
quickly
chime,
in
that
I
I
did
add
the
get
the
moderation
onboarding
dock
updated
to
include
covering
the
pkgs
side
and
onboarded
the
moderation
team.
A
So
I've
checked
off
the
you
know:
the
moderation
team,
access
and
tc
members
access.
I
think
we
just
have.
Let's
see
I
think
dominicus
has
already
had
mentioned
a
few
things
added,
would
be
detect,
node
sport
and
depends
to
pkgs
and
pm
org,
create
teams
for
above
and
added
the
node.js
foundation
account
to
all
the
above
teams.
So
thank
you
very
much
for
that.
F
E
F
A
I
Did
we,
I
don't
remember,
did
I
did
we
switch
to
enforce
the
we
did
not?
I
was
just
checking.
E
A
A
A
E
Couldn't
we
just
put
it
on,
could
we
just
save
it
into
the
the
last
path
and
just
say
the
first
time
somebody
needs
it?
We
can
deal
with
it.
Then
right,
like
we
don't
need
people
aren't
logging
into
this
all
the
time.
It's
not
like
it's
a
big
deal,
no.
A
F
Can
you
can
always
export
the
seed?
It's
it's
it's
inside
the
qr
code,
so
you
get
the
qr
code.
I
just
rotated
my
two
last
weekend,
so
yeah
it's
in
the
qr
code
and
you
can
just
use
yeah.
You
probably
need
some
sort
of
software
that
can
do
that,
but
I
know
that
the
optic
tool
that
we
built
for
2fa
it
can
scan
qr
codes
and
it
will
give
you
back
the
seed
so.
A
E
Okay,
I
did
turn
it
on
on
all
the
ones
I
had
published,
but
I
guess
we'll
have
to
go
through
the
list.
So
that
will
be
something
we'll
have
to
add
to
the
to-do
list.
When
people
create
a
new
package,
they'll
all
have
to
go
and
turn
that
on.
B
Unfortunately,
right
now,
there's
there's
been
subtle
improvements
and
some
stuff
backlogged
for
for
improvements
around
this,
as
I'm
sure
you've
seen
published
tokens
also
just
came
yeah.
B
Yeah,
that
should
be
a
check
check,
check
box
for
when
you're
publishing
or
bringing
in
a
new
package
to
the
to
the
org
or
the
scope.
A
A
E
The
other
window
I
couldn't
unmute,
I
just
made
a
comment
on
the
publishing
strategy,
which
I
have
to
download
the
steps
or
assuming
in
ownership.
So
I'll
just
add
this
into
that
as
well
and
I'll.
Do
the
I'm
literally
going
through
the
packages
right
now
so
I'll
make
sure
it's
enabled
on
all
of
them,
so
no
need
to
do
a
tracking
issue.
Okay,
perfect.
A
A
A
Okay,
so
let's
move
on
to
the
next
issue,
then,
which
is
okay,
all
complete
closed
next
step
for
next
steps
on
support
levels
in
package.json.
A
I
think
we've
covered
that
under
the
suggested
list
of
modules
413
is
there
anything
else,
people
think
we
should
talk
about
right
now
on
that
one.
A
E
F
E
But
yeah
dependence
will
I
break
you
and
detect
node
support.
I
I
can't
edit.
G
A
G
G
G
H
G
I
mean
the
the
readme
says,
maintain
or
needed,
and
although
there's
a
few
people
that
have
the
implication
from
looking
at
that
closed
issue,
is
that
you
know
he
because
of
all
the
incidents
he
doesn't
want
to
pass
on
maintainership.
G
In
other
words,
he
doesn't
want
to
maintain
it
or
they
don't
want
to
maintain
it
by
themselves,
but
they
also
don't
want
to
be
the
next
event
stream.
So
it
does
kind
of
seem
like
a
trusted.
Part
of
the
node
organization
would
be
a
help
to
this
maintainer
because
they
can
be
assured,
hopefully
that
passing
that
adding
us,
as
anyone
in
this
group
as
maintainers,
does
not
expose
the
package
to
those
security
concerns.
G
Oh
so,
the
issue
link
I'm
looking
at
is
number
29
on
the
query
string
repo.
I
just
went
hop
to
the
npm
package
to
its
repo
to
the
first
link,
and
it's
read
me
thank
you
and
there
is
an
issue
somewhere
on
the
package
maintenance
repo,
but
I
also
don't
have
that
on
hand.
G
It's
418.,
so
yeah
I
mean
if
the
maintainer
is,
is
content
to
just
like,
never
publish
it
again
and
just
leave
it
as
finished.
Then
that's
also
fine,
but
that
also
seems
like
it
would
be
helpful
to
kind
of
close
outstanding
issues
and
pull
requests
and
update
the
readme
to
indicate
that
and
perhaps
npm
deprecate
everything
and
so
on,
and
if
that's
not
what
they
want
to
do,
and
they
also
don't
want
to
maintain
it.
Then
it
also
seems,
like
perhaps
you
know,
it's
a
worthy
module
to
request
that
we
take
over.
J
And
forgive
my
unawareness
of
the
depth
of
package.json
npm,
but
could
it
also
is
there
a
process
here
for
things
like
this,
where
you
know
you
can
add
a
flag
or
piece
of
metadata
to
package.json,
try
and
get
the
maintainer
to
do?
One
last
publish
that
says
you
know
go
over
here
or
I
guess
not
like
a
post
install
but
kind
of
like
that,
where
you
can
flash
a
message
that
says:
hey.
G
Yeah,
so
you
don't
even
have
to
do
a
publish,
you
can
do
npm
deprecate
specifier
at
version
range
and
pass
a
message
that
will
be
displayed
on
install,
so
we
don't
even
have
to
publish
any
updates,
just
update
the
repo
and
then
like
npm
deprecated,
if
that's
in
fact
what
they
want
to
do
so
they
may
not
want
to
do
that.
I
don't
know
but
like.
H
Should
we
just
take
an
action
to
contact
him?
I
can
follow
up
on
that.
Just
say:
like
we
contact
him,
we
make
the
best
effort
to
contact
them
and
ask
them
these
questions.
What
do
you
want
to
do?
What
what's
your
intent?
Is
your
intent
just
to
leave
it,
and
you
want
to
mark
it
as
deprecated
and
we'll
just
follow
up
with
that,
because
it
does
have
quite
a
few?
Is
it
12
million
downloads.
H
G
J
A
J
We
can
make
the
rules
yeah
like
yo,
yeah,
presidents
yeah
exactly
so
playbook
one
could
be
like
you
know.
First,
you
know
create
an
issue
in
your
repository
and
then
potentially
also
create
an
issue
with
the
package
maintenance,
say
you're
looking
for
some
help.
You
know
if
you
can't
effectively
transfer
ownership.
That
may
be.
The
next
best
thing
is
to
you
know,
update
the
readme,
put
it
in
maintenance
mode,
maybe
even
go
so
far
as
like
deprecated
at
least
then
there's
some
kind
of
steps
because
to
different
points.
J
You
know
at
some
point,
maybe
something's
just
kind
of
done,
and
you
know
it's
just
good
the
way
it
is
or
at
some
point
it
just
also
is
you
know
not
meant
not
intended
to
carry
on
past
a
certain
point.
So
maybe
there's
legitimate
cases
where
transferring
is
not
the
right
solution.
Just
kind
of
spinning
the
project
down
is
the
right.
So.
G
I
mean,
I
think
we
should
maybe
start
sketching
out
some
rough
drafts
of
what
that,
like
kind
of
guidebook,
might
look
like.
I
think
that
the
most
useful
thing
will
be
to
actually
have
that
be
informed
by
a
case
study
that
we
did
where
we
like
made,
where
we
kind
of,
because
we're
going
to
be
making
for
each
package
right
a
lot
of
case-by-case
decisions
that
like
what's
like
so
for
query
string.
Let's
say
the
combination
of
what
the
maintainer
wants
with
its
download.
You
know
like
it's
its
reach
with.
G
What's
the
best
choice
for
this
package
right
is
that's
we're
gonna
have
to
be
asking
ourselves
a
lot
of
questions
to
like
decision
tree
our
way
to
what
we
do
and
those
questions
are
worth
documenting
and
like.
Even
if
we
don't
know
what
the
other
answers
will
be.
Yet
just
saying
we
asked
ourselves
this
question,
and
this
answer
led
us
down
this
path
right
and
then,
as
we
add
more
case
studies,
we
will
be
able
to
flesh
that
out
and
we
may
come
up.
D
J
This
opportunity,
as
like
pilot
to
get
to
a
first
draft
and
then
just
iterating
on
it
from
there
as
more
cases
and
form
options
or
maybe
part
of
it,
is
also
from
like
a
self-service
perspective.
Maybe
what
questions
or
you
know
what
could
have
maintainer
asked
of
themselves
in
terms
of
like
yeah?
What
do
I
really
want
from
this?
You
know.
Do
I
just
want
to
hand
it
over,
like
you
know,
but
yeah
to
your
point,
you
know:
could
they
yeah?
J
Could
we
also,
in
the
process
of
this
help,
present
questions
that
they
could
ask
themselves
so
things
to
think
about,
as
you
think
about
what
you
want
to
do
with
your
package
and
then
based
on
what
you
want
to
do
it's
like
kind
of
a
choose,
your
adventure.
You
want
to
deprecate,
you
want
to
transfer,
it
could
be
a
progression
right.
It's
like
okay.
I
tried
finding
other
people
no
one's
stepping
up
to
help.
I
really
can't
do
this,
but
I
want
to
be
a
responsible
member
of
the
package
community.
Then
it's
like
all
right.
J
If
you
know
nothing
else
works,
and
maybe
we
recommend
like
try
it
for
a
month
or
three
months
or
something
make
the
issue
and
just
repo
and
then
maybe
the
you
know
the.
If
it's
not
what
you
wanted,
but
there's
no
other
option,
then
maybe
the
final
stage
is
like
then
just
deprecate
because
at
least
then
you
communicate
that
you
know
no
one
else.
Listen,
maybe
the
people
will
listen
in
the
the
console.
You
know,
and
at
least
no
no,
then
it's
not
just
like.
J
I
just
sold
it
to
a
bunch
of
you
know
whatever.
I
don't
want
to
get
into
that
right.
Yeah,
no
defender
issue,
but
you
know
whatever.
F
We
do
have
a
dock
in
the
drafts
or
from
before
for
duplicate
guidelines.
J
Okay,
I
can
maybe
I
don't
mind
picking
those
up.
Maybe
I
could
do
a
draft
or
something
or
I
know
that
we
also
yeah.
So
I
know
that
we
also
have
some
links
on
the
readme
to
kind
of
give
breadcrumbs
to
more
of
our
documentation.
I
don't
know
if
it's
worth
singling
this
one
out
specifically,
so
it
can
be
easily
kind
of
linked
to.
But
I
guess,
if
there's
a
doc
in
the
docs
director,
you
can
just
as
easily
link
that,
but
we
can.
G
J
A
J
Right:
okay,
yeah:
I
got
a
top
level
item.
A
J
Yeah,
it's
pretty
complete,
so
yeah,
it's
probably
out
of
it
wasn't
in
my
tracking
document.
So
let
me
paste
it
in
if
anybody
wants
to
check
it
out.
I
don't
know
if
it's
just
something
we
want
to
get
out
of
drafts
anyway,
so
pr
might
be
just
just
to
move.
It
gets
at
least
on
the
agenda
for
discussion.
J
Yeah
and
yeah,
we
can
do
that
in
the
context
of
this
discussion,
so
we
can
get
some
extra
apply,
some
additional
context
as
we
get
ready
to
merge
it
in
you
know
we
can
just
update
the
pr,
so
I
could
probably
do
that
by
next
week.
If
glenn
has
a
chance
to
do
some
outreach
and
then
we
can
kind
of
merge
or
we
can
discuss
those
two
in
a
couple
weeks
and
you
know
figure
out
if
we
need
to
do
any
updates
in
either
case.
J
J
A
A
A
A
Next,
one
dependency
management,
this
one
dominikas,
you
opened.
F
F
There's
one
point
that
we
haven't
come
to
a
conclusion
on
with
jordan
and
I
wasn't
sure
how
to
reward
it.
I'm
not
sure
if
it's
this
one
but
yeah
yeah.
So
that's
why
I've
been
putting
that
off.
Okay
for
a
while,
I
I
I
need
to
find
a
way
to
reward
it
so
that
we're
both
happy
with
the
boarding.
So
unless
somebody
else
can
chip
in
I'm
just.
G
Reading
it
yeah,
I
think
my
I
mean
this
was
a
while
ago,
but
I
think
my
yeah
that
that
comment
on
the
last
comment
there
is,
I
think
I
I
think
it's
a
good
idea
to
consistently
and
frequently
emphasize
the
downsides
to
having
a
shrink
wrap
in
packages
we
shouldn't
like
it.
It
would
be
a
bad
thing
if
we
accidentally
encouraged
people
to
do
that.
F
One
I
I
don't
mind,
although
we
do
have
that
mentioned
somewhere
in
the
text.
I
think
it
was
more
about
the
decision,
whether
you
want
a
dependency
or
don't
want
the
dependency
and
whether
building
your
own
or
taking
one
from
the
wild
is
is.
F
Is
that
this
one
something
we
should
be
recommending
or
not
recommending?
And
let
me
see
no
okay
for
me,
I
think
it's
the
yeah.
This.
F
G
Yeah,
so
this
one
is:
there's
there's
a
minor
trend
with
like
some
folks
in
the
ecosystem,
where
they
kind
of
they
they
use
the
term
they
use
dependencies
as
a
negative
term,
meaning
like
they
what's
the
word,
I'm
looking
for
they
put
things
on
pedestals
that
have
zero
dependencies
and
they
out
have
an
outsized
measure
of
the
downsides
or
the
costs
of
adding
a
dependency,
and
I
think
that
catering
to
that
those
attitudes
is
actually
a
really
bad
idea
for
the
ecosystem,
like
the
reason
the
ecosystem
is
large
is
because
people
have
lots
of
dependencies
and
because
they,
you
know,
what's
the
word,
I'm
looking
for,
like
they
modularize
their
code,
a
lot
yeah
and-
and
it's
fine-
if,
if
that,
if
my
perhaps
other
end
of
the
spectrum
of
of
severely
preferring
lots
of
small
dependencies,
isn't
something
we
encourage,
I'm
not
trying
to
push
my
viewpoints,
I'm
trying
to
be
very
sensitive
to
things
that
crush
my
viewpoints.
A
A
G
G
You
have
a
list
of
licenses
that
they're
cool
with
which
are
usually
mit,
isc
apache
2,
and
you
know
perhaps
a
few
others,
and
that
covers
like
95
of
your
depth
graph
and
there's
definitely
some
so.
So
it's
not
the
addition
of
a
dependency,
that's
a
problem.
It's
the
addition
of
a
dependency
with
a
license,
that's
undesirable
and
similarly
like
the
addition
of
a
dependency
with
the
security
vulnerability
or
the
addition
of
a
dependency
with.
You
know
a
compile
step
or
something
like
there's.
G
It's
fine
to
be
nuanced
in
those
discussions,
and
I'm
certainly
not
trying
to
suggest
that
at
least
in
any
official
documentation
that
more
dependencies
is
always
better
but
but
like.
I
think
that
it's
it's
important
that
our
documentation,
just
as
we
would
want
to
avoid
a
strong
push
towards
a
viewpoint.
We,
I
think
it's
really
important,
that
we
avoid
encouraging
fud
in
the
end.
F
This
is,
should
you
build
it
yourself,
yes,
line,
28,
okay,.
A
G
It
right
yeah
and
I
apologize
if
I
like,
since
I've
clearly
failed
to
look
at
the
update.
This
looks
fine
to
me.
I
think
that
this
this
this
isn't
as
strong
as
a
document.
I
would
want
to
write
myself
for
myself,
but
it
is
definitely
it
avoids
the
the
like
strong
concerns
that
the
original
phrasing
gave
me.
So
I
think
this
is
great
and
thank
you
for
updating
it.
G
F
A
So
that's
that
new
one,
okay,
I
was
just
surprised
we
we're
getting
we're
going
backwards.
We
resolved
one
there's
one
new
one
anyway,
not
really
dependency
management.
We
just
talked
about
tools:
beveri's,
automation,
tooling,.
E
I
think
we
shouldn't
have
this,
so
I
I've
been,
you
know,
we've
had
a
list
like
this
for
express
for
years
and,
to
be
honest,
it's
just
more
of
a
pain.
Half
of
things
are
out
of
date.
If
you're
not
regularly
keeping,
you
know
up
with
it,
it's
just
pointing
people
in
bad
directions.
G
Everyone
may
or
may
not
agree
that
the
existing
ones
should
be
there
right
like
and
it
we
could
certainly
come
to
a
decision,
but
it
there
will
inevitably
be
a
time
when
somebody,
some
maintainer
will
try
to
add
their
own
packages,
and
we
all
think
that
they're
bad
packages
and
we
would
end
up
hurting
that
maintainers
feelings
by
not
accepting
that
request
and
it
would
be.
I
think
it
would
be
best
if
we
avoided
that
mine
field,
that
hypothetical
minefield
you.
A
A
G
E
E
Thanks,
can
I,
since
we're
going
through
pr's,
can
I
add
one
topic
for
hopefully
a
very
quick
discussion
and
we
may
need
to
open
up
a
pr
sorry.
An
issue,
though,
can
we
switch
main
to
master
domain
since
we're
going
through
these
we'd
be
really
easy
to
just
do
them
all
in
one
fell
swoop,
and
I'd
be
happy
to
open
that
pr
as
well.
A
E
We
can
we
should
probably
wrap
up
since
it's
over
time.
I
I
wanted
to
throw
that
one
in
there
just
because
you
know
you're
trying.
Sometimes
you
just
have
to
make
that
you
just
have
to
make
it
happen,
and
if
everybody
here
is
like,
you
know
good
with
it,
I'll
just
do
the
change
and
we
don't
even
need
to
revisit,
because
it
should
just
be
happening
across
all
node
projects.
E
A
Cool
okay!
Well
then,
thanks
for
everybody
for
taking
the
time
we're
a
couple
minutes
over
so
we'll
close
out
and
we'll
talk
to
everybody
in
github
and
see
you
in
a
couple
weeks.