►
Description
Everyone loves the open source module ecosystem in JavaScript, you can rapidly develop new applications using tried and tested technologies, collaborate, integrate and innovate at a pace never before known. But Twitter is awash with developers pushed to burnout, and module maintainers unable to cope with the unexpected success and long term support requirements for their gifts to the community. There are many proposed solutions to open source economics, in this talk, we will discuss the practical steps the Node.js community is already taking to support module maintainers, and how we can come together to make this ecosystem work for everyone. This will include how you can help, how you can get support, and how we can ensure our code is built on reliable and secure foundations.
A
I
also
want
to
thank
Dominique
us
who
helped
put
together
the
first
version
of
this
presentation.
We
gave
a
very
similar
one
that
note
coffee
you
as
well,
so
want
to
give
him
the
credit
for
helping
we
put
this
together.
Unfortunately,
for
you
today,
you
only
have
me
so
we'll
do
what
we
can
before
we
get
there
a
little
bit
to
let
you
know
we're
gonna
talk
about.
First
of
all,
we're
gonna
talk
about
some
problems
that
we've
seen
and
how
do
we
think
we
can
make
things
better
next,
we'll
talk
about
concretely.
A
What
you
might
be
able
to
do
to
help
out
so
I
end
up
with
a
call
to
action
to
hoping
to
get
more
people
involved
to
help
us
figure
this
all
out,
because
there's
no
really
easy
answers
so
looking
at
the
start,
the
problem
is
that
you
know:
we've
seen
a
real
explosive
growth
in
the
use
of
nodejs
both
for
personal
use,
but
also
within
businesses,
and
that's
really
because
of
all
the
value,
that's
provided
by
modules
and,
in
fact,
often
a
number
of
key
modules
within
the
ecosystem.
There's,
like
I've
lost
count.
A
It's
like
900,000.
Every
time
you
do
the
chart,
there's
more
but
there's
a
smaller
subset
which
get
used
and
reused
very,
very
heavily,
and
so
we
have
a
dependency
on
those
key
map
modules
because
of
the
value
they're
providing
to
the
overall
ecosystem.
What
that
results
in,
though,
is
a
desire
for
basic
maintenance.
If
I'm,
you
know
deploying
an
application
that
my
business
depends
on,
I
would
really
like
some
basic
maintenance.
A
A
A
Saying:
hey,
I'm,
gonna
turn
this
into
a
business
or
a
living,
and
so
as
the
day
as
sort
of
the
expectation
grows,
it's
hard
to
keep
up
with
that,
because
that's
not
really
part
of
their
business
plan,
and
maybe
there
just
wasn't
even
a
business
plan
at
the
same
time.
Sort
of
compounding
this
is
that
there's
some
things
that
have
happened
like
the
the
event
stream
issue.
That
happened
about
a
year
ago,
where
people
are
starting
to
think
more
and
worry
more
about
their
dependency
trees.
Understanding
that
you
know
I've
installed
this
module
with.
A
We've
seen
some
recent
efforts
where
maintainer
czar
some
packages,
we're
trying
to
reach
out
to
their
end,
use
just
say:
hey
I
could
use
some
funding
and
so
there's
not
necessarily
well-established
communication
channels
between
the
package,
maintainers
and
the
users
of
those
modules
so
that
they
can.
You
know
one
set
good
expectations
and
communicate
to
figure
out
how
to
how
to
do
different
things.
A
If
you
want
to
read
a
little
bit
more
in
detail
on
sort
of
our
thoughts
on
the
issue,
there's
a
link
at
the
bottom
there
and
I
will
send
out
links
to
the
the
overall
presentation
at
the
end,
so
that
you
can
read
up
on
those.
If
you
want
to
the
other
thing
that
we
realized.
Looking
at
the
issue
is
it's
not
a
one
answer
fits
everybody
so,
for
example,
some
module
package
maintainers
they
want
to
keep
doing
it
themselves.
They
don't
necessarily
want
a
bunch
of
new
maintainer
x'
to
come
and
help
them
out.
A
There
are,
you
know,
happy
maintaining
the
module
themselves,
but
they
actually
would
like
support
to
be
able
to
do
that,
so
whether
it's
funding
or
support
of
some
other
ways
so
that
they
can
continue
to
maintain
this
module.
So
it's
not
hey.
We
want
to
grow
it.
It's
like
hey
I,
want
to
keep
doing
it,
but
help
me
do
that.
The
next
set
of
maintainer
x'
actually
want
to
grow
contribution.
They
they
say:
oh
I,
don't
want
to
be
the
one
person
maintaining
this
I
want
to
grow
it
into
a
into
a
bigger
thing.
A
With
multiple
maintainer
and
sort
of
spread,
the
load,
so
that's
kind
of
another
viewpoint,
and
then
there's
some
who
just
want
to
move
on
and
as
we
saw
with
the
events
cream
incident,
when
you
pass
on
a
package,
you
know
it's
important
to
do
that
responsibly
and
to
sort
of
consider
the
the
ecosystem
and
the
you
know.
The
maintainer
--zz
want
to
do
that.
So
there's
those
who
want
to
move
on
but
move
on
in
a
responsible
way,
so
the
people
who
are
depending
on
their
packages
still
have
a
good
path
forward.
A
So
what
are
the
things
we
think
we
can
do
to
actually
improve
the
overall
situation?
The
first
one
is
to
try
and
reduce
those
mismatched
expectations.
In
my
personal
experience,
I
find
that
a
lot
of
the
time
when
there's
friction
or
a
disagreement
or
people
getting
upset
is
because
we
had
different
expectations.
I
expected
that
you
know
I
just
did
this
for
fun
and
if
people
wanted
to
use
a
grape,
but
the
risk
is
on
them.
On
the
other
hand,
I
built
this
into
my
money-making
application
and
I'm
under
a
lot
of
stress.
A
This
is
really
one
form
of
the
larger
problem
of
trying
to
build
closer
communication
and
collaboration,
so
try
and
build
it
between
the
consumers
and
the
maintainer
zazz.
We
just
were
talking
about
also
between
the
maintainer
x',
though,
because
part
of
the
struggle
is
how
do
I
keep
up
with
some
of
these?
You
know
if
I
want
to
meet
the
expectations
for
basic
maintenance.
How
do
I
do
that
as
easily
and
effectively
and
by
having
collaboration
between
the
maintainers?
A
We
can
come
up
with
best
practices
tools
to
make
that
easier,
and,
of
course,
because
we
know
that
when
you
bring
more
people
more
thoughts,
more
different
views
coming
from
different
perspectives,
you
can
come
up
with
a
better
answer.
Really
I
say
everybody
else
as
well,
because
it's
even
those
who
aren't
directly
involved
may
come
with
it.
The
problem
with
a
different
perspective.
It
really
helps
us
see
the
oh
wait
a
second.
If
we
just
don't
do
what
we're
already
doing.
Maybe
we've
got
wait
to
it.
A
Next
one
is
trying
to
make
it.
You
know
concretely
make
it
easier
to
maintain
packages.
So
you
know,
let's
look
at
what
tools
we
can
build.
Let's,
let's
you
know,
figure
out
processes
that
work
so
work
on
that
side,
so
concrete
implementations
of
things
that
will
make
it
easier
and
then
last
one
is
promoting
responsible
and
sustainable
consumption.
A
So
this
is
actually
working
to
say
if
you're
using
modules,
it's
important,
not
not
just
because
it's
the
right
thing
to
do,
but
it's
important
like
if
I
run
a
business
and
my
coat
and
my
my
application
depends
on
all
these
modules.
It's
it's
risk
management
for
me
to
actually
understand
what
they
are
to
understand,
whether
they're
maintained.
You
know
whether
there's
there's
paid
support,
no
paid
support.
What
the
expectation
that
the
maintainer
has
set
like
are
they
gonna
say?
A
Well,
sorry,
you're
on
your
own:
when
I
go
talk
to
them
or
are
they
gonna
say?
Oh
yes,
you
know
I'm
totally
willing
to
help
you
it's
it's
part
of
my
risk
management
to
understand
that
and
basically
be
responsible,
but
what
I'm,
consuming
and
and
so
promoting
that
responsible
and
sustainable
consumption
by
helping
people
understand,
you
know
how
that
affects
them
as
well
as
provide
the
past
for
them
to
provide
support
back.
So
once
you
realize
wait,
a
sec
I
want
to
help
and
manage
the
risk.
A
How
do
I
provide
funding
to
people
who
want
funding?
How
do
I
get
involved
in
projects
that
want
to
grow
the
the
collaborator
ship
or
you
know
how
do
I
even
take
over
a
module
if
it's
important
to
me,
but
the
maintainer
no
longer
wants
to
do
that
so
in
promoting
that
responsible
and
sustainable
consumption.
A
So
about
a
year
ago,
we
started
the
package
maintenance
team
within
the
nodejs
project
and
serve
a
little
bit
of
history
as
we
started
by
thinking
about
what
we
call
module
LTS,
if
you
use
node,
you're,
probably
familiar
with
the
the
node
LTS
cycle
and
process,
and
we
were
deeply
involved
in
helping
to
put
that
together
and
implement
it
within
node
core.
And
you
know
we
found
that
people
that
is
really
resonated
with
people
and
they're
very
happy
with
it.
A
So
we
wanted
to
say
what,
if
you
extended,
that
concept
to
modules,
we
think
that
would
be
a
good
thing
and-
and
we
had
some-
you
know
ideas
about
how
you
would
tie
the
LTS
for
a
module
to
the
LTS
lifecycle
of
a
node
application
so
that
you
know
people
who
have
applique
and
need
upgrade.
You
know
it's
a
more
planned
and
coordinated
thing.
A
So
we
started
to
talking
to
people
in
the
community
about
that
about
a
year
ago
was
at
node
summits
about
a
year
and
a
quarter,
and
what
we
found
is
we
ran
into
the
discussion
of
this
bigger
problem.
Well,
wait
a
sec,
maintainer
czar,
just
having
a
hard
time
keeping
up,
so
we
figured
out
we
needed
to
tackle
the
larger
problem
before
we
could
sort
of
move
on
to
that
specific
issue.
That
was
also
about
the
same
time
that
the
event
stream
was
in
the
press
and
and
being
discussed.
A
So
we
ended
up
with
a
lot
of
interest
interested
people
joining
the
module
LTS,
not
the
module.
It's
yes
joining
the
package.
Maintenance
team
you'll
see
there's
a
huge
list
of
people,
as
is
often
the
case
in
open
source.
We
have
a
much
smaller
active
group.
So
don't
let
that
scare
you
off,
because
we
still
have
you
know
we
still
have
more
work
than
we
can
possibly
do
with
the
active
people
within
the
group
itself.
We
do
have
a
good
representation,
though,
from
across
the
different
areas.
A
We
have
people
using
the
modules
we
have
package
maintainer
x'.
We
have
no
GS
collaborators
because,
of
course
the
module
ecosystem
is
really
important
to
the
success
of
node
itself.
So
we
have,
you
know
a
number
of
collaborators.
We
have
people
from
NPM,
which
is
good
because
they're
a
you
know.
One
of
the
primary
delivery
vehicles
and
again
I'll
throw
it
there.
Maybe
it
should
be
you
if,
if
this
all
makes
sense
to
you
and
fundamentally
what
it
is
is
a
place
to
work
together,
we
don't
have
the
answer.
A
All
the
answers,
but
like
it's
a
place
to
get
together,
talk
about
them,
share
processes,
figure
out
what
works
and
hopefully
makes
them
some.
You
know
we're
not
going
to
solve
this
today
tomorrow,
but
let's
make
some
progress
in
the
right
direction.
So
concretely,
what
we're
doing
is
we're
doing
some
work
to
understand
the
state
of
the
ecosystem.
A
So,
looking
at
some
of
the
data
to
kind
of
understand
where
we
might
go
we're
working
on
what
we
call
support
info,
which
is
additional
metadata,
that
we
think
will
help
close
the
gap
in
expectations
and
hopefully,
like
we've
mentioned
on
licenses,
help
consumers
understand
their
dependents
and
and
sort
of
work
with
it.
We're
also
working
on
best
practices,
developing
patterns
of
engagement.
So
you
know
I
always
thought
if
I
had
a
hundred
developers
and
said
go
help
this
project
without
a
little
structure.
A
That's
actually
probably
going
to
be
a
bad
thing
for
the
maintainer
'he's
right.
We're
gonna
have
like
a
million
PRS
for
new
features,
they
have
to
review
and
it's
actually
more
work.
So
we
need
to
figure
out
the
pattern
of
engagement
for
how
people
will
get
involved
and
it
actually
reduces
the
load
on
the
maintainer
versus
making
things
worse
and
then,
finally,
tooling,
you
know
what
kind
of
tooling
can
we
build
and
and
put
in
place
to
help
the
overall
thing.
A
So
some
of
the
things
we
did,
we
went
to
the
the
the
maintainer
x'
and
we
asked
you
know
a
couple.
Questions
like
what
are
they're
one
of
the
problems
they're
face
facing
what
are
some
of
the
most
time-consuming
tasks,
and
we
also
want
to
do
some
work
to
kind
of
understand
the
impact
of
dependencies
on
them
and
I'll
talk
a
little
bit
through
the
different
slides
on
some
of
that
data
and
what
we're
doing
so,
one
of
the
first
things
we
looked
at
npm
published,
like
a
top
1,000
modules,
a
little
while
back.
A
A
I,
don't
have
it
in
the
slide
deck,
but
there
are
some
issues
in
the
packaging
maintenance
repo
talking
about
some
new
options
in
Travis
that
let
you
more
easily
basically
test
on
a
particular
set
and
have
those
tests,
change
and
LJ
harbor's
has
done
some
work
to
sort
of
create
some
templates
which
you
could
pull
in
and
therefore
like
get
testing
on
all
LTS
versions
and
as
they
change
get
the
new
versions
without
having
to
change
your
your
Travis
configurations.
Every
time
we
also
looked
at
you
know
which
version
things
were
testing
and
again.
A
You
know
eighty
eight
hundred
seventy
seven
them
had
sorry
Travis
configurations
which
we
used
as
a
proxy
to
what
they're
testing
on
and
again-
and
you
know
what
we
found
is
only
two-thirds-
we're
testing
on
the
current
LTS
version.
So
these
are
the
ones
which
are
most
used
almost
certainly
being
run
on
10,
but
don't
necessarily
test
on
that.
So
you
know
it's
potentially
moving
in
the
right
direction,
because
70
packages
were
added
since
April,
but
again
in
this
blog
post.
A
20%
of
them
were
outdated,
and
that
may
or
may
not
be
a
worry,
but
it
certainly
is
interesting
in
terms
of
like
how
actively
they're
being
maintained
and
updated
in
terms
of
development
dependencies,
it
was
even
higher,
although
we're
not
necessarily
sure
that
that's
a
concern
because
development
dependencies,
you
know,
if
you're
developing
from
get
you're,
probably
already
using
those
new
versions
versus
you
know
it.
Doesn't
you
don't
need
a
publish
to
get
those
so
not
particularly,
let's
say
a
problem.
A
The
good
news
is,
though,
that,
despite
that,
when
we
looked
at
those,
only
seven
had
deprecation
warnings
and
they
didn't
have
any
vulnerabilities
reported,
so
the
module
maintainer
is
I
think
they
all
deserve.
A
big
hand,
you
know
they're
doing
a
good
job,
keeping
these
modules,
which
are
very
dependent
on
in
a
good
state.
A
So
that's
actually
a
you
know
a
really
positive
thing
so
now
on
to
the
support
info,
which
is
one
of
the
the
key
sort
of
best
practices,
we're
working
on
and
that's
to
add
some
metadata,
which
is
hopefully
intended
to
close
that
expectation
gap,
and
it's
got
three
main
areas.
It's
got
the
target
response
and
backing
so
target
is
not
like
engines.
So
there's
already
an
engines
field
which
says
I
support.
A
These
specific
versions
of
node
target
is
meant
to
be
my
ongoing
intention
of
what
I'm
going
to
support
so
I'm
going
to
support,
for
example,
all
owl
active,
LT
versions.
So
when
there's
a
new
DLTS
version,
you
don't
need
to
change
that.
It
tells
you
I'm
gonna
support
that
LTS
version
and
likely
when
I
drop
off.
It's
no
longer
LTS
I'm,
no
longer
to
support
that.
A
So
we
have
a
you
know,
a
number
of
definitions
which
are
intended
to
let
the
you
know
to
express
and
set
the
expectation
in
terms
of
what
am
I
going
to
support
going
forward
responses
around
telling
setting
the
expectations
in
terms
of
like
what
kind
of
response
you
can
get
from
a
maintainer
like
is:
is
there
paid
support
available?
If
it's
not
even
if
it's
not
paid?
How
quickly
is
my
intention
as
a
maintainer
to
respond?
A
A
That's
actually,
you
know,
and
the
NPM
people
who
did
that
are
part
of
the
the
team
working
on
this
overall
scheme.
Oh,
we
kind
of
see
that
as
complementary
and
hope
to
hope
to
leverage
it.
They
just
didn't
want
to
wait
until
we
had
the
whole
thing
sort
of
figured
out
and
and
vetted
before.
We
did
that
and
I'll
go
into
a
little
bit
more
detail
on
what
they
are
at
the
very
high
level.
Those
some
key
attributes
is
it's
like
Jason
formats,
those
tooling
friendly,
but
also
sort
of
readable.
A
It's
consistent
with
the
package
Jason.
We
had
a
lot
of
discussion
as
to
whether
it
should
be
part
of
the
package
Aysen
or
not.
In
the
end,
it's
actually
we've
set
it
to
link
and
ideally
a
link
to
your
github
repo.
So
you
can
always
go
to
that
link
to
get
the
most
active,
the
most
current
version
of
the
data,
because
it's
not
necessarily
tied
to
a
publish.
A
You
could
change
your
support
statement
at
any
time
right,
but
at
the
same
time
we
want
in
that
github
repo,
so
that
most
likely,
when
you
make
a
publish
you're,
going
to
get
a
copy
of
the
current
data
so
that,
if
you're
offline
and
can't
go
something
you're
gonna
have
you
know
a
reasonable
proxy
for
what
the
data
would
be
in
general
we've?
It's
not.
A
You
know,
we've
thought
about
it,
use
of
this
in
the
JavaScript
ecosystem,
but
tried
to
avoid
anything
that
would
like
limit
it
to
the
JavaScript
ecosystem,
because
we
think
other
ecosystems
are
gonna
have
the
same
challenge.
And
finally,
you
know
it's
a
draft
you'll
see
the
way
we
have
our
dock
structured.
We
still
have
it
in
the
drafts
and
so
we're
still
looking
for
input
and
feedback
and
so
forth
terms
of
just
a
quick
view
of
the
structure
itself.
You
know
in
terms
of
the
backing.
This
shows
the
current
versions
that
we
have.
A
We
do
see
that
this
is
something
that
people
will
like
TRN
new
versions
over
time.
So,
but
if
there's
something
that
doesn't
exist,
we
can
add
to
sort
of
the
the
terminology
in
terms
of
what
they
might
be.
So
in
this
case,
you
know
sponsored
is
the
one
that
kind
of
relates
to
what
we
saw
with
the
NPM
funding,
where
you
can
provide
links
to
say
here's
the
way
you
could
provide
me
funding,
but
you
can
also
provide
other
information.
A
So,
for
example,
of
you
know,
I'm
part
of
a
foundation
I'm
part
of
the
open,
J's
Foundation,
for
example,
and
maybe
by
joining
or
supporting
that
Foundation
you're
gonna
help
support
this
module
in
terms
of
the
the
target.
Again,
as
I
mentioned,
it's
not,
and
you
know
it
doesn't
overlap
with
the
engines
field.
It's
meant
to
be
more,
like
some
people
actually
say
they
support
all
versions
of
nodejs,
and
if
you
want
to
do
that,
you
can
use
that.
You
know.
A
In
this
case,
it
says,
like
paid,
equals
false,
so
here's
just
a
URL
where
maybe
you
go
to
a
github
project?
Other
ones
might
be
like
here's,
the
the
entry
point
if
you've
bought
a
support
contract
and
the
whole
thing
is
about
doing
this
in
a
way
where
we
have
data
that
comes
along
with
the
packages
that
we
can
now
build
tools
around.
That
will
help
you
just
like
licenses,
go
through
your
dependencies
understand
what
they
are
and
hopefully
motivate
you
to
help,
get
involved
and
support
the
packages
that
matter
to
you.
A
We're
also
working
on
other
best
practices
go
very
quickly
through
this,
but
you
know
we
have
ones
around
testing
publishing,
versioning
licensing.
We
understand
that
you
know
package
maintainer
x'
they
can
do
whatever
they
want,
but
often
at
least
for
me
I.
You
know
it's
easier
for
me
to
say:
what's
the
best
practice
I
just
want
to
adopt
that
so
we're
trying
to
define
some
of
those
and
even
if
I
end
up
tweaking
that
understanding
the
best
practice
just
makes
me
more
comfortable.
That
I
know
know
what
I'm
doing
so.
A
We've
worked
on
a
number
of
them.
If
you
go
to
the
repo,
we
have
a
Docs
and
we
have
a
draft
Docs.
So
you
can
go
and
see,
you
know
we
kind
of
release
them
in
the
drafts,
get
some
more
feedback
and
then
promote
them
to
the
doc.
So,
if
you're
interested
in
seeing
what
those
other
ones
are,
you
know
we
have
a
good
set
that
we're
working
on
and
that's
the
thing
we're
gonna
continue
to
work
on
and
build
up.
I
also
mentioned
developing
patterns
of
engagement.
A
So
in
this
case
again,
100
developers
unleashed
on
your
project
is
probably
not
going
to
help
you.
So
our
approach
is
to
choose
one
or
two
pilot
packaged
packages,
experiment
to
figure
out
what
works
and
then
document
that
and
then
hopefully
have
a
recipe
that
we
can
use
to.
You
know
when
people
come
to
us
and
say:
hey
I'm,
interested
in
helping
through
the
package
maintenance
team.
You
know
my
ultimate
goal
would
be.
A
We
would
have
some
sort
of
backlog
or
work
or
modules
that
need
help
and
as
people
came
in
showing
interest,
we
could
point
them
at
that,
but
we
got
to
figure
out
how
we
can
point
them
usefully
to
practice.
So
today
we're
currently
working
with
Express
I'm
sure
everybody
knows
Express.
It's
one
of
the
key
projects
within
the
ecosystem
and
some
of
their
answers
in
terms
of
what
they
were
looking
for,
like
the
top
one
that
always
comes
through,
is
help
triaging
and
answering
questions.
So
don't
write
me.
Some
new
features
help
me
answer.
A
People's
questions
for
coming
in
the
other
things
that
have
sort
of
come
out
through
the
discussions
is
that
when
you
get
to
issues
you
can
actually
build
up
in
an
open-source
project,
a
large
number
of
issues,
but
those
aren't
necessary
all
of
equal
importance
to
the
maintainer
x'.
So
having
a
top-ten
list
where
the
maintainer
x'
can
identify.
A
I
think
it's
like
10
20,
so
I'd
really
recommend
going
to
that.
He
also
has
a
session
at
the
community
corner,
which
is
gonna,
follow
that
if
you
want
to
actually
become
a
maintainer
sorry,
a
triage
er
and
get
involved.
One
of
the
great
things
that
has
happened
is
we've
been
working
with.
Express
is
actually
I'll.
Wait
till
the
next
slide
when
I
get
there,
so
some
of
the
concrete
things
we're
doing
with
them
is
Wesley
put
together
this
status
board.
A
A
You
know
announced
the
the
triage
role
and
the
project
seems
very
open
to
giving
the
triage
role
to
people
who
want
to
help,
and
it's
a
I
think
that's
going
to
unlock
the
ability
to
get
involved
in
help
on
that
front
significantly.
So
definitely
some
some
progress
on
that
front
and,
like
I,
said,
if
you're
interested
at
all
go
see,
West's
talk,
I,
think
it's
an
important
one
as
well
as
you
have
the
opportunity
to
maybe
even
become
one
of
those
triage
errs
in
the
session
afterwards.
A
The
next
piece
we're
working
on
is
tooling,
so
we
built
a
number
of
tools
or
they're
in
progress
and
we're
talking
about
some
and
and
I'll
go
into
the
detail.
So
the
first
one
is
and
I'll
mention
packed.
Pkg
GS,
that's
another
organization
that
the
team
decided
to
create
to
basically
be
the
home
for
these
tools.
The
support
tool
basically
is
to
help
you
manage
those
support
files
that
we're
recommending
people
generate.
So
basically,
you
know
create
an
initial
version
and
validate
that
you've
gotten
it
right.
A
So
it's
this
one's
not
about
you,
know,
looking
at
the
dependency
tree,
but
about
helping
the
package
maintainer
z--
generate
and
maintain
them
and
v
we
talked
about
the
target,
not
the
target
yeah
the
target,
not
listing
node
version.
Specifically
this
actually
will
help
you
take
what
what
the
the
you
know,
LTS
our
LT
is
active
and
convert
that
into
what
does
that
really
mean
today?
A
A
That's
some
of
the
things
we're
working
on
the
the
other
one
which
we
definitely
want
to
do
in
terms
of
like
the
support.
One
is
also
like
build
that
into
a
tool
that
helps
you
validate
the
dependency
tree.
Just
have
a
quick
tour
on
that.
The
next
thing
that
Dominique
has
really
been
working
a
lot
on
is
thinking
about
2fa.
If
you're
a
package
maintainer.
You
probably
know
that.
A
A
So
Dominique
has
been
looking
at
different
options
so
like
doing
remote,
OTP
solely
your
CI
publishes
your
package
and
then
it
you
know:
you'll
get
a
reach
out
immediately
over
mobile
chatbots,
some
sort
of
software
of
a
service
to
be
able
to
give
the
second
factor
in
and
let
the
publish,
complete
other
ideas
have
been
like
published
there
or
deliver
your
package
to
into
github
and
then,
as
a
second
step,
take
that
out
and
publish
it.
We
using
your
two-factor
authentication.
All
of
these
have
enough
complication
and
challenges
that
it's
not
like.
Just
a
straightforward.
A
Here's.
What
we'd
recommend
you
do
you
do.
The
great
news
is
back
November
14th
and
one
of
our
package
maintenance
meetings.
Npm
actually
announced
that
they're
going
to
work
on
something,
so
they
we
haven't
seen
the
full
proposal
yet,
but
basically,
what
they've
said
is
they're
gonna
have
something
integrated
into
the
cly
which
will
let
you
staged.
So
you,
basically
in
your
CACI
stage,
your
release,
then
come
back
to
the
zoo,
the
claw
and
actually
promote
that
to
be
an
actual
release,
and
you
know
you
can
control
that
through
the
2fa.
A
So
we
haven't
seen
the
details
and
it
doesn't
mean
that
it's
necessarily
gonna
cover
all
the
use
cases
that
some
of
these
others
might
so
maybe
they'll
still
be
applicable
in
more
complex
cases,
but
we
do
have
hope
that
we're
gonna
have
something
which
is
you
know,
covering
the
the
80%
use
case
and
make
things
a
lot
better
and
I
think
this
is
just
a
good
example
of
like
having
brought
people
to
think
and
talk
about
the
the
problems
in
the
package.
Maintenance
team.
A
We're
seeing
some
things
actually
come
out
from
the
ecosystem
terms
of
future
work.
We
still
want
to
get
back
to
that
long-term
support
idea
and
how
it,
but
you
know
we
understand
that
it's
adding
more
potentially
more
work,
so
we
want
to
figure
out
and
lay
the
pattern
for
how
people
would
implement
that.
So
we
need
to
do
that.
Canary
and
gold.
Mine
is
actually
something
that
we've
used
in
the
community,
the
node
community
itself
to
test
dependency
so
that
we
don't
break
them.
It
came
out
of
work.
A
We
did
actually
at
IBM
in
our
node
team.
We
contributed
it
to
the
community
and
it's
bait.
It's
used
in
all
the
releases
to
validate
we're,
not
breaking
modules.
We
think
this
can
be
useful
for
modules
to
sort
of
do
the
same
thing
to
validate
they're,
not
breaking
their
own
dependencies,
the
ones
who
could
do
consume
them.
So
that's
one
thing
we
want
to
move
on
to
when
we
get
you
know
sort
of
get
there
as
well.
A
So
just
to
end
up,
you
know,
hopefully
I've
got
you
sort
of
interested
and
excited
and
seeing
that
we're
actually
making
some
progress.
It's
it's,
it's
a
gonna,
be
a
long
effort
but
I
think
we're
making
some
some
positive,
positive
progress,
and
so
my
call
actions
like
come
and
help
us
figure
this
all
out.
We
have
meetings
every
two
weeks
we
alternate
between
9:00
Eastern
and
3:00
p.m.
Eastern.
These
are
the
times
I
work
in.
A
So
that's
what
I
know,
but
it
helps
between
you
know
letting
people
both
on
the
west
coast
and
in
Europe
be
able
to
make
the
meetings.
If
you
can't
make
those
you
know,
please
look
at
the
best
practices.
Comments
suggest
things
that
we
should
be
documenting
or
if
you
have
a
best
practice,
you
know
suggester
PR
them
in
and
let
us
work.
Let
us
know
what
works
for
you.
If
you
are
interested,
you
know,
of
course
we
have
the
the
github
repo
you
can
get
involved
in
and
on
the
node.js
org
calendar.
A
That
shows
all
of
the
meetings
that
are
going
on,
and
so
you
can
find
the
package
maintenance
meeting.
If
you
look
at
the
repo
a
few
days
before
the
meeting,
it
will
also
an
issue
is
always
opened
as
well.
That
has
like
the
meeting
details.
The
links
and
all
that
kind
of
stuff,
so
that's
what
I
had
today,
I'm,
not
sure
if
we
have
any
time
for
questions,
oh
and
1251,
I
think
I'm
just
on
time.
So
I
should
probably
close.