►
From YouTube: Package Maintenance Team meeting - 11th Feb 2020
Description
A
B
We
had
a
planning
meeting
earlier
today
for
the
collab
summit.
One
thing
we
might
also
consider
is
somebody
may
be
opening
an
issue
to
discuss
what
this
group
would
want
to
do
at
the
next
collab
summit
so
that
we
can
get
ahead
of
that
and
make
sure
that
our
whatever
we
want
to
do
is
actually
represented,
because
there's
a
little
bit
of
back-and-forth
last
time
when
we
thought
we'd
have
the
community
corner
and
then
that
sort
of
fell
through
so
maybe
coming
up
with
a
plan
there
I
did
sorry
that's
sort
of
not
an
announcer.
A
B
D
A
B
So
one
thing
that
came
out
of
us
discussing
this
in
the
last
meeting
is
here:
let
me
post
a
link
to
that
issue.
So
one
of
the
things
blocking
the
auto-update
of
the
list
of
those
issues
was
this
status
board.
A
feature
where,
like
the
indexing,
was
timing
out
in
the
github
action,
John
Church
opened
an
issue
based
on
that
just
discuss
next
steps.
We've
made
some
progress
in
the
discussion,
but
it
would
be
great
if
folks
could
well
if
somebody
could
volunteer
to
actually
do
the
work.
B
B
So
it
is
due
to
the
amount
of
data.
Yes,
so
we
have
to
paginate
through
basically
all
the
express
issues
on
all
the
repos.
So
that's
what
makes
it
take
a
long
time
we're
not
actually
timing
out
on
any
individual
requests.
It's
the
github
actions.
Runner
has
like
what
appears
to
have
been
and
I
haven't
revisited
it
a
bit
like
around
a
10
minute
timeout.
B
B
Yep
to
process
there's
a
lot
of
issues
but
I
cuz
yeah
anyway,
there's
a
the
thread
goes
through
a
couple
of
possible
improvements,
but
yeah
index
everything
across
all
three
orgs
and
all
Rico's
I.
Think
in
my
local
tests
was
something
like
12
minutes
to
get
it
all
done.
I
think
what
we
we
just
wanted.
There
was
like
an
incremental
index,
so
it
didn't
necessarily
reindex
everything
all
the
time.
Yeah.
D
Yeah
you'll
wanna,
yeah,
yeah,
okay
I
have
some
ideas
of
how
to
solve
that
at
a
higher
level
so
that
we
can
reuse
that
solution,
because
I
know
what
the
stash
board
there's
opportunity
to
probably
query
other
data
other
than
issues
that
you're
gonna
need
the
same
kind
of
like
strategy
for
whether
that's
like
spinning
on
the
cluster
child
processes.
That
then
can
go
off
and
hopefully
run
faster
and
and
then
also
storing
data.
And,
as
you
noted,
like
not
fetching
things
I've
run
into
some
give
API
restraints,
though
myself
as
well.
B
A
D
B
I'm
just
I'm,
just
rereading
it
just
to
make
sure
I
was
up-to-date,
so
there
is
the
tool
so
that
actually
leads
to
the
next
discussion,
which
is
the.
What
is
our?
What
like
process
guidelines?
Do
we
need
to
put
in
place
around
contributions
to
the
the
stuff
in
that
other
org,
that's
sort
of
related.
There
adds
support
info
so
like
in
order
to
have
all
this
support
info
added
to
these
packages.
B
We
really
need
a
tool
that
helps
us
do
that,
which
was
what
that
support,
adding
a
CLI,
because
I
think,
if
you
we
had
a
CLI
that
would
help
us
generate
the
support
metadata.
Then
that
would
be
what
we'd
promote
to
the
rest
of
the
modules
in
the
node
org
evangelizing
and
get
additional
input.
We
could
be
doing
and
writing
a
blog
post
about
it,
that
kind
of
stuff,
but
I,
don't
I,
don't
think
it's
blocked
by
well
it
could.
B
We
could
consider
it
blocked
by
lack
of
tooling
right,
so
I
think
one
of
your
team's
concerns
was
that
it
is
a
bit
of
a
complicated
and
large
data
structure
and
so
having
no
tooling
around
it
and
also
trying
to
promote
it
is
maybe
not
going
to
be
successful.
I,
don't
know
how
y'all
feel
about
that.
Yeah.
D
D
D
Some
of
the
tooling
that
I
know
Wes
has
already
built
around
generating
and
or
validating
I
think
there
was
some
initial
work
done
there
around
the
support
schema
once
we
have
that,
then
it
you
know,
MPM
supports
templates
for
in
it
and
then
the
create
pkg,
essentially
template
package
would
work
and
look
very
native,
I,
think
to
the
end
user
and
the
developer.
Experience
is
very
nice.
If
you
can
imagine,
I
developed
our
being
able
to
initialize
a
brand
new
package
with
you
know.
B
I
want
to
throw
my
weight
behind
this.
I
really
believe
that
this
is
a
great
move.
I
think
take
you
know
the
fact
that
99%
of
people
will
use
NPM
in
it
without
any
extra
tooling
is
pretty
crazy,
cuz
there's
so
many
other
things
it
takes
to
get
a
package
with
all
of
the
actual
best
practices
implemented
off
the
ground.
B
I
love
this
package,
but
I
actually
want
to
make
clear
that
we
don't
have
to
block
building
this
tooling
on
that
package,
so
we
can
have,
and
so
the
way
that
the,
if
you
look
at
the
PK
gjs
slash
create
package
is
the
idea
is
that
that
is
this
foundation
for
making
composable
generators
so
with.
If
we
could
make
a
generator
for
the
status.
Sorry,
the
the
support
schema
that
would
then
be
loadable
and
come.
You
know
composable
with
the
PKG
generator.
B
So
I
just
want
to
make
sure
that
it's
good.
That
is,
I
think,
the
ultimate
goal,
but
I
think
we
should
be
thinking
about
these
incremental
steps
where
we
have
a
generator
for
a
default
support
definition.
We
have
a
generator
for
how
you
test
your
like.
We
have
a
recommendation
about
testing
in
all
the
LTSs
with
like
the
aliases.
We
can
build
a
generator
that
spits
out
a
Travis,
that
is
by
recommendation
what
we
do.
We
can
do
it
with
a
github
action.
D
B
B
B
B
B
B
C
Yeah
we're
just
saying
that
I
don't
think
he
was
able
to
shine
these
calls
recently,
as
I
was
always
saying,
but
also
getting
back
to
the
topic
of
evangelizing
this
Shh.
Do
we
have
a
volunteer
to
do
that?
I
am
NOT
able
to
do
that
myself
right
now,
but
I
think
we
should
start
for
the
blog
and
I
think,
despite
the
fact
that
we
don't
have
all
the
children
yet
we
definitely
need
input
from
from
the
rest
of
the
community
and
from
more
people.
B
A
B
A
C
A
A
C
C
Yeah
sure
yeah
I
didn't
realize
that
it
was
in
the
meeting
so
yeah
we
had
a
very
productive
and
very
long
RFC
called
bounce.
Some
ideas
back
and
forth
I
still
have
to
follow
up
and
post
my
notes
on
it
and
just
list
the
use
cases
there
and
so
from
the
NPM
site.
It
looks
like
this
is
moving
forward
right
and
there
will
be
a
staging
area
that
you
can
publish.
Packages
on
most
is
some
details
and
technical
points
that
need
to
be
ironed
out
and
that's
moving
forward.
C
So
that's
nice
and
then,
from
the
perspective
of
the
current
PR
I'll,
just
update
it
with
the
notes
that
we
have
and
probably
rephrase
it
to
to
do
to
basically
list
things
that
are
coming
and
things
that
you
can
use
today.
If
you
have
this
issue
because
continuous
off
that
dev
is
pretty
cool
and
it
looks
like
it
will
get
support
and
semantic
release
pretty
soon.
So
that's
very
nice
yeah!
That's
that's!
Roughly
the
overview.
Do
we
have
anything
specific
to
discuss
here.
D
C
Yeah
so
so
we
discussed
we
had.
We
had
some
discussion
points
there,
so
I'm
I
still
have
to
follow
that
up.
I'll
post
the
notes
and
there's
there's
some
minor
editing
that
needs
to
be
done
there
and
I
think
we
discussed
that
there
may
be
some
use
cases
that
we
want
to
revisit
and
see
if
we
are
covering
all
of
them.
A
B
Did
but
I
think
we
should
have
the
the
formal
discussion
of
what?
What
do
we
need
to
put
in
place
or
do
we
need
to
put
anything
in
place
officially
and
then
what
should
that
thing
be?
Which
is
so
like
Donna
cussin
myself
have
both
created
repos
over
there.
We
didn't
ask
anybody,
we
just
did
it
I
like
that,
but
also
for
things
as
they
move
forward.
B
We'll
have
to
make
sure
that
there's
like
a
cohesive
vision
and
that
we
have
you
know
you
know
we
don't
make
breaking
changes
on
accidents
like
who
we
need,
like
probably
a
PR
approval
process.
Do
we
need
approve?
Do
we
need
some
sort
of
idea
about
creating
repos
so
like,
or
do
we
just
want
to?
Let
anybody
create
anything
and
we'll
figure
it
out
later,
like
what's
the
for
maintaining
our
tools,
since
we
decided
that
putting
them
spinning
them
up
inside
the
node
org
is
risky
for
many
reasons.
B
D
D
B
B
It
might
never
like
a
lot
of
our
efforts,
probably
should
never
rise
to
the
level
of
like
here's,
a
fishel,
node
solution
for
this
thing
so
having
the
separate
org
gives
us
a
place
to
do.
Off-The-Wall
experiments
where
you
know
we
maybe
someday
they.
They
become
popular
enough
and
receive
enough
backing
that
they
come
into
the
node
org
proper.
But,
like
there's
reasons
why
I
think
it's
risky
to
start
there,
because
then
we
have
all
of
these
eyes
on
us
and
we'd.
B
D
B
B
D
How
like
tightly
coupled,
we
are
like
what
what
we're
gonna
have
to
be
mindful
of
in
terms
of
like
everything,
you're
saying,
which
is
a
lot
more
like
politically
charged
or
like
you
know,
has
other
ramifications,
and
there
should
be
a
standard.
It
shouldn't
be
like
different
for
how
we're
spinning
up
this
sub
Fork
compared
to
like
how
any
other
team,
like
the
you
know,
like
the
tooling
working
group,
could
spin
up
on
Orcas.
Well
like
a
sub
or
maybe
I,
don't
know
for.
B
D
G
Yeah,
this
would
just
be
a
quick
point.
It
gets
a
despairing
away,
I'm,
not
sure
if
it's
antithetical
to
the
notion
of
open
source,
but
would
there.
But
if
one
the
challenges
is
trying
to
keep
it
under
the
hood
or
under
the
umbrella
of
nodejs,
but
maybe
not
necessarily
all
this
ceremony
because
of
its
kind
of
niche
experimental
approach.
G
B
C
C
What
wes
is
saying
about
the
process
that
we
do
need
some
process
and
we
do
need
PR
reviews
and
approvals
and
all
of
that,
but
also
at
the
same
time
so,
for
example,
the
thing
that
I'm
working
on
the
Travis
camel
parser
for
the
node
versions,
so
that
I
can
reuse
it
in
a
in
a
larger
scale.
I,
don't
know
how
many
people
are
interested
in
looking
to
my
peers.
There
do.
C
We
have
people,
do
really
just
stay
there
and
then,
on
the
other
hand,
putting
it
into
the
official
repo,
it's
kind
of
a
baggage
and
a
burden
right.
I
it
feels
a
lot
more
official
than
it
should
be,
and
then,
in
that
case,
I
would
probably,
if
we
didn't
have
that
other
repo
I
would
have.
Probably
we
created
that
either,
under
my
personal
or
under
near
forms
account,
which
is
also
not
a
problem.
C
G
C
B
Yeah
but
I
think
that
your
your
the
fact
that
you
said
I
didn't
think
I
had
permissions.
Oh
I
do
like
that's
exactly
kind
of
the
problem
that
this
other
org
would
be
trying
to
solve
right.
It's
like
we.
We
would
like
people
to
be
able
to
not
have
to
hem
and
haw
and
make
sure
that
they
are
pushing
a
complete
thing.
B
Can
click
that
traitor
repo
button
every
day
and
make
a
new
thing
and
then
not
finish
it
and
then
have
it,
sit
there
for
a
little
bit
and
have
it
be
sort
of
a
thing
you're
noodling
on
and
then
we
can
all
sort
of
collaborate
and
then
you
know
maybe
someday
you
delete
it
or
maybe
you
move
it
to
your
own
personal
space,
but
that
should
be
kind
of
fine,
because
that's
what
helps
us
move
the
ball
forward
today?
You
look
at
what
Jordan
Harbor
and
is
doing
it's
all
in
his
own
personal
stuff.
B
I,
don't
follow
all
of
that,
but
I
definitely
can
go
to
one
org
and
follow
everything.
That's
at
me,
no
I'd
love
to
see
him
move
some
of
his
tooling
into
the
team
space
as
well,
so
that
it
doesn't
feel
like
quite
so
disconnected,
but
not
also
under
the
node
org,
where
it
feels
like
whoa.
You
have
to
go
through
all
the
hoops
you
know.
D
Yeah,
so
I
think
definitely
for
some
people.
The
reason
why
they're
doing
that
is
because
they
want
to
ensure
that
there's
the
proper
systems
and
policies
and
practices
in
place
for
so
that
they
know
that
their
efforts
are
wasted
in
something
that's
maybe
thrown
away,
so
that
level
of
sophistication
for
some
contributors
is
probably
actually
what
with
is
like
a
barrier
to
entry,
if
you
don't
have
because
they
don't
want
to
they,
would
they
want
that
level
of
sophistication
to
that?
D
D
So,
let's
try
to
not
just
solve
for
our
specific
use
case
here,
but
like
let's
potentially
bring
this
bubble
this
up
a
bit
higher
and
then
figure
out.
If
there's
something
that
we
can
do
that
also
alleviates
some
of
the
things
that
have
been
brought
up
and
in
terms
of
like
how
do
we
enforce
the
code
of
conduct?
How
do
we
onboard
people
who.
B
A
B
B
E
A
A
B
You
know
what
one
other
thing,
while
we're
we're
kind
of
looking
for
other
things
to
talk
about
with
rare
that
we
don't
fill
up
the
whole
time.
A
apparently
yarn
has
some
level
of
end-to-end
automation,
which
hits
a
bit
on
what
we
had
talked
about
with
like
carrying
the
goldmine,
and
let
me
find
the
link
to
their
and
their
tests.
B
B
So
I
haven't
dug
in
yet
but
I'll
post
a
link
in
case
other
people
want
to
so
this
is
yarns
and
to
end
test
suite,
and
they
were
saying
that
a
lot
of
that
well,
this
is
the
I
guess,
is
the
actions,
but
so
it
runs
off
on
other
things
anyway.
This
might
be
a
good
inspiration
for
us
when
we
start
looking
at
like
matrix
testing
and
down
stirring
dependency
testing
and
that
kind
of
stuff
that
we
talked
about
at
the
collab
summit.
B
A
On
a
similar
note,
I
did
doodle,
it
was
issue
3:07
in
package
maintenance
and
to
kind
of
kick
off
the
tooling
discussion
around
set
Jim
and
some
of
the
issues
that
were
related
to
how
we
test
across
LTS
versions
and
also
had
a
release
team.
You
sit
Jim
and
maybe
we
could
leverage
it
in
working
groups
and
the
first
available
time
to
kick-start
discussions
was
actually
this
Thursday,
which
was
5
p.m.
to
6
p.m.
UTC.