►
From YouTube: Package Maintenance Team meeting - February 25 2019
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
A
I'm,
seeing
shaking
heads
I'll
take
that
as
a
no
so
we'll
just
move
on
to
our
agenda
items
I'm
just
going
to
paste
in
the
chat
the
link
to
the
minutes,
if
people
can
add
themselves
to
the
present
list.
Okay,
so
for
the
first
issue
on
the
agenda,
is
numbers
160
so
choosing
a
license
in
choosing
dependencies?
So,
let's
just
see
who
added
that
in.
A
A
A
B
A
B
Cool,
we
don't
always
make
it
very
clear
who
the
dog,
who
the
intended
audience
for
a
specific
dog,
is
I.
Think
in
this
case
the
intended
audience
is
the
maintainer
right.
That's.
A
B
B
A
True
but
I'm
thinking
that
might
be
more
general
guidance.
It's
like
when
you
choose
your
licenses
of
anything
yeah
I
think
yeah
you're
right.
We
should
keep
that
in
mind,
but
I
think
the
first
focus
would
be
like
fur
package,
maintainer
Ziff,
there's
guidance.
We
can
provide
in
terms
of
what
license
what
licenses
and
how
to
choose
them
and
how
to
sort
of
I
guess.
The
concerns
that
the
consumers
may
have
will
affect
that
for
sure.
I
guess.
A
B
Think
have
sort
of
a
there's
some
of
the
issues
they
do
have
heated
discussion,
I
think
the
version
one
is
a
sort
of
contentious
point
right.
Do
we
have
it
as
a
general
practice
that
we
write
up
two
things.
I
mean
there
are
obvious
best
practices
such
as
you
know,
use
ember,
whereas
the
other
ones
to
be
note
that
there's
opinionated
people
who
may
or
may
not
have
advice
on
certain
things,
such
as
starting
on
v1.
A
Yeah
I
mean
I,
guess
that
we,
our
choices,
are,
we
can
kind
of
like
say
nothing
about
the
contentious
ones
or
we
could
try
and
say
you
know,
there's
two
points
of
view.
Here's
the
advantages
at
this
one
and
here's
the
advantages
that
the
other
one
I
think
in
my
mind,
that
would
be
useful
right.
So
people
can
come
to
it
and
say
well,
I.
You
know
some
people
would
tell
me
this.
Some
people
tell
me
that
I'm
gonna
make
my
decision
based
on
you
know
that
understanding,
rather
than
just
choosing
at
random
right.
C
I
think
we
absolutely
need
guidance
and
I
must
say
some
of
the
things
I
like
volunteering,
for
just
for
the
fact,
because
I
don't
know
anything
about
them
or
I
must
be
the
vast
majority
of
people
that
randomly
go,
that
one
break
and
I
think
that's
what
we
need
some
help,
even
even
a
few
lines
you
know.
Do
you
know
what
even
a
popularity
thing
saying
this
is
the
most
popular,
and
this
is
the
least
popular
which
would
help
people
and
I.
C
Know
what
we
tend
to
do
just
internally
is
we
use
two
below
one
numbers
for
test
versions,
that
people
can
actually
release
modules,
and
just
don't
worry
about
that.
You
need
a
real
module,
but
it
might
be
a
bespoke
one
and
it
will
order
like
the
integer
numbers
are
the
ones
and
higher
are
real
things.
It
gives
people
some
leeway.
Obviously
we're
never
gonna
run
out
numbers
right.
A
C
A
A
So
I
see
there's
some
some
discussion
as
well.
It's
the
same.
Unless
people
want
to
have
specific
things
to
talk
about
now,
it's
I
guess
the
question
there
was
like:
should
we
be
telling
people
how
to
do
it
or
what
to
do
and
I
think
I'd
agree
that
we
shouldn't
necessarily
choose
a
winning
package
or
test
framework
but
guidance
around
what
you
should
test
or
sort
of,
and
then
maybe
you
know
then,
following
on
that
saying:
okay
now
that
here
are
the
recommendations.
A
Yeah
yeah
yep,
oh
but
I,
think
this
is
even
for
like
new
modules,
you
know
I
think
I,
think
saying
you
know
there
should
be
tests
and
even
if,
like
somehow
I,
don't
know
in
my
mind,
it
might
make
sense
to
have
some
guidance
in
terms
of
like
to
standardize
how
you
can
run
those
tests,
because
you
know
if
other
people
are
gonna
run
the
test.
That's
a
lot
easier.
If
you
know
you
know,
NPM
tests
will
always
run
the
core
tests
that
need
to
run
or
whatever.
It
is
something
like
that.
A
D
Think,
with
all
these
topics
like
there's
a
context
of
we're
talking
a
lot
about
the
what
now
there's
a
context
of
why,
right
to
the
point
about
like
new
maintainer,
so
people
like
just
give
them
a
little
bit
of.
Why
is
this
important
as
opposed
to
here's
the
steps
and
here's
what
you
need
to
do
right.
A
A
E
A
Sure
I
mean
I'm
happy
to
bounce
off
ideas
and
stuff
with
you.
If
you
want,
but
it's
it's,
you
know
I
think
sort
of
right
out.
You
know
the
way.
I'd
start
anyway
is
to
write
out
what
might
look
like
the
table
of
contents
for
it,
and
then
you
know
we
can
start
filling
in
and
asking
writing
section
stuff
like
that.
So
it
sounds
like
well
well
tag.
You
is
the
the
owner
of
that
one
and
yeah.
If
you
need
help,
feel
free
to
to
reach
out
okay.
A
A
You
so
maintainer
is,
this
is
continued,
so
this
is
maintainer
x',
proper
use
of
maintainer
xin
package
adjacent
how
to
select
maintainer,
potentially
github
md
template
that
requires
peer
code
for
review
background
check
right.
So
this
is
basically
how
to
manage,
maintain
errs
in
a
project
and
I
guess
that
can
get
on
to
the
even
how
to
transition
if
it's
not
covered
somewhere
else.
A
A
A
F
A
No.
This
is
no
longer
maintained,
so
there's
the
then.
The
question
is,
if
somebody's
deciding
other
than
the
maintainer,
whether
it's
maintained
or
not,
who
and
what?
Who
are
they
and
what
are
they
gonna
do
when
they
define
when
they
figure
that
out?
Is
it?
Is
it
the
consumer,
the
module
that
will
say?
Okay,
I,
don't
think
this
is
maintained
anymore
or
is
it
us
as
a
team
like
the
the
package
maintenance
team?
That
is
gonna.
Do
something
that
says:
okay,
we're
gonna.
If
we
identify
unmaintained
modules,
will
take
some
action
or
something
like
that.
A
F
Now
that's
a
good
point:
I
think
it's
probably
both
for
the
maintainer
and
consumer.
Again
primary
would
be
for
maintenance
like
hey.
If
you
have
a
package
that
you
that's
really
you
don't
want
to
spend
any
more
time
on,
or
you
don't
have
time
to
work
on
any
more
than
what
what
should
you
do?
Here's
the
guidelines
that
we
suggest
you
follow
in
order
to
hand
Han
off
a
package
to
someone
else
and
I
think
secondary.
It
is
also
we
should
have
a
section
for
consumers.
Hey
if
you
you're
trying
to
use
a
package.
F
Here's
guess
what
you
need
to
do
to
figure
out.
If
it's
it's
a
stay
up
to
date,
or
if
we
have
some,
you
found
a
serious
/,
critical
issue
with
it
and
no
one's
responding
to
yield.
Here's
what
you
should
do
you
raise
the
issue
and
we
should
reach
out
to
watch
what
you
should
do
to
figure
out.
What's
the
status
of
the
package
and
what
are
your
options?
Kind
of
thing
right.
A
So
I
could
almost
see
that,
like
we
could
have
won
best
practice,
which
is
for
maintainer
x',
which
is
like
how
to
handle
deprecation,
okay
and
then
I
could
almost
see
a
separate
one
which
is
targeted
at
consumers.
It's
like
you
know.
How
do
you
select
how
to
select
modules
and-
and
part
of
that
could
be
well
look
to
see
whether
you
think
it's
being
actively
maintained
or
not
sounds.
F
A
A
We
should
be
able
to
see
that
now
so
I
think
this
is
the
one
that
we
have
so
Express
sounds
like
they've.
You
know,
I've
shown
interest,
so
is
mqtt
and
nab
is
the
three
that
we
have
identified
as
showing
interest
to
get
started.
I
guess
we
need
either
West's
or
Matteo
I
think
we're
kind
of
probably
Wes
who
is
pushing
on
this
to
figure
out
you
know.
Do
we
want
to
push
for
a
few
more
before
we
take
the
next
step,
or
should
we
start
doing
things,
but.
C
Does
and
one
of
the
other
things
with
all
of
these
sort
of
endeavors
to
us
package
maintainers,
we,
you
must
try
not
to
lose
momentum
and
it
we've
all
developers.
They
like
doing
things,
Deborah,
okay,
some
way
talking
but
mostly
like,
and
we
should
get
going
on
something,
even
if
only
to
learn
what
not
to
do
right.
C
A
I
think
I
think
it's
it's
true
like
with,
since
we
have
to
I
think
I
expressing
them.
Qtt
are
probably
too
good
ones
to
say.
Okay,
what
could
we
start
to
get
going
and
start
to
do
and
so
I'm
definitely
in
agree.
So,
okay,
we'll
put
that
on
we'll
see
what
Wes
says
and
then
we'll
figure
out
how
to
get
moving
on
the
next
step.
A
I
mean
it's
kind
of
like
we're,
trying
to
get
a
like
we're
trying
to
come
from
two
different
directions:
one
is
from
the
well.
What
can
we
start
doing
and
the
other
one
is.
What
are
the
problems
we're
trying
we're
going
to
start
to
solve,
but
it
is
so
it's
I
guess.
Then
the
next
step
might
be
to
talk
to
the
pilot,
the
two
pilot
ones
and
see
if
we
can
get
a
list.
Maybe
the
next.
A
A
Okay,
so
then
next
issue
is
number
93
yeah
now
I
think
a
number
of
these
two
are
like
all
these.
So
far,
I
will
go
through
and
remove
the
package
agenda
and
then
whoever
the
volunteer
is
who's
pushing
them
forward.
If
you
want
to
bring
it
back
to
talk
at
the
next
meeting,
just
add
the
package
agenda
back
on,
but
I
think
that
makes
sense
as
opposed
to
just
assuming
they
should
be
the
on
the
agenda
against
this
discourage
use
of
unmaintained
packages.
A
Like
I
think
that's
sort
of
the
two
parts
there
was
that
there
was
the
one
part
you
we
were
talking
about,
which
is
the
as
a
package
maintainer
or
what
should
you
do
to
deprecate
packages
and
so
forth?
And
then
on
the
flip
side?
What
do
we?
What
are
we
gonna
do
to
evangelize,
discouraging
the
use
of
unmaintained
packages
so
that
yeah
that
would
be
covered
by
the
one?
A
D
A
1:39
so
its
first
kind
of
documentation
for
support
levels-
and
you
know
I
think
really
is
just
a
call
for
people.
We
have
a
couple
of
people
who
have
reviewed
and
approved
just
need
to
get
a
few
more
people
in
there
to
say
yeah
that
looks
good
and
then
I
think
it
can
land
I,
there's
been
a
number
of
comments.
I
think
I've
got
everything
a
dress,
that's
in
flight,
so
just
want
to
put
it
on
people's
radar,
because
I
think
it's
one
that
we
can
get
landed.
B
A
B
A
D
B
D
A
But
but
it
just
seems
like
it's
gonna
be
simple
enough
that
it's
like
grab
a
node,
you
know
grab
a
JavaScript
script.
People
can
pull
it
out,
they
can
play
with
it.
So
I
would
say
like
we
might.
Why
don't
we
just
put
it,
you
know,
put
it
in
the
as
a
sub-directory
package,
maintenance,
slash
tools,
or
you
know
something
like
that.
A
So
that
makes
sense
sure.
Okay,
that
way
we
can
share
it
play
within
then
once
we're
ready,
we'll
figure
out,
I
think
the
the
right
answer
is
probably
a
repo
under
the
nodejs
org,
but
we
can
figure
that
out
when
we
get
there.
Is
that
something
you're
looking
to
work
on
or
thank
code?
Yeah
sounds
good,
okay,
so
yeah.
So
if
people
can
take
a
look
at
that,
I
don't
know
if
there's
any.
E
D
A
D
A
A
A
A
F
A
F
A
A
Yeah,
like
that's
one,
that
I
would
like
to
know
it's
like
if
there's
just
a
standard
set
that
say,
here's
ones
you
just
never
want
I
did
see
that
there's
like
the
tests
and
stuff
seem
to
be
controversial.
All
right
was
there
a
small
set?
That's
that
people
agreed
with
or
from
the
discussion
or
is
it.
F
Actually,
by
default,
NPM
itself
ignores
some.
Some
files
and
NPM
also
uses
git
ignore,
but
there
there's
like
certain
things
that
sometimes
you
go
and
now
we're,
because
if
you
have
an
NPM
ignored
and
NPM
will
not
use,
git
ignore
and
and
losest,
and
then
a
difference
between
NPM
ignore
versus
how
far
so
there
it's
gotten
better
over
years,
but
it
because
NPM
just
by
default,
ignore
some.
F
You
know
fairly
common
files
that
you
should
not
publish
with,
but
there's
still
some
minor
things
which
in
which
one
you
use
and
what
you
should
be
aware
of.
That's
why
they're
still
package
out
there
that's
publishing
some
files
that
they
should
not
for
examples
like
coverage
data.
That's
definitely
should
not
be
published
right.
A
I
think
like
I,
guess,
they're
and
I,
wonder
if
like
could
it
be
written
in
a
way
that
says
like
here's,
the
here's,
the
ones
you
just
most
likely
don't
want
to.
You
want
to
ignore
no
matter
what
right
and
then
there
could
be
a
next
set,
which
would
be
and
if,
for
some
reason,
you're
worried
about
the
space
or
size
of
your
packages.
Here's
some
other
things
you
can
ignore
because
from
the
discussion
it
sounds
like
there's
it
that's
where
it
gets
into.
A
F
I
am
not
aware
that
NPM
has
any
like
guideline
on
what
to
do.
Np,
I'm
just
talking
and
you
know,
and
what
what
kind
of
tools
they
offer
like.
It
is
what,
when
you
in
P
unpublished.
This
is
what
NPM
does,
and
these
are
the
standard
files
NPM
ignore
and,
and
you
can
put
have
a
NPM
ignore
file
or
you
can
put
files
in
package
partition,
and
there
are
certain
things
like
the
behavior
of
these,
depending
on
which
option
you
go
with.
There
are
certain
things
that
NPM
doesn't
document.
D
About
NPM
ignore
but
more
smoke
more
generically
I'm
just
asking:
if
is
it
in
the
benefit,
because
NPM
is
not
the
only
way
right
for
users
to
get
packages
and
for
maintainer
publish
packages.
So
what
is
kind
of
the
subset
or
lowest
common
denominator
of
information
that
a
package
maintainer
needs
to
consider,
rather
than
something
that's
NPM,
specific
I
guess
alright,
so
I
could.
F
D
Npm
things
but
I'm,
just
like
I,
want
to
refocus
the
issue
a
little
bit
on.
You
know
things
that
are
specific
to
the
package
maintainer
or
the
package
user
in
particular,
and
you
kind
of
you
know
mentioned
a
few
of
them
like
you
know
the
idea
files
should
that
be
included
or
not
you
know,
and
YC
output
coverage
whatever
like
those
are
a
little
bit
more
generic
things,
at
least
like
your
coverage
data.
Your
test
data
should
should
this
be
issue,
be
about
discussing
those
things
rather
than
potentially
NPM
specific
things.
I.
A
D
A
D
F
B
A
It
might
be
easier
to
like
write
a
draft
of
what
the
doc
might
look
like
factoring
in
the
comments
so
far,
and
then
it's
easy
to
like
remove
if
somebody
says
well,
you
shouldn't
exclude
you
shouldn't.
You
shouldn't
exclude
this.
It's
easy
to
like.
Take
that
one
line
out
and
say:
okay!
Well,
do
we
agree
that
this
now
makes
sense
or
not
right,
yeah.
A
A
Not
it
looks
like
we're,
making
some
good
good
progress
on
the
baseline
practices,
thanks
to
everybody,
for
volunteering
to
do
the
different
ones.
That's
that'll
be
great
and
we'll
see
if
we
can
catch
up
with
Wes
and
and
start
the
discussion
with
the
our
candidate
or
a
proof-of-concept
maintainer
zazz.
Well,
a.