►
From YouTube: Package Maintenance Team meeting - Oct 22 2019
Description
A
A
A
A
A
C
D
A
A
that's
a
good
question:
it's
it's,
it
will
be,
might
will
go
out
under
the
foundation
medium
and
we
don't
have
a
standard
way
yet
to
like
notif
a
notify.
This
team.
We
should
you
know
if
at
mentioning
do
you
think
kept
mentioning
the
team
in
the
issue
is
good
enough
for
what
other
ideas
that
people
have
to
because
yeah
that's
a
great
idea
to
figure
out
how
we
do
a
good
job
of
that
yeah.
D
E
Can
you
leverage
some
type
of
content
manager
that
you
can
like
line
up,
tweet
or
whatever
I
think
I've
used
one
of
those
in
the
past
for
some
type
of
brand
type
thing
where
you
can
load
up
tweets?
You
want
to
send
out
at
intervals
like
even
schedule
them
out
like
weeks
or
such
an
advance,
amazing
on
those
lines,
I
think.
A
It's
like
our
work
is
to
figure
out
what
we
want.
I
think
this,
the
foundation
Twitter
account,
does
have
that
kind
of
capability.
So,
if
we
said
hey,
we
want
to
have
these
retweeted
at
this
time
these
between
at
that
time,
we
can
easily
make
that
request.
Okay
in
terms
of
us
remembering
and
retweeting
ourselves,
I'm,
not
sure
like
we
don't
have
a.
We
don't
have
an
instance
of
something
like
that
that
we
can
all
log
in
and
use
ourselves,
but
we
could
come
up
with
some
other
way
to
remind
ourselves
right.
A
I
mean
like,
for
example,
I
I
just
mentioned
is
that
we
probably
need
to
think
about
what
and
how
we'd
want
to
do
that.
One
thing
off
the
top
of
my
head
we
could
come
up
with
is
like
an
issue
that
says:
hey
here's
some
things
we
want
to
promote
periodically
and
we
could
have
a
standing
issue
on
the
agenda
to
kind
of
go
through
and
say:
hey
is
it?
Is
this
the
time
to
go
and
do
that
again
or
something
like
that?
A
F
D
Podcasts
and
if
we
make
an
issue
like
that,
you
know
maybe
regularly
send
them
a
link
to
it
and
just
say:
hey
in
your
next
podcast
or
next
newsletter,
or
you
know,
it'd
be
great
if
you
could
help
us
get
the
word
out
about
some
of
these
initiatives
are
working
on
because
I'm
sure
they,
you
know,
they're,
always
looking
for
content.
Yeah
I
know
a
good.
E
A
G
Yeah
I
can
take
the
lead
there,
so
we
I
was
the
last
one
to
comment
on
that
issue.
Trying
to
give
you
some
feedback.
Apologize
I
haven't
been
more
active
with
all
the
work
that
I've
got
in
flight
on
my
end
and
I
didn't
but
tried
to
give
some
feedback
and
and
some
insight
into
sort
of
what
we're
looking
to
do
and
I
know
that
we've
had
numerous
discussions
about.
You
know
the
scope
is
probably
the
biggest
concern
for
me.
G
G
And
we
would
you
want
to
try
to
action
on
this
like
extremely
quickly
so
Roy's,
actually
here
from
our
team
and
he's
actually,
the
one
queued
up
to
take
this
work
and
run
with
it.
If
we
think
that
this
looks
like
a
good
sort
of
intermediate
step
again,
I'm
I
want
to
preface
all
that
with,
like.
We
tried
to
take
the
lens
of
doing
something
small
that
we
thought
would
be
the
most
meaningful
and
also
sort
of
circles.
G
Back
on
a
conversation,
we
started
in
late
August
in
terms
of
how
we
were
going
to
try
to
move
the
needle
forward
for
for
package
maintainers,
specifically
with
the
monetary
funding
lens
in
mind,
so
just
wanted
to
follow
up
with
that.
It
doesn't
change
the
conversation
around
the
sport
field
itself,
and
that
was
also
a
key.
We
didn't
want
to
clobber
that,
because
there's
a
lot
more
to
be
said,
I
think
in
that
realm
and
I
know
that.
Obviously
the
discussion
is
gonna
keep
going
on
in
terms
of
where
that
information
is
gonna
live.
G
So
we
didn't
want
to
steal,
obviously
that
key
and
we
thought
that
would
be
more
appropriate
to
specifically
utilize
the
funding.
He
impacted
a
song
specifically
for
that
type
of
information.
The
only
one
caveat,
I
think
that
has
been
brought
up
is
whether
or
not
we
want
to
maintain
multiple
references
like
an
object
in
that
field,
which
is
sort
of
what
was
proposed
in
the
backing
key,
which
I
liked
and
I
thought
was
useful.
G
Although
I
didn't
want
to
have
such
a
prescriptive
reserved
word
listing
again,
I'm
willing
to
desculpe
that,
based
on
Faris's
comments
and
and
other
folks
comments,
and
what
here,
what
people
have
to
think
to
say
or
think
on
that
again
this.
This
would
take
a
piece
out
of
what
the
support
schema
is
trying
to
solve
and
try
to
execute
against
it
in
some
way.
So
I
would
love
to
hear
people's
feedback
and
would
love
to
give
some
people
some
time
to
review
that
as
well.
H
That
at
least
my
opinions
here
are
clear:
that
funding
information
represents
an
opportunity
for
the
user
to
give
something
to
pay
or
whatever
the
package,
maintainer
--zz,
there's
no
implied
contract
or
return
like
or
quid
pro
quo
right,
so
I
see
no
issue
with
like,
for
example,
a
URL
showing
up
in
the
funding
field
because,
like
whatever,
if
that
URL
doesn't
work
anymore,
I
can't
give
money
to
the
package
mutator
like
that's
on
that.
That's
their
problem
right,
like
I,
don't
suffer
because
of
that.
H
Somehow
then,
I
think
that's
good
now
to
me
that
actually
says
that
it
should
be
an
object
so
that
each
kind
of
funding
thing
has
an
ID
essentially
because
an
object
key
is
basically
an
ID,
because
that
way
you
can
address
it
from
the
support
field
or
from
tooling
there
I,
don't
think
it
should
be
prescriptive.
I
think
any
key
should
be
allowed.
H
It's
a
funding
object.
It
has
a
key
like
methods
or
mechanisms
or
something,
and
then
that
object
all
the
keys
are
IDs
and
all
the
values
are
maybe
a
URL
to
start
with
and
could
expand
to
be
an
object
later
or
something
but
like
by
doing
that,
then
you've
kind
of
ensured
any
potential
future
expansion.
Even
if
we're
not
100%
sure
what
that
might
look
like.
Does
that
make
sense.
G
H
F
H
You
know,
and
and
and
I
don't
mind
if
it's
stealing
pieces
out
from
the
support
field
right
like
that,
like
flat,
is
better
than
nested
so
like
I
would
rather
have
ten
fields
that
each
have
an
independent
use
case
in
schema
that
can
interoperate.
Then
one
massive
field
that
does
everything
that
said
I
think
that
I
also
don't
think
the
support
field
is
biting
off
too
much,
but
like
I
I,
don't
think
we
have
to
like
I
would
rather
see
things
go
in
and
see
things
held
up
on
it
on
a
big
solution.
A
Like
y'all
just
thought,
the
like
the
the
flat
fields
make
sense,
and
until
you
want
to
have
that
version
info
that
was
in
there
but
I
think
like
I'm.
On
the
same
thing,
it
would
be
good
to
get
something
you
know,
there's
a
desire
to
have
some
stuff
and
I
wonder
if
it's
a
replacement
or
if
it's
something
where
like
in
the
support,
backing,
there's
some
options
in
terms
of
specifying
what
it
is,
and
you
know
if
sponsored
could
maybe
include
be
expanded,
include
an
option
which
is
a
reference
to
that
field.
That's.
H
Doesn't
need
versioning
because,
like
yeah,
maybe
you
could
make
it
be
an
object
that
has
a
distant.
You
know
expired
true
field
or
sauna.
We
can
figure
that
out
later
but,
like
you
know,
you
can
always
expand
the
string
to
then
be
an
object
later,
but
but
the
that
once
you've
the
funding
mechanism
kind
of
sits
by
itself
and
if
github
sponsorship
is
a
funding
mechanism,
that's
forever
valid.
Now
it
may
no
longer
accept
new
funds
at
some
point,
but
it
like
it.
Never
wasn't
it's
it's
it
like.
A
H
H
H
But
then
once
this
exists,
like
kind
of
in
terms
of
like,
if
you
were
designing,
a
database
schema
like
funding
mechanisms
is
a
table
and
the
support
field
is
a
table
and
there's
a
linking
table
between
the
two
and
like
the
the
linking
table
is
the
part
where
you'd
need
the
versioning,
where
it's
like
version
1,
and
to
have
this.
These
funding
mechanisms-
and
these
supports
but
version
3-
has
a
different
one
and
you
know,
and
but
that
doesn't.
A
Yeah,
although
anyway
I
I
think
we
could
get
into
a
long
discussion
of
that
I'm,
just
more
thinking
of
like
is
the
funding.
Would
it
replace
the
entire
backing
section
or
is
it
a
like?
The
you
know,
we'd
still
think
that
some
of
the
other
things
we've
defined
in
the
backing
section
makes
sense.
But
then
you
would
you
know
when
you
want
to
say
sponsorship
or
one
of
this
one
of
the
subtypes.
It
could
say.
Well,
actually
it's
just
a
reference
to
this
other
funding
thing.
I
would.
H
D
D
So
I
say
that
mostly
because
we
have
some
semantics
in
the
spec
that
we
have
today,
that
I
think
are
valuable
and
have
if
a
author
of
a
package
wants
to
duplicate
some
of
that
across
the
two
areas,
for
a
reason
that
you
know
makes
sense
to
them.
I
I'm,
not
super
opposed
to
that,
but
I
think
hat
I
think
it
would
be
uncommon
once
we
actually
get
into
the
the
weeds
on
that
wants.
D
A
lot
of
people
have
implemented
that
it
would
most
likely
be
a
reference,
but
the
reason
I
say
that
it
might
be
separate
is
because,
if
you
were
doing
something
like
a
tear
like
say
you
had
you
had
to
sponsor
over
a
certain
tier
right
to
get
that
specific
support
of
that
specific
version
you
might
put
in
the
sponsor
or
I.
Guess
the
funding
or
I
guess
I
have
to
get
the
keys
right.
D
You
might
put
in
the
funding
that
you
accept
github
sponsors
and
you
might
put
in
the
support
side
that,
in
order
to
achieve
this
level
of
support,
you
need
this
sponsorship
with
this
tier
right
and
so
having
sort
of
a
a
bit
on
both
sides.
I
actually
think
might
make
this
more
powerful
in
the
long
run.
Does
that
make
sense,
yeah.
A
I
think
I
think
I
know
you're
saying,
although
we
haven't
necessarily
bound
the
two
different
sections
together,
but
it
is
interesting
that,
like
you
could
say
for
a
particular
version,
these
are
the
funding
mechanism
yeah,
so
I
guess
the
the
the
key
question
here
is
before
we
flip
back
to
discussing
the
actual
original
PR
is
I.
Guess
you
know
there,
so
you
want
some
more
direct
feedback
on
the
on
the
the
RFC
itself.
Yeah.
G
That
would
be
super
helpful
just
to
get
folks
input
there
and
again
I
want
to
preface
this
with
it.
We
don't
know
if
this
would
be
a
long-term
solution
compared
to
I
think
the
scope
of
the
work
that
has
been
done
for
support,
which
is
why,
again,
we
didn't
want
clobber
a
keyword
we
didn't
want
to
essentially
try
to
take
on
too
much
as
well
like
where
I'm
totally.
We
are
ready
to
D
scope
this.
G
A
I
Terms
of
making
progress
like
on
getting
it
to
whatever
the
finish
line
is
and
I
know
we're
waiting
to
hear
back
feedback.
If
I
recall
the
original
reason
that
we
were
breaking
down
the
object
into
multiple
parts
and
considering
which
parts
are
going
to
be
referenced
by
URL
or
at
least
have
the
option
to
be
referenced,
it
was
because
we
wanted
the
flexibility
to
be
able
to
make
updates
to
it
without
a
full
publish,
so
I'm
curious.
What
would
be
the
blockers
for
putting
out
a
version?
I
A
G
So
the
affairs
came
back
with
the
first
piece
of
feedback
and
just
said:
let's
limit
the
scope
of
this
to
just
the
URL
now
I
want
to
be
mindful
I
think
there
was
a
note
there
about
updating
that
URL.
At
any
point,
that's
that's
not
the
idea
here.
I
think
this
would
be
you'd
have
to
be
updating
this
on
publish
okay,.
A
I
Original
issue
was
that
if
you
have
like
version
3
over
here
or
whatever
version
1.0
point
1
and
you
go
to
version,
1.0
point
2
and
you
have
different
support
I
like
would
there
be
some
sort
of
accountability
for
one
point:
0.12
continue
to
provide
the
level
of
support
for
anyone
that
continues
to
use
the
older
version.
Based
on
the
support.
You
know
that
we
said
that
we
have
provide
in
the
night,
but.
A
D
I
guess
back
on
that
was
mostly
centered
around
the
NPM
s,
responsibility
for
doing
that
and
that
to
Jordan's
point,
if
you
don't
have
there's
the
part
of
our
spec,
which
is
really
trying
to
be
binding,
which
is
different
from
the
funding
stuff.
So
the
the
the
not
having
a
URL
has
been
a
point,
a
sticking
point
for
the
r-spec,
because
we
have
some
parts
where
we
want
them
to
be
binding
based
on
others,
but
and
funding
stuff
is
separate.
D
I
With
NPM
page
loading,
the
data
from
the
URL
but
I,
don't
recall
it
being
related
to
publish
based
on
our
previous
conversations,
because
I
thought.
The
whole
point
was
that
NPM
site
would
show
the
data
per
the
spec
in
the
in
the
published
JSON.
But
if
you
changed
it,
it
would
load
whatever
the
new
data
was.
You
know
whatever
the
page
loads,
but
it
wouldn't
only
change
the
data
that
shows
up
on
the
NPM
page
related
to
the
module,
because
there
was
a
publish
like
I
thought.
I
It
was
decoupling
the
publish
process
from
the
ability
to
update
the
data,
that's
shown
on
the
NPM
module,
because
you
have
like
a
single
source
of
truth
about
the
type
of
funding
or
the
type
of
support
that
you're,
providing
that
you
can
update
independently
of
publishing.
But
it
would
still
show
up
on
the
NPM
page
I
thought.
H
A
Also
going
going
back
to
the
original
discussion
is
I,
don't
think
like
Wes,
I
and
other
people
in
correct
me
if
I'm
wrong
I.
My
understanding
is
not
that
we're
worried
about
a
commitment
right,
I
mean
the
package
meant,
can
change
what
they
support
for
any
version
at
anytime.
This
is
this
is
not
a
contract
that
you
know,
an
old
version
will
be
supported
forever
or
anything
like
that.
It
was
around
having
the
information
available
in
the
package
itself
versus
having
a
URL
where
you
might
have
to
go.
Get
that
data
I,
guess.
H
Let
me
click.
Let
me
clarify
the
current
plan
had
been
to
inline
the
data
in
package
JSON,
but
to
have
the
implied
part
of
the
spec,
be
that
whatever
was
tagged
latest
on
NPM,
always
trumped
all
other
versions
of
the
support
field,
which
means
that,
yes,
you
can
update
it
at
any
time
whether
it
is
legally
binding
or
not
is
entirely.
If
you
know
a
separate
issue
that
we're
not
touching
that's
related,
like
local
laws
and
what
you
actually
write
in
the
field
and
blah
blah
blah.
It's
more
that
the
but
the
but
beak.
H
So
by
having
an
inline
in
the
package
JSON.
The
the
the
benefits
of
that
were
that
you
can
obtain
the
data
without
downloading
the
entire
tarball,
and
then
it
could
be
stored
in
the
NPM
registry,
which
is
the
only
reliable
data
source,
the
additional
ability
for
NB
m
to
allow
that
data.
Any
data
to
be
updated
without
a
publish
and
to
show
the
you
know
just
like
they
show
the
latest
readme
to
show
the
latest
support
data
on
the
website.
The
the
latter
is
something
that's
probably
easy
for
them
to
do.
H
The
former
is
probably
trickier,
but
like
the
it
would
be
ideal
if
we
got
NPM
to
commit
to
and
then
ship
those
features
and
with
that
we'd
be
able
to
be
more
flexible
in
what
we
could
do
with
the
format
of
that
data.
But
without
that
the
like
we
were,
we
were
kind
of
proceeding,
multi-tiered,
saying,
assuming
that
we
never
get
that
commitment
for
NPM
that
the
the
only
downside
was.
F
H
A
A
So
far
right
so
that
reflects
my
understanding
and
I
guess
it's!
You
know
we
have
a
number
of
people
who
think
that
this
data
and
and
to
be
honest,
I,
think
any
of
this
data
can
change
so
I
know,
there's
been
some
mention
of
like
some
is
less
changeable
than
others.
But
to
be
honest,
you
know
the
package
maintainer
can
change,
I
think
any
of
this
any
of
this
data.
So
it's
it's
and
there's
some
people.
You
know,
there's
a
group
that
feel
that
the
because
of
that
you
know
having
it
actually
be.
A
Something
that's
in
the
package
and
that's
tied
to
a
path
to
a
publish,
doesn't
make
a
lot
of
sense
because
you
should
really
get
the
the
most
current
data.
I
know
that
you
know
you
feel
the
opposite,
that
it
should
be
there,
and
so
the
latest
sort
of
compromise
attempt
was
to
say-
and
this
obviously
you
know-
would
be
it's
a
long
term
solution,
not
saying
you
get
there
today
would
be
like.
Does
it
make
sense
that
it
actually
is
a
URL,
but
then
to
address
the
issues
of
the
data
being
available
in
the
package.
A
You
know
offline
is
that
when
you
do
a
publish,
it
actually
pulls
the
data
from
the
URL
and
adds
into
the
package
now
thinking
about
it
doesn't
necessarily
have
to
go
into
package
JSON.
It
could
be
another
file
in
the
package
as
well,
but
some
way
where
you
know
so
the
URL
could
be
in
the
package
I
son.
H
And
that's
a
reasonable
compromise
and
as
long
as
NPM
is
willing
to
add
a
make,
an
internet
request
and
validate
it
as
part
of
the
free
published
process,
if
they're
willing
to
add
that
to
the
CLI,
which
is
a
much
lower
impact
thing
to
add,
then
the
like
update
in
place
without
publishing.
Right
then
sure
that
would
work.
But
if
it's
not
part
of
the
CLI,
if
a
failure
in
validating
that
data
doesn't
block
publishing,
for
example,
then
I
don't
think
it's
gonna
work
as
well.
H
That
a
failure
in
inline
data
to
validate
woodblock
publishing,
but
that's
like
I,
think
there's
a
difference
if
you're
fetching
a
remote
resource
and
you
suddenly
get
a
404
and
HTML,
you
know
or
503
and
HTML
floods
down
like
you,
wouldn't
want
a
package.json
to
have
some
three
megabyte
503
page,
because
then
that
would
make
installing
the
package
slow
and
would
probably
break
npm
a
little
bit
so
like
the
I
like
the
compromise.
But
it
requires
it
also
in
a
way
that
the
inline
one
doesn't.
It
requires
some
commitment
from
NPM.
So.
A
G
G
F
Yeah
my
concern
about
it
is
that
to
me,
so
it
sounds
more
like
it's
just
so
fundamentally
different
from
what
IBM
does
itself
that
to
me.
It
sounds
like
a
different
cope
and
we
can
just
like
hook
using
maybe
like
a
pre-published
hook
and
like
it
sounds
like
a
different
tool
than
just
trying
to
bake
that
into
India.
So.
D
That's
actually
I'm
glad.
You
said
that,
because
that
was
what
I
was
going
to
maybe
propose
would
be.
Is
there
any
opportunity
for
us
to
run
some
some
sidecar
infrastructure
when
we
have
ideas
like
this?
If
if
the
problem
is
NP,
M's
got
to
foot
the
bill
which
I
don't
want
you
to
have
to
do,
I
mean
it
doesn't
make
sense
for
you
to
have
to
add
these
features.
Add
the
you
know
this
infrastructure?
If
you
don't
already
have
it,
and
if
it's
a
big
ask,
is
there
any
way
that
we
could
work
with?
D
Maybe
the
foundation
and
get
the
foundation
to
add?
You
know
to
get
some
donated
hardware
and
run
a
server
that
we,
you
know,
build
the
feature
set
for
and
win
and
we
get
some
web
hooks
on
NPM
side
and
all
that
it
is,
is
a
web
hook
that
calls
to
this.
You
know
sidecar
service,
the
sidecar
service
does
the
validation
we
as
the
packet
maintenance
team
and
the
node.
D
You
know
infrastructure,
group
or
whatever
could
manage
it,
and
it
would
just
be
sitting
there
on
the
side
so
that
NPM
doesn't
have
to
do
any
of
the
the
problematic
stuff,
which
is,
you
know,
dedicate
engineering
resources
pay
for
the
servers
feel
the
extra
bandwidth
right
like
if
we
could
just
offload
that
on
to
some
other
organization.
Would
that
actually
make
these
kind
of
requests?
Not
just
this
one
in
particular,
but
other
ones
that
we
might
you
know,
come
up
with
as
a
group,
more
feasible.
A
D
A
G
But
just
imagine
how
many
dependencies
you're
gonna
have
to
make
that
curl
requests
for
so
I
like
this
is
not
necessarily
and
Wes
I,
totally
on
board,
with
figuring
out
ways
that
we
can
be
more
collaborative
and
fun,
and
you
know
enter
like
interesting
ways
that
we
can
unblock
future
development.
So
definitely
want
to
take
that
offline,
somehow
and
figure
out
that.
But
in
this
particular
case
it's
not
an
infrastructure
problem
or
like
overhead
on
our
our
ends.
H
H
H
Of
the
folks
who
have
expressed
concerned
about
the
in
line
approach
or
don't
like
the
idea
of
just
vomiting
more
stuff
in
the
package.json,
so
I
think
that
the
in
the
benefit
that
some
people
see
there
is
that
they
have
one
line.
That's
a
URL
instead
of
adding
a
bunch
of
support
data
and
then
the
URL
can
separately
maintain.
A
Jason,
we
would
be
like
if
you
want
to
actually
get
the
latest
value.
You
would
use
that
URL
you'd
get
the
latest
data,
and
so
you
get
it
addresses
the
I
think
this
should
be
the
latest
up-to-date
thing.
So
you
get
that
you
get
that
for
people
who
think
that's
on
the
flip
side,
for
people
who
are
concerned
about
being
able
to
get
the
data
without
having
to
do
a
URL
request
or
having
to
do
you
know,
be
able
to
get
it
from
the
NPM
repository
and
having
it
offline
in
a
package.
A
You
get
that
as
well,
and
you
could
you
could
do
it.
You
could
basically
say
well.
What
you
need
to
do
is
add
a
URL
to
your
package
that
Jason
and
add
this
file
to
your
to
your
pack,
to
what
you
publish
right,
but
the
the
complaint
I
think
LJ
would
come
up
with
on
that.
Is
it's
not
very
ergonomic
and
nobody's
gonna?
Do
that
right.
H
When
that's
two
sources
of
truth,
whereas
if
you're
automatically
pulling
from
the
URL
every
time,
then
that's
just
one
and
then
that
that's
right
that
does
solve
the
kind
of
offline
like
if
I
don't
have
internet
I
can
still
look
at
the
last
published
version.
But
whenever
I
do
have
internet
I'd
go
to
the
URL
and
get
the
latest
and
the
URL
would
always
trump
whatever
is
regarded
in
the
artifact.
That's.
H
G
H
Anything
in
existence
like
nobody
will
ever
use
it
again
because,
like
and
then,
as
far
as
shipping
and
a
tool
to
me,
if
it's
not
an
NPM,
it
doesn't
count
and
with
the
definition
of
the
correct
behavior
is
what
NPM
does
.
and
anyone
that
like
breaks,
that
in
in
you
know
in
terms
of
effective
user
visibility
like
they're,
the
ones
that
are
broken,
and
that's
just
the
position
NPM
happens
to
be
in
so
I
think
that
what
we
can
certainly
build
a
tool
easily.
H
A
A
A
H
F
C
F
H
And
and
what,
if
I,
don't,
have
internet
access
and
I'm
curious?
What
the
support
is
for
the
package
like
that?
I
want
to
be
able
to
get
to
that
information
without,
depending
on
the
internet
and
similarly,
if
I'm
in
a
company
and
I'm
deploying
theoretically
I
have
no
dependence
on
the
dependency,
the
outside
internet.
H
G
Want
to
be
a
month
all
the
time,
because
you
and
I
know
that
this
is
a
conversation.
We've
had
multiple
times
with
similar
sort
of
outcomes
and
conversations,
so
we
only
have
10
minutes
left
here,
but
just
on
that
I
guess
last
point
I
would
love
to
know
how
folks
are
doing
this
today,
like
in
those
scenarios
where
you're
offline
and
you
need
to
know,
support
information.
Are
people
using
the
license.
Information
in
terms
of
their
understanding
of
what's
is
supported,
like
that
you
know
in
terms
of
prior
art.
G
This
is
the
reason
why
we
decided
to
bite
off
the
funding
aspect,
because
there
was
so
much
existing,
tooling
and,
and
the
community
had
done
so
much
work
around
how
they
thought
best
to
move
forward
in
that
aspect,
I'm
just
wondering
how
much
our
art
there
is
around
this
scenario
in
which
I'm
offline
and
I
need
to
know
what
the
support
level
is
of
the
the
packages
like
that,
exactly
what
you're
saying
in
the
CI
a
CD
environment?
How
are
people
working
around
the
lack
of
a
tool
and
the
lack
of
that
information
today?
Well.
H
I
would
say
it's
the
same
as
the
way
they're
handling
the
way
that
licences
were
handled
prior
to
the
SPD
ex
compliant
license
field.
The
answer
is
they
weren't?
They
were
just
crossing
their
fingers
and
hoping
it
was
cool
so
like
essentially
we're
creating
the
ability
to
do
to
have
the
use
cases
here
by
having
first
class
NPM
support
and
lacking
it.
H
If
I
want
to
know
what
percentage
of
my
stack
like
is
maintained
at
all
as
a
like
has
any
sort
of
maintenance,
as
opposed
to
abandon.
There's
no
way
to
do
that
right
now,
because
there's
no
cano
standard
form,
but
if
the
standard
form
existed
at
all,
then
that
gives
me
something
and
if
the
standard
form
exists
in
a
way
that
doesn't
require
internet
access,
then
I
can
validate
it.
As
part
of
my,
you
know,
CI
process
right.
G
So
then
I
would
again
like
I
would
go
back
to
then
something
that
you
brought
up
yourself
like
how
binding
you
know.
Is
this
contract
based
on
fact
that
every
licensed
open-source
license
pretty
much
distributes
with
it
as
is
and
best
effort
pretty
much
a
term
so
I'm
just
wondering
like
this
is
what
we're
trying
to
do
here
is
that
superseding
those
that
sort
of
contract
that
the
I.
G
A
Dangerous
I
mean
we're
trying
to
avoid
more
information.
I,
don't
think
this
tries
to
form
a
contract
or
a
commitment.
It's
like
this
is
what
I'm
telling
you
if
you
actually
want
to
get
into
a
legal
agreement
in
terms
of
support,
it's
providing
you
the
information
for
how
to
contact
the
package
maintainer
or
the
company
to
do
that.
I!
Don't
think
you
form
that
agreement
through
this
well.
H
And
then
like
in
the
in
the
category
of
licenses,
right
like
the
the
lawyers
for
my
company,
were
concerned
with
like
risk
level
and
that's
always
a
spectrum,
it's
not
binary
and
right.
If
something
claimed
that
it
was
a
certain
license,
then
that
was
low
enough
risk
that
we
could
be
okay
with
it,
whereas
if
something
claimed
it
was
a
different
license,
then
that
was
high
risk
and
we
wanted
to
resolve
that
somehow
as
quickly
as
possible.
I
would
say
the
same
as
with
support
right
like
something
being.
Unmade
is
a
risk.
H
It's
not
like
that
doesn't
guarantee,
like
maybe
I,
could
file
a
github
issue
and
I'll
get
responded
to
immediately
but
like
that
like,
if
we
might
want
to
mitigate
risk
by
saying
like,
let's
try
and
maximize
how
much
of
our
stack
has
is
supported
explicitly
and
like
a
tool
helps
us
do
that.
You
know:
there's
no
like
binding
anything
here:
no
contract,
no
legal
requirement,
it's
just
kind
of
a
reporting
mechanism
and
the
more
we
make
it
easy
to
keep
it
up
to
date
and
to
also
work
in
offline
scenarios.
A
A
We
recommend
you
add
the
URL
and
and
then,
if
you
want
to
include
the
and
and
include
the
file
which
is
like
the
current
state
and
then
based
on
stats
as
to
how
many
people
we've
got,
including
that
file
you've
got
a
stronger
case
to
be
made
that
the
client
itself
should
just
do
the
update
automatically
so
like
I,
don't
know
if
you
know
LJ
would
be
would
be
strong
enough.
If
you
know
NPM
didn't
was
saying
well,
this
isn't
a
crazy
idea.
A
G
That's
totally
exactly
like,
where
I'm
going
with
that
so
I'd
like
again
when
I
was
trying
to
find
a
prior
art
for
this
type
of
like
the
rest
of
the
support
schema,
which
is
why
we
also
narrowed
in
on
again
the
funding
it
was
just.
There
was
leaps
and
bounds
more
probably
like
package
maintainers
trying
to
solve
that
one
problem
versus
the
this
other
problem
of
the
extra
metadata
around
like
level
like
because.
G
E
H
Is
a
maintainer
problem?
It
get
me
there's
a
lot
of
overlap,
but
like
the
yeah
but
I
just
something
I
mentioned
in
chat,
real,
quick,
the
the
compromise,
my
Michael,
you
suggested.
The
one
of
the
benefits
of
having
an
in
line
is
that
I
don't
have
to
download
the
tarball
to
get
the
information.
I
can
do
NPM
view
package
name
like
support,
sure
and
the
information
comes
out.
H
If
it's
a
separate
file
I
lose
that
alright
so
like,
but
you
know
I,
so
Darcy
I,
don't
know
if
they're,
if
the
package.json
is
modified
anyway,
between
what's
published
and
what's
local.
So
is
that
something
that's
it
that
with
is
theoretically
trivial,
to
modify
like
prior
to
the
pack
running
like
I,
think
it's
modified
on
the
server
not
locally
but
like
yeah.
H
H
H
C
H
Yeah
yeah
cuz
NPM
in
view
pulls
the
pack
event.
Not
the
tack
is
JSON
in
the
turtle,
but
they're
built
from
it.
So
I
don't
actually
care
if
it's
in
the
tarball,
if
like,
if
the
NPM
well
yeah,
it's
the
NPM
view
can
pull
it
because
I'm
not
worried
about
I'm
worried
about
not
having
a
connection
to
the
public
registry.
I'm,
not
worried
about
having
no
internet
at
all.
To
be
honest,
yeah.
A
H
Yeah,
that's
right
if
it's
a
separate
file
in
the
tarball,
but
if
that
file
is
inlined
into
the
pack,
you
mint,
then
all
the
use
cases
are
met.
Where
it's
a
separate
file,
it's
outside
of
package.json.
You
have
the
URL.
It's
validated
at
publish
time
and
npm
view
can
still
show
it
without
needing
to
download
the
tarball
so
you're
right.
That
would
actually
work
and
it
requires
a
server-side
integration
to
inline
it
into
the
packet.
H
C
G
That
was
definitely
always
the
ideal.
I
think
we've
talked
about
this
before
for
sure
like.
If
there's
gonna
be
immutable
table
to
something
that
needs
to
change,
then
that
would
be
the
ideals
that
you
can
update
it
there
at
any
time
with
that
requiring
unpublished.
So
I
think
we've
talked
about
that.
It's
just
something
that
I
think
has
been
backlogged
in
my
mind,
and
it
hasn't
been
something
that
we've
agreed
to
yet
based
on.
A
Back
to
I
think
we
only
talked
about
the
NPM
view
when
the
only
source
was
in
the
files
itself
right
like
if,
if
we're,
if
we're
at
the
point
where
the
source
of
truth
is
the
URL,
so
that's
how
you
get
the
latest.
You
don't
go
to
the
latest,
publish
to
get
it.
You
get
you
go
to
that.
Url
I'm,
not
sure
the
NPM
view
matters
anymore,
because
you've
installed
your
you've
installed,
your
module,
get
the
extra
file,
so
you've
you've
got
what
you're
gonna
get.
A
H
A
H
A
A
H
A
A
I
So
if
somebody
wants
to
I'm
not
sure,
but
we
should
update
the
ticket
with
whatever
feedback,
we
need
to
keep
the
conversation
moving
forward.
This
is
part
of
the
reason
that
I
have
the
kind
of
like
ticket
template
or
issue
template
kind
of
on
the
agenda
is
to
decide
in
advance.
Before
we
start
the
like
on
discussion,
what
we
think
would
be
a
good
way
to
like
close
the
conversation,
so
we
can
kind
of
work
towards
a
end
point
and
I'm,
not
sure
I
understand.
F
A
The
the
one
that's
in
my
mind
is
a
potential
way
forward
and
I
don't
know
if
everybody
would
agree,
but
I
think
recapping.
That,
and
seeing
so
is,
is,
is
that
you
know
we
have
the
URL
we
we
would.
You
know
we
would
say
for
to
start
with
well.
You're
gonna
have
to
put
the
file
in
yourself,
and
that
might
be
okay,
provided
that
on
the
NPM
side
we
get
some
feedback.
A
That
says,
if
we
see
people
adopting
that,
and
we
start
to
see
packages
that
have
that
that
you
know
that
extra
file
in
the
URL
in
it,
then
it
makes
sense
to
optimize
that
for
people
by
saying
well,
when
you
have
the
URL,
we
will
suck
down
the
content,
put
it
into
a
file,
and
you
know
it
would
make
sense
to
actually
have
that
in
the
client.
The
answer
is
well
know
what
still
doesn't
make
sense
in
the
car,
then
we're
no
further
ahead,
but
if
it
does,
maybe
that
helps
us
with
a
path
forward.
G
G
I
It's
that
I
mean
also
that
we're
missing
the
place
to
put
it
where
we
here,
that
you
are
else
and
for
just
retrieving
at
some
place.
So
I
don't
know
if
it's
something
that
we
would
add
to
the
repo.
So
it's
not
necessarily
published,
but
the
repo
has
like
one
file
that
we're
retrieving.
Is
that
a
way
that
we
can
get
our
initial
rendering
it
on
the
page?
Is
that
because
we're
talking
they're
grabbing
from.
A
A
B
So
sorry,
it's
just
that
we
had
a
lot
of
discussion
about
URLs
and
the
problem
being
LJ
raised.
Initially
is
what
there's
no
reliable
place
if
we
say
it's
github
that
can
go
away
if
we
say
somewhere
else,
you
know
there
could
be
broken
links
and
we
seem
to
be
going
a
little
circular
thing.
We've
come
backs
it
up
when
that
point
just
be
raised
again,
but
this
is
the
mean
where
we
would
be
saying:
there's
both
right.
H
A
Well,
that's
what
I'm
looking
for
queries
of
compromise
right
like
it's
yeah,
you
know,
there's
the
that's
why
I
was
trying
to
poke
at.
Is
it
like
the
you
know
if
NPM
says
well,
that
makes
sense,
but
I'd
like
to
see
some
uptake
first,
but
it
sounds
like
it's
like.
No,
it's
got
to
be
there
from
the
beginning
or
forget
it.
C
So
it's
like
it's
going
to
be
pointing
to
the
same
repo
that
you're
publishing,
and
so
if
the
support
days
on
file
exists,
but
clients
just
before
publish
time,
can
fill
in
the
URL
from
the
get
information
that
it
already
has,
or
it
can
even
inline
the
file
or
do
the
other
way
around
right.
Two
or
three
like
if
there's
a
support
key
in
the
package.json
you
have
created
before
json
pushes
back
to
get
them.
A
I
think
that's
what
we're
trying
to
get
at
is
like.
Can
we
can
we
get
a
compromise?
It
says
yes,
you've
got
this
URL
you've
got
the
static
copy
and-
and
you
know
I
think
you
know
it
so
it
sounded
like
there
was
some
agreement
that
if
we
had
those
two
but
then
the
concern
was
like
over
will
people
keep
them
up
to
date,
and
so
you
need
to
lling
and
then
the
next
question
was
like
well,
okay,
do
we
do
we?
Can
we
is
there
any
compromise
around
like
well?
A
H
C
When
we're
saying
tooling,
we
could
mean
that
you
know
tooling
isn't
being
published,
but
if
there
existed
some
alternative
way,
which
automatically
does
that
for
you
as
part
of
pre,
publish
or
something
we
could,
but
what
we
didn't,
but
NPM
could
measure
whether
there's
any
response
and-
and
if
there's
no
response,
then
we
need
to
decide
whether
it's
the
tooling
or
not,
the
tooling,
and
it
is
the
tooling
we
can
try
to
treat
the
tooling.
If
it's
you
know
marketing,
then
we
can,
but
to
the
MVP
I
think
we
can.
A
H
That
fully
manually
now
yeah
and
we
could
add
an
extra
tool
and
our
recommendation
to
be
run,
npx
magic,
a
URL,
and
if
you
do
it
for
you
of
course,
and
then
like
the
easier
we
make
it
the
better.
But,
like
the
you
know,
I
it
just
doesn't
feel
like
you
feels,
like
people
are
just
going
to
manually,
stick
a
URL
in
their
in
their
thing
or
they're,
not
going
to
add
it
to
pre,
publish
and
like
so.
The
thing
that
they
benefit
here
is
that
you
can
rely
on
when
this
file
exists.
G
You
I
have
to
drop,
and
so,
but
I
was
hoping
again
just
a
circle
back
to
at
least
the
first
step
towards
a
portion
of
this
is
is
maybe
that
funding
aspect,
and
then
we
can
continue
to
have
the
discussion
about
how
we
can
maybe
write
some
to
lengths
to
to
support
the
supports
back
in
the
income,
not
maybe
necessarily
inside
of
NPM
but
I
mean
again
pre-published
scripts
or
whatever.
It
looks
like
to
see
if
there's
some
adoption
of
this
and.
H
D
And
as
far
as
the
tooling
goes,
I
have
that
package
that
I
published
also
have
a
package
on
the
node
repository.
We
never
resolved
that
where
we
want
to
be
doing
that
work
but
I'm
happy
to
make
that
tool
that
I've
started
the
thing
that
does
what
we
want.
Based
on
this
discussion.
I,
you
know
whatever,
whatever
we
think
we
need
there,
we
can
have
it
have
a
CLI
that
writes
to
your
package
Jason
and
in
lines
the
URL
you
specified
I
mean
we.
Can
anybody
can
go
in
there
and
start
adding
stuff
I'll?
D
B
A
Can
we
can
we
move
forward
with
a
recommendation
or
not
but
like
to
to
to
Darcys
point
about
having
something
that
we
can
start
to
get
feedback
on
and
talk
to
the
community
about?
And
you
know
it
may
change,
but
it
would
be
great
to
get
it
beyond
our
discussion
and
get
it
out
there.
Maybe
you
know
what
we'll
get
the
feedback
that
points
us
in
a
different
direction,
but
you
know
saying:
let's
suggest
and
extend
try
this
it
would
be,
and
so
anyway,
I
guess.
A
H
Mean
we
can
build
it
in
where
it's
currently
at
for
now
right
and
if
we
want
to
move
it
somewhere
later
we
can
and
if
we
should
have,
we
should
build
it
anyway,
because
the
same
code
hopefully
will
be
usable
in
a
pr2
NPM.
If
it
comes
to
that
so
I
don't
see
any
reason
to
delay
working
on
the
tooling.
D
G
D
Should
I
yeah,
you
can
just
shoot
those
to
me,
I'll,
fine
and
then
I'll,
maybe
also
make
a
like
discussions
reap
over
there,
so
that
we
can
have
a
space
win.
That's
why
I'm
like
this?
This
is
why
the
problem
with
the
other,
org
and
I
totally
understand.
This
is
now
what
we
would
have
discussions
in
two
places.
A
D
D
H
A
H
H
D
A
D
E
My
issue,
real
quick,
is
very,
very
small.
Those
opening
good
discussion
amongst
the
members
I
believe
it
was
the
one
I
opened
for
just
in
regard
to
what
snowing
an
unmaintained
package
and
I
had
some
we
had
some
discussion
in
our
company
about
in
regards
is
for
an
open-source
package,
so
any
one
of
the
members
could
just
look
into
that
issue.
It's
270
I
believe
just
start.