►
From YouTube: Package Maintenance Team meeting - Jan 14 2019
Description
A
A
No
okay,
then
we'll
move
on
to
the
issues
which
were
tagged
with
the
agenda.
As
I
was
saying
earlier,
just
four
people
have
joined
the
stream
in
the
first
meeting.
We
had
a
good
discussion
of
sort
of
you
know.
Generally.
How
do
we
get
started?
What
should
we
start
working
on?
Out
of
that?
We
created
a
number
of
issues.
I
did
tagged
some
of
those
with
the
agenda
issued
just
so
that
we
can
get
a
quick
update
on
those
as
well
as
a
few
others.
A
I
thought
that
we
we
could
talk
about
the
auto
generator
generate
will
will
tag
everything
for
the
agenda.
That's
tagged
with
package
maintenance
agenda,
so,
if
you
ever
want
to
put
anything
on
the
agenda,
just
add
that
tag
and
it'll
automatically
be
added
to
the
list,
but
before
we
move
on,
is
there
anything
that
people
want
to
add
on
to
the
list
before
we
get
started.
A
Sounds
like
so
the
first
thing
this
tag
is
baseline
practices,
brainstorm.
The
initial
list
I
know
that
that
was
one
of
the
sort
of
three
things
that
we
discussed
by
getting
started
on
and
Edgar
helped
and
worked
with
us
to
open
this
issue
with
an
initial
list
of
some
questions,
and
there
has
been
a
good
discussion
in
that
issue.
In
terms
of
you
know
what
some
of
the
different
practices.
B
A
A
At
this
point,
I
think
you
know
the
next
step
might
be
for
us
to
sort
of
gather
the
discussion
together
and
then
create
some
sub
items
in
terms
of
like
concrete
thing,
concrete
processes
to
start
trying
to
document
or
or
identify
an
open
issue
specifically
for
them.
One
thing
we
did
do
is
we
did
create
a
directory
in
the
repo
itself.
So
under
the
repo
there
is
a
now
a
Docs
that
contains
a
doc.
You
know
readme
and
then
our
drafts
so
I
think
those
are
places
we
could
start
peeing
in
either
something
in
draft.
A
If
we
don't
think
it's
quite
ready
or
into
you
know
the
docs
that
we
would
be
pointing
people
to
so
that's
a
place
where
people
can
start
to
open
PRS
for
documentation
a
little
bit.
The
discussion,
I
I
forget
which
issue,
but
on
one
of
them
was
you
know
we
could
do
it
PRM
directly
to
the
the
website,
but
we
thought
maybe
collecting
it
in
this
repo
first
and
then,
once
we
sort
of
hit
critical
mass,
we
can
think
about
whether
we
need
to
move
things
to
the
the
website
and
stuff
like
that.
A
C
You
you
I
would
just
add
that
I'm
in
full
support
of
the
plan
to
have
everything
in
the
repo
before
it
goes
to
the
website.
I
think,
as
this
issue
made
pretty
clear,
there's
a
ton
of
discussion
and
a
ton
of
different
points
and
I
think
it's
probably
going
to
take
a
fair
bit
of
time
before
we
have
something.
That's
really
solid.
That
would
be
worth
putting
on
the
website
and
it'd,
be
unfortunate
to
put
on
website
too
early
and
have
it
be
incomplete
or
misleading,
or
anything
like
that.
A
A
A
F
A
A
E
A
Also,
if
anybody
else
wants
to
help
out
with
keeping
the
minutes
and
updating
the
minutes
feel
free
to
jump
in
okay.
So
the
next
issue
on
the
agenda
is
discuss
discussion
on
the
node.js
slack
Channel.
So
that's
number
one
18.
In
terms
of
that,
there
was
basically
discussion
on
how
we
might
talk
more
directly
than
through
github
I.
Think
you
know
there
was
consensus
at
the
end
that
we
could
move
forward
with
slack,
and
so
there
is
a
slack
channel
opened
and
channel
that
was
created.
A
So
this
is
more
of
a
sort
of
an
FYI.
So
if
people
want
to
join
that
slack
and
and
that's
a
place
where
you
know,
people
may
ask
questions
or
post
things
in
real
time
versus
github,
although
I
still
expect
most
of
the
conversations
will
be
in
github
any
questions
or
comments
or
concerns
on
that
front.
There's.
C
E
A
So
that's
one
I've
actually
been
working
with
one
of
the
maintainer
x'.
We
have
had
some
some
some
concern
over,
like
the
node
slack
link
itself
used
to
have
a
list
of
email
addresses
that
confuse
people.
We
managed
to
remove
that
the
other
one
was
a
registry,
as
you
said,
was
it
seemed
to
like
he
semi
manual
or
take
some
amount
of
time,
so
I
I
have
been
talking
to
the
maintainer
and
he
actually
proposed.
He
start
using
a
new
slack
registration
tool,
which
was
an
existing
repo
that
he
cloned
I.
A
A
E
G
E
E
A
A
A
A
A
Okay
right,
so
next
issue
was
number
113,
which
is
which
problems
no
GS.
Oss
maintain
errs
authors
face
today
that
was
number
113
Matteo
who
was
with
us
last
time,
but
can't
make
it
today
because
he's
travelling
and
in
a
different
time
zone
open
that
one.
After
our
discussions
from
last
last
week
and
there's
been
some
good
discussion
back
and
forth
I'm
thinking
you
know,
maybe
we
can
spend
a
few
minutes
discussing
what
we
think
the
next
step
on
dot.
One
is.
A
You
know
people
have
thoughts
of
like
are
there?
Are
there
ways
what
ways
do
we
think
we
should
apply
to
try
and
get
more
input
from
maintained
errs,
because
the
idea
here
was
to
try
and
build
up
we're
sort
of
coming
from
the
best
practice
aside,
we're
thinking
about
what
we
think
will
help
maintain
errs.
We
were
thinking,
we
should
try
and
you
know,
find
out,
go
from
the
you
know
the
problem
space
to
get
input
on
what
do
maintain
errs
have
the
most
problems
with,
and
that's
this
one.
H
Yes,
so
what
we're
seeing
is
I've
copied
you
in
a
few
emails
just
where
the
people
are
trying.
There
are
a
lot
of
packages
that
already
have
maintained
us
and
a
century
they've
inherited
them,
and
what
they're
really
looking
for
I
see
is
expertise
in
certain
areas
to
fix
things.
They
can't
do
themselves
and
I've
just
been
looking
at
the
node
API
one,
so
I
think
I
can
help
on,
but
I
think
generally
I'm.
Guessing
people
either
overwhelmed.
H
They
don't
have
time
or
there
are
things
that
I've
taken
on
that
they
can't
quite
cope
with
and
that's
it
always
falls
into
those
three
areas
and
we
could
actually
engage
a
bit
more
with
package
maintains
I,
didn't
see,
much
talk
about
or
I
didn't
see.
Much
mention
of
named
maintained,
errs
and
problems
they
are
having.
So
a
lot
of
this
is
going
to
be
hypotheses.
Unless
we
actually
start
engaging
with
people
to
have
problems,
you
won't
have
real
feedback,
hey
guy,
that's
my
two
cents
worth
and.
A
A
You
know,
should
we
some
maintainer
Zoar
pick
some
projects
and
go
and
then
reach
out.
You
know
each
we
could.
If
we
had
a
list
of
20
people
we
could
have.
You
know
we
could
break
up
that
list
and
say
we'll
all
go
talk,
reach
out
to
these
guys
these
people
and
then
somebody
else
will
reach
out
to
the
others,
but
that's
just
one
idea
of
how
we
might
do
it
I.
You
know
what
what
do
people
think
is
a
good
way
to
try
and
sort
of
start
that
engagement
so.
C
To
piggyback
off,
maybe
Matteo
also
brought
up
the
idea
of
having
some
friendlies
right,
I
wrapped
into
the
other
issue.
That's
on
the
agenda,
which
is
stages
of
of
who
we
engage
with
I.
Think
if
we
make
that
list,
that
list
should
probably
be
the
exact
same
list
we
use
for
who
we
go
and
talk
to
first
and
pilot
some
of
our
ideas
with.
C
A
So
do
you
want
to
do
you
want
to?
We
could
brainstorm
it
as
part
of
that
discussion
or
we
could
because
I
agree
that
yeah,
starting
with
some
friendlies
and
you
know
a
list
of
I,
don't
know
five
or
whatever
would
be
a
really
good
way
to
start
to
get
some
initial
feet
and
we
might
be
able
to.
Then
you
know
once
you
have
a
little
bit
more
of
a
context,
it's
easier
to,
then
you
know
maybe
go
out
with
a
survey
or
whatever
something
more
broadly.
The.
I
People
who
are
maintaining
hundreds
of
packages
are
really
kind
of
the
outlier
I
feel
like,
and
so
you
know,
while
their
input
is
going
to
be
valuable,
I'm,
not
sure
if
they're
necessarily
the
first
people,
we
should
reach
out
to
just
kind
of
throwing
that
out
there.
You
know,
there's
there's
lots
of
people
who
have
a
lot
of
their
time
on
open-source
eaten
up
by
a
one
or
two
projects,
and
so
you
know
I
think
those
people
are
probably
much
more
widespread
than
the
really
prolific
authors.
I.
C
A
You
know
some
other
smaller
and
not
smaller,
but,
like
you
know
somebody
who
maintains
you
know
just
one
or
two
packages,
so
maybe
we
should
just
you
know
open
an
issue
to
put
together
that
list,
people
that
we
want
to
reach
out
to,
and
then
you
know,
people
I'm
sure
each
of
us
will
have
different
ideas
and
we'll
come
up
with
a
list.
That
sort
of
I
know
is
a
good
representation
of
all
those.
If
we
do
it
that
way,.
C
A
Yeah,
like
is
there
any
reason
you
don't
think
that
we
could
start
with.
You
know
here's
our
list
of
initial
list.
It
was
gonna,
be
like
our
friendly
people
that
we're
gonna
go
out
and
sort
of
try
and
work
with
them.
As
our
pilot
you
know,
does
it
make
sense
to
just
use
the
same
list
or
should
we
actually
have
two
lists,
because
you
know
somebody
should
be
on
our
list
of
people
that
we
go
and
try
and
reach
out
for
input.
I
wouldn't
necessarily
make
it
on
to
the
pilot
list
or
I.
A
A
A
Okay,
so
on
that
one
is
there.
Is
there
other
things
that
people
should
think
we
should
talk
about?
I
mean
I.
Think
next
step
is,
is
that
we
need
that
list
and
then
encourage
you
know
I
will
in
that
issue
we
should
get
volunteers,
and
once
we
have
a
list,
we
should
get
volunteers
of
who's
going
to
go
reach
out
to
the
to
the
each
of
the
people
on
the
list.
In
terms
of
saying
hey,
this
is
what
we're
doing.
Can
we
have
some
of
your
time
and
input?
A
D
Is
there
been
any
discussion
of
like
some
sort
of
automation
to
say
like,
for
example,
the
new
buffer
changes?
You
know
there
was
a
lot
of
feedback
there
by
I
haven't
touched
this
module
in
two
years
and
now
I
have
to
go
changed.
You
know
new
buffer
or
buffered
up
from
two
new
buffer.
Those
are
the
types
of
things
that
can
easily
be
like
I'm
BOTS
can
do
that
and
then
make
pull
requests
for
people.
A
B
A
C
C
Also
just
said,
there's
been
maybe
three
or
four
issues
that
have
been
open.
That
haven't
been
talked
about
in
the
other
meeting
or
on
the
agenda
here.
Actually
well,
maybe
feel
made
it
on
the
agenda,
but
that
talk
about
what
things
we
could
automate
there's
some
specific
ones
in
the
repo
that
might
be
worth
linking
to
from
the
agenda
that
that
I,
don't
think
made
it
here.
Sure.
A
D
A
We
haven't
talked
about
yeah.
That
sounds
great.
The
thing
the
thing
I
would
say,
though,
is,
if
you
know
driving
that
might
be
good.
You
know
you
mentioned
the
buffer
one.
So
that's
a
perfect
example
that
says
if
we
know
there's
something
currently
being
faced
by
maintain
errs.
That's
maybe
another
good
way
to
address
this
is
to
say,
okay,
here's
a
particular
issue.
What
are
the
kind
of
things
that
would
help
maintain
errs?
In
that
case
it
also
I'm.
D
It
also
sort
of
turns
what
is
somewhat
tedious
work
into
like
the
fun
part
of
coding,
which
is
great
spot.
You
know,
there's
a
mic
that
does
a
codemod,
it
makes
PRS
and
you
could
make
an
issue
for
that
and
somebody
could
go
implement
it
independently.
We
did
in
the
very
early
days
of
note,
I
think
it
was
the
zero
four
two
zero
six
migration.
D
We
did
an
experiment
with
an
internet,
no
jitsu
where
they
wrote
a
bot
like
this
and
made
like
20,000
PRS
or
some
absurd
number
of
pull
requests
automatically
and
a
lot
of
them
got
merged.
So
I
don't
know
how
much
it's
gonna
annoy
people
like
that's
another
way
to
think
about
it,
but
I
could
also
see
it
being
very
valuable.
Yeah.
A
So
that's
where,
like
you
know,
I
think
we
should,
if
we,
you
know,
maybe
worth
opening
in
it.
If
there
was
like
if,
for
example,
if
buffer
hadn't
been
addressed,
it
would
be
like
hey.
What
can
we
do
for
buffer
or
we
could
create
a
bot,
then
I
think
we'd
want
to
test
that
against
some
of
the
module
owners
to
say
well,
do
you
want
to
be
getting
automated
PRS
for
something
like
that,
or
is
that
not
something
you'd
want
to
see
and
if
we
then
confirm
that
most
of
the
maintainer
say
hey?
A
D
Yep
yeah
I
mean
it's
just
the
question
of
the
efficacy
of
the
bot
like.
Sometimes
it
makes
mistakes
and
other
stuff
it.
It's
an
interesting
area
to
explore
and
I
again,
I
wasn't
sure
if
that
had
been
brought
up
before
it
sounds
like
there
could
be
some
useful
discussion
there
in
an
issue
down
the
road
yeah.
A
D
Yeah
I'll
try
and
dig
up
the
the
bots
that
we
use.
This
is
I
mean
this
ancient
ancient
history
at
this
point,
but
the
it
did
work.
One
of
the
challenges
was,
you
have
to
have
a
source
for
all
those
things
to
be
PRD
from
so
you
need
to
make
an
organization
for
the
bot
pr2
and
then
right
cuz,
that
has
to
fork
it
and
then
PR
it
right.
A
D
D
A
And
I
guess
it
would
come
back
to
like
you
know,
maybe
in
if
you
opened
an
issue
and
and
do
you
think
you've
said
a
bunch
of
you
know,
a
lot
of
people
have
fixed
the
buffer
issues
but
I'm
not
sure
also,
maybe
it's
still
a
concrete
one
to
to
sort
of
prove
out.
If
that's
the
right
concept
and
we
could
do
something
with
that.
This
time.
B
For
the
for
the
buffer
issue,
in
particular,
I
actually
looked
into
that
and
I
submitted
a
bunch
of
PR,
so
a
bunch
of
repos
fixing
it,
and
at
least
as
far
as
I
can
tell
it's
not
entirely
automatable,
because
replacing
the
buffer
constructor
is
easy,
but
you
have
to
make
a
choice
between
I
think
buffer,
a
lock
and
buffer
from,
and
the
choice
depends
on
the
value
of
the
parameter
that
you
use
to
pass
it
a
constructor
and,
and
so
that
value
cannot
always
be
statically
determined
like.
Is
it
a
constant
like
if
you
pass?
B
A
variable
in
that
variable
could
be,
could
be
a
number
in
which
case
you
want
buffer,
a
lock
or
it
could
be
a
string,
in
which
case
you
want
buffer
from,
and
so
so.
This
decision
is
not
easy
to
make
so
I
found
I
actually
wrote
the
script
that
would
replace
all
the
buffer
constructors,
but
I
had
to
go
in
after
the
script
was
done
and
edit
at
times,
because
the
tests
weren't
passing
in
the
end
for
that
particular
module.
B
A
And
I
guess
you
know
in
the
context
of
this
group
if
we
had
something
that
would
go
through
and
do
that
and
then
you
know
basically
have
a
bunch
of
branches
that
were
ready
to
PR
but
required
to
help
from
people
to
go
through
and
actually
make
the
you
know
actually
submit
the
PR.
We
could
build
a
list
of
you.
D
Things
they
could
do
right,
yeah,
the
the
I'm
remembering
this
now
this
was
when
exists
and
exists:
sync
moved
from
the
path
module
to
the
fs
module,
I
think
in
zero,
six
or
zero
eight,
and
that
there
was
a
lot
of
hubbub
about
it
and
we,
you
know
one
of
the
folks
on
our
team
just
made
a
bot
that
changed
path.
Two
FS
for
you
and
I
dropped
one
of
the
samples
PRS
in
there,
so
just
something
to
think
about.
I
think
that
it
could
help
solve
a
lot
of
the.
D
A
A
A
A
A
C
Sure
it
sounded
like
from
the
issue
that
everybody
was
on
board
with
this
little
three-phase
path.
So
I
have
like
I
mentioned
just
a
little
bit
earlier,
been
a
bit
busy,
so
I
haven't
opened
the
three
issues,
but
that's
my
next
step
for
that.
Maybe
I
can
tackle
that
this
week.
I
just
want
to
do
a
little
synopsis
of
what
each
of
the
three
phases.
So
the
idea
is.
We
can't
just
take
something
and
open
it
up
to
everyone
out
right
away.
C
We
need
to
try
out
what
our
ideas
are:
iterate
on
them
before
we
lock
ourselves
into
hundreds
of
packages,
we're
supporting
so
we'll
do
a
three
phase
approach
where
we'll
pick
some
pilot
partners,
being
you
know,
partners
being
the
the
authors
and
maintainer
of
these
packages,
we'll
work
with
them
with
whatever.
So,
if
we
make
some
automation,
we'd
run
it
through
these
packages,
first
make
sure
it
works
with
them,
take
their
feedback
or
if
there's
checklists,
or
you
know,
best
practices
that
we
develop
for
maintenance.
C
If
there's
LTS,
you
know
commitments,
we
want
to
make
those
kind
of
things.
We'd
run
them
past
these,
these
people
first
and
then,
once
we
have
a
good
foundation.
We'd
then
take
that
and
try
to
engage
with
more
partner.
You
know
more
Mainers.
Those
maintained
errs
would
then
get
a
little
bit
less
hands-on
with
us,
but
we
work
with
them
to
do
that
and
then
in
the
end,
we'd
like
to
automate
the
onboarding
process.
C
So
that's
sort
of
the
third
phase
is
once
we
have
all
these
practices
figure
out
a
way
that
a
module
author
without
anybody's
help
can
say,
like
hey,
look,
I
I
subscribe
to
these
best
practices.
These
you
know
tooling,
approaches
and
get
them
automated
onboard
without
us
having
to
help.
So
that's
the
three
phases,
so
I'm
gonna
open
up
three
issues,
one
for
each
of
them
just
to
continue
the
discussion.
A
A
H
Money,
thought
or
fear
about
that
is
weeman.
We
may
believe
the
mantras
are
maintained.
We
may
see
that
they've
been
PRA
stood
that
have
been
ignored
for
several
years,
but
that
mean
maintaining
may
be
very
active
working,
another
quite
significant
projects
and
its
really
a
case
of
they
own
the
project,
whether
they're,
maintaining
it
or
not,
I
still
doing
very
active
stuff
in
the
community.
How
do
they
feel
about
that?
And
how
do
we
feel
about
that?
H
We're
labeling
it
because
I
was
a
little
bit
arrogant
and
when
I
first
started
looking
at
things
and
then
I
looked
at
some
of
the
other
things,
a
person
had
been
doing.
I
thought,
oh,
my
god.
I
used
this
person
stuff
everywhere
and
I
may
have
been
too
hasty
in
my
feelings
about
what
was
maintained
and
it's
a
very
hard
thing
to
actually
say
they're.
Just
how
do
you
approach
somebody,
that's
doing
great
work
and
they
they're,
obviously
will
have
stuff.
They
haven't
looked
at
that
they
haven't
taken
Piazza
and
label
it
as
unmaintained.
A
Mean
I,
don't
think
the
discussion
in
the
issue
was
about
ice
labeling.
Anything
I
think
it
was
more.
It
was
more
around.
Are
there
things
or
tools
or
best
practices,
the
you
know
or
baseline
practices
that
we
can
come
up
with
which
encourage
maintain
errs,
who
feel
that
their
their
module
is
no
longer
maintained
and
which
people
didn't
use
it?
So
it's
easy
for
them
to
just
say:
don't
use
this
anymore
and
then
on
the
flipside.
It's
it's
very
easy
for
people
using
modules
to
know.
A
D
Think
the
biggest
challenge
that
I
see
is
ghosting,
okay
and
ghosting.
To
me,
is
you
you're
just
not
there
and
it's
not
like
oh
you're,
consciously
not
there
like
I'm
ignoring
people,
but
how
do
you
avoid
labeling
people
when
you
know
if
it's
not
opt-in?
So
unless,
if
it's
not
just
oh,
they
come
to
us
and
say
I'm,
not
maintaining
this
anymore.
Please
help
spread
the
word.
Then
you
are
gonna,
be
labeling.
D
You
know
labeling,
but
at
a
certain
point
there
is
like
a
SLA
for
somebody
opened
at
issue
where
they
want
to
be
a
contributor
or
they
want
to
join
your
project,
and
you
ignored
that
for
some
period
of
time,
let's
go
with
three
months
right,
you
know,
there's
there
is
some.
You
have
ghosted,
you
are
no
longer
present.
If
you
want
to
come
back
and
say,
I'm
sorry,
I
ghosted
that's
fine
I've
coasted
before
and
come
back
six
months
later
and
been
like
yeah
ghosted.
My
dad
died,
I'm,
sorry
like,
but
you
ghost
it.
D
H
C
So,
but
to
be
clear,
there's
a
difference
between
a
PR
being
open
for
several
years
and
somebody
ghosting
and
then
there's
another
our
difference
right
between
a
package
that
you
as
the
maintainer
just
don't
think
needs
updates
right,
like
I
could
have
it
could
be
five
years
old
and
it
could
be,
in
my
opinion,
perfect
yep
I'm,
not
ghosted,
but
I'm
also
not
going
to
spend
my
time
going
back
and
like
hand-holding.
Every
person
who
thinks
at
this
package,
which
is
tiny,
needs
something
right.
So.
D
The
classic,
like
you
know,
when
you
look
at
the
objective
definition
of
ghosting,
like
you,
didn't,
update
new
buffer
and
it
you
haven't
changed
it
in
over
a
year
and
somebody
opened
the
P
R,
moving
it
to
buffer
dot
from
and
you
haven't
merged.
That
P
are
like
there's
like
when
you're,
not
keeping
up-to-date
with
with
the
platform.
D
Those
are
the
places
where
it's
really
objective,
that
you're
not
present,
because
even
if
it
is
perfect
and
you're
having
that
sort
of
you
know
that
the
artisanal
versioning
conversation,
which
is
fine,
you
still
have
to
make
it
work
with
the
latest
node
and
the
latest.
Whatever
so
you'll
still
see
a
little
activity,
you'll
still
see
some
versions,
I.
D
A
Of
the
discussion
there
that
you
know
my
first
question
is:
do
we
think
that
all
like
that
maintainer
x',
so
that
ghosting
is
a
problem?
People
just
disappear?
Okay,
so
that's
one
issue
is:
is
it
not
a
problem
of
maintainer
who
were
active
but
haven't
indicated
that
it's
deprecated
or
because
I'm
thinking
an
easier
first
step
is
to
say
how
do
we
make
it
so
that
more
maintainer
x',
who
think
it's
no
longer
maintain
taking
action
so
that
it's
clear
or
is
that
just
not
a
problem
like?
Is
that
so
small
that
it
doesn't
matter.
F
A
F
Case
that
NPM
deprecated
is
a
fairly
new
thing
right,
right,
relatively
and
and
not
a
lot
of
people
know
about
it.
So
there's
definitely
a
case
of
advocating
the
use
of
that
right
and
there's
definitely
a
case
for
advocating
of
not
depending
on
back
is
that
have
been
marked
as
deprecated
or
versions
that
have
been
marked
as
deprecated
and
then
there's.
As
for
the
case
of
ghosting,
which
somebody
just
stops.
Maintaining
and
updating
I
mean
somebody
has
to
form
that
module
and
make
it
better
and
more
popular
yeah.
That's
kind
and.
H
C
So
can
I
just
say
on
the
forking
and
making
it
more
popular
I
think
there
is
a
active
issue
in
some
in
this
and
I
think
it
came
from
this
repo
on
the
npm
CLI
to
help
I
might
have
been
registered
because
I
think
it's
a
register
feature
to
help
try
to
come
up
with
a
way
that
NPM
can
help
transition.
People
I'll,
look
for
it
and
I'll
try
to
link
it
up
here.
C
D
I
mean
NPM
is
is
in
many
ways
trying
to
make
things
reliable.
You
know
like
the
way
that
they
changed
unpublish
a
couple
years
back
is
a
great
example
of
that,
like
once,
the
content
is
there,
the
content
is
there
and
it
is
the
same
git
repo
or
things
like
that.
So
you
know
when
the
git
repo
changes
between
version,
1
and
version
2,
because
you
you've
passed
the
stewardship
on
I,
could
see
them
being
really
against
that
in
principle,
from
like
transparency,
reliability,
security
model
threat,
model
perspective.
C
Yeah
I
think
it
I
think
it
makes
sense.
I
think
this.
The
suggestion
I'll
have
to
find
the
link
to
get
the
full
context,
but
I
think
the
suggestion
was
to
be
able
to
label
a
package
as
basically
an
alias
for
another
package
so
that,
if
you
had
the
forking
case
right,
you
could
just
say
you
could
publish
a
thing
in
your
package.
Jason
that
would
say:
hey
API
here
is
actually
a
fork
of
this
other
package.
C
A
And
then
back
to
like
the
the
deprecation
side,
I
mean
one
one's
you
know
so
I
I
think
the
MCUs
comment
is
like.
Maybe
we
should
put
some
effort
into
helping
to
promote
like
if
we
think
that
NPM
deprecated
is
helps
this
this
case
we
should
help.
Do
some
work
to
promote
it.
We
could
put
together
a
blog
post,
get
the
node.js
counter
to
tweet
that
you
know,
and
we
can
make
sure
that
we
incorporate
it
into
the
baseline
practices
for
module,
maintainer
and.
A
B
D
D
C
So
and
I
wanted
to
point
out
that
that's
actually
a
I
think
a
big
failure
in
using
this
feature:
they're,
not
deprecated.
They
are
no
longer
going
to
receive
updates.
There's
a
difference
right.
The
package
fully
worked
and
deprecates
original
design
was
to
say,
like
look
that
has
a
bug
that
has
a
security
vulnerability,
don't
use
it
I
think
there's
a
big
distinction
between
the
two
right,
because
I
might
not
care,
because
my
fun
yeah
right.
D
D
A
I
guess
there's
another
discussion
under
the
best
practices
where
I
I
was
suggesting.
We
like
try
and
advocate
for
something
like
in
your
package.
Jason,
that's
your
support
level
and
the
lowest
level
of
that
is
like
this
is
unmaintained.
We
don't
recommend
you
use
it
anymore
and
then
it
sort
of
goes
up
from
you
know
and
I
may
not.
A
I,
probably
don't
have
all
the
right
Grady
ations,
but
it
goes
up
to
you
know:
hey
I,
support
this
all
the
LTS
release
lines
or
whatever
and
or
actually
no
I,
think
that
I
think,
and
there
is
another
discussion
to
sort
of
have
it
had
a
dimension
between
you
know.
What
do
you
support
it,
for
you
know
LTS,
just
the
latest
and
so
forth,
and
then
separately
than
that
you
could
sort
of
have
something
that
asserts
your
support
level.
Is
it
like
I,
don't
use
it
or
hey
I'm,
a
one
person.
A
You
know
I
did
this
in
my
spare
time.
So
if
you
want
to
use
it
use
it
at
your
own
risk,
you
know.
Do
I
have
an
organization
like
you
know.
Is
it
part
of
the
nodejs
organization?
So
there's
a
project
behind
it.
Is
there
a
company,
that's
you
know,
committed
to
to
support
and
and
so
forth
right.
So
I
guess
maybe
is
that
you
need
a
little
bit
more
subtlety
than
depth.
You
know
deprecated
or
non
deprecated.
C
B
C
Think
I
think
it'll
be
hard
for
until
we
can
come
up
with
so
so
like
if
you're
thinking
putting
it
in
the
package
Jason
the
engines
field
obviously
had
its
problems
and
stuff
like
that.
That's
that's
one
thing:
if
we
do
the
same
like
what's
your
SLA,
we're
gonna
need
a
really
defined
set
of
that
way.
C
Right
so
so
I
think
maybe
a
better
place
to
start
would
be
to
come
up
with
some
best
practice
recommendations
and
give
people
like
an
NPM
module
that
just
generates
an
SLA
MD
file
or
something
and
just
say,
like
hey,
start
putting
this
in
here.
Here's
some
common
SLA
s.
What
kind
of
common
licenses
and
people
are
using
tooling
to
just
generate
their
license
files
that
would
be
maybe
a
better
middle
ground.
I
think.
A
You
want,
like
you,
know
the
what
I
was
thinking.
Is
you
want
something
like
licenses
where
there's
like
common
identifiers
for
the
common
licenses?
So
you
know
we
need
to
develop.
Like
you
know,
maybe
you
start
with
here's,
just
your
5s
LA's
and
here's
the
identifiers,
and
then
you
could
you.
You
probably
want
the
identifiers
in
the
package.json.
So
it's
easy
to
parse
right
like
you,
can
get
it
and
tell
it
and
it
just
points
to
and
then
if
people
want
to
suggest
new
SLA
is
well.
A
We
can
add
new
identifiers
for
those,
so
yeah,
okay,
I,
guess,
I.
You
know
I
wasn't
for
this
year.
Basically,
you'd
suggest
that
we
don't
necessarily
publicize
deprecated,
because
that
may
not
be
sending
the
right
signal
and
that
we
should
instead
start
with.
Let's,
let's
define
the
SLA
s,
because
that's
really
what
you
want
to
communicate
more
broadly
yeah.
A
A
Okay,
I
think
I.
Think
I
like
I,
see
that
I
can
definitely
see
that
and
we
don't
want
to
cause
noise.
So
I
think
the
more
completely
said
what
I'm
gonna
current
thing
is.
The
more
complete
solution
of
like
here
the
SLA
levels,
it'd
be
good
to
sort
of
figure
out
what
that
looks
like
and
then
then
we
can
see
what
the
existing
deprecated
feature
looks
like
in
that
context
and
decide
whether
to
say:
oh,
no,
it
still
makes
sense,
let's
publicize
that
or
let's
publicize
it
in
the
context
of
it.
A
You
know:
here's
your
SLA
levels
when
you
choose
this
one
also
do
this
NPM
deprecated,
because
there's
a
tool
or
something
right:
okay,
okay,
so
we'll
try
and
push
that
forward
as
part
of
the
the
baseline
thing.
So
you
know
it'll
likely
come
out
of
some
of
the
discussion
and
and
when
Rick
summarizes
it
we'll
make
sure
there's
one
issue
for
pushing
on
those
sort
of
SLA
levels
and
I
think
there
was
like
at
least
a
couple
of
parameters,
but
they're
not
coming
to
me
because
I
think
adding
at
least
defining
them.
A
Okay,
so
I
think
actually
seven
tene,
which
is
the
next
one,
is
actually
related
to
the
discussion
we
just
had.
It
has
to
do
with
displaying
a
business
model.
I'm.
Sorry,
no
I
think
I
just
opened
the
wrong
one.
All
right
got
the
name.
I
missed,
I
missed
one.
Okay,
no
17
is
a
different
one.
So
it's
basically
package
maintenance
issues,
suggest
I.
B
C
This,
like
really
early
when
the
repo
was
created,
I,
think
the
discussion
here
has
not
happened.
My
ID
here
has
been
covered
by
a
bunch
of
other
issues
and
I
think
the
only
reason
they
didn't
go
and
just
close,
it
was
because
I
think
there's
a
couple
of
things
that
haven't
been
directly
talked
about
in
other
issues:
okay
and
I'm-
I'm-
hesitant
to
waste
time
talking
in
this
forum
about
this,
since
it's
been
covered
in
so
many
other
okay.
C
A
This
I'm
just
gonna,
take
a
note
for
that.
Let
me
paste
I'm
trying
to
paste
it.
The
title
back
in
yeah,
sometimes
Google
Doc
does
there
we
go
okay,
so
over
to
Wes
much
content
is
covered
in
other
issues,
we'll
pull
out
what
is
not
an
open
new
issue
issue
or
issues
to
cover
that
and
then
close.
This
one
sounds
good.
A
Okay,
so
we'll
leave
it
at
that
and
then
the
last
one
on
the
list
was
the
suggestion
to
display
the
project's
business
model,
which
is
one
I
was
thinking,
is
actually
similar
to
a
little
bit
of
the
discussion
we
were
having
on
the
SLA
or
the
support
level.
I
think
there's
some
number
of
dimensions
that
would
be
useful
to
have
some
more
information
and
coming
up
with
a
pallet
or
whatever
you
want
to
call
it
like
a
license,
seems
you
know
it's
now
fairly
well-established
to
say
you
should
you
know
baseline
practices.
A
You
should
choose
one
of
these
and
tell
people,
you
know
what
you're
doing,
and
this
one
fits
in
that
as
well.
I
think
where
the
business
model
could
also
be
one
where
it's
like,
and
this
you
know
in
the
initial
description
here.
It
has
some
overlap
with
support
bubble,
so
I
think
we
need
to
sort
of
tease
that
apart.
In
terms
of
you
know,
support
may
not
necessarily
directly
relate
to
your
business
model,
but
having
some
information
about
your
business
model
may
make
sense
in
terms
of
people
choosing
your
module
or
not.
A
A
Okay,
I
think
we're
pretty
much
at
the
end
of
time.
Unfortunately,
haven't
had
time
to
then
loop
back
to
the
other
issues,
so
I'd
say
if
there's,
if
there's
ones
you
want
us
to
discuss
the
next
time,
maybe
just
tag
them
with
the
agenda
issue
and
and
they'll
pop
up
the
next
time.
The
other
thing
I
would
like
us
to
start
discussing
so
I'll,
either
see
if
I
can
find
somebody
or
opener
it
myself
is.
We
do
want
to
start
I.
A
H
A
E
A
F
A
No
I
know
that's
not
I
mean
just
separate
separately
from
that,
like
we'll
alternate
between
the
two
times,
but
the
other
question
is
like:
do
we
want
to
do
it
every
week
or
do
we
think
every
two
weeks
like
will
enough
happen
in
one
week
that
we
should
meet
every
week
or
we
got
enough
to
discuss
I
I'm,
just
getting
people?
What
do
people.
D
H
E
A
A
F
A
G
A
I
think
what
I
need
to
do
is
get
people
into
the
team
and
then
basically,
when
you're
on
an
issue,
you
should
be
able
to
just
choose
the
like.
If
you're
on
the
issue,
there's
like
a
tags
on
the
right
mm-hmm
and
you
can
just
collect
that
tag
but
I
think
I
need
to
get
people
into
the
right
team
so
that
they'll
be
able
to
do
that.
Yeah.