►
From YouTube: 2020-09-22 - 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
Package
maintenance
team
meeting,
or
I
should
say
working
group
meeting
for
september,
22nd
2020,
we'll
follow
the
agenda.
That
was
tagged
in
the
issue
which
is
409
in
the
repo
and
before
we
get
started,
does
anybody
have
any
announcements
that
they'd
like
to
share.
A
No
okay:
let's
move
on
then
to
the
issues
that
were
tagged.
The
first
one
is
building
crete,
pkg
404.,
who
wants
to
take
that
one.
B
B
Maybe
wes
we
had
the
call
last
week
if
you
wanted
to.
Maybe
we
could
look
up
that
or
link
that
specific
issue
from
it.
D
A
Yeah,
these
were
the
next
steps
from
the
so
here
I'll,
just
paste
them
in
the
chat.
Those
were
the
next
steps
we
had
from
the
minutes.
D
Yeah,
so
we
had
that
call,
we
had
a
bunch,
I
think,
of
really
good
progress
on
that
call.
Our
takeaways
from
that
call,
so
we
brought
the
this
idea
to
the
team
via
was
that
only
on
that
call
or
did
we
actually
have
another
package
and
a
normal
meeting
in
between.
D
Okay,
yeah
so
anyway,
so
then
I'll
go
into
the
takeaways
from
that
call
which
was
to
so
I
had
some
foundation
setting
to
do,
I'm
I
actually
have
it
done.
I
just
never
pushed
it
because
there
were
some
broken
tests.
D
I
had
some
tests
written
and
I
probably
just
should
have
pushed
the
code
before
trying
to
fix
the
test,
but
you
know
so
it's
still
sitting
on
my
hard
drive,
but
it's,
but
it's
mostly
done
and
then
we
had
like
a
few
different,
and
this
is
where
having
that
other
issue
would
be
helpful,
but
I
think
I
don't
remember
which
exact
one
it.
B
We
had
we,
I
don't
know
if
we
had
a
hack
md
going
during
the
call,
but
I
I
just
copy
and
pasted
the
actual
issue
in
the
repo
itself
that
you
sort
of
put
together.
There
was-
and
this.
B
D
Okay,
I
don't
think
we
did,
but
here
let
me
I'm
posting
right
now,
the
video
I
just
found
it
on
youtube.
So
that's
the
recording
and
then
we
could.
D
You
know
if
we'd
feel
value
in
pulling
out
details,
but
I
seem
to
just
remember
at
the
end
it
was
I'll
set
the
foundation
and
then
we
had
a
few
people
volunteer
in
the
issue
to
get
involved
and
that
issue
is
on
the
pkg
js
org
yeah,
so
those
folks
sort
of
raised
their
hands
and
then
and
then
it
was
basically
once
I
push
that
work.
We
can
then
move
on.
B
Yeah,
I
think
I
also
took
the
or
I
said
I
would
take
the
a
on
creating
a
project
board
in
the
pkgs.
If
I
remember
correctly
so,
essentially,.
B
You
know
to
do's
to
to
get
this
to
a
better
place.
I
think
we
can
actually
close
the
technical
sync
issue
that
I
think
is
still
open.
I
know
it
wasn't
a
part
of
this
agenda,
but
it's
linked
essentially
yeah.
I
I
think
there's
some
follow-up
to
do
here,
michael
from
from
myself
and
probably
wes
and
okay.
Actually
things
are.
The
ball
has
started
to
roll.
I
guess
is
sort
of
the
update.
A
Yeah,
I
captured
the
two
next
steps
as
wes
to
push
what
he
has
and
then
we'll
go
from
there.
Darcy
just
set
up
project
board
for
issues
to
identify
where
people
can
get
involved,
because
I
think
I
do
remember
that
too.
As
one
of
the
things.
If
we
could
structure
what
needs
to
be
done,
people
might
jump
in
and
start
helping.
B
A
F
A
E
A
Nope
great
so
on
to
the
next
issue
draft
text
for
support
info
blog
post
that
should
be
going
out
this
week.
I
expect
I
talked
to
rachel
and
she's
going
to
help
us
get
that
out
so
well
underway.
A
A
It
seemed
like
there
was
general
consensus
that
doing
something
along
that
lines
makes
sense
and
really
now
it's
a
matter
of
trying
to
broader,
broaden
the
conversation,
and
you
know
see
how
we
can
move
move
it
forward
into
a
concrete
proposal
on
that
one.
I
think
the
next
step
is
to
kind
of
what
I
was
thinking
would
be
good
was
to
find
you
know,
figure
out
who
wants
to
be
the
champion,
and
then
you
know
we
can.
You
know
work
on.
A
We
didn't.
We
didn't
quite
get
like
lorraine
from
from
dudes
at
the
time
and
it
sounded
like
we
should
pull
in
some
other
people
from
npm
so
kind
of
once
we
figure
out
who's
our
champion
on
that
one.
We
can
start
to
move
forward
on
those
items
as
well.
G
B
You
already
supposed
to
do
this
product
or
offering
from
yeah
like
some
sort
of
service,
that's
kind
of
like
where
my
head
imagines
that
so
I
think
yeah
the
last
time
we
talked
about
this,
like
I
think
I
have
to
go,
poke
some
folks
and
see
what
they're
working
on
on
that
side.
Things
have
moved
around
a
little
bit
on
on
our
teams,
so
yeah.
The
makeup
is
just
a
little
bit
different
of
who's,
owning
like
the
future
of
security
products,
let's
say
but
yeah.
B
Audit
resolving
database
or
data
like
should
that
not
live
in
the
same
place
like
the
cve
data
lives
right,
so
that
could
be
right.
Then
we
could
create
tooling
around
it
to
actually
use
that
information
right,
so
so
yeah
any
future
services,
and
that
capability
probably
would
be
built
by
security
folks
and
that
team.
So
I
mean.
A
B
Yeah,
so
I
I,
I
definitely
think
so
too.
I
think
there's
probably
some
collaboration
that
could
could
happen
there.
So
is
just
finding
like
probably
a
product
manager
to
own
this
and
be
on
this.
G
A
A
The
the
sort
of
some
of
the
ideas
we
we
talked
about
was
not
necessarily
a
single
source
of
you
know,
a
single
list
that
was
maintained
somewhere,
but
the
ability
to
you
know
for
the
end
user
to
say
here
are
the
sources
that
I
trust,
and
so
you
know
you
might
choose
to
trust
the
express
project
to
maintain
their
list.
You
might
so
you
know
trust
some.
A
Some
projects-
or
maybe
you
know
some
businesses
might
want
to
like
you
know
npm
could
say
well
we're
going
to
have
a
process
where
people
can
submit
things
and
we'll
review
them
and
then
put
them
on
our
list.
If
we
think
they're
credible-
and
you
know
so,
then
people
might
trust
that
list,
but
the
main
thing
was
to
have
it
be
you
know
so
that
the
end
user
could
choose
one
or
more
sources
and
those
sources
together
in
kind
of
a
binary.
Yes
or
no.
A
You
know
type.
If
we
we
had
some
discussion
around
great
the
gray,
but
I
think
that
greatly
complicated
things.
So
if
you
could
get
to
the
point
where
you
basically
said
in
the
list,
it's
like
we've
looked
at
it.
We
do
not
believe
this
applies
to
us
and
maybe
a
reason
that
says
like
because
we
don't
call
the
method
or
whatever,
from
some
reason,
common
reason
codes.
A
G
So
that
sounds
good
to
me.
The
only
concern
or
question
that
that
brings
up
for
me
is
discoverability
right,
like
it's,
it's
great
to
be
able
for
me
to
be
able
to
say
these
700
package
maintainers.
I
trust
each
one
of
them
to
maintain
their
own
dependencies
or
whatever,
but
like
how
do
I
know
that
they're
even
maintaining
those
lists
in
the
first
place
like
how
do
I
like
is
there?
Is
there
a
way
in
the
interface
to
like
present
the
options
to
me
and
say:
do
you
want
to
trust
this.
D
D
That
one
has
a
few
problems,
because
anything
included
in
the
package
can't
be
updated,
but
you
know
it
could.
It
would
be
sort
of
a
choice
based
on
the
maintainers.
You
know
goals
and
and
what
they
want,
but
as
a
package
back,
then
you
could
just
search
them
on
npm.com.
D
D
A
So
yeah,
so
that
one
I
have
in
mind
like
unless
somebody
else
figures
it
out
before
I
get
there
to
kind
of
try
and
talk
to
some
of
the
people
who
were
there
and
see
you
know,
do
we
who
would
like
and
if
anybody
wants
to
chime
in
here
like
if
we
have
somebody
who
wants
to
chime
in
in
terms
of
championing
this
to
move
forward,
you
know
figure
out
who
that
would
be
and
then
work
towards
those
kind
of
next
steps
which
you.
G
A
We
had
the
we
didn't
record
the
call
just
so
that
we
could
have.
You
know
some
frank
discussions
on
some
things,
but
I
think
going
forward.
We
agreed
you
know
from
now.
From
now
on,
we've
probably
laid
the
groundwork
and
can
have
those
discussions
in
a
more
public
space.
D
One
other
small
thing
I
wanted
to
address
jordan.
You
said
about
all
of
these
other
places
where
these
are
being
reported
today
and
that
we
want
to
shoot
for
support
there.
I
think
we
can
make
impactful
progress
without
all
of
those
being
covered.
D
I
mean
in
some
ways
if
npm
supported
it,
it
would
help
force
the
hand
of
the
other
places
it
would
set
it
as
a
precedent
and
also
it
would
be
super
impactful
in
you
know
most
of
my
use
cases,
which
I
only
you
know
I
and
many
people
I
you
know,
look
over
their
shoulder.
It's
like.
Oh,
I
got
a
quick
audit
result
now.
Let
me
go
dig
into
the
the
audit.
You
know
even
that
would
like
save
each
individual
engineer
a
bunch
of
time.
D
So
so
to
me,
I
think
just
starting
with
the
you
know
the
folks
that
we
have.
You
know
good
connections
with
and
the
ability
to
push
a
thing
forward
like
npm
we
should
you
know
we
should
make
sure
that
we
don't
require
those
other
things
just
to
their
buy-in
from
those
other
orgs.
Just
to
start
the
process.
A
No,
it
would
be
good
to
have
a
list
of
that
of
the
you
know
the
plate,
the
the
places
we'd
like
to
consume
this
list
in
the
end,
because
just
at
least
inviting
people
from
those
groups
would
make
sense.
But
I'd
agree,
you
don't
need
to
have
consensus
among
everybody
or,
or
you
know
the
attention
from
all
of
the
groups
to
actually
start
to
make
useful
progress
with
one
or
two
of
them.
A
Okay,
the
next
one,
then
is
pkgs
org
for
pkts
org
that
one
I'm
not
sure.
If
there's
too
much
new
to
talk
about
this
time,
I
know
dominicus
has
been
helping
to
push
some
of
the
things
forward
and
it's
still
kind
of
on
the
list
to
just
sort
of
do
the
last
few
steps.
E
I'm
not
sure
what
you
mean
by
the
last
bullet
point
in
your
last
post
there
in
terms
of
integrated
into
node.js
org.
A
Right,
if
there's
any,
you
know
like
the
moderation
team,
doesn't
have
access
and
we
haven't
made
the
tse
members.
You
know
the
owners
and
so
forth,
like
we,
we
would
do
it
once
it's,
it's
finally
integrated.
So
I
think.
D
A
D
A
I
haven't
heard
anything
on
that.
What
what
I
thought
we
would
do
in
for
now
is
just
create
another
team
which
has
all
the
tse
members
in
it
and
add
to
the
onboarding
instructions
for
tse
members
that
here's
another
list
you
need
to
add
somebody
to.
I
couldn't
think
I
couldn't
think
of
anything
better
than
that.
G
D
Yeah,
I
did
because
this
was
the
three
hours
of
the
triage
team
I
at
first
I
was
well
not
at
first.
I
still
have
this
problem
because
I
never
finished
the
tool
I
was
it's
just
going
in
and
adding
everybody
to
the
three
express
orgs
was
getting
really
annoying
and
it'd
be
really
easy
to
do
with
a
github
action
that
just
has
access
to
all
three
orgs,
because
then
you
just
you
know
you
can
change
all
the
policies
anyway.
It's
in,
I
can't
remember,
what's
called
membership
syncer
or
something
it's
in
pkgjsorg.
D
D
A
A
So
I
think,
okay,
so
I'm
just
looking
looking
at
the
like.
Is
there
any,
I
think,
from
the
tse
members
at
least
to
start,
though
it
might
you
know,
instead
of
blocking
on
getting
the
tool
ready,
we
could
just
create
a
team
called
nodetsc,
and
I
can
we
could
add
that,
as
I
think
that
would,
if
we
created
that
team,
we
could
then
give
that
team
access
as
owners
is
that.
A
D
I
have
before,
but
dom
sort
of
led
a
lot
of
the
initial
investigation.
Also
there
might
be
some
developing
things
here,
so
I
don't
you
know,
I
don't
know
if
there's
been
progress,
but
we
should
also
not
spend
a
ton
of
time,
probably
on
it
just
yet
until
we,
I
think
see
what
offerings
might
come
from
some
of
the
folks
at
github
or
something.
D
I
will
reach
out
privately
to
somebody
who
can't
I'll,
maybe
reach
out
to
the
person
directly
right
after
the
meeting
and
say
you
need
to
turn
this
on
or
you'll
get
booted
and
then
I'll
do
it
later
today.
Hopefully,.
D
Also,
no
so
we
need
to
add
the
this
is.
Actually
I
should
add
this
to
the
checklist
as
well.
What's
the
you
said,
there
was
another
discussion
on
the
node
repo
about
the
the
node.js
scope
and
there's
a
like
foundation
account.
I
think
that
should
be
added.
Is
that
correct.
A
There
is
a
node.js
foundation
account
which
yeah
they
they
it's
one
which
it's
basically
a
backup.
So
the
build
working
group
has
access
to
that
account
so
that,
if
say
all
the
the
people
who've
published.
Basically,
if
all
the
current
collaborators
disappeared,
somebody
could
log
in
as
that
user
and
add
somebody
new.
E
E
We
have
a
couple,
namely
webby,
because
it's
just
easier
to
type
for
things
that
you're
executing.
A
E
D
You
just
from
the
npm,
but
if
we
don't
do
that,
I
would
like
to
propose
we
dual
publish
again
for
the
same
reason,
because
then
we
can
migrate.
People
easily.
E
Yeah,
so
I
I
very
much
agree
about
that
with
that.
If
we're
talking
about
libraries,
however,
if
you're
talking
about
executables,
it's
just
the
hassle
to
type
npx
at
something
slash
and
then
also
npx
itself
is
very
fiddly
when
there's
scopes
involved.
E
I
don't
remember
the
issues
precisely
that
I
had,
but
that's
basically
the
primary
reason.
I
put
that
and
then
the
other
stuff
that
are
meant
to
be
used
as
clis,
that
I
put
them
in
a
public
scope
is
that
nvx
is
not
always
cooperating.
D
And
there's
darcy
going,
maybe
there's
a
bug
there.
We
should
go
fix,
but
that's
actually
a
really
great
reason
not
to,
but
I
still
think
dual
publishing
would
be.
You
know
reasonable,
because
then
you
know
maybe
that
that
those
issues
go
away
in
the
future
or
there's
some
better
way
for
us
to
think
about
that.
E
To
just
something
like
pkg,
slash,
webby
and
use
wb
as
a
dependency
and
just
expose
that
as
a
as
a
bin
and
export
just
re-export
it
do
you
think,
that's
enough
or
do
you
think
it
needs
to
be.
D
Cloned
I'm
definitely
not
opposed
to
that.
I've
never
tried
that.
So
I
don't
know
you
know
it
would
mean
that
any
you
can't
deep
require,
which
is
maybe
fine.
You
can't
right
like
there's
a
few,
like
maybe
edge
case
scenarios
that
might
be
different,
but
again
I
don't
think
that
should
be
a
blocker
I've
just
never
done
it.
E
D
A
I
some
of
those
I
would
just
create
another
issue
in
the
well.
Do
we
have
a
org
or
in
the
package
maintenance
repo
to
say
we
should
do
this
right
versus
tying
them
to
this
issue,
which
is
really
we
should
basically
say
what
are
the
last
few
things
we
have
to
do
to
say:
we've
created
the
org,
we
needed
it's
integrated,
we're
done.
D
Yeah,
I
think
I
think
that's
I
think
those
we
can
just
open
an
issue
on
would
be,
and
just
that's
fine
because
again,
I
think
the
only
real
thing
is
like
access,
right
and
and
settings
for
this
particular
issue
and
we're
very
close
on
that.
I
mean
I
think
I
can
knock
a
bunch
of
those
out
soon,
but
and
then
we
can
just
do
the
whippy
conversation
or
whichever
other
ones.
You
know
we
think
we
have
strong
value
and
being
published
on
the
public
scope.
You
know
looking
forward
anyway.
E
I'm
also
hogging
a
couple
of
organizations
in
npm
at
webby
and
at
webb
test
same
as
on
github.
We
have
we
be
test.
Just
literally
I
mean
this.
You
have
to
have
a
separate
torque
for
tests.
I
might
need
yet
one
more
for
the
forks
and
then
add
will
be
just
just
in
case,
so
I
should
probably
add
folks
in
there
as
well
right.
A
In
terms
of
the
team
to
put
the
tse
members
in
it's
just
called
tsc
and
the
node.js
org
and
then
yeah
the
node.js
org,
should
I
call
this
node
tsc
in
the
pkgs
org,
to
make
it
more
obvious
or
probably.
B
A
Okay,
anything
more
to
discuss
on
that
one
all
I'll
start
by
adding
the
tc
members
and
then,
after
that
we
can
look
at
figuring
out
the
the
moderation
side
of
things
and
what
else
was
on
that.
Was
there
anything?
What
else
was
on
that
list?
So
wes
is
gonna
handle
the
the
2fa.
D
A
A
A
Okay,
let's
move
on,
then
let
me
find
the
minutes
trying
to
get
back.
D
To
the
minutes,
okay,
just
to
round
that
off,
I
added
the
node.js
foundation,
I
think
they'll
whoever's
on
there
will
have
to
accept
it
and
then
I'll
bump
them
up
from
member
to
owner.
A
A
Okay
and
then
the
next
steps
on
support
levels
for
package.json.
I
think
that
we've
already
covered
under
the
blog
post
and
once
that
it
that's
that
we
can
come
back
to
to
that
and
that's
the
end
of
the
agenda
is
there
anything
else
that
we
think
we
need
to
talk
about
this
week.
B
B
I
think
roy
might
be
late
because
he
just
shipped
his
first
node
release
and
then
also,
I
think,
hey
as
an
announcement
again
worshiping
beta
releases
of
the
npm
seven
every
tuesday.
So
that's,
I
think,
also
what
he
was
probably
working
on
just
now
so
feel
free
to
keep
giving
us
feedback
on
that
and
yeah
we're
working
away
each
week,
so
new
releases
on
every
tuesday.
So
far,
so.