►
From YouTube: Package Maintenance Team meeting - July 29 2019
Description
A
Okay,
so
welcome
to
the
node.js
community
package,
maintenance
working
group
meeting
for
July
29th
2019
we'll
be
following
the
agenda
that
was
set
in
issue
number.
So
let
me
see
if
I
can
find
that
issue
number
three
232
and
we'll
start
out
by
seeing
if
there
is
any
announcements
that
people
would
like
to
share.
A
D
The
reason
I
base
that
question
originally
was
because
we
were
having
a
afternoon
European
afternoon
time
Monday
morning,
us
time,
I,
suppose,
meeting
and
I
think
there
was
only
two
or
three
of
us,
and
so
that's
why
I
was
thinking
that
maybe
there's
a
better
time
for
people
to
John
might
have
been
just
summer.
Of
course,
I
have.
C
A
So
I
guess
it's
like
this
pushing
I'm
just
looking
at
the
schedules
and
on
Tuesdays,
so
yeah,
three
and
four
there's
a
build
working
group
meeting,
although
that's
less
frequent
I'm,
just
looking
like
you
know,
say
if
we
pushed
it
to
say
four
or
one
other
direction
right
or
is
it
actually
that
both
is
it
the
twelve
o'clock?
It's
that
no,
the
nine
is
okay
right.
It's
the
303
p.m.
the
one
that
would
conflict.
E
F
C
A
B
A
D
A
B
H
G
So
the
given
that
last
point
of
contention
I'm
led
to
believe
that
there
were
some
comments
at
this.
The
node
summit
by
a
few
folks
that
wanted
it
to
not
be
in
line
in
package.json
I
feel
pretty
strongly
that
it
should
be
I,
don't
know
if
it's
worth
talking
about
that
in
the
meeting
or
if
we
want
to
keep
doing
it
on
github
I.
Think
that
the
the
trade
offs
basically
are
that
if
it's
in
line,
then
the
downside
is
that
you
need
a
publish
to
update
it.
G
The
upside
is
that
you
don't
need
to
download
the
entire
package
to
get
that
information.
You
can
just
type
NPM,
show
some
stuff
and
get
it.
If
it's
a
separate
file
in
the
package,
then
you
still
need
to
publish
to
update
it
and
also
you
can't
get
it
without
downloading
the
whole
tar
ball.
So
it
seems
to
me
like
that's
strictly
the
worst
of
those
three
options
and
then
the
with
a
URL,
the
upside
is
that
you
can
update
it
without
publishing
a
new
version.
G
Another
possible
downside
of
a
URL
is
that
it
won't
be
as
immutable
as
the
package,
which
means
that
the
URL
could
go
down
and
disappear
off
the
web,
even
though
the
package
will
be
around
forever
so
obviously,
I'm
biased,
I
have
a
preference,
but
like
that's
kind
of
the
roughly,
how
I
see
the
trade-offs.
So
if
anyone
has
a
really
strong
opinion
in
a
different
way,
I
mean
it's.
G
We
seem
to
have
a
group
address
most
of
the
quirks
that
by
saying
that
whatever
the
latest
version
is
cancels
out,
all
the
previous
ones,
so
if
you
do
make
it
require
a
publish,
then
the
the
latest
chronological
one
published
just
Trump's,
all
the
previous
ones,
but
anyway
sorry
go
ahead.
If
you
have
a
Conner,
no.
C
No,
what
you
actually
addressed
the
main
the
considered
concern
that
I
had
was
what
you
addressed
very
at
the
very
end
there.
That
is
the
rule
that
the
newest
publish
from
severing
I
still
think
that
doesn't
account
for
one
of
our
bigger
problems,
which
is
the
author
dropping
off.
You
know
completely,
so
do
we
have
do
we
have
any
resolution
on?
What
we
would
want
to
do
in
that
case
is
that
the
expires
field
like
what's
our
what's
our
solution,
there
I.
G
Mean
the
expires
field
has
some
suggestions
that
I
think
mitigate
that
a
lot,
but
I
also
think
that
I
could
always
say,
expires,
never
and
then
still
vanish.
If
I
do
vanish,
then
the
whether
it's
a
URL
or
in
the
package,
it's
just
as
likely
that
could
vanish
and
I
would
argue
it's
more
likely
that
the
URL
would
vanish
in
that
case,
because
I
could
lose
I
can
stop
paying
for
my
domain
names
so
to
me
that
that
none
of
the
options
alter
the
calculus
of
that
it's
just
that's
more
like.
C
That
case
and
I'm
I
think
I'm
on
board,
with
at
the
in
line
which
I
was
not
previously,
but
I
think
we've
we've
resolved
all
evasion.
I
had
with
that.
Maybe
one
other
suggestion
that
we
could
do
would
be
whatever
tooling
we
provide
around
this.
We,
maybe
we
maybe
put
a
repo
that
has
exceptions
somewhere
so
that
when
we
have
tooling
and
that
somebody
does
drop
off
the
face
of
the
earth,
we
can,
you
know,
have
somebody
open
a
PR
on
a
repo.
We
maintain
that
we'll
check
against
to
say
like
hey.
C
G
A
I
You
I
just
a
quick
note
on
Monday
and
the
separation
of
files
or
not,
and
and
so
much
that
we're
talking
about
the
JavaScript
ecosystem
here,
those
values
in
those
fields,
don't
necessarily
need
to
be
limited
by
that.
So
in
trying
to
make
it
in
line
with
back
into
JSON,
we
lose
out
on
the
opportunity
of
adoption
across
the
board.
In
that
context,
to
the
point
of
the
you
know,
version
wise
are
published
wise.
You
know
you
always
lose
out
on
the
most
recent
one
or
things
might
change
between
version
a
and
version
version.
I
One
version,
two,
that's
where
potentially
having
it
as
a
separate
file
and
having
the
provider
level
or
a
you
know.
Third
party
level,
like
a
service
type
of
information
on
the
latest
at
being
outside
of
the
context
of
an
install
step
or
a
CLI
command,
so
that
you
have
a
authoritative
source
to
determine
that
logic.
For
you,
as
opposed
to
whatever
is
in
is
in
line,
will
always
be
the
determining
factor
because
you
might
be
on
an
older
version
that
declared
a
level
of
support
that
the
author
has
change
our
mind
afterwards.
I
So
that
to
me,
that's
where
the
inline
context
comes
in
and
a
from
the
perspective
of
I
mean
authoritative
logic
that
determines
what
is
the
most
effective
and
recent
view
of
it.
Things
and
as
well
as
putting
an
impact,
JSON
kind
of,
is
a
very
JavaScript
opinionated
thing,
which
is
fine,
but
you
know
there
is
value
in
those
kind
of
standards
that
about
that
I
can
apply
to
other
communities
as
well.
Yeah.
G
I
mean
that's
fair,
I
guess,
I
feel
that
that
the
only
Authority
is
an
NPM
registry
because
everything
else
can
and
does
vanish,
and
so
like
there's
other
ecosystems,
probably
have
similar
things
where,
like
the
package
registry,
holds
the
immutable
data
and
everything
else,
even
if
it's
unlikely
to
be
changed
like
github,
repos
and
stuff,
is
still
technically
immutable
and
could
vanish
anytime
so
like
I'm
unscented
to
that
and
but
I
would
I
feel
like.
We
can
address
that
by
saying
no
matter.
G
What's
in
your
package,
JSON
always
run,
you
know
always
check
the
registry
for
the
latest
published
you
know,
published
version
or,
or
you
could
even
say
we
could
move
you
very
specific
and
say
what's
under
the
latest
tag.
Is
the
latest
support,
so
that
covers
like
pre-release
and
deprecated
versions,
and
you
know
so
from.
A
From
the
vanishing
perspective,
in
my
mind,
like
the
URL
no
longer
being,
there
means
it's
not
supported.
So
I'm
finishing
is
not
necessarily
a
bad
thing
in
my
life
like
it.
If
you're
not
able
to
keep
that
up,
then
that's
a
clear
signal
to
whatever
tools
running
that
there's
a
problem.
Now,
if
it's
intermittent
that
could
be
a
different
thing
right,
somebody
else
was
yeah.
D
Regarding
the
fact
that
we're
debating
putting
in
a
line,
I
am
sort
of
in
favor
of
keeping
in
package.json.
But
aside
from
that,
if
we're
saying
that
the
registry
is
the
canonical
source
of
that
information,
so
I
think
NPM
already
reports
through
the
API
when
you
retrieve
the
pack
meant
it
includes
the
readme.
Would
it
be
a
major
change
to
include
an
additional
field
which
reads
from
another
well-known
file
so.
I
Looking
at
this
initiative
as
part
of
a
driver
for
that
context
of
you
know
what
is
that
file
format
looks
like
what
is
that
interface
for
declaration
of
these
type
of
activities
and
support
level
look
like
and
will
will
be
able
to
represent
that
meaningfully
in
are
both
in
our
API
is
in
the
CLI
as
well.
What.
C
I
do
in
regard
to
that
I
really
like
that
idea,
but
I
think
that
that
risks
not
getting
a
good
solution
in
place
today,
because
we're
waiting
on
all
these
other
communities
to
resolve
what
they
think
might
be
best.
Is
there
anything
that
we
could
do
or
change
about
the
spec
that
we
have?
That
would
make
it
a
little
bit
more
forward
compatible
if
we
decided
to
say
like
mix,
you
know
an
external
file
with
an
internal
you
know
or
with
a
external
file,
another
file
format
and
package
Jason
is
there?
C
I
Suggestion
would
be
like
yes,
good
point
like
I.
Don't
want
to
wait
for
of
collective
coming
together
and
agreeing,
or
you
know
yet
another
working
group
of
that
sort,
but
it
would
be
nice
if
we
all
get
together
on
the
same
page.
In
that
front,
what
I
would
suggest
is
if
you
have
a
reference
in
a
package
of
JSON
to
that
file.
I
That
makes
it
a
lot
easier
for
in
terms
of
current
tool
sets
and
current
set
up
to,
you
know
become
a
pointer
effectively
and
at
your
point
Dominika
earlier
like
we
can
use
the
api
as
it
is
today
and
just
pulling
that
content
of
that
file
and
just
no
CLI
tooling
wise.
Even
if
it's
a
third
party
CLI
functionality
that
you
introduced
and
then
later
we
can,
you
know
they
do
kim
CLI
itself
to
have
more
of
those
functionality.
I
G
If
there
was
a
way
to
do
that,
then
I
presume
there
would
also
be
a
way
to
designate
explicit
supporting
files
like
support,
JSON
or
funding
JSON
and
update
them
without
a
new
release.
At
that
point
it
would
be
very
trivial
to
like-
and
this
of
course
requires
a
little
work
on
a
VM
side,
but
you
could
have
every
NPM
install
just
pull
those
files
from
the
canonical
source
and
not
from
the
tarball.
You
could
you
know,
and
just
kind
of
virtually
bundle
them
together.
G
You
could
have
NPM
like
read
that
read
the
data
command
that
just
pulls
from
the
latest
version
without
needing
to
download
the
tarball.
There's
lots
of
like
ways
to
handle
that,
but
I
think
that
the
ability
to
update
without
publish
the
documentation
without
publishing
is
I.
Think
pretty
critical
to
that
and
I
and
I
would
rather
see
work
go
into
doing
that
on
the
readme,
then,
on
the
support
file,
if
it's
gonna
go
anywhere.
First,
because
that's
a
long-standing
pain,
point
and
I
think
that
in
a
world
where
that
ability
existed,
it
would
be.
I
A
G
Well,
I
mean
we
could
start
with
in
line
now
and
then
expand
the
schema
later
to
say
like
if
the
object
is
just
an
object
with
the
key
href,
then
that
points
to
a
URL
or
if
it's
just
a
key
with
you
know,
I,
don't
know
some
other
some
other
key.
We
can
have
a
point
to
a
relative
file
like
there's
lots
of
ways.
We
can
expand
it
to
group.
You
know
gracefully
migrate
to
that
world.
When
those
abilities
are
present,
I,
don't
think
we
have
to
necessarily
make
that
decision
now.
G
I
A
G
Whether
we
ship
both
abilities
at
the
same
time
or
not
I'm
suggesting
we
start
with
inline,
because
we
accept
that
we
can
expand
future
to
be
a
URL
and
if
we
want
to
ship
both
at
the
same
time,
we
can
talk
about
doing
that
too.
But
given
that
we
don't
yet
have
the
ability
to
update
them
without
publishing
that
seems
to
me
to
be
like,
like
I,
would
prefer.
We
not
implement
that
right
now.
G
If
it's
pointing
to
a
file
within
the
package,
then
then
we're
at
the
place
where
it
requires
an
update
still
and
also
you
can't
get
it
without
downloading
the
tarball.
So
that
doesn't
seem
valuable
and
then,
unless
there's
an
API
to
get
it
without
the
whole
tar
ball
and
the
guy
to
update
it
without
publishing
the.
A
G
I
G
G
G
C
I'm
on
board,
with
waiting
to
decide
whether
we
want
to
do
URLs
I,
think
that's
the
easiest
one
and
once
there's
a
compelling
reason
to
add
it.
We
go
ahead
and
add
it
I
think.
Today
we
have
enough
questions
around
it
that
committing
to
it
is
questionable,
and
if
we
can
move
forward
on
on
a
you
know,
recommended
standard
and
and
iterate
later
then
I
think
we,
you
know
we're
all
we
win,
because
we
can
start
getting
people
on
board
today.
F
Would
like
only
to
add
to
the
conversation
that
I
asked
myself
when
a
user
need
the
support
5,
because
of
course,
Hamada
talked
about
the
CI
integration,
of
course,
but,
for
example,
I
think
people
would
check
the
support
when
he
had
to
choose
which
libraries
which
models
have
to
use,
for
example,
and
for
of
course,
when
the
the
user
check
for
support,
he
maybe
won't
open
an
issue,
for
example.
So,
for
this
reason,
I
think
that
the
URL
or
something
that
is
online,
would
fit
better
our
needs
instead
of
the
publish
of
course
and
p.m.
A
G
Only
thing
is
that
I
would
like
more
if
there's
more
concrete
information
to
be
had
about
the
folks
at
the
summit,
who
said
that
they
did
not
want
it
in
line
about
their
reasons.
I've
heard
that
it
makes
package.json
longer
is,
and
then
it
requires
a
publish
to
update
are
those
those
were
their
concerns
if
there's
another,
if
someone
could
like
enumerate
those
online
like
on
github,
that
would
be
helpful.
Okay,
I.
A
A
E
F
G
Yeah
I
just
it
sounds
like
a
standard
format,
but
it
also
seems
really
confusing
and
hard
to
understand
so,
like
you
know,
I
wouldn't
block
on
that,
but
it
seems
like
a
nice.
We
should
try
and
find
a
better
balance
between
readability
and
standardization
for
a
field
for
a
profile
that
is
likely
to
be
worked
with
by
both
machines
and
humans.
Okay,.
F
G
D
D
So
that's
why
I
would
really
be
interested
in
seeing
if
we
can
discuss
with
Travis
whether
they'd
be
considering
an
option
to
make
the
default.
The
multiple
versions
I
know
Jordan
had
some
concerns
there,
but
basically
that's
where
we're
at
and
based
on
the
changes
that
Travis
are
making
I
think
I
can
start
working
on
the
blog
post
that
I
have
on
the
in
the
plans
to
basically
write
something
up
about
which
versions
people
should
be
generally
testing
with
and
there's
there's
another
small
thing.
I
D
Which
is
sort
of
lit
related
to
the
package,
support
as
well?
I
guess
basically
renovate
they.
They
do
automatic
updates
of
of
your
dependencies
and
they
can
also
bump
the
versions
of
node
in
your
Travis
channel
and
they
have
a
grammar
for
specifying
which
versions
you
want
to
taking
and
I
think
we
can
maybe
take
that
grammar
and
build
on
top
of
that
and
reuse
that
grammar
for
the
support
field,
as
well
as
in
which
node
versions
do
you
support
and
they
have
a
couple
of
options.
G
G
However,
many
at
which
point,
and
so
it
may
be
useful
if
I'm
going
to
have
that
time
to
do
it,
and
it
may
be
useful
that
Travis
hold
off
a
minute
because
then
they
could
default
it
to
the
oldest
LTS
instead
of
the
newest,
and
that
way
the
default
would
kind
of
keep
pulling
forward.
But
it
would
be
the
the
most
compatible
and
not
the
most
edge
version.
G
You
know
so
well.
I'm
gonna
try
to
have
the
time
I've.
You
know.
I
left
my
job
a
few
weeks
ago,
so
I'm
but
I
also
have
two
kids
but
yeah
I
intend
to
add
that
feature
regardless.
My
concerns
were
about
the
ergonomics
of
having
a
default
matrix
of
like
four
versions
of
node
and
then
adding
one
thing
to
your
yellow
file
and
having
it
flip
to
one
version.
C
Have
a
sort
of
tangential
question
here:
are
we
concerned
at
all
about
such
a
recommendation
being
so
dependent
on
a
company
and
their
product
in
this
regard,
so
right,
where
they
recently
bought
by
somebody
and
in
some
questions
on
whether
or
not
the
product
will
remain
what
has
been
I'm
just
concerned?
If
we're
gonna
start
recommending
and
more
around
this,
that
we
do
our
due
diligence,
yeah.
D
So,
where
I'm
coming
from
is
I
took
a
scan,
that
was
that
there
was
a
top
1,000
NPM
modules
posted
recently
I
scanned
all
of
their
repos
and
90%
of
them
use,
Travis's,
okay,
so
de
facto
heard
the
standard.
Okay,
there's
there's
no
other
CI
systems
in
the
world
as
a
sense.
So
that's
so
that's
why
I
would
really
really
really
love
if
people
from
travels
could
join,
but
I
haven't
gone
as
far
as
poking
them
on
Twitter
or
you
know,
get
up
without
any
any
any
any
sort
of
prior
contact.
D
So
if
anybody
knows
anybody,
please
go
ahead.
I
posted
a
link
to
the
Travis
about
page
on
the
issue.
Maybe
you
know
somebody
there
or
sorry
that
it
would
be
really
great
if
they
could
participate,
because
at
the
way
it
is
as
you're
saying
they
are
one
of
the
critical
infrastructure
companies
for
the
open
source
right.
So
ideally,
we'd
have
them
in
these
discussions
here.
D
D
I
G
G
Yeah
I
do
have
the
same
concerns
that
were
brought
up
about
their
acquisition
and
their
layoffs
and
the
you
know
uncertain
future
of
it,
but
they're
also
the
like
99.999%
used
solution.
So
while
I
hope
that
we
can
offer
recommendations
for
services
beyond
Travis,
Asher
and
circle,
and
things
like
that,
if
we
have
Travis
we've
like
really
missed
the
mark,.
F
F
Yes,
I
think
that
this
issue
is
blocked
by
the
pipe
so
because
this
is
a
list
of
a
to-do
list,
it's
the
to-do
list.
So
in
order
to
do,
we
have
to
decide
for
the
certified,
so
I
will
complete
off
birthday
request,
with
the
feedbacks
that
we
have
decided
today.
So
I
think
that
it
will
be
for
unblock
unlock
next
few
days.
E
E
E
E
G
Strong
feelings
here:
yeah
there's
basically
two
methods:
there's
NPM
ignore
and
files
NPM
s.
Official
Doc's
have
mentioned
files
for
a
long
time,
but
I
think
it's
like
a
terrible
and
dangerous
practice
and
the
like
so
either
way.
I
think
we
need
to
recommend
both
approaches
and
we've
kind
of
talked
through
it
a
lot
and
arrived
at
a
sort
of
like,
let's
recommend
two
based
on
two
mindsets.
One
mindset
is
you're
really
really
concerned
with
the
size
of
the
tarball
that
people
download
when
they
type
NPM,
install
and
in
that
world.
G
You
want
to
restrict
some
files
from
being
published.
How
do
you
do
it?
Here's
the
two
ways:
here's
the
pros
and
cons
and
I
just
I'm
gonna
be
very
interested
in
making
sure
that
the
that
those
are
well
represented
because
the
like
you
know,
I
I've,
set
it
on
github,
so
I
won't
compete
here,
but
there's
pros
and
cons
there
and
then,
if
we
go
with
the
mindset
of
you
are
more
concerned
with
people
being
able
to
access
everything
in
their
node
modules.
G
Folder
offline
not
have
to
check
github
things
like
that,
or
if
you
just
have
a
lack
of
concern
about
it,
then
don't
have
an
I'm
ignored.
You
know,
don't
have
a
files
things
like
if
I
was
alright
things
like
that,
so
I
think
it's
really
just
about
coming
up
with
those
recommendations
in
a
way
that
that
matches
the
enthusiasm
of
all
the
people
with
opinions
here
and
phrases
them
correctly
with
well
worded
trade-offs
that
are
both
as
unbiased
as
possible,
but
also
as
that.
Don't
over
that.
Don't
minimize
the
real
real
concerns
of
certain
approaches.
G
You
know
it's
a
given
that
some
people
have
different
priorities
here.
It's
tough
to
it's
gonna,
be
tough
to
word
it
in
a
way
that
it
meets
that
I
create
that
goal,
but
I
think
that's
where
we're
at
is
that
we
just
have
to
kind
of
iterate
and
come
up
with
language
that
that
doesn't
like
try
to
shame
people
or
make
them
feel
bad
for
their
priorities,
but
also
acknowledges
the
the
true
pros
and
cons
of
them
of
all
the
different
ones.
So.
C
I
would
just
raise
my
hand
but
I,
don't
know,
I
think
that
we
as
a
group
can
not
have
opinions
on
certain
things
and
that's
fine,
even
if
they
relate
to
package
maintenance
and
I
would
hesitate
for
us
to
get
involved
in
this
type
of
discussion
in
a
broader
context,
unless
there's
a
really
important
reason,
so
I
think
something
like
making
a
recommendation
around
package,
lock
files
being
committed
to
your
repos,
fine,
there's
a
real
reason.
Not
to
do
that.
We
should
say
that's
the
best
practice.
Don't
do
it
in
your
modules.
C
This
is
very
much.
What
does
your
module
do?
Why
do
you
think
it's
not
a
good
idea.
Does
your
module
have
a
large
binary
in
it
that
should
never
be
used
by
the
downstream
consumer
and
yeah?
Ignore
it,
but
that's
very
much
dependent
on
like
what
your
module
is
doing
and
so
I
think
it's
reasonable
for
us
to
not
publish
best
practices
on
some
of
these
kind
of
things.
When
there's
just
too
much,
you
know
variants,
we
could
maybe
publish
help
articles
and
that's
where
I
think
there's
this
there.
C
We
need
to
be
very
clear
about
what
we're
saying
we're
saying
this
is
a
you
know.
We
have
a
we.
We
want
to
make
some
blog
posts
about
this
feature,
which
is
very
different
than
saying.
We
want
to
recommend
a
best
practice,
so
I
think
we
just
need
to
be
very
clear
on
what
our
scope
is
around
some
of
these
things
and
and
D
scope.
Something
like
this,
where
it's
just
like
you
know,
there's
maybe
not
a
good
documentation
source,
but
that's
a
different
thing
than
recommending
best
practices
as
such,
so.
G
I
think
the
main
I
generally
agree
with
that,
but
the
main
concern
I
have
is
that
NPM
has
official
guidance
on
both
of
the
things
you
mentioned.
They,
the
NPM
CLI,
strongly
pushes
everyone
to
commit
package
lock
to
their
packages,
and
so
it's
actually
really
important
that
a
best
practice
is
propagated.
G
That
combats
this
misinformation,
that's
been
going
out
for
years
and
similarly,
the
NPM
documentation
on
the
website
mentions
the
files
property
without
mentioning
any
of
its
downsides
and
I
get
20
PRS
on
my
packages
a
year,
easy
of
people
trying
to
add
the
files
property
to
my
package,
JSON
completely
unaware
of
the
downsides
and
then
citing
NPM
documentation
as
an
authoritative
source.
So
I
actually
think
that
what
well
I
agree
with
you
that,
like
like,
we
shouldn't,
be
telling
people
use
tabs
or
spaces
right
like,
but
but
we
definitely
should
be.
G
We
need
to
be
establishing
a
a
balanced
explanation
of
trade-offs,
even
if
we're
not
calling
it
a
best
practice
to
do
one
or
the
other
or
even
a
best
practice.
To
only
do
these
things
I
think
it.
We
kind
of
are
obligated
to
address
that
that
information
and
then
community,
so
I,
think
I
see
I'm
on
standard.
I
I
just
want
to
comment
like
when
we're
talking
about
best
practices
as
offering
them
to
the
community.
We
don't
need
necessarily
to
limit
to
a
single
best
practice
and
context
like
this.
You
can
give
it
a
different
profile
or
different
perspective,
saying
if
you
are
a
package
maintainer
and
you
really
just
want
to
distribute
your
compiled
source
code,
you
know
here
is
a
set
of
best
practices
around
that
versus
you're,
using
it
for
different
purposes
and
you
wanna.
Do
you
want
to
publish
your
test
files
or
not
right?
I
Like
that's
an
interesting
conversation,
it
doesn't
have
to
be
a
single
best
practice,
so
you
can.
You
can
potentially
offer
a
different
kind
of
perspectives
on
it
and
would
that
maybe
templates
of
NPM
ignore
and
what
that
looks
like
for
different
users,
but
like
yeah
I,
think
you
know
it's
a
very
broad
topic
at
the
end
day
of
trying
to
cover
that
in
a
single
single
stroke,
best
practice
is
going
to
be
very
complicated
when
it
comes
to
what
NPM
describes
as
the
CLI
perspective
and
how
the
CLI
operates.
I
I
think
that's
how
the
you
know,
whether
it's
an
authoritative
source
or
not.
It's
it's
relevant
to
the
way
it's
presented
as
opposed
to
you
know.
You
know
just
publishing
packages
and
how
do
I
want
to
share
my
files?
So
that's
that's
so
there's
a
bit
of
a
nuance
there,
but
we
can
talk
about
that
more
coming
back
to
the
original
kind
of
point
of
this
particular
ticket.
I
The
original
questions
were
asked
around
things
like
you
know,
do
I
include
my
code
coverage
file
to
include
my
you
know,
test
files
and
so
on
and
whatever
we
might
try
to
publish
a
best
practice
in
the
kind
of
more
broader
sense
or
in
different
contexts.
Maybe
we
can
address,
though
it
was
like
categorize
them
in
a
sig
meaningful
way
and
just
talk
about
a
meta
files
that
are
not
part
of
your
source
code.
Should
you
publish
those
or
not
rather
than
method,
and
what
you're
gonna
declare
what's
included
in?
What's
now.
D
I
Yeah
I
mean
I'm
just
going
back
to
the
origin
of
the
ticket,
like
the
first
topical
poet
posed
there
like
it
started
out
of
the
concept
of
coverage,
Files
and
NYC
output
files,
and
yes,
let's
RC
files
should
those
be
included
or
not
right
but
like
I
know
how
the
conversation
started.
Moving
towards
other
areas
and
I've
seen
Joel
try
to
clarify
a
number
of
times.
Talking
about
these
store
files,
I
know,
I,
see,
outputs
and
so
on.
G
When
I
think
even
just
identifying
user
stories
and
being
like
this
is
an
example
of
somebody
who
cares
about
these
things,
and
this
is
what
they
did,
and
this
is
why-
and
this
is
an
example
of
someone
who
cares
about
different
things,
and
this
is
what
they
did,
and
this
is
why
it
like
we
don't
have
to
moralize
on
it
and
call
it
a
best
practice
necessarily,
but
it's
really
useful
to
be
able
to
show
in
kind
of
an
exemplar
for
the
different
paths
so
that
everyone's
not
just
running
over
the
lawn.
You
know.
E
Oh
I'll
reread
the
issue,
but
I
think
that
a
lot
of
the
stuff
that
was
talked
about
is
really
good
and
should
maybe
be
moved
to
that
discussion
as
well.
I
tried
to
capture
as
much
like
hood
in
the
in
the
note,
but
I
do
very
much
like
the
idea
of
having
different
use
cases
and
maybe
a
blog
post,
to
ask
people
what
they
think.
E
C
C
I
think
that
was
the
overwhelming
takeaway
from
the
answers
to
the
questions.
I,
don't
know
if
we
had
specific
deliverables,
I
know
Express
we've
talked
about,
and
we
have
a
meeting
later
this
week
to
talk
about
how
we
can
concretely
improve
the
situation
around
getting
people
to
help
us
triage
I,
don't
know
if
MQTT
has
had
any
similar
like
here's.
What
we're
gonna
do
to
try
to
improve
the
situation
so
I
don't
know
what
next
steps
are
on
it.
C
Maybe
it's
just
you
know
the
or
you
know
the
two
groups
need
to
get
on
the
call
together
and
say
like
yeah.
This
would
be
this
would
work
for
both
of
us
because
Express
we're
gonna
talk
about
it
on
on
Wednesday.
What
we're
gonna
do
is
we're.
Gonna
have
three
tiers
of
issues,
and
so
the
we're
gonna
try
to
maintain
tags
on
the
repos
that
will
help
direct
users
to
where
to
go
so
we're
gonna
have
the
triage
ones
will
be
the
newest,
opened
issues,
ones,
labeled,
question
and
ones
labeled
discuss.
C
So
those
are
just
question
and
discuss
or
ones
that
express
is
already
using
across
most
of
our
repos
to
you
know
just
signal
to
people,
hey
that
you
know
these
are
still
up
for
up
for
grabs.
If
you
have
opinions
come
come
talk
about
it
and
then
the
newest
ones
are
just
you
know,
will
be
the
unlabeled
and
and
so
I'm
I'm
working
on
a
little
tool
that
will
give
us
like
a
status
page
that
will
be
across
all
of
the
repos
on
all
of
the
orgs.
C
That
will
get
all
those
and
keep
them
up
to
date.
Then
there's
the
second
level,
which
is
the
top
ten
we're
calling
it,
but
it's
really
just
not
necessarily
ten
issues
that
will
be
agreed
upon
by
the
Express
CTC
at
any
given
time.
You
know
it
might
be
just
a
PR
to
the
to
the
list
or
something,
but
the
idea
is
that
that
would
be
for
people
who
have
a
little
bit
of
context
around
the
project
and
want
to
contribute
more
comprehensive
things.
They
would
be
able
to
go
to
that
list
and
see.
C
C
You
know
Doc's,
like
those
are
big
initiatives
that
we
have
and
those
would
be
for
people
who
really
have
context
and
want
to
want
to
push
the
project
forward.
So
that's
the
plan
that
we
have
for
express
and
I
don't
know
you
know
I
guess:
Matteo
is
not
on
the
call,
but
he's
the
point
person
for
MQTT.
So
if
he
likes
that
approach,
maybe
that's
something
that
we
could
come
up
with
some
sort
of
standard
document
around
and
say
like
look.
C
F
F
F
C
Yeah
I'd,
like
to
I,
will
take
a
look
at
that
I
I
do
think
one
thing
I
should
put
on
the
priority
list
here
is,
and
I
can
do
this
manually
for
the
first
time,
but
I
will
take
our
Express
issues
and
do
just
like
you
did
in
this
board
and
I'll
make
I'll
make
issues
that
point
to
the
Express
ones
here.
I
think
I
think
that's
a
great
start.
C
I
can
do
that
after
our
meeting
on
Wednesday,
when
we
finalize
our
list
and
that
and
then
from
an
automation
standpoint,
anything
I'll
take
a
look
at
this
word
word
tool,
and
maybe
we
can
collaborate.
I
did
create
a
github
and
NPM
organization
called
PK
gjs.
My
intent
was
to
publish
this
tool
there
for
that
exact
role
of
like
here's,
where
we'll
share
it
for
other
ecosystems.
C
I,
don't
know
how
much
other
ecosystems
have
the
problem
that
expressed
does
is
that
were
split
across
github
orgs
and
repos
and
like
like
heavily
split
like
there's
I,
think
probably
like
40
repos
that
are
actively
maintained
across
three
different
github
orgs,
so
the
the
specific
tooling
I
was
building
was
to
try
to
consolidate
that
I.
Don't
know
if
that's
something
other
people
have,
but
you
know
if
MQTT
has
that
as
well.
C
If
not,
maybe
we
can
reach
out
because,
like
you
know,
like
babel
and
some
of
these
other
big
ones,
they're
all
really
consolidated,
they
have
sometimes
they're
even
a
mono
repo
and
Express.
Just
has
the
opposite
problem.
So
I
don't
know
you
know
if
that
if
we
want
to
solve
for
both
or
or
what
but
I
think
I'd
be
a
point
to
to
collaborate
on
with
some
of
these
other
ecosystems
that
are
bigger.
D
I
also
in
your
questionnaire,
you
mentioned
and
I
believe
metal,
as
well
mentioned
in
the
that
an
amputee
the
release
process.
Are
there
any
discussions
happening
on
that
anytime
soon,
because
I've
been
working,
two
fronts
there
at
work
and
there's
one
that
there's
obviously
semantic
release
which
automates
a
lot.
If
you
adopt
certain
conventions
and
then
there's
the
other
thing
that
near
form
has
built
as
part
of
their
sort
of
experimental
exploration.
D
Type
thing
is
something
that
should
be
actually
a
part
of
or
NPM,
but
things
are
the
way
they
are
so
there's
an
experimental
tool
which
allows
a
remote
OTP
requests,
which
means
that
you
can
publish
using
2fa
from
CI
directly
right
so
CI.
It
makes
a
request.
You
receive
a
notification
on
your
phone,
you
click
approve.
The
package
is
published,
you
click
reject.
The
package
is
not
published,
so
we
have
a
thing
like
that
and
yeah
I'm
happy
to
assist
there.
If
there's
some
discussions
that
you
can
join
or
something
I.
C
Be
willing
to
add
that
to
our
meeting,
because
that's
one
of
the
topics
Doug
and
I
have
discussed
sort
of
offline
a
bit
is
what
could
be
so
at
some
point:
Doug
removed.
Basically,
everybody
from
published,
writes
on
NPM.
There
was
a
security
concern,
and
this
was
before
two
FA
so
minoan
and
with
express
this
is
very
important
specifically
because
of
the
reach
he
just
removed,
everybody,
which
is
a
really
bad
thing
for
contributors
right,
because
now,
like
even
me,
I
can't
publish
I
have
to
ping
Doug.
C
So
if
you
have
something
that
I
think
we
absolutely
love
to
hear
about
it
and
and
talk
about
how
we
can
utilize
that
and
be
involved.
So
if
you're
interested
in
coming
to
the
meeting
I'll
put
that
on
the
agenda
and-
and
we
on
the
call
what
I
was
that
Wednesday,
let
me
double
check
here,
I
think
it's!
Oh,
it's
4:30!
Pacific,
though
I
can
I'll
post
it
in
the
I'll.
Put
it
in
the
agenda,
I'll,
put
a
link,
thank
you
and
I
think
we're
out
of.