►
From YouTube: 2022-05024-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
may
24
2022
we'll
follow
the
agenda.
That
was
tagged
in
the
issue,
which
was
issue
number
5
28..
Before
we
get
started.
Does
anybody
have
any
announcements
they'd
like
to
share.
B
A
Okay,
so
openjs
world
is
in
two
weeks.
I
think
that's
a
good
thing
to
mention
as
well
and
I
think
well,
there
weren't
any
other
announcements.
So
I'm
going
to
say,
let's
go
on
to
the
first
agenda
item,
which
is
522,
which
is
session
at
collaborator
summit,
which
I
think
is
what
you
were
talking
about
right.
B
Yeah
I
remember
during
the
last
session.
I
know
we
had
talked
about
this
and
you
know
I
was
willing
to
help,
but
you
see
to
get
that
milestone
out
of
the
way.
So
I'm
not
sure
if
there's
any
new
news
or
action
items,
but
I
have
a
little
bit
more
bandwidth
now.
If
there's
any
updates
on
that.
A
Okay,
I
see
right,
you
submitted
your.
You
were
talking
about
putting
together
your
own
talk
versus
right,
one
for
the
club
session.
B
Yeah,
I
just
didn't
do
both,
but
the
virtual
track
had
to
hand
theirs
in
yesterday.
A
Okay,
I
was
thinking,
do
I
am
I
behind
on
something?
No.
B
A
A
B
I
noticed
darcy's
comment
about
maybe
doing
a
co
event
with
the
npm
team,
which
could
be
really
nice.
I
think
there's
maybe
some
natural
synergy
there.
You
know
because
potentially
there's
rfcs
that
maybe
you
know,
could
use
spiking
or
you
know,
user
land
tools
that
might
not
make
it
into
npm
or
vice
versa.
But
you
know
there
could
be
some
good
cross
pollination,
even
if
just
those
two
groups
are
in
the
same
room
without
even
a
strict
agenda.
You
know
you
know,
I
scratch
your
back.
B
You
scratch
mine
kind
of
thing,
but
he
offered
to
co-host
to
set
up
something.
So
you
know
just
having
the
you
know.
If
you
build
it,
they
will
come
so
I
won't
be
there.
Unfortunately,
I
don't
know
if
there's
any
virtual
opportunities
outside
of
you
know
just
any
streams,
but
you
know
I
was
going.
I
would
certainly.
A
B
Yeah
pop
open,
your
zoom
from
yeah
impromptu
on
demand,
live
stream.
Yeah,
that's
exactly
definitely
yeah,
like
you
said:
if
there's
a
if
the
times
are
set
or
what
not
then
yeah
with
a
little
advanced
notice,
make
sure
we
could.
I
could
certainly
join
for
that.
You
know
not
sure.
A
A
A
So
I'll
post
that
in
the
the
chat-
and
I
guess
we
can
go
from
there
and
yeah
like
you-
know
for
everybody
else-
we'll
try
and
open
up
a
laptop
and
let
people
remote
into
on
your
comment
about
the
npm
session.
I
did
also
it
did
conflict
with
some
of
the
node
ones,
and
I
asked
I
said
I
suggested
maybe
it'd
be
good
to
put
that
at
a
different
time,
so
it
wouldn't.
A
A
A
I
think
one
of
the
things
we
could
chat
about
too,
is
this
next
one:
how
to
accelerate
the
modernization
of
the
ecosystem.
I
think
that's
a
rather
large
topic
and
you
know,
maybe
suited
better
suited
for
the
kind
of
in-person
discussion.
So
if
we,
if
we're
looking
for
type
for
topics
that
might
be
a
good
one
as
well,
because
I
don't,
I
think
we
chatted
a
little
bit
last
time,
but
there's
no
obvious.
B
Like
the
split
between
cjs
and
esm,
because
I
know
it's
fairly
common
in
browser
land
to
kind
of
treat
es,
2015
is
kind
of
this
new
stake
in
the
ground
of
like
feature
detection,
progressive
enhancement.
You
know
if
they've
got,
if
the
browser
supports,
esm,
probably
got
you
know,
class
and
promise,
and
things
like
that
seems
to
be
a
bit
more
contentious
in
the
npm
ecosystem.
B
The
original
post
like
what
modernization
means
if
it
just
means
just
please
keep
updating
your
dependencies.
So
you
know
you
don't
get
nailed
by.
You
know
security,
vulnerability
or
some
you
know,
but
to
your
point
you
know
you
think
about
like
tutorials
and
stuff
like
that,
you
know
who's
gonna
change
them.
The
downside
is
someone
could
still
be
using
them
to
you
know
you
see
a
blog
post,
you
maybe
don't
see
that
it
was
published
in
2014.
A
Think
it's
fine,
but
yeah.
That's
what
that
modernization
started.
The
discussion
like
just
saying
esm
is
more
modern
that
there
was
not
even
consensus
on
that
right.
So
like
right,
you
can
get
into
quite
the
discussion
about
what
modernization
means.
I
think
the
the
key
point
was
not
like
what
modern
means,
but
was
like.
I
think
they
used
the
example
of
of
not
fed
last
releases.
A
No,
what
was
prefetch
requests
right
right.
It's
clearly
deprecated
has
been
deprecated
and
yet
still
has
tons
and
tons
of
use
right,
and
I
think
that's
kind
of
what
the
starting
point
was
like
you
know.
A
I
think
it
would
be
less
contentious.
You
said
we
want
to
encourage
people
to
use
non-deprecated
things
right
and
even
I'll
see
you
so
we're
going.
No,
no
finish.
Sorry
I
mean
even
that
is
going
to
be
a
challenge
right
like
if
you
know
it's,
sometimes
it's
maybe
buried
in
the
dependency
of
something
else
right
or
but.
B
I
mean
I
guess,
because
looking
at
the
the
table
at
the
bottom
of
the
original
post,
you
know
yeah.
I
think
maybe
you
have
a
much
better
case
in
the
scenario
where
something
has
literally
been
deprecated.
You
know
that's
pretty
clear
signal,
but
then
it's
mixed
in
with
other
packages.
That
seems
the
only
criteria
criteria
is
just
their
last
published
version,
and
you
know
I
don't
know
you
know.
I
guess
it
seems
to
me.
B
It
almost
seems
like
if
I
think
about
how
I'm
not
sure,
if
you've
heard
of
socket
the
new
company
by
frost,
that's
trying
to
examine
vulnerability
and
like
malware
intent
in
packages
and
it's
less
about
like
static
analysis,
but
maybe
more
like
this
package
just
released
a
patch
release
and
all
it
did
was
add
a
post
install
script
that
seems
kind
of
sketchy.
B
You
know
things
like
that,
so
I
don't
know,
if
maybe
the
shape
of
the
conversation
and
where
you
know
the
synergy
between
npm
and
this
group
is,
you
know
more
of
like
a
how
to
evaluate
and
analyze
packages
you
are
and
aren't
using.
So
you
can
take
a
holistic
look
like
almost
like
a
waiting
scale.
It's
like
last
major
release
or
update.
You
know
that
weighs
this
much.
You
know
health
of
the
mate.
I
don't
know
you
know
like.
Is
it
more
of
just
things?
A
A
That
starts
to
get
integration.
We
could
probably
have
long
long
discussions,
the
I
I
the
original
one
example
of
like
something.
That's
deprecated
though,
like
I
know
early
on,
we
did
some
and
I
think
dominique
has
you
ran
some
of
the
tooling
that
captured
like
here
are
the
most
used
packages
right.
C
C
A
Yeah,
so
I
think,
like
the
original
issue
like
you
know-
and
I
actually
suggested
they
come
here,
because
I
think
it's
the
most
likely
to
see
a
group
of
like
we're
interested
in
maintaining
packages
yeah
does
it,
like
you
said,
is
there
a
problem?
Would
it
make
any
sense
like
if
we
generated
those
thoughts
and
said
here's
the
top
downloaded
deprecated
modules?
Would
it
make
any
sense
for
us
to
write
some
blog
posts
that
says,
stop
using
blah
blah
blah
right,
like
you
know,
because
that's
the
one
thing
I
could
think
one
thing.
A
C
I
mean
there
is:
there
is
a
couple
of
dedication
warnings
that
you
get
when
you
install
requests,
there's
the
uad,
which
has
a
note
about
math
random,
which
could
remotely
lead
to
security
issues.
But
if,
if
it
works,
if
all
the
tests
pass.
A
C
C
B
I
guess
it's
one
of
the
things
I've
observed
in
the
contributions
to
the
node
website
they're,
and
I
think
I
think
rightfully
so,
like
their
avoidance
of
like
creating
pages
that
are
just
like
links
to
whole
bunch
of
other
things.
You
know
kind
of
walking
that
line
between
picking
winners
and
losers,
or
something
like
that.
I
think
it
was.
You
know
fairly
for
project
as
large
as
node.
You
know
it's
a
makes.
B
A
lot
of
sense,
as
opposed
to
like
a
react,
saying
like
here's,
a
couple
recommendations
for
how
to
start
a
full
stack
react
app.
You
know
that's,
but
you
know,
I
think
so
I
think
maybe
the
value
in
the
conversation
is
more.
B
What
could
I
look
for
to
give
me
some
confidence
that
a
this
is
the
right
package
for
me,
which
is
probably
more
based
on
your
requirements,
but
you
know,
like
I
said,
kind
of
thinking
about
like
how
for
us
and
his
team
are
critically
evaluating
kind
of
more
like
the
softer
side
of
package
maintenance.
You
know
looking
for
those
kind
of
odd
crevices
and
weird
patch
releases
that
do
shady
stuff.
You
know,
isn't
more
along
the
lines
of
yeah,
so
I
guess
is
it?
Can
we?
B
These
are
old
things
and
here
are
new
things,
you're
looking
for
new
things
or
as
you're
looking
across
the
ecosystem.
If
you
find
something
that
like
wow,
this
fits
my
use
case,
you
know,
can
what
are
some
quick
things
like
in
the
github
repo?
You
know
because
that,
but
then
you
get
into
like
just
because
it
hasn't
been
maintained
for
a
little
while
you
get
people
that
are
like
I
haven't
seen
a
commit
in
a
month.
Is
this
project
dead?
You
know
it's
like.
I
don't
want
to
lead
to
those
kind
of
issues
either.
B
You
know
so,
like
you
know,
can
anything
be
hard
and
fast
in
this
industry.
I
don't
know,
and
is
it
the
place
of
this
team
to
say
that
or
is
it
just
you
know
broad
strokes,
you
know
here's
how
to
evaluate
an
npm
page
and
a
github
repo,
and
you
know
like
it's
just
for
a
side
project,
not
a
big
deal.
Is
it
for
your
enterprise?
C
Maybe
we
need
to
start
writing
down
some
of
these
things,
but
so,
if
we're
talking
specifically
about
requests,
there's
like
things
that
I'd
like
to
see
in
terms
of
research
in
terms
of
like
how
people
are
using
requests,
are
they
using
it
directly,
which
could
be
made
the
case
that
it's
just
because
it's
a
great
name
and
there's
a
lot
of
material
and
there's
so
exactly
there's,
there's
a
decade
of
of
blog
posts,
so
he's
saying
to
use
request,
or
is
it
mostly
that
it's
installed
via
dependencies?
C
D
C
You
can
probably
maybe
issues
well.
You
could
extrapolate
that
from
like
take
all
the
dependency
downloads
and
subtract
that
from
the
total
downloads
and
then
whatever
remains
is
direct
downloads.
So
that's
one
thing
that
I'd
like
to
think
about,
because
that
immediately
differentiates
the
path
you
can
need
to
take.
If
you
want
to
modernize
it
like
this.
Aside
from
the
separate
discussion
like
two,
you
need
to
modernize,
but
that
tells
you
how
to
modernize.
A
C
So
that's
that's
one
question.
The
other
question
is
request,
has
at
least
one
or
two
forks
that
are
being
maintained
that
I'm
aware
of.
I
don't
know
how
widely
used
those
are,
but
I
think
at
least
one
of
those
wasn't
a
fairly
prominent
namespace,
which
I
don't
remember
and
whether
I
mean
this
is
a
lot
of
throwing
the
ball
back
onto
npm,
but
exposing
these
forks
as
good
forks.
Like
you
know,
here's
a
package.
C
It
has
20
million
downloads,
but
here's
a
fork
which
has
a
million
downloads
that
doesn't
have
the
deprecated
warning
right.
C
Even
necessarily
related,
like
some
of
those,
are
direct
forks
right
with
just
a
couple
of
dependency
upgrades,
so
I
assume
something
like
uuid,
which
is
deprecated,
and
that
version
seven
now,
whereas
request
is
using
version
three
so
yeah.
D
D
C
D
A
B
I
was
just
gonna
say
it
was
just
a
similar
rfc
we're
just
talking
about.
Is
you
know,
you
know
because,
like
we're
saying,
the
package
manager
probably
has
a
lot
more
insight
into
the
relationship
of
your
dependencies
and
we're
just
talking
about
one
recently
about
something
you
might
not
even
know
from
reading
the
github
is
this
package
depends
on
a
link
to
github
it's
not
even
coming
from
the
registry.
B
So
you
know
maybe
these
are
that
can
manifest
in
the
package
manager
somehow
just
through
feedback,
and
you
know
knowing
at
the
point
of
entry,
what's
going
on
exactly
when
you
run
it
instead
of
you
know
an
old
yeah,
because
you
could
look
at
npm
and
you
know
all
the
dependencies
shift
in
the
past
month
and
that's
where
the
sneaky
stuff
comes
in.
You
know
maybe
some
downstream
downstream,
that
updated
a
version.
A
Yeah,
and
even
I
don't
know
like
some
of
these
might
be,
policies
that,
like
an
organization,
would
want
to
apply
like
because
we
we've
we've
wrote
something
called
np
check,
just
to
say,
like
we
have
a
reference
architecture
where
we
say:
okay,
here's
the
experience
from
across
ibm
and
red
hat,
here's
the
modules
we're
using
and
then
to
sort
of
keep
a
sniff
check
on
them.
We
write
that
we
wrote
this
tool
which
looks
and
tries
to
figure
out
like.
A
Are
there
any
red
flags
and
and
why
I'm
thinking
about
this
now
is
one
of
those
is
like.
Well,
obviously,
if
it's
deprecated
it's
not
something,
we
should
be
telling
people
they
want
to
use
the
other
one
that
I
think
we
came
across
as
the
one
that
owen
also
mentioned
is
like.
If
you've
got
a
link,
that's
actually
going
to
github
to
pull
it.
It's
like
whoa,
that's
like
crazy,
crazy,
dangerous
right.
A
I
think
that
was
the
one
instance
where,
when
we
were
renaming
the
the
primary
branch
in
node
to
main
like
we
most
of
those
went
fine,
but
there
was
one
one
thing,
and
I
can't
remember
what
it
is
now,
but
we
we
renamed
that
thing
and
it
somehow
had
a
link
to
some
dependency.
You
know
10
layers
down
that
had
a
direct
link
or
no
with
some
other.
It
was
an
external
package,
it
had
a
direct
link
to
something
in
the
node
project
and
it
was
from
git
and
it
had
the
the
the
the
actual.
A
You
know
it
had
the
the
the
primary
branch
hard
coded
into
it,
and
it's
like
you
know
basically
you're
getting
the
latest
all
the
time
and
now
you're
broken
because
we
changed
the
name
of
it
right,
even
sorry,
but
but
it
just
makes
me
think,
yeah
some
of
those
things
that
we've
been
we're,
checking
really
resonate
that
you
mentioned
and
even
like.
I
could
see
somebody
wanting
a
policy
that
says
you
know
if
the
package
managers
were
involved
like
now.
I
want
my
strict
policy.
I
nothing
deprecated,
nothing.
You
know
that.
A
Yeah
and
like
I
even
like
the
check
we
put
in
place,
was
just
as
the
top
level
one
deprecated,
but
now
I'm
thinking,
because
it's
always
hard
like
do
you
check
just
the
module
that
you've
said.
You've
had
success
for
or
do
you
check
all
of
its
dependencies
and
we've
ch
some
for
for,
except
for
vulnerabilities.
A
D
A
Like
another
thing,
that
would
make
sense
is
like
because
the
deprecated
you
know,
they've
deprecated
they've,
done
what
they
were
supposed
to
do
right.
It's
the
people
who
continue
to
use
them,
and
maybe
it's
like
it
hasn't,
been
updated
for
a
long
time.
So
it's
not
necessarily
it's
not
like
we.
They
owe
us
anything
right
but
or
your.
A
D
B
B
Is
that
really
the?
Is
that
really
where
the
vulnerability
is
going
to
necessarily
happen,
because
I've
decided
my
package
is
using
hdp
directly
instead
of
fetch?
You
know
this
is
kind
of
why
I
think
where
the
some
of
the
conversations
happening
in
npm
are
interesting.
You
know
because
it
is
trying
to
you
know
it's
not
looking
at
the
tech.
It's
literally
just
looking
at
you
know,
fairly
obvious
issues
in
your
dependency
chain.
Like
the
you
know,
the
non-registry
urls,
or
things
like
that.
B
So
so
I
think
even
beth
was
you
know,
so
I
think
maybe
the
question
to
bali
back
with
is
you
know
again?
What
does
modernization
mean
because
it
seems
to
imply
that
yes,
projects
get
old
and
people
kind
of
move
away
from
them,
and
maybe
someone
else
forks
and
whatnot
and
that's
fair
and
in
a
like,
you
know,
window
shopping
sense,
but
is
it
like?
B
You
know
you
know,
so
I
I
don't
know
that
that
seems
to
be.
The
main
premise
of
this
is
that
you
know
old,
apis,
bad
new
apis
good,
but
that
doesn't
seem
to
be
necessarily
relevant
to
the
the
substance
of
the
post,
which
is
things
are
old
and
things
are
new,
but
is
it
really
because
of
the
apis
they
use
per
se?
Or
you
know
I
I
don't
know
I
mean
it
seems
like
that's.
Maybe
s
subjective,
you
know
like
does
any
you
know
or
a
lot
of
I
don't
know.
B
B
Discussion
around
what
do
we
do
about,
like,
I
guess,
maybe
with
requests
of
a
deprecated
package
that
still
get
a
lot
of
high
traffic.
You
know
that
seems
a
little
more
actionable
in
terms
of
like
don't
use
it
because
it's
not
maintained
at
all,
don't
use
it
because
it
uses.
You
know
you
know
fs.sync
instead
of
fs.
You
know
promises
you
know
like.
Are
those
really
the
the
met?
You
know
those
really
the?
Is
that
really
the
grand
level
granularity?
We
want
to
be
passing
judgment
on
so
to
speak.
B
A
Yeah,
I
think
your
point,
like
there's
kind
of
two
very
different
things
maybe
covered
there,
one
one
which
is
like
hey.
We
have
newer
apis.
How
do
you
convince
people
to
move
up
to
the
latest
and
greatest,
but
that's
really
quite
different
than
how
do
we
convince
people
to
stop
using
things
which
are
are
no
longer
alive
or
whatever
you
want
to?
You
know.
B
Yeah,
that's
the
reason
to
stop
using
requests
is
because
it's
no
longer
maintained
not
because
of
the
api
choices.
Potentially
I
mean
if
they
still
work,
they
still
work.
Maybe
it's
a
millisecond
slower
in
production,
but
you
know
or
just
like,
because
it
uses
cjs
I
mean
yeah.
It
might
pose
an
interoperability
problem
and
with
a
newer
tool.
But
you
know
that's
not
necessarily
a
indicator
of.
B
I
don't
know.
I
think
modernization
is
something
that
happens
as
ecosystems
grow.
Naturally,
you
know
eventually,
node
gets
enough
of
these
neat
apis
and
someone's
like
yeah.
I'm
gonna
write
the
next
I
mean
see
it
with
like
bundlers
and
stuff,
like
that.
You
know
the
the
ecosystem
churns.
Just
as
you
know,
experience
grows,
and
you
know
like
esm,
unlocks
a
lot
of
things
now,
there's
a
whole
lot
of
next
generation,
bundlers
and
stuff
like
that.
B
But
you
know
you
see
people
building,
you
know
companies
off
of
webpacks
still
you
know
so
or
hiring
the
maintainer
to
to
do
things
like
that.
So
yeah,
I
guess
so.
I
guess.
If
this
was
to
go
into
a
conversation,
you
know
is
the
focus
less
on
the
apis
and
more
on
the
you
know.
Maybe
the
more
glaring
or
more
obvious
signals
like
package
deprecated,
you
know
so,
but
otherwise
I
don't
feel
I
need
to
tell
people
to
stop
using
express.
B
B
I
was
simply
looking
for
you
know
async,
you
know
so
I
evaluated
based
on
the
technical
criteria,
but
that
was
you
know,
because
you
know
that's
that's
what
I
wanted
at
the
time.
So
I
don't
know
I
just
need
to
pick
winners
and
losers
over
maybe
a
potentially
arbitrary
point
of
you
know
api
decision.
You
know
I
feel
like
there's
bet,
there's
bigger
signals
to
you
know
so
I
don't
know,
but
I
guess
yeah.
B
Maybe
that
is
a
topic
because
you
know
if
there
are
signals
you
know
it
would
be
great
to
feed
them
into
the
cli.
Where
you
know
there's
you
know
things
like
deprecated
non-registry,
tar
balls,
like
you
know,
really
big
flags
can
actually
be
surface
not
like
hey.
This
is
still
using
fs.sync.
You
know
like.
B
They
should
just
maybe
if
the
apis
are
deprecated.
You
know
something
like
that,
but
you
know
like
hey.
We
found
that
this
will
just
totally
phone
your
system,
don't
use
you
know
xyz
or
shift
up
to
node
version
or
something,
but
you
know
it
gets
gray,
and
you
know,
as
nathan
said,
you
know
it's
not
like
a
singular
problem
here.
B
You
know,
but
I
think
it
would
be
good
to
take
the
hints
and
signals
that
something
like
npm
builds
into
it
and
then
maybe
make
a
document
in
the
package
maintenance
docs
about,
like
you
know
how
to
understand
what
you
know.
Deprecated
means
you
know
how
to
understand
what
the
impact
of
a
not
using
a
non-registry
tar
ball
means.
I
mean
it.
B
A
Because
I
think
I
think,
like
the
there's,
there's
thought
I
think,
which
is
is
also
like.
I
don't
know
that
there's
a
problem
or
it's
a
feature,
but
like
the
tendency
for
everybody
to
want
to
create
something
new
and
different
means
that,
like
typically,
I
think,
that's
good,
except
that
that
means
we
then
fragment
our
effort
so
much
that,
like
having
10
things
that
have
one-tenth
of
the
effort
put
into
each
of
those
10,
things
probably
would
be
not
as
good
as
2
or
three
like
I'm
not
going
to
advocate
for
one
right
like.
A
I
don't
want
to
choose
one
winner,
but
we
probably
have
an
easier
time
if,
like
there
were
two
good
strong
ones,
with
lots
of
activity
versus
10
with
a
little
right,
and
I
think
we
sort
of
tend
towards
that
pen
at
least
that's
the
way
I
get
the
feeling
some
days
and
it
kind
of
comes
back
to
like
helping
the
maintainers
make
good
decisions.
If
we
could
say
you
know,
choose
one
of
the
trident,
like
you
went
back
to
express
right,
it's
tried.
It's
tested,
it
still
works.
It's
still
maintained
enough
that
there
aren't
security.
A
Vulnerabilities
and
it's
kind
of
one
of
those
things
if
it
does
what
you
need-
you're,
probably
not
making
a
bad
decision,
and
you
might
find
something
else
which
is
like
got
all
sorts
of
fancy
new
things,
but
will
and
and
maybe
is
maintained
today,
but
has
much
higher
risk
because
tomorrow
it
might
not
be
so.
A
B
A
A
Should
the
node
project
even
weigh
into
this
right
like
we
could
maybe
be
the
the
place
to
allow
people
to
come
together
and
collaborate
on
something
but,
like
I
don't
think,
we'd
want
the
project
to
be
like
you
know,
I
don't
know
if
we
even
have
like
a
hey,
here's,
the
the
the
I
can
see
us
coming
up
with
guidance
on
how
to
make
a
choice
or
tools
that
helps
surface.
A
D
Yeah
I
mean
the
I
think
the
problem
is
is
like
it's,
it's
private
companies
that
are
trying
to
create
solutions
to
this
because
they're
the
ones
with
the
funding
and
motivation
to
do
so
like
process
group
or-
or
you
know,
security
companies,
research,
companies
or
registry
hosts
themselves
right,
they're,
the
ones
with
the
funding
and
motivation
to
do
something
about
this.
D
So
yeah
we
can
be
a
discussion
point,
but
I
think
it's
it's
pretty
hard
to
say.
Like
you
know,
this
is
the
overall
solution
to
this
problem.
Yeah.
A
I
think
what
would
be
great
is
if
we
could
somehow
help
the
conversation
so
that
it
was
like
you
know.
What
is
it
that's
good
practice
and
again
maybe
this
will,
you
know,
be
the
secret
sauce
of
some
of
these
companies
right,
but
like
back
to
we,
we
tried
to
get
going
that
cbe
vulnerability,
reporting
collaboration
space,
and
I
think
that
would
be
the
perfect
place
if
we
could
actually
bring
together
the
people
to
collaborate
and
say
this
is
the
data
that
makes
sense
and
here's
a
format
that
could
be
shared
by
maintainers
right.
A
So
I
publish
a
package.
If
I
look,
if
I
get
a
vulnerability
report,
I
look
at
it
and
say:
oh
well,
that
doesn't
apply
to
me
because
you
know
the
tendency
I
use.
I
don't
use
that
if
there
was
a
standard
way
for
that
maintainer
to
report
that
then
the
tooling
could
actually
really
leverage
that,
and
maybe
you
know,
different
companies
could
find
ways
to
leverage
it
better
or
worse.
A
D
A
No-
and
you
know
like
what,
like
I
said,
we've
we've
got
our
np
check,
which
tries
to
run
a
bunch
of
checks
and
another
company
might
have
another
set
I'd
be
interested
if
we
had,
like
you
know
three
or
four
companies
who
all
have
their
own
set
of
checks.
It'd
be
interesting
to
understand
and
share
that
kind
of
information,
because
that
would
be
it's
a
really
hard
problem
to
look
at
something
and
say:
yes,
it's
more
of
a
red
flag
versus
non-red,
flag
kind
of
thing
versus
a
black
and
white.
B
Yeah,
I
was
actually
just
typing
that
in
it's
like
it's
not
really
about
what's
modern
but
what's
risky
and
risk
can
come
from
a
varying
amount
of
criteria,
one
could
be
like
api
or
technology
choice,
but
another
could
be,
you
know,
dependency
choice,
zero
to
a
hundred
or
you
know,
or
you
know,
maintenance
activity
or
whatever.
So
you
know
some
of
these
things.
A
package
manager
can
help
you
out
with
other
things.
Maybe
it's
more
of
a
you
know.
I
just
need.
B
I
need
to
have
my
own
risk
matrix
and
as
I'm
comparing
two
or
three
things,
I
kind
of
see
what
checks
the
box
and
what
doesn't
and
then
you
know
I
go
from
there.
So
it's
like
we
could
provide
some
of
that
supporting
information
that
can
maybe
help
you
flesh
out
your
own
personal
risk
matrix.
But
you
know
at
the
end
of
the
day,
it's
your
choice
and
you
know
I
can't
you
know,
can't
fault
you
for
still
using
express
today.
You
know
so
you
know,
because
maybe
that's
falls
within
your
risk.
B
Matrix
and
yeah.
There's
nothing
objectively
wrong
with
it
other
than
maybe
it's
you
know
slowed
down
a
little
bit,
but
it's
still
perfectly
usable.
You
know,
but
again
that
might
be
in
your
you
know,
and
so
maybe
it's
like
subject.
Maybe
it's
just
a
matter
of
also
categorizing
like
subjective
versus
objective
risks.
You
know
you
might
weigh
release
activity
more
because
it's
a
brand
new
project
versus
like
a
tutorial.
You
know.
So
I
don't
know
if
that
helps
at
all.
A
I
think
we
should
move
on
because
we're
almost
near
the
end,
but
I
think
we
could
we
could
from
what
I
understand
of
our
discussion.
We
could
probably
and
correct
me
anybody
who's
here,
like
I
don't
hear
any
enthusiasm
in
terms
of
trying
to
wade
into
hey,
you
should
move
to
a
promise-based
api
versus
this
other
api
in
terms
of
the
modern
like
that's
that,
for
me,
is
like
people
should
decide
that
on
their
own
on
the
merits,
right
yeah,
so
we
might,
we
might
respond
in
there
like
there's,
not
really
enthusiasm
for
that.
B
Just
the
old
gi,
joe
mantra
or
the
nbc
right,
the
more
you
know,
kind
of
thing
you
know
yeah.
I
I
because
I'd
personally
rather
have
a
a
more
educated
consumer
base
than
you
know.
One
that's
gonna
parrot
like
or
potentially
artificial
signals
like
you
know,
same
versus
async,
or
something
like
that.
You
know.
A
Sounds
good,
okay,
so
the
next
one
2022
promotion
of
events.
I
think
I
don't
think
there's
an
update
there.
Okay,
let's
see.
A
I
think
bostrick
did
submit
a
talk,
but
I
don't
think
it
was
accepted
from
what
I
remember
seeing
of
the
agenda
and
really
our
next
event
is
kind
of
the
opengs
world
club
summit.
So
I
don't
sure
there's
anything
to
discuss
this
week
on
this
one.
A
The
team
membership
audit
number
497
this
one
I'm
looking
through
this
is.
B
Okay,
that's
not
okay
down
here.
C
A
A
Don't
know
if
there's
any
updates
on
that,
I
think
last
time
we
did
give
access
to
zach
right
yep.
Okay,
did
we
tell
him
that?
Yes,
okay,
good
right?
Should
we
leave
this
open
on
the
agenda,
or
should
we
wait
for
you
know
when
zach
makes
progress
to
come
back?
What
do
we
think
on
that.
B
A
And
then
the
last
issue
is
just
a
list
of
modules
to
get
supporting
for
when
this
one
I
I
I
I'll
just
mention
again.
I
think
it
relates
to
our
earlier
discussion
about
like
trying
to
give
more
info
to
the
people
choosing
modules
you
know.
So
that's
maybe
part
of
that
larger
discussion.
C
C
A
A
A
A
Okay,
perfect
I'll
type
that
in
there
okay
and
I
think
we're
at
time.
So
thanks
for
everybody
for
taking
the
time
is
there
anything
we
should
talk
about
before
we
close
out
for
today.
A
Issue,
yeah
I'll
try
and
put
it
make
a
post
a
comment
in
that
basically
not
much
appetite
for
x,
more
appetite
for
y,
and
you
know
you
can
I'll
taste
that
when
I'm
putting
together
the
minutes
later
on
today,.
A
Or
if
you
want
to
summarize
I'd,
also
be
happy
if
you
want
to
go
ahead
and
do
it
sure
whichever
works,
I
I
go
for
it,
don't
want
to
say
the
wrong
thing.
No,
no,
you
can
you
can
go,
I
mean
go
for
it.
B
All
right,
yeah
I'll,
probably
do
it
a
little
bit
later
after
my
meetings
but
yeah.
Basically,
I
was
just
going
to
say
just
try
to
thread
the
needle
between
subjective
and
objective
criteria,
and
you
know
maybe
less
on
the
technical
and
more
on
the,
like.
You
know
clearer
signals
yeah.
That
kind
of
thing.
B
A
Okay,
we'll
see
everybody
later
all
right
have
a
good
day,
thanks
nathan
for
coming
bye.