►
From YouTube: Package Maintenance Team meeting - Dec 17th
Description
A
Okay,
so
we're
live
so
welcome
to
the
first
node.js
community
package,
maintenance
team
meeting,
and
we
were
just
starting
to
talk
a
bit
about
the
process
for
meeting
meetings
themselves
and
so
we'll
just
carry
back
on
that.
So,
as
I
was
just
outlining,
we
followed.
You
know.
The
typical
agenda
has
the
announcements,
things
that
were
tagged
with
package
maintenance
agenda
from
across
the
project,
question
and
answer
for
anybody
who's
watching
on
the
YouTube
stream
I'm.
A
A
A
So
the
question
is,
is
you
know?
How
do
we
choose
that
that
recurring
meeting
time
I
might
suggest
that,
since
this
turned
out
to
be
a
good
time
for
a
good
number
of
participants?
Maybe
we
choose
this
as
a
starting
point,
but
because
we
also
know
that
there
you
know
there
were
a
number
of
people
who
couldn't
make
this
time
and
we
do
have
people
across
the
world.
A
We
might
want
to
choose
another
team
time
which
is
more
favorable
for
people
who
can't
make
it
to
this
particular
time
and
then
alternate
between
those
two
different
top
times.
The
other
thought
I
do
have
as
well
likely.
You
know,
given
the
number
of
people
that
showed
interest,
I
need
to
break
out
into
smaller
groups
as
well,
so
we
might
adjust
based
on
that
later
on.
But
you
know
maybe
just
start
with.
We
could
choose
two
times
if
that
makes
sense
to
people.
A
D
A
Depends
what
time
slot
that
is
and
how
far
off
it
is
like,
if
it's
say
8:00
or
9:00
Eastern,
which
is
but
seven
eight
hours
earlier
than
this
I
can
still
host
that,
if
it's
earlier
than
that,
then
I'd
look
for
somebody
else,
I
think
Matteo
is
is
in
that
time
zone.
So
he's
probably
can
time
probably
more
available
to
do
something
earlier
right.
C
E
Thing
we
should
probably
try
and
do
is
make
sure
that
in
the
two
different
meeting
times,
there's
as
much
overlap
as
possible
so
that
we
don't
kind
of
have
to
separate
groups,
rice
cussing
things
past
each
other.
So
there
might
be
a
time
that's
best
for
like
other
parts
of
the
world
that
makes
it
really
hard
for
the
people
in
this
time.
So
and
this
time
slot
to
join
in,
and
we
should
try
and
maximize
that
overlap
right.
A
A
Think
you
know
what
we
ended
up
on
the
TSC
for
Inferno
GS
was
we
have
won,
it
I
think
it's
8:00
a.m.
Eastern,
it's
current
11:00
Eastern
and
5:00
Eastern,
which
were
the
three
and
so
maybe
I'll.
Try
the
you
know
this.
This
matches
its
close
to
one
of
them,
I'll
see
if
I,
if
either
the
other
two
one
seemed
it
to
work
out
for
people.
A
A
Okay,
so
the
next
one
is
the
the
meet
of
the
meeting
where
we,
you
know:
I
outlined
a
few
initial
goals
that
I
had
in
mind,
but
I
think
it's
worth
spending
time
to
see
if
people
have
additional
goals
that
we
should
add
to
that
list
and
then
sort
of
go
through
each
of
them
and
figure
out.
Okay,
what's
the
first
step
on
those,
do
we
have
volunteers
to
start,
pushing
them
forward
and
and
so
forth,
so
I
guess
the
first
question
would
be.
A
The
second
one
is
building
and
documenting
guidance
tools
and
processes
that
businesses
can
identify
to
figure
out
what
they
depend
on
and
understand.
You
know
how
and
why
they
should
help
contribute
to
those
packages
because
of
that
dependence.
Third
one
was
documenting
a
backlog
and
providing
resources
to
help
businesses
identify
how
their
developers
can
ramp
up
and
get
engaged.
A
So
basically,
that's
you
know
trying
to
not
necessarily
take
on
all
that
work,
but
enable
that
enable
people
to
get
volunteer
and
get
involved
in
that
work.
And,
finally,
the
fourth
one
was
building
and
documenting
and
evangelizing
guidance
tools
and
processes
that
make
it
easier
for
maintainer
to
mean
to
manage
multiple
streams
and
accept
help
from
those
who
depend
on
the
module
and
I
think
you
know.
The
recent
example
of
you
know,
part
of
that.
G
Yes,
so
I've
been
trying
to
help
in
any
way
I
can
for
a
perhaps
a
couple
of
years
and
I
think
the
biggest
problem.
I
think
this
pad
is
the
job
you
are
doing.
The
management
of
this,
but
also
the
onboarding
process,
I
think
that
comes
on
to
the
splitting
into
subgroups,
because
what
I'm
willing
to
do
almost
anything
to
help
that
mean
this
is
putting
my
kids
through
college
and
I
taught
I
do
is
node
all
day
long.
There
is
often
not
a
process
for
bringing
somebody
on
board
year.
I
can
build
it.
G
Yes,
so
what
yeah
even
good
instructions
for
that,
but
as
soon
as
you
get
beyond
that
simple
things
like
you
wanted
help
with
Jenkins
builds
other
things.
There
doesn't
seem
to
be
like
the
onboarding
process
and
nobody
seems
to
have
time
and
I
think
that's
actually
the
real
problem
you
have.
You
may
agree
or
disagree
with
it.
H
G
Say
I
am
willing
to
help,
but
it's
a
bridge
to
get
between
coming
in
from
outside
and
the
current
maintainer
of
any
part
of
the
node
infrastructure
right,
a
big
gap
and
what
their
it
needs
to
be
some
sort
of
handhold.
You
know
this
is
the
way
we
do
it
I'll
stop
there
because
there's
enough
people
in
the
core,
but
I,
think
you
know
that
that's
probably
an
issue
already
yeah.
A
I
As
a
fifth
one
to
me
to
me,
that
actually
seems
like
a
sub
bullet
point
of
the
resources
for
documenting
processes.
Right
because
that's
really
just
a
process
that
any
module
ecosystem
would
need
to
have
a
good
foundation
for
right,
unborn.
A
new
participants
is
that
maybe
not
just
a
subset
of
providing
that
kind
of
Docs.
Everyone.
A
Yeah
I
think
that
I
think
you're
right
in
that
it
fits
under,
but
I
think
it
fits
under
other
ones
as
well.
So
like
it
definitely,
you
know
part
one.
One
piece
would
be
the:
how
do
you
help
maintain
errs
sort
of
accept
help
and
there
could
be
a
standard
practice
for
that?
I
think
that
it
might
fit
also,
though,
under
like
documenting
the
backlog.
A
So
if
we
actually
build
the
backlog-
and
you
say
okay,
these
are
the
things
we
think
are
important
as
a
team
to
be
worked
on,
but
you
know
this
team
isn't
gonna
be
able
to
do
all
that
work.
So
how
do
we
onboard
people
to
help
they
don't
necessarily
have
to
come
and
participate
in
the
work
of
you
know,
setting
up
the
processes,
but
we
also
want
people
who
are
just
gonna,
say
well.
I've
got
cycles
to
help
with
that
particular
module.
How
do
we
onboard
them
so
that
they're
engaged
and
know
what
to
do?
A
And
you
know
and
it's
it's
kind
of
related
as
well
to
the
business
one
where
it's
like?
Okay
businesses?
How
do
we
get
them
engaged
to
say
to
their
people?
Hey,
yes,
you
have
time
to
go
work
on
this,
so
but
I
think
calling
it
out
is
something
on
its
own.
Just
so
we
don't
forget
about
it
and
across
all
of
them,
probably
makes
some
sense.
In
my
mind,.
E
E
I
would
have
signed
up
to
join
and
you've
kind
of
mentioned
this
a
little
bit
but
like
I,
think
that
at
some
point,
there's
too
many
people
to
have
a
productive
meeting,
and
so,
while
it's
awesome
that
we
get
as
many
people
as
possible
to
help
with
whatever
they
can
help
with
that's
not
the
same
thing
as
wanting
as
many
people
as
possible
in
the
regular
meetings
and
you
know
making
decisions,
so
it
might
be
useful
to
maybe
create
like
in
the
modules
group.
We
have
this
observer
category
in
this
member
category.
E
We
might
to
decide.
Yes,
we're
gonna
focus
first
on
making
recommendations
to
NPM
or
we
might
decide,
let's
not
focus
on
that
now
and
that
can
help
us
triage
as
people
file
a
bunch
of
suggestions
about
that
are
really
NPM
problems
like
either.
We
say
great,
that's
part
of
that
initiative,
or
we
say
thanks.
E
Things
and
I
feel
like
for
personally
I
feel
like
we
shouldn't
be
in
the
business
of
taking
ownership
of
a
package
or
orchestrating
maintain
ership
of
a
package
until
we
have
a
agreed
upon
and
publicized
and
generally
accepted
by
the
community
list
or
guide
as
to
what
those
best
practices
are,
in
other
words,
I.
Don't
think
we
should
try
to
follow
practices
we
haven't
established
yet,
but,
like
that's
my
personal
opinion
and
we
can
decide
a
group,
if
that's
the
order,
we
want
to
do
it
in,
but
I
think.
A
A
E
Like
identify,
you
know,
it
might
be
useful
to
identify
the
problems
instead
of
with
and
explicitly
focus
on.
No
solutions
are
to
be
suggested,
just
identify
the
problems
and
let's
agree
on
the
problems.
What's
hard
and
you
know,
and
then
we
can
say
what
problems
do
we
want
to
solve,
and
then
we
can
look
at
those
problems
and
say:
can
they
be
solved?
Can
they
be
solved
by
just
note
or
do
they
need
NPMs
involvement?
You
know
like
there's
a
lot
of
ways
we
can
go
about
it
and
I.
E
Don't
really
have
a
huge
opinion
as
to
what
the
best
way
is,
but
I
know
the
current
flurry
of
activity
on
the
reboot
is
I,
don't
think
conducive
to
making
any
progress
anywhere,
and
we
have
to
find
a
way
to
focus
that,
because
programmers
JavaScript
programmers
and
humans
in
general
have
lots
of
opinions
and
to
find
a
way
to
to
narrow
those
down
in
a
way
that
makes
people
feel
like
their
opinions
are
still
wanted.
Even
if
they're
temporarily
not
relevant,
are
temporarily
not
useful
right.
A
Yeah
I
know
I
I
I,
agree
that,
like
you
know,
we
want,
as
a
group
coming
to
go
together
and
say:
okay
of
you
know,
if
these
are
the
things
that
you
know
say
long-term
things
we
want
to
get
to
what
are
the
things
the
concrete
next
steps
we
want
to
do
in
the
next
month,
for
example
right
and
then
make
sure
we
have
volunteers
to
tackle
those
and
then
publicize
those.
So
you're
right,
you
know.
A
So
it's
it's
it's
great
to
have
lots
of
suggestions,
but
we
need
to
have
some
focus
on
and
that's
where
I
was
thinking
you
know.
Hopefully
we
can.
We
can
look
at
what
these
an
existing.
These
initial
areas
were
and
any
other
ones
that
we
think
should
be
the
starting
points,
pick
one
or
two
of
them,
and
you
know,
or
if
we
have
enough
people
to
break
off
into
smaller
groups
as
many
as
that
make
sense,
and
then
say:
okay
for
each
of
those.
What
are
the
the
key
things
that
we
you
know?
A
A
C
A
C
It
was
built
as
a
way
to
create
a
venue
for
different
people
to
talk
and
express
the
different
opinion
and
try
to
see
and
reduce
something,
because
there
was
like
different
opinions
being
a
blocking
progress
in
any
way
in
any
form.
However,
I
think
in
this
specific
case
there
is
a
I,
don't
I
don't
expect
there
is
so
much
of
contention
and
the,
but
that
is
a
lot
of
work
to
do
so.
I
would
prefer
to
follow
the
usual
pattern
of.
Does
anybody
object
and.
C
I
would
like
to
have
this
like.
Let's
see,
let's
do
not
develop
this
process
is
in
isolation
and
then
test
them
out,
but
more
of
an
iterative
approach
where
we
go
slowly
in
the
sense
that
we
have
like
one
project
and
then
we
define
some
ground
rules,
then
we
go
and
pile
it
up
a
project.
Then
we
trait
among
the
wheat
rate
on
this
rather
than
we
do.
C
We
think
a
lot
before
doing,
but
I
will
follow
more.
Let's
learn
how
to
do
this
as
we
go,
because
we
have
no
clue
so.
I
I
have
my
own
my
own
opinion
and
being
up
like
highly
impactful
and
p.m.
author,
but
I
am
NOT
the
most
the
biggest
one
in
any
form
in
one
sense
and
in
the
other
sense
I
am
I
have
no
time.
So
you
have
a
ton
of
modules
that
are
between
my
racket
and
get
my
maintenance.
C
So
this
is
more
or
less
pie,
that's
more
or
less
my
suggestion,
but
we
can
probably
reach
out
to
Dominic
guitar
or
Matias
booze
or
a
lot
of
other
people
that
are
definitely
helpful
and
would
really
be
help
a
glad
to
receive
some
help
in
some
in
some
of
their
modules.
So
that's
kind
of
the
the
situation
where
that's
kind
of
my
proposal
in
that
regard,
and
then
we
extend
it
to
modules
that
we
don't.
We
are
not
be
that
are
authored
by
people
that
we
do
not
know.
Okay,
that
is
my
I
read.
A
B
A
You
know
we
could
reach
out
to
ones
as
Matteo
says,
who
are
pretend
potentially
friendly,
because
we
know
that
the
package
maintainers
are,
you
know,
are
the
node,
the
node
community
or
closely
related
to
start
of
start
testing
out
ideas
and
stuff
like
that.
But
the
first
thing
is
to
really
like
decide
how
we
would
prioritize
like
how
do
we
identify
modules
that
we
think
are
ones
that
we
should
get
engaged
with?
Yeah.
B
So
I
think
I'm,
like
just
looking
at
NPM
down
low
numbers
and
second,
is
we
identify
like
critical
applications
like
anything,
that's
to
do
with,
say
electron
and
we
as
co-editor
like
most
more
some
of
the
popular
apps
out
there
and
we
identify
the
package
they
use.
So
we
create
this
initial
list
based
on
some
of
this
criteria.
We
want
to
pick
and
then
we
maintain
the
of
modules
that
or
authors
wanted
to
look
for
people
to
transfer
over
and
we
facilitated
the
transfer
process.
J
It's
just
that
they
weren't
trustworthy
and
maintaining
it
and
us
creating
a
pool
of
resources
of
people
who
are
willing
to
help
each
other.
Maintain
packages
doesn't
really
solve
this
problem
of
like
how
do
we
deal
with
trust
in
terms
of
when
those
packages
are
handed
off
from
one
another?
So
I
think
before
we
jump
into
like
let's
build
a
model
for
what
important
ecosystem
packages
are.
I
think
we
should
try
and
figure
out
what
we
would
do
with
that
information.
H
B
Lower
my
hand,
but
so
yes
was
just
my
simple
thing
I
want
to
make-
is
that
we
we
want
to
add
in
your
initial
list
of
packages
that
we
are
interested
in
looking
for
popular
apps,
look
if
MPM
downloads,
and
we
want
to
help
out
with
authors
at
the
transfer
process.
So
then
we,
you
know,
we
know
if
any
package
has
recently
transferred
and
we
we
would
add
those
two
and
I
keep
an
eye
on
these
for
a
while
kind
of
thing.
Until
you
know
at
some
point,
we
decided.
Okay.
This
is
trust.
I
First
on
the
trust
thing
I
think
that,
even
if
we
are
a
problem
for
us
to
try
to
solve,
because
even
if
we
have
a
list
of
modules-
and
we
know
what
we
want
to
do
with
them
figuring
out,
who
can
help
in
what
situations
is
is
still
a
problem?
Okay,
I,
don't
think,
there's
anything
we
can
effectively
do
other
than
having
a
popularity
contest
of
saying
people
we
know
or
people
who
contribute
to
node
core,
which
is
just
not
going
to
scale
I.
I
Don't
think,
there's
a
really
good
way
for
us
to
manage
that
so
I
think
a
more
effective
approach
would
be
to
try
to
define
processes
to
notify
users
of
changes,
not
necessarily
managing
actually
handing
it
over
not
managing
trust
and
all
this
stuff,
but
but
coming
up
with
a
way
to
maintain
that
list
of
recently
changed
packages
or
something
like
that.
That
would
help
users
make
decisions
on
their
own
right
like
us,
making
decisions
on
how
gets
it
and
and
who
can
help.
I
A
And
I
was
thinking
along
the
lines
of
like
best
practices
of
what
you
should
do
when
you
do
handover
a
module
or
whatever,
and
if
there's
some
things
that
we
can
say
like
these
are
some
things
you
should
think
about
when
you
do
that
or
whatever
that.
That
could
be
the
kind
of
helpful
thing
so
that
at
least,
if
you're
a
package
owner-
and
you
do
that-
you
can
at
least
feel
comfortable
you've
done.
You
know
something
reasonable
right
without
having
to
figure
out
what
something
reasonable
is
yourself,
which
is
sometimes
quite
difficult.
A
G
K
Okay,
this
is
my
first
time
joining
so
I'm
pretty
excited
about
that
yeah
I.
Think
from
the
goals
that
were
stated,
there
wasn't
anything
specifically
addressing
the
security
aspect
out
of
those
goals
outlined,
there's
just
goals,
focus
on
improving
maintenance
and
the
event
stream
package.
I
think
is
well
from
the
outside
perspective.
It
seems
to
be
what
caused
this
group
to
be
created,
which
is
trying
to
figure
out
ways
to
prevent
something
like
that
from
happening
again
and
I've
gone
through
and
I've
just
done.
K
If
you
know
it
so
for
me
trying
to
figure
out
what
problems
I
actually
need
to
be
solved
here,
there
seems
like
okay.
Well,
this
improve
maintenance
or
node
upgrades
happen
quicker
in
package
versions,
upgrade
quicker,
leaving
less
old
versions,
exposed,
improved
maintenance
processes
that
ease
the
burden.
So
more
packages
are
many
times,
but
then
there's
also
the
security
once
which
is
prevent
attack
vectors
of
unmaintained
packages
being
exploited
from
accidental
security
vulnerabilities.
K
So
the
attack
vector
there
would
be
outdated
dependencies,
but
there's
also
like
prevent
attack
vectors
from
popular
packages
being
exploited
from
intentional
security
vulnerabilities.
So
what
are
these
vectors?
So
it
could
be
a
malicious
dependency
or
malicious
actor,
and
then
how
do
we
reduce
the
damage
of
these
attack
vectors
because
they
think
a
lot
of
the
statement
in
the
goals
is
just
how
to
improve
the
management
process.
Help
maintain
is
reduce
the
burden
of
maintenance,
but
there
isn't
anything
particularly
there
on.
How
do
we
react
when
there
was
a
malicious
intent
or
bad
actor?
K
And
how
do
we
prevent
the
vectors
that
would
cause
you
know,
or
how
do
we
reduce
the
damage
of
a
malicious
package,
or
how
do
we
reduce
the
incentive
of
creating
a
malicious
package,
so
I
think
about
having
that
in
the
goals
like
the
security
concerns?
So
what
specifically
are
problems
that
we're
trying
to
attack
and
want
solutions?
So
we
can
have
buyback
I,
don't
know
things
we
can
check
off
with
a
checklist,
rather
just
something
we
can
continuously
continue
to
and
right.
A
So
just
some
background
with
it
I
actually
was
having
this
discussion
with
a
number
of
people
long
before
that
incident.
So
it
wasn't.
It
wasn't
formed
in
in
response
to
that
particular
security
issue,
but
I
do
agree
that,
having
like
a
specific
goal
of
improving
security
for
the
ecosystem,
directly
called
out
probably
makes
sense.
I've
added
that
into
the
list
there
I
see.
Edgar
has
his
hand
raised.
L
Yeah
so
in
terms
of
being
aware
of
what
the
vectors
are
that
you
know,
problems
are
entering
so
do
we
have
some
sort
of
a
dashboard
or
some
kind
of
logging
system
set
up
where
we
can
all
kind
of
go
in
and
start
to
observe
patterns,
and
maybe
I'm
not
talking
about
like
we
don't
have
to
have
a
Splunk
board
or
something
like
that.
But
just
the
general
idea
of
that
kind
of.
Let
me
run
a
query
that
says
I'm
starting
to
see
problems
coming
in
or
being
introduced.
L
L
Ideas
on
how
we
can
begin
to
aggregate
the
data
around
the
problems
so
that
we
can
start
finding
the
solutions
based
on
the
data
rather
than
what
we
were
talking
about
before,
where
we
hope
that
people
just
observe
enough
individuals
observe
observing
individual
events,
aren't
going
to
be
able
to
observe
the
entire
pattern,
because
that's
the
whole
issue
with
the
maintenance
is
that
no
one
of
us
has
the
time
to
be
everywhere
at
once.
So
some
kind
of
aggregate
place
for
us
to
be
able
to
look
at
the
bigger
picture
together
as
individuals,
yeah
right.
A
Sounds
like
a
big
effort.
What
I
I
could
see
it
making
sense
just
off
the
top.
My
head
is
like
is
acting
as
a
focal
point
for
where
things
could
be
reported
and,
and
then
you
know
a
so,
you
can
start
to
gather
that
data.
Just
from
you
know,
if
it's
not
all
you
know,
as
you
said,
none
of
us
can
be
everywhere,
but
if
there's
somewhere
people
could
say,
oh
I've
seen
this
I
don't
know.
If
that's
like
a
first
step,
we
might
think
about
taking
I.
L
Know
a
lot
of
times.
We
do
these
things
like
that,
where
multiple
issues
will
be
raised
about
a
similar
topic,
because
people
aren't
observing
the
pattern
but
yeah
we
could
maybe
start
out
as
a
low
effort
solution
to
start
out.
Just
kind
of
spending.
Time
like
having
someone
commit,
maybe
have
like
a
git
issue
to
say,
scrape
the
issues
that
we
have
and
see.
A
A
E
Think
that,
like
so,
for
example,
tracking
package
ownership,
that
is
exclusively
an
NPM
concern,
it
would
be
great
to
be
able
to,
like
I,
don't
know,
put
a
list
in
your
lock
file,
of
which
publishers
of
a
package
you
trust,
and
then
it
will
warn
you
when
you
try
to
install
a
package
from
a
new
publisher
or
something
but
like
that's
something.
Npm
has
to
deal
with
pretty
exclusively
and
then
separately
like
if
we're
talking
about
restricting
what
packages
can
do
from
a
security
standpoint.
E
That's
something
the
security
working
group
should
be
handling
and
that's
a
really
hard
problem
to
solve
within
a
way
that
keeps
no
ergonomic
and
like,
but
that's
I,
think
something.
Although
we
I
think
the
package
maintenance
group
should
be
involved
in
those
discussions
and
can
make
recommendations
to
the
security
group
into
NPM
and
I
think
they
will
be
given
their
due
weight.
I
think
that's
not
something
we
should
really
focus
on.
It's
not
that
it
shouldn't
be
solved.
It's
that,
like
that,
that
makes
consuming
packages
easier
that
doesn't
make
maintaining
them
easier.
E
Maintaining
them
is
is
what
my
package
maintenance
group
I
think
should
be
focusing
on,
and
so
I
think,
as
an
echoed
in
the
chat
tracking,
finding
ways
to
track
changes
for
people
and
finding
ways
for
maintainer
x'
to
communicate
to
their
consumers
when
ownership
has
changed
when
that
ownership
like
how
trusted
that
ownership
change.
Is
things
like
that?
You
know
finding
and
documenting
best
practices,
as
we've
said,
but
I
think
that
it's,
it's
definitely
gonna
distract
our
discussions.
If
we
focus
on
installing,
which
is
an
NPM
concern
and
security,
which
is
the
security
groups
concerned.
E
L
A
And
if
we
have,
if
we
have
good
ideas,
we
can
coordinate
with
the
security
working
group.
I
know
that
you
know
in
terms
of
the
work
that's
going
on
on
that
front
too,
but
yeah
I'd
agree
yeah.
We
certainly
can't
we
shouldn't.
You
know
that
the
it's
a
very
the
example
he
had
there
of
like
restricting
what
packages
can
do
is
clearly
out
of
scope.
A
In
my
mind
you
know
it
it's
it's
that
there
are
like
you
know
the
best
practices
if
people
follow
the
best
practices
that
does
help
security
and
at
some
at
in
some
way
right
like
and
when
handing
over
the
packages.
So
it
there's
gonna,
be
some
sort
of
overlap,
slash
fuzzy
line
that
we'll
have
to
keep
our
eye
on.
H
Can
you
guys
hear
me
yes,
okay,
yeah,
my
questions
were
around
more
clarification
with
the
the
boundaries
between
the
security
group
in
package
meetings.
I
mean
I'm,
looking
at
it
from
a
perspective
of
if
I'm
going
to
include
a
package
in
my
project,
if
I
can,
beyond
with
more
information
about,
eight
is,
what's
the
probability
of
what's
the
likelihood
that
somebody
that
was
authorized
introduced
some
kind
of
malicious
code
into
that
package
and
now
to
dependency
my
ecosystem?
H
That's
that's
really
where
my
security
question
was
coming
from
that,
like
security
of
the
the
platform
as
a
whole,
but
when
it
comes
to
trust,
how
do
we
are
there
tools?
Is
that
part
of
our
concern?
Is
that
something
we
should
try
to
corral
information
about
if
there's
a
way
to
automate
that
some
kind
of
static
analysis
with
remote
repositories?
H
If
there
is
some
vulnerability
that
can
pick
up,
it
can
be
picked
up.
That
way.
Would
that
be
something
that
we
would
be
concerned
about
is
party
information?
We
want
to
surface
to
the
no
foundation
for
it
included
dependencies
and,
if
not,
then
it
does
that
does
that
matter?
I
guess:
I!
Guess
that's
where
my
my
question
comes
comes
from
right.
A
But
that
does
sound
like
a
good
question
to
me,
like
do
people
think
that
it's
in
scope
to
say
come
up
with
the
best
practices
for
how
you
should
select
your
dependencies,
which
is
I.
Think
part
of
what
you
just
were
you
know
touching
on
is
like
when
you,
when
you
like
your
dependencies,
you
know
use
these
criteria
and
you're
more
likely
to
you
know
be
choosing
ones
that
are
secure.
Is
that
something
that
people
think
is
is
reasonable
within
our
scope
or
or
not
I,.
I
I've
been
vetting
the
packages
and
I
get
made
fun
of
by
most
of
my
co-workers
for
being
too
rigorous
about
this,
and
it
takes
a
lot
of
time
and
I
still
I'm
sure
I,
miss
things
and
no
maintainer
following
a
best
practice
list,
is
going
to
find
things
like
a
Bitcoin
mining
bug
in
a
malicious
code.
It's
just
not
I
mean
it's
just
not
reasonable
to
to
set
out
I
think
this
goes
sort
of
with
what
Jordan
was
saying
with
like
limiting
the
scope
to
not
be
all
things
for
all.
I
You
know,
let's
really
focus
on
what
maintenance
can
be
done
and
if
security
help
is
a
side
effect
than
great,
but
like
trying
to
really
nail
down
those
kind
of
best
practices
is
maybe
not
I
think
the
security
working
group
would
be
better
to
define
security
best
practices
than
we
would
be
to
define
those
kind
of
things.
I
do.
J
J
J
I'm
just
trying
to
figure
out
like
whether
using
a
best
practices
guide
would
be
a
waste
of
our
time
or
would
improve
the
situation
incrementally
in
some
way,
so
I'm
a
big
pinion
that
right
now,
people
just
npm
install
anything
and
they
don't
really
understand
the
cost
of
what
it
is
to
depend
in
another
package,
whether
you're,
an
application
developer
or
a
library
author
and
to
put
out
or
at
least
started
discussions
that
people
are
more
aware
that
hey.
Maybe
they
should
look
at
a
list
of
direct
dependencies
and
find
out.
J
Are
they
running
CI
and
are
they
you
know?
Do
they
have
a
process
for
handling
security
bugs?
Do
they
have
an
LTS
schedule?
Things
like
that
I
think
seeding
that
information
under
the
community.
While
we
can't
provide
absolute
trust,
but
helping
people
understand
what
sort
of
tools
they
have
at
their
disposal
in
order
to
gain
trust
on
their
own
I
think
that's
still
a
productive
one
and
I
think
it
can
make
a
incremental
improvement
across
the
entire
ecosystem.
If
not
like
a
monumental
improvement.
J
E
I
So
I
I
was
not
trying
to
say
that
it
is
not
worth
the
time.
I
think
that
if
a
group
of
people
wanted
to
take
that
on
I
think
it
would
be
productive
and
incremental,
but
I
think
that
there
are
bigger
things
to
focus
on
and
I
think
it
just
changes
a
lot.
So
that's
why
you
know
it
just
be
a
work
to
keep
it
up
to
date
and
and
relevant.
A
Taking
a
few
notes,
yeah
so
I
mean
I,
think
I
think
it
comes
down
to
everybody's
volunteers.
So
if
people
have
a
particular
interest
and
say,
for
example,
on
that,
that
may
be
where
they
want
to
spend
their
time
and-
and
so
it's
a
matter
of
picking
out
the
like
more
than
one
like
because
there'll
be
different,
people
are
interested
in
different
areas,
is
picking
out
that
the
you
know
the
three
four
that
we
think
we
can
identify
concrete
next
steps
of
what
we
want
to
get
started,
we're
down
to
five
minutes.
A
You
know
the
the
you
know.
We
have
some
broad
areas.
You
know
I
think
best
practices
in
some
form.
You
know
make
sense
to
me.
I
don't
know
about
everybody
else,
but
like
we
could,
for
example,
to
say:
let's:
okay,
let's
try
and
open
an
issue
that
says,
let's
list
out
the
best
practices
that
we
think
we
should.
We
should
start
on
and
prioritize
which
ones
people
want
to
work
on,
or
we
could
you
know
say
let's
get
together
and
talk
about
what
we
think
problems
are
or
we
could.
A
K
Yeah
I
just
want
to
clarify
then
on
that
security
point
so
for
the
event
stream
security
issue.
What
is
that
something?
That's
going
to
be
covered
by
package
maintenance,
or
is
that
something
gonna
be
covered
by
the
security
working
group?
Or
is
this
something
going
to
be
covered
by
boys
because
it's
a
bit
confusing,
because
that
was
a
package
issue
rather
than
like
a
nerdcore
issue
or
one
of
the
known
foundation
packages.
K
A
I
think
there's
different
aspects
to
it
like
I
think,
and
it's
just
my
opinion
that
the
problem
of
you
know
if
you've
got
some
packages,
you
can
no
longer
maintain
them
and
you
you
either
want
help
to
do
that
or
want
to
find
new
owners.
That
seems
like
something
that
you
know
this
group
should
be
involved
in.
A
Because
I'm
not
sure
you
know
the
security
working
group
itself,
it's
it
takes
vulnerability
reports,
but
I'm,
not
sure
you
know,
I,
don't
think
it
or
the
even
this
group
is
gonna.
Get
involved
in
like
like
somebody
else
mentioned.
Is
you
know
tools
that
would
have
prevented
that
exploit
from
happening?
You
know
so
controlling
what
packages
could
do
or
anything
like
that
and
I'll?
Let
the
other
antenna
and
Tonio
has
his
hand
up.
H
Yeah
and
I
think
whatever
what
I
want.
That's
the
the
group
also
was
given
that
some
of
these
things
might
be
introduced
to
through
packages
these
these.
These
issues
that
can
cause
trouble,
or
we
also
considering
like
a
some
kind
of
patient
kind
of
best
practices.
Information
for
when
things
can
go
wrong
things
two
things
that
should
can
go
yeah
things
that
should
be
looked
at
as
a
package
maintainer
that
can
be
used
and
other
things
when,
when
things
go
wrong,
what
are
what
should
happen?
H
A
Think
that
fits
under
the
like
best
practices
is
a
pretty
broad
area.
The
first
step,
in
my
mind,
would
be
like
identifying
what
we
think
are
the
best
best
practices
or
where
people
have
expertise
that
they
think
they
can.
You
know
start
writing
something
up
that
we
could
discuss
and
test
with
the
community.
M
H
M
A
A
M
I
Said
to
wrap
up
what
youth,
what
we're
thinking
of
maybe
good
next
steps,
I,
really
I,
would
like
to
second
I.
Think
taking
both
approaches.
I
can
remember,
Te'o
and
Jordan
may
be,
who
brought
up
those
two
approaches
to
next
steps.
I
think
taking
both
of
those
in
parallel
would
be
a
good
idea,
defining
some
packages
and
some
friendlies
I
guess,
as
you
put
it
to
start,
collaborating
with
I'd
like
to
volunteer
the
Express
ecosystem.
I
We
have
lots
of
problems
that
we
love
people
come
help
solve
and
then
also
identifying
specifically,
our
problems
that
we're
going
to
try
to
come
up
with
solutions.
Is
that
a
lot
of
issues
open
that
are
presenting
solutions
to
problems?
But
we,
you
don't
have
anything
that
actually
is
like
nailing
down
those
problems.
I
think
taking
both
of
those
steps
in
parallel
would
be
a
good
good
next
step.
Yeah.
A
A
You,
the
only
other
thing
I'd
end,
and
this
comes
to
bandwidth,
but
like
this,
the
sort
of
third
thing
I
could
see
is
we
could
start
to
think
about
best
practices.
If
we
have
people
who
are
interested
in
again,
like
I
said
it
comes
down
to
what
people
are
interested,
but
if
people
have
a
specific
interest
in
that
front,
I
think
in
parallel
we
could
start
to
say,
let's
put
some
shape
to
what
that
might
be
and
do
that
in
parallel
with
the
other
two
as
well.
A
Does
anybody
have
anybody
have
things
that
they
feel
like
do
we
have?
Could
anybody
object
to
those
being
sort
of
the
three
priorities
that
we
start
out
with,
so
we
find
some
some
some
key
packages
and
and
the
friendlies
to
go
along
with
them
so
and
I
think
expresses
a
is
a
perfect
example.
If
you
think
that
West
you
can
sort
of
volunteer
to
represent
that
and
get
us
started
in
that
front
and
then
having
the
okay.
What
are
those
general
problems?
A
A
A
It's
like:
we
need
to
open
an
issue
that
says
you
know
what
are
the
key
problems
that
module
Lane
owners
are
currently
facing,
that
we
want
to
help
solve,
and
you
know
at
the
very
first
you
know
I
think
if
there's
already
some
new
ideas,
like
I,
think
we
have
some
ideas
what
they
might
be.
So
we
could
capture
some
of
those,
but
we
want
to
open
an
issue
to
start
people
adding
their
thoughts
on
that
and
then
we,
you
know,
sort
of
by
volunteering.
A
A
L
A
L
A
It's
kind
of,
like
think,
maybe
think
a
little
bit
about
what
some
of
them
might
be
and
say:
let's
put
together
our
list
and
the
ones
we
think
are
most
important
to
work
to
work
on
and
push
forward,
and
you
know
maybe
here's
a
list
of
just
to
think
about
and
then,
like
I
said,
it's
the
same
kind
of
thing
of
yeah.
Okay,
here
all
the
individual
comments
and
sort
of
trying
to
pull
that
into
the
you
know
a
sort
of
evolving
issue.
A
L
A
I
L
A
L
H
L
A
A
A
A
The
one
I
can
think
of
is,
like
you
know,
sort
of
a
long-term
support
process
or
whatever
is
not
going
to
be
different
based
on
the
type
of
package
or
you
know,
if
you
know
the
use
of
cember
or
whatever
I
I,
don't
for
me
at
least,
we
need
more,
you
know,
figuring
out
or
more
thought
or
sort
of
structure
before
I
dive
into
like
a--.
Is
it
different
for
different
types
of
packages.
A
A
I
mean
I
think
we're
out
of
time
today.
I
think
that
the
model
we
started
with
was
you
know
everybody
who's
who's
shown
an
interest
is
basically
joining
in
in
terms
of
the
I
think
we
should
almost
just
like
open
an
issue
where
we
can
have
some
discussion
around
that
and
see
what
what
people
think
I
think
like
like
Matteo
was
saying:
there's
not
going
to
be
as
much
contention
in
this
particular
meeting.
A
You
know
that
there's
very
specific
context
around
and
technical
context
around
the
modules,
so
I
I'm,
not
as
worried
in
terms
of
you,
know,
saying:
okay.
Well,
you
know
you
can
join.
If
we
get
to
the
point
where
we
have
to
start
resolving
conflict,
you
know
we
can.
We
can
become
more
formal,
but
I
tend
towards
you
know
not
going
there
unless
we
have
to
I.
Do
think
the
point.
A
The
point,
though,
about
like
subdividing
into
subgroups
and
stuff
like
that
opening
an
issue
to
kind
of
start,
a
discussion
there
say:
okay,
you
know,
we've
got
a
really
large
group
of
people,
which
is
great.
Obviously,
you
know
a
meeting
of
a
hundred
people
doesn't
make
a
lot
of
sense.
How
do
we
sort
of
subdivide
the
different
areas
of
where
people
are
in
so,
for
example,
if
we've
said
these
first,
three
things
are
where
we're
gonna
focus
on
mm-hmm.
A
We
can
start
out
by
taking
a
poll
to
see
of
the
people
who've,
you
know
who
shown
shown
interest.
Where
do
their
interests
align
or
not?
You
know,
maybe
there's
some
other
area.
We
need
to
start
to
do
in
parallel
as
well,
because
you
know
50
percent
of
the
people.
Don't
I
don't
have
any
interest
in
those
three
and
want
to
do
something
else.
Yep.
D
A
A
A
D
A
B
A
Then
yeah
and
Benjamin's,
even
asking
about
weekly
I,
think
we
might
start
it
weekly
to
kick
off.
Often
you
know
in
the
community
there
like
every
two
or
three
weeks,
but
in
sort
of
the
bootstrap
stage,
I
I
suspect.
Maybe
we
want
to
do
them
a
little
bit
more
often
to
start
so
that
sound
great
to
people
exams,
okay
and
Tony.
Your
hands
up.
H
A
A
D
A
A
Okay,
I
think
most
of
the
comments
seem
to
be
people
a
couple.
People
talking
to
themselves
good
idea
focus
a
little
sort
of
package
in
order
to
find
the
practical
problems
right,
I
think
which
is
Mateo.
Mateo
go
and
Wes
had
called
out,
and
he
already
has
an
answer.
Okay,
so
I
think
we
will
call
it
a
day
for
for
this
week.
Hopefully,
everybody
will
be
active
in
in
github
and
will
get
issues
open
to
start
working
on
those
three
particular
areas
and
push
it
forward
from
there
sounds
good.
Thank
you
very
much.
Thank
you.