►
From YouTube: 2021-01-12-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
january
12
2021.
We
will
follow
the
agenda
that
was
tagged
in
the
issue
within
the
repo
which
was
issue
number
442..
A
B
C
I
just
brought
it
up
as
like
I
for
me
personally,
I've
only
been
able
to
attend
half
or
less
of
the
meetings,
because
I
can
only
ever
attend
one
of
the
two
times.
C
So
if
I'm
the
only
one
that
that
applies
to
then
we're
good,
because
my
convenience
is
not
more
important
than
the
groups,
but
it
was
more
just
like
raising
the
question
of.
Should
we
periodically
reevaluate
whether
the
meeting
times
we've
chosen
are
allowing
for
maximal
efficiency
and
attendance
and
if,
if
the
current
ones
are
doing
that,
then
we're
good.
No
change
is
needed.
B
B
People
booked
that
that's
like
the
the
time
to
get
hold
of
the
group
before
before.
Something
happens
like
have
you
all
heard
and
so
forth,
and
so
on.
I'm
sure
we're
all
very
aware
of
that,
but
that
doesn't
take.
That's
very
selfish,
only
takes
into
account
my
very
new
york
centric
view
of
the
world,
which
has
been
kind
of
shattered
on
a
few
occasions
right.
A
C
E
But
is
that
why
it
alternates-
because
I
think
I
see
that
as
a
common
pattern
in
other
groups
right,
it's
yeah,
it's
kind
of.
I
guess
what
would
be
a
reasonable
accommodation.
You
know.
Does
everybody
have
an
opportunity
to
catch
one
a
month
or
you
know
right
plurality,
every
time
or
right
somewhere.
E
C
Equity
is
really
important
right,
like
providing
increasing
the
chances
that
people
can
attend
a
meeting,
and
I
think
that's
that's
valuable,
even
if
it's
one
a
month
right
the.
However,
at
some
point,
if
the
membership
in
the
group
has
remained
relatively
constant
and
every
current
member
of
the
group
has
a
subset
of
time
zones
or
meeting
slots
to
op,
that
would
be
better
for
them.
Then
it
often
is
productive
to
wait
until
someone
shows
up
for
whom
the
new
meaning
slots
are
inconvenient
to
widen
it
again.
C
So
I
was
sort
of
just
saying
like:
can
we
take
stock
of
ourselves
and
be
like
what
is
what
we
have
good
and
if
not,
what
would
be
better-
and
you
know-
that's
it
without
trying
to
you
know-
be
imposed.
My
selfish
personal
concerns
onto
the
group
just
kind
of
raising
the
question.
A
A
F
So
it
would
be
the
earlier
one.
The
current
one
is
roughly
the
latest.
I
can
do
right
now,
mostly
because.
A
F
A
G
For
me,
I
find
it
in
unless
I
join
this
kind
of
late
one
for
us
in
europe.
There's
half
of
this
group
that
I
never
kind
of
speak
to
unless
I.
H
G
Exception
to
join
one
evening
just
because
I'm
online,
so
if
I
I
could
probably
do
the
early
one
a
couple
of
hours
later
and
this
late
one
a
couple
of
hours
earlier,
because
they're
such
like
polar
ends
of
the
day
and
it
means
I'd,
never
make
the
late
one.
Apart
from
today.
Actually
it's
an
exception.
C
I
Is
that
I
could
also
go
with
that,
because
the
earlier
one
is
actually
harder
for
me
to
get
to.
I
Well,
I
mean
harder
to
get
through
scheduling,
conflicts,
scheduling.
A
I
I'm
in
favor
of
that
and
I
own
just
shared
the
yeah
estimator
here.
E
Yeah
I
just
stumbled
upon
that
the
other
day
trying
to
coordinate
with
folks
in
australia
and
texas.
So
it
came
in
quite
handy,
so
I
wasn't
sure
if,
like
maybe
either
well,
if
we
can
do
it
live,
but
maybe
this
is
helpful
for
other
groups
where
you
can
kind
of
try
and
collect
where
everyone
is
and
see.
If
there's
any
organic
overlaps-
and
you
know
then
kind
of
work
out
from
the
the
center
as
it
were
so
just.
H
Figured
by
that,
we
did
that
very
early
on
with
this
group
that,
document's
probably
still
in
the
repo,
like
our
link,
I
think
to
one
of
those
scheduling
tools
where
we
collected
who
can
go
when
yeah.
I
don't
know
if
that
matters,
if
we're
all.
Basically
on
the
call
saying
we
agree
that
moving
toward
the
center
is
better,
it
sounds
like
that
would
just
should
be
a
fairly
easy
decision.
A
E
That's
what
I
was
think
is:
maybe
we
try
and
give
a
window
for
a
few
weeks
and
try
and
get
as
many
folks
on
the
team
to
add
their
time
zone
and
maybe
preferences
to
the
issue,
and
then
we
can
pull
all
that
into
and
you
know
might
either
there's
maybe
a
a
convenient
time
that
works
for
both
or
you
know
we
just
find
the
most
convenient
individual
time
for
the
depending
on
how
far
apart
we
are.
I
guess
that's,
maybe
the
point
of
jordan's
issues
like.
E
A
A
A
C
A
C
Right
and
the
important
thing
as
well
that
I
want
to
stress
by
asking
the
question
in
the
first
place,
is
that
it
should
be
low.
Friction
to
ask
this
question
and
to
change
the
meeting
times
to
whatever
is
up
community
for
all
of
us,
which
means,
if
someone
shows
up
from
like
asia
or
something
where
these
most
of
these
time
zones
may
air
time
slots
may
not
work
like.
We
should
all
be
open
to
also
accommodating
them
and
changing
making
changes
at
that
point.
But
we
don't
need
to
necessarily
accommodate
people
that
aren't
here
yet.
A
Right
yeah,
there
is
some
discussion
around.
You
know
the
the
you
know,
building
the
opportunity
and
you
know
versus,
but
I
think
we've
been
running
at
this
time
long
enough
that
and
that
we
kind
of
see
what's
happened
right
like
if
we
don't
have
people
who
were
here
saying
hold
on
a
second,
maybe
we're
a
little
bit
better,
because
we've
actually
had
the
two
extremes
for
quite
a
while.
A
So
I
guess,
like
I
think,
in
terms
of
making
a
concrete
proposal
do
we
want
to
propose.
You
know
thursday,
thursday,
at
12.
D
I
mean
I
will
say
from
my
standpoint:
I
won't
be
able
to
make
those
times
just
because
I
do
have
meeting
like
stand-up
conflicts
with
that
so
right.
So
if
we
have
a
second
time
that
would
be
right.
A
So
the
nine
o'clock
does
that.
I
guess
that
you
know
that's
a
very
good
point
about
the
other
reason
for
having
two
times
is
that
it
just
for
whatever
conflict
makes
it
a
bit
easier
for
people
yeah.
A
A
H
Yeah
true,
we
could,
I
mean
I'm
sure
we
would
even
be
open
to
moving
it,
we're
a
much
smaller
group
with
a
lot
easier
ability
to
be
flexible.
So
if
that
was
the
only
time
that
worked
for
everybody
here,
I'm
sure
that
we
could
just
change
what
day
would
that
fall
upon.
A
A
I
From
there
does
that
make
sense,
could
we
just
set
up
a
doodle,
michael
with
those
time
slots
in
it,
so
that
then
we
can
also
see
who
agrees
to
it.
Instead,
volunteering,
I
can
do
it.
I
actually
have
it
open.
I
Sync,
I
can
pull
out
those
yeah.
I
literally
was
like
creating
it,
as
you
were
talking
right,
okay,.
A
A
A
G
A
The
watch
I'm
also
happy
to
announce
or
let
people
know
that
it
was
added
to
the
modules
in
node
shift.
So
a
number
of
the
red
hat
maintain
modules
now
have
the
the
support
info
added
and
we're
gonna
put
a
blog
post
out
on
that.
So
if
you
know
it
probably
be
good,
if
people
could
help
promote
that,
just
as
I
like
hear
some
people
starting
to
adopt
it
in
node
shift,
so
I
don't
know
exactly
when
that's
going
out
but
I'll.
A
A
J
Yeah
so
I
talked
with
wes
the
other
day
and
yeah
he
pushed
what
he
had
and
I'm
working
with
wes
to
you
know,
implement
more
stuff.
A
I
No
okay!
No!
This
is
this
effort
I
think,
is
completely,
and
I
know
I'm
not
sure
chris.
I
know
you
had
a
question
there
from
a
while
back.
I
don't
know
if
we
already
talked
about
it,
but
like
just
the
whole
point
of
of
kicking
this
off,
but
yeah
like
there's
nothing
from
npm
side
to
to
do
the
idea
to
bring
it
to
the
space
was
to
like
create
a
standard
outside
of
of
our
defaults.
I
A
H
I
was
going
to
say
chris
remember
the
the
sort
of
next
step.
One
of
the
next
steps
for
this
group
was
we
wanted
to
see
if
there's
any
interest
in
moving
some
of
the
other
packages.
I
had
involved
there
into
the
org,
so
I
have
a
create
package.json
which
is
used
in
the
code
that
that
I
pushed
and
the
idea
was.
H
I
I've
made
a
post
a
while
back
with
sort
of
like
an
architectural
plan
for
it,
but
the
idea
was
to
decouple
like
our
opinions,
which
is
the
stuff
in
create
pkg
js,
create
from
the
like
mechanics
right,
which
is
like
how
do
you
structure
a
package
json
and
write
it
to
the
file
system?
How
do
you
read
it
from
the
file
system?
H
What
about
you
know
setting
up
the
git
repo,
like
all
that
stuff
is
sort
of
generic
and
doesn't
have
anything
to
do
with
us
as
a
group,
but
when
it
comes
down
to
it
like
management
of
the
underlying,
you
know,
packages
that
are
required
to
build
a
library.
H
Scaffolding
tool
might
be
valid
to
move
into
the
pkgjsorg
as
far
as
ownership
and
right
now,
I
own
the
only
other
two
that
are
used
there,
which
is
create
package.json
and
create,
but
I'd
be
happy
to
move
them
into
the
org
or
to
add
everybody
onto
those
repos
which
are
just
under
my
personal
name,
or
we
can
scrap
those
entirely
and
rebuild
them
in
a
way
that
makes
more
sense.
H
A
J
Yeah,
I
think
they
should
be
move
also
opta,
probably
unless
you
think
otherwise,
west.
H
No,
I'm
happy
to
move
all
of
them
that
one
is
probably
a
little
bit
more
on
the
generic
side.
But
again,
I
think
you
know
whatever
makes
whatever
is
going
to
enable
folks
to
work
on
it.
The
most
easily
right
and
and
if,
if
moving
them
into
the
org,
helps
achieve
that
goal,
then
yeah
I'll
move
all
the
repos.
H
It
is
we
need
to
make
a
more
formal
list.
The
list
that
I
linked
chris
to
I
think
is
incomplete.
I
think
what
darcy
had
in
the
original
issue
also
has
a
ton
of
stuff
that
we
haven't
finished
discussing
like
you
know.
What
should
we
have
test
command
with
certain
frameworks
that
come
out
of
it
or
you
know
or
like?
I
can't
remember
exactly
the
list.
I
don't.
H
A
A
J
J
Like
the
list
and
just
just
transpose
it
over
somewhere,
like
I
don't
know
in
a
project
or
or
something
right
now,
specifically
I'm
not
looking
at
the
support
stuff,
I'm
I'm
filling
out
more
fields
in
the
package.
Json
creator
thing,
so
that's
where
I
am
right
now:
okay,.
A
J
I
mean
it's
just
like
fields
in
this
list,
for
example
that
are
not
like
supported
yet
so.
Funding,
for
example,
needs
to
be
implemented.
J
Just
for
like
an
action
item,
I
will
take
like
darcy's
list
and
I'll
throw
it
in
somewhere
once
once.
I
don't
know
where
should
it
go
exactly
like,
I
could
put
it
in
a
project
on
the
package.
Js
jsorg.
Does
that
sound
reasonable.
I
H
I
think,
even
if
we
don't
agree,
I
think,
moving
the
full
list.
That
is
our
like
here's
ideas
over
would
be
good.
Just
so
folks
can
have
a
centralized
place
to
disagree.
If
that's
what
they
want,
because
I
think
having
the
conversation
split
is
going
to
be
harder.
J
Yeah,
it's
just
it's
like
a
it.
It
it
cross
will
cross
many
repos.
So
that's
just
why
I
suggested
a
project
just
kind
of
to
tie
it
all
the
I'll
tie.
All
of
it
together.
I
don't
know
I'll
figure
something
out.
H
H
A
I
Yeah,
sorry,
I
didn't
get
around
to
looking
at
the
hack,
md
doc.
I
have
to
follow
up
on
that.
I
apologize
what's
the
email,
I
have
to
send
it
to.
Let
me
quickly
find
that.
C
A
I
Okay,
so
I
can
take
the
ace
to
to
send
this
off
today,
unless,
if
folks
want
to
just
give
it
a
once-over
I'll,
give
you
like
an
hour
or
two
to
poke
me
offline.
A
A
A
The
next
one
is
next
steps
on
support
levels
and
package
json.
I
know
the
two
things
I've
taken
notes
on
like
we
still,
you
know,
need
to
promote
adoption
through
the
modules
we
talked
about,
adding
to
create
pkg.
A
A
A
A
Sorry
say
it
again:
sorry
which
badge
info
remember
like
we
had
like
the
support
info
and
there
were
like
badges
that
we
had
in
in
in
support
and
we'd
added
that
some
other
way,
but
like
the
idea
was
like
one
npm
could
actually
show
like
what
you've
set
for
the
different
things.
I
did
open
that
as
a
as
a
discussion.
A
A
I
Yeah,
I
can't
speak
to
you
like
the
timeline
there,
but
that's
definitely
the
right
place
to
to
put
that,
and
there
is
a
team
dedicated
to
the
site
and
registry.
So
adding
adding
feature
like
that.
I
know
we
added
like
the
typescript
badge
recently,
so
that's
like
something
that
they're
those
small
wins
is
and
that
bubbling
up.
That
extra
metadata
is
something
that
they're
interested
in
so.
I
Yeah
b,
mpm
slash
feedback,
slash
discussions
is
probably
the
right
forum
for
it
today
for
those
driving.
F
I
The
link
again
it's
it
should
be
npm,
slash
feedback,
slash
discussions
so
like
github.com
and
then
the
npm.org
feedback
discussions.
I
A
A
What
what
we're
discussing
there
and
comment
whether
it
makes
sense?
It's
not
100,
though.
A
A
This
one
right
here,
oh
yeah,
okay,
sorry
now
you
pasted
one
twice,
got
it:
okay,
so
yeah!
So
that's
the
one
people
want
to
jump
in
and
it's
gonna
see
just
following.
C
When
you
click
on
that
support
indicator,
it
should
tell
you
something
about
it
like.
This
is
what
this
means
here
is
how
you
can
do
this
to
your
own
package
right
and
potentially
also,
maybe
npm
would
show
in
a
like
a
grayed
out
version
of
it
no
support
info
and
that
you
click
on
it.
This
is
how,
if
you're
the
maintainer,
you
can
add
support
info,
and
hopefully
the
instructions
to
do
that
are
as
trivial
as
possible,
and
I
have
not
it's
been
so
long.
I
don't
remember
where
we're
at
with
that.
A
C
So
that's
cool
that
should
be
mentioned
in
there
too,
but
it.
I
think
that
it
would
probably
behoove
us
to
build
the
one-liner
to
configure
it
before
we
well
create
package
is
good
for
new
stuff,
but
I
have
hundreds
of
existing
projects
so
like.
C
While
I
might
be
willing
to
do
the
extra
work
to
type
out
the
json
like
it
would
be
nice
if
there
was
just
a
one-liner,
I
could
run
in
each
package
that
just
like
set
up
the
support
that
I
already
intended
to
provide,
and
maybe
you
know,
and
then
I
I
you
know,
I
get
that
badge
and
it
just
kind
of
it
makes
the
the
blurb
we
have
to
describe
the
support
feature
much
smaller
and
it
makes
the
time
we're
asking
people
to
invest.
C
Much
smaller
right
seems
like
it
would
be
before
be
like
sort
of
from
a
pr
standpoint
right.
You
have
your
big
impact
of
your
announcement
right
and
I
think
before
we
only
have
one
of
those
and
before
we
have
our
splash,
it
seems
useful
that
we
build
those
those
polish
toolings
so
that
we
get
the
most
boost
possible
from
that
exposure.
C
C
H
I
think
so
two
things
I
think
the
the
package
we
have
today
should
contain
the
one
liner
so
like
you
shouldn't,
have
to
have
a
separate,
create
support
info
package.
Do
this?
So
that's
one
comment
and
secondly,
I
think
if
you
piggybacked
off
of
the
stuff
for
create
pkg,
you
could
probably
do
this
in
like
less
than
100
lines
of
code
to
get
the
to
get.
Have
it
ask
the
questions
and
and
insert
the
format
into
the
package
json-
and
you
know
built
like
yeah
and
and
do
all
that.
C
Right
well-
and
it
seems,
seems
like
a
nice
place
to
be
if
create
package
is
just
gluing
together,
a
bunch
of
separate
packages
that
are
capable
of
with
or
without
a
wizard
like
doing
the
right
thing
for
this
exact
purpose,
because,
like
creating
a
package
yeah,
you
want
to
do
all
those
things,
but
like
there's,
probably
a
bunch
of
stuff
that
npm
in
it
does
that
I
would
actually
love
to
have
as
one-liners.
So
I
can
like
ensure
all
my
packages
are
consistent,
even
though
they've
existed
for
years
and
yeah.
H
Yeah,
I'm
fully
on
board
with
this,
and
the
part
of
the
design
of
the
create
package.
Json
thing
was
to
enable
those
kind
of
things,
so
it
like
reads
the
initial
package
json
first
and
tries
to
make
the
minimum
amount
of
edits
that
design.
I
think
we
should
carry
over
to
anything
that
we
write.
That's
going
to
touch
the
package.json
so
that
existing
package
ecosystems
are
really
well
supported
there.
H
H
That's
the
create
pkg,
but
right
so
my
proposal
there
was
to
use
the
same
internals
there
right,
which
handle
the
like
cli,
the
user,
prompts
and
then
the
question
would
be
whether
you
want
to
reuse
the.
I
think
it's
just
using
the
chris
and
I
were
talking
about
this
yesterday.
You
should
probably
use
the
npm
package
for
reading
the
package
json.
H
I
don't
know
if
you
have
a
do.
You
all
have
a
package
for
writing
the
package
json
out
to
disk.
H
That's
the
requirement,
that's
what
I
think
the
current
one
doesn't,
the
create
p
package
jason
doesn't
have
and
that
I
was
looking
for.
So
if
you
have
that,
I
think
that
would
be
a
great
addition
and
we
could
just
read
the
same
things
inside
of
create
or
inside
of
the
support
package.
Get
that
job
done.
H
K
Name,
jordan,
I'll
put
it
in
the
chat.
A
Okay,
yeah-
and
I
just
created
this
issue
in
the
support-
the
support,
module
to
say,
create,
add
this
command
and
I
tried
to
capture
the
you
know:
coordinate
with
adding
through
info
through
the
create
package,
but
like
wes.
If
you
want
to
jump
in
there
and
clarify
anything,
I
got
wrong.
That
would
be
great
too.
A
A
But-
and
you
know,
I
think
it
could
even
be,
and
it
could.
I
guess
you
know
last
comment
would
be
this.
We
can
probably
keep
the
initial
version
of
that
simple
as
well.
It
doesn't
have
to
cover
all
the
cases
as
long
as
it
goes
back
to
jordan's
comment.
It
would
cover
like
enough
of
the
cases
for
hey.
I
just
want
to
add
something.
That's
probably
going
to
be
right
for
me,
so
it
could
be
a
subset
of
the
total
options,
but.