►
From YouTube: Package: ThinkBIG March 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
I
wanted
to
share
with
everyone
a
an
update
on
the
research
that
we
are
doing
the
next
as
we
wrap
up
the
quarter,
we're
going
to
have
a
lot
of
really
fun
research
and
a
lot
of
great
data
coming
out
of
it.
We
have
the
job
to
be
done
survey.
The
public
survey
is
about
to
go
on
social,
so
we'll
get
our
users
to
say
what
jobs
to
be
done.
B
Relevant
the
pakad
registry
category
maturity
scorecard,
there's
a
new
process,
that's
being
rolled
out
by
the
UX
team,
to
sync
with
our
users
and
see
if
the
product
is
as
mature
as
we
think
it
is.
It's
really
exciting
initiative
to
see
what
they're
feeling
about
it
and
help
us
guide
us
in
the
next
steps.
So
this
is
really
exciting.
Is
the
container
solution,
validation,
we're
gonna,
start
interviewing,
hoping,
hopefully
next
week,
so
we'll
be
able
to
move
forward
on
that
and
get
feedback
from
our
users
of
what
they
think
about
it.
B
Special
thanks
to
aliens
ROM
for
volunteering,
to
help
me
with
the
research
and
setting
up
projects
and
reviewing
that
I
know
that
I
really
appreciate
it
and
the
last
one
is.
We
have
some
problem.
Validation
and
focus
are
on
the
naming
conventions
and
seeing
if
we
can
loosen
those
up
to
help
our
users
migrate
from
other
package
managers
and
kind
of
experience,
less
disruption
for
naming
stuff
I
just
wanted
to
give
that
update.
That's
all
going
to
wrap
up
nicely
at
the
end
of
the
quarters.
B
A
Why
do
I
wanted
to
follow
up
on
the
maturity
targets?
Cuz,
that's
something!
Dan
has
been
adding
into
our
team
page
and
how
we're
working
dan.
You
want
to
maybe
just
briefly
touch
on
what
you're
hoping
to
do
with
product
maturity
and
and
planning
our
work
and
measuring
success,
and
things
like
that.
Yeah.
D
C
Is
already
aware
that
we
have
I
haven't
on
a
handbook
page
to
sort
of
measure
our
success
fire,
our
progress
towards
our
product
category
and
maturity,
rather
than
emphasizing
am
I
right
as
much
as
we
have
been
mi
rate
is
still
important
as
a
measure
of
efficiency
and
iteration.
So
it's
not
going
away,
but
ultimately
our
goal
is
to
deliver
a
cool
awesome
stuff
to
our
customers,
and
so
the
measure
of
that,
in
my
mind,
or
at
least
that
I'm
trying
to
document
is
our
progress
towards
these
category.
C
Maturity
goals
that
that
Tim,
developed
RS
has
been
developing
slash
get
so
that
a
while
ago,
before
we
all
showed
up
so
I,
think
this
ties
in
to
that
Tim
I.
Think
you
made
a
suggestion
on
the
issue
itself
that
Emma
that
I
created
that
this
could
tie
into
that
and
determining
our
actual
level
maturity.
Would
it
would
be
part
of
this
process,
but
the
idea
is
to
take
our
category
of
maturity
goals.
C
Look
at
the
next
maturity
stage
for
each
of
those
categories:
break
that
down
into
actual
epics
and
slash
issues,
and
then
the
closer
those
things
are
to
us
needing
to
execute
on
them.
We'll
start
evaluating
weighting
proactively
to
sort
of
determine
what
work
is
required
to
deliver
on
those
within
a
quarter
or
a
milestone
or
whatever
block
the
way,
we're
actually
doing
and
then
to
loop
back
and
determine
whether
we
actually
reach
that
maturity
level.
C
Now
I
think
I
think
this
measure
ian
is
sort
of
a
measure
of
our
whole
set
up
the
maturity
scorecard
and
the
research
that
you'd
be
doing
without
users.
The
measure
of
whether
we
determine
the
right
things
to
deliver
as
well
as
whether
we
deliver
the
things
we
committed
to
deliver
so
I
think.
As
far
as
a
measure
goes,
I
think
I'd
be
a
little
bit.
C
It's
it's
difficult
to
know
whether
we
old
they'll
build
the
right
thing,
and
this
is
sort
of
a
measure
of
that
and
then,
but
as
far
as
our
measure
of
success
goes
I'm
more
a
bit
more
focused
on
what
we
want
to
get
these
issues
done
and
deliver
them
to
our
customers,
and
we
did
that.
So
that's
that's
one
part
of
that
measurement.
This
feels
like
a
man.
C
B
Yeah
I
think
so
the
focus
is
like
you
were
discussing.
It
is
on
the
validation
idea,
so
where
we
have
decided
that
we've
moved
forward
in
a
category
maturity,
we
think
it's
a
viable
solution
for
a
lot
of
our
users.
This
effort
is
thus
going
back
in
really
validating
that
our
users
are
great.
This
has
become
a
viable
solution
off
the
top
of
my
head
for
package,
the
package
registry,
which
is
specifically
what
we're
testing
it's
going
to
be.
B
Do
we
offer
the
right
package
managers
for
your
solution
and
is
that
why
we're
viable
and
then
as
well
as
how
easy
is
it
to
kind
of
on
board
to
make
sure
that
we
are
that
viable
solution?
There's
a
rigid
process
involved
where
we
ask
them
like
scored
on
one
to
ten
and
give
it
a
grade
and
stuff
like
that.
So
there's
a
cross
stage
aspect
to
it,
where
every
other
team
is
measuring
it
and
trying
to
measure
in
the
same
way,
so
that
we
have
that
kind
of
constant
score.
B
C
Do
you
think
the
the
time
scale
is
for
that
sort
of
ethic?
Well,
I?
Think
in
terms
of
so
we
say:
oh
yeah,
we
reached
you,
know
viable,
we
reached
loveable
or
whatever
it
is
for
a
particular
category.
What
do
you
think
the
basic
guesstimate
is
of
how
long
it
takes
to
do
this
validation
process
that
you're
looking
at
for
sure.
B
I
would
expect
it's
gonna
be
a
little
greater
than
a
milestone,
maybe
a
milestone
and
a
half
right
around
that
for
context.
The
process
for
doing
this
was
just
kind
of
merged
into
the
handbook
a
few
days
ago,
and
so
the
overall
expectation
is
that
we'll
be
able
to
finish
it
by
the
end
of
the
quarter,
because
it's
one
of
our
okrs
so
that
lines
up
with
about
that
milestone
in
the
half
measurement.
C
Cool
yeah,
so
I
think
I
think.
As
far
as
the
evaluating
effort,
we're
gonna
be
sitting
on
a
shorter
time
scale
on
that,
so
it
could
probably
be
just
a
little
bit
more
of
a
I.
Don't
look
it'll
be
a
little
bit
more
of
a
measurable
type.
We
completed
seven
out
of
ten
or
like
ten
out
of
ten
items
that
we
committed
to
doing
and
then
coming
back
and
then
reevaluating
that
that
could
mean
the
maturity
stage
moves
further
out,
which
is
not.
C
You
know
that
that's
sort
of
it,
because
that's
an
evaluation
of
our
whole
planning
process
as
well
as
not
just
their
execution.
That
would
mean
we
after
we
potentially
adjust
our
timelines
to
then,
because
if
we
said
these
things
make
up
sure,
I
should
try
to
get
my
thoughts
straight
out
apologize
and
if
these
things
make
up
our
next
goal,
which
is
complete
and
then
we
do
that.
And
then
you
do
your
evaluation
which,
as
you
said,
maybe
takes
a
milestone.
The
end
of
the
next,
the
following
milestone.
We
go.
C
A
The
whole
package
group
I,
contribute
and
sort
of
doing
that,
mapping
of
maturity,
targets
to
a
roadmap
and
two
issues
and
giving
everyone
a
chance
to
sort
of
chime
in
and
have
a
conversation
about
that
I
think
we
could
still
do
it
asynchronous
synchronously,
but
I'm
wondering
should
we
should
we
set
a
date
for
ourselves
to
sort
of
have
that
where
we
want
everyone
to
say
I
have
you
know
for
me
when
are
the
maturity
targets
due
and
then
secondly
like?
When?
A
C
Well,
I
mean
let's
break
it
down
into
chunks
a
like,
so
this,
for
the
first
thing
would
be
to
sort
of
determine
let's
just
pick
a
product
category
and
I,
don't
really
mind
which
product
category
it
is
actually
because
we
need
to
do
all
of
them
at
some
level
right
so
pick,
one
that
we
think
is
maybe
the
smallest
and
easiest
so
that
we
can
refine
the
process
as
we
do
that
and
that
would
be
kind
of
your
picton
I.
Don't
think
I
could
you're
the
best
person
to
make.
C
That
decision
have
a
look
at
that
have
a
look
at
the
long
term.
Maturity
goals
break
it
up
to
take
just
the
next
maturity
stage
and
say:
okay,
this
is
the
one
we're
gonna
look
at,
go
through
that
and
make
sure
you're
pretty
comfortable
with
it,
and
everything
will
change
like.
So
it's
not
doesn't
have
to
be
perfect.
It
just
needs
to
be
something
we
can
work
on
and
then
in
the
next
and
then
we
can
start
looking
at
breaking
that
up
until
milestones
even
and
say.
Okay,
what
milestones
are
there?
C
Let's
get
the
next
milestone
and
effectively
say?
Okay,
these
are
the
issues
that
we
need
to
complete
in
the
next
milestone,
ish
to
make
that
work
right
and
there'll,
be
discussions
at
that
point,
but
I
think
if
we
can
sort
of
break
it
down
into
the
smallest
little
chunk
like
that
and
I,
it's
not
arbitrary
by
any
that
by
any
means.
Sorry
Nico,
I
sneakers
that
diligently
trying
to
take
notes,
and
he
can't
keep
up
with
all
that
big
goofy
conversation.
But
thank
you
for
your
hard
work.
Nico.
It's
much
appreciated.
C
If
everyone
else
maybe
can
help
with
the
notes.
That
would
be
good
too.
You've
all
seen
the
gift
so
yeah,
so
they
I
think
if
we
break
it
down
and
it's
not
arbitrary
by
any
means
to
just
select
one
of
the
product
categories
that
you
feel
probably
most
comfortable
with.
So
we
get
moving
on
that
and
then
we
could
break
it
down
into
the
next
product
maturity
stage,
and
then
we
can
break
that
into
the
milestones
and
then
the
next
milestone.
We
basically
look
at
that
and
say:
okay,
what?
C
If
what
features
are
meant
to
be
delivered
in
this
milestone,
and
then
we
can
break
those
up
and
then
it's
a
little
more
than
what
we're
doing
right
now
for
each
of
our
milestones,
because
it's
a
little
broader,
but
it's
not
a
completely
different
process
for
the
team
to
do
that,
because
we're
already
putting
weights
on
things
asking
questions
making
sure
that
things
are
actually
actionable
right,
like
ready
for
development,
so
that
same
process
would
be
then
applied,
but
just
a
little
more
broadly
so
they're
covering
everything
in
it.
That
way.
C
A
Sense-
and
you
even
saying
fitting
this
into
our
normal
process,
makes
me
think
that
our
milestone
review
issue
should
start
to
have
whether
or
not
initially
moves
us
forward
and
maturity
target,
or
things
like
that.
So
I
think
just
carrying
this
conversation
about
maturity.
Targets
into
our
like
normal
planning
is
important
and
then
the
follow
up
to
that
will
be
Ian
will
then
say:
okay,
I'm
gonna,
go
evaluate,
we
hit
a
new
target,
I'm
gonna,
go
evaluate
it
and
see
if
it's
true
and
if
it's
true
we
bump
up.
B
Cool
and
I,
just
want
to
add,
is
all
of
the
other
organizations
from
our
standpoint
is
doing
similarly
structured
tests.
So
when
we
do
have
that
UX
validation
of
maturity,
it
is
just
as
robust
of
a
process
to
confirm
that
as
it
is
for
other
teams,
so
we
all
kind
of
have
that
balance.
Instead
of
it
kind
of
being
one
person's
opinion,
it'll
it'll
be
exciting
to
see
how
quickly
we
all
start
moving
up.
Because
of
that.
C
Yeah
the
I
was
just
writing
this
down.
Next
step
would
be
to
determine
the
product
category.
You
start
with
Tim
and
again
you're
the
best
person
to
make
that
decision
figure
out
the
product
category
and
then
start
looking
at
the
issues
and
epics
that
make
up
that
next
maturity
go
for
that
product
category
and
then,
ideally,
I
know
that
it's
a
moving
target.
So,
like
it's
not
going
to
be
perfect,
we
can't
expect
it
to
be
perfect
and
that's
okay.
C
A
C
And
then
the
the
process
that
Ian's
doing
just
to
reiterate
is
that
we
did
say
this
earlier.
This
process
that
you're
following
here
would
be
to
figure
out
whether
we
had
the
right
goals
and
delivered
on
them,
which
is
to
the
two
parts
to
this
right.
I
feel
like
it's
it's.
It
feels
a
little
scary
to
do
that,
like
after
I
want
to
do
it
before
so,
like
maybe
maybe
I
wonder
if
the
process
would
be
helpful
to
sort
of
say
something
like
once.
C
We've
gone
through
this
step
of
next
maturity
like
proactively,
asking
our
customers
whether
this
would
actually
meet
their
needs
as
far
as
that
maturity
stage,
rather
than
like
after
we've
done
it
and
then
having
to
refactor
everything.
If
we
miss
stuff
right
and
then
we
would
also
be
able
to
say
if,
if
we
preemptively
had
this
discussion
with
customers
and
I'm,
not
saying
that's
easy
by
any
means,
I'm
not.
D
C
B
Just
want
to
call
out
I
think
it's
really
exciting
and
you're
on
the
nail
or
nail
in
the
head
for
that.
We
should
be
doing
a
little
bit
of
pre-emptive
research
as
well
working
with
our
users
to
make
sure
that
what
we're
what
we
think
is
what
will
move
us
to
the
next
maturity
is
what
they're,
what
resonates
with
daemul?
What
feels
right
and
then
we're
all
working
on
moving
this
process
a
little
bit
earlier
and
the
validation
part
so
that
it
is
part
of
the
overall
move
for
a
category
of
maturity.
C
Cool
thanks
for
that
and
and
the
mr
is
out
there
all
shared
in
the
agenda,
so
people
can
go
look
at
it
if
they
haven't
had
a
chance
early
I'm
about
ready
to
merge
it
I'm
just
having
a
bit
of
a
chat
with
one
of
my
peers.
Who's
been
asking
some
really
good
questions.
Rachel.
Thank
you
for
right,
Rachel.
If
you've
seen
this
video
much
appreciated,
but
but
basically
they
get
to
go
so
I,
probably
no
jets
of
mine
today.
A
Cool
so
I
had
the
next
item
on
the
agenda
and
I
wanted
to.
We've
talked
about
the
dependency
proxy
a
little
bit
before
as
a
team,
but
I
wanted
to
bring
it
up
again
because
it's
now
available
on
calm
since
Puma
was
released.
I
think
that
was
last
milestone
and
it's
also
top
of
mind
for
me,
because
I
really
want
to
push
for
moving
the
basic
package
manager,
functionality
to
core
and
having
and
then
incentivizing
and
growing
I
incremental
revenue,
but
I
had
offering
more
premium
and
ultimate
features
built
around
the
dependency
proxy.
A
So
speeding
up
pipelines-
and
you
know
offering
virtual
and
remote
repositories
so
as
part
of
that
I'm
really
interested
in
figuring
out
how
we
could
do
that.
Sorry,
I'm,
just
looking
at
my
notes
and
yes,
I,
just
wanted
to
start
this
conversation
of.
How
can
we
expand
the
functionality
to
help
other
package
types?
A
That's
exactly
what
I
mean
so,
for
example,
for
NPM
the
the
offering
we
have
it
for
NPM
right
now:
move
that
down
to
core,
because
that
I
think
that
it's
a
big
advantage
for
us
to
offer
it
for
free
over
companies
like
a
frog
and
so
no
type
that
are
charging
for
it,
and
it's
a
good
way
for
us
to
take
market
share.
It's
a
good
way
for
us
to
get
more
feedback
from
the
community
on
how
to
improve
the
future
and
then
thus
like
design
better
features.
A
E
There
would
be
a
fair
amount
of
moving
stuff
around
it's
hard
to
say
how
much
effort
that
is,
if
it
really
is
just
like
copy
and
paste
files
from
one
place
to
another
yeah.
That's
kind
of
why
I
asked
I
was
trying
to
get
my
head
around
like
how
much
of
an
effort
that
might
get
before
moving
to
some
of
these
extended
features.
A
Would
we
be
able
to
do
it
in,
as
in
like?
Can
we
focus
on
one
at
a
time?
For
example
like
for
NPM,
we
see
our
most
usage,
so
I'm
always
trying
to
prioritize
the
NPM
registry
first,
so
we
can
get
feedback
and
then
decide
if
we
want
to
move
it
to
the
less
popular
package
managers.
Could
we
move
NPM
to
Korbut,
or
would
everything
have
to
basically
be
moved
at
once?
Yes,.
E
E
Get
lab,
that's
fetching
data
and
displaying
it
on
the
front
end.
So
in
order
to
make
the
move,
we
need
to
move
over
all
of
the
internal
gate
lab
front
and
back-end
stuff.
That
needs
to
be
moved
over.
No
matter
what
and
then
from
there
each
package
manager
can
kind
of
go
one
at
a
time
and
be
done
incrementally.
E
D
F
Well,
actually,
maybe
maybe
not
actually
the
more
that
I
think
about
that.
Maybe
we
could
just
move
all
the
front-end
code
over
to
non
EE
straightaway
and
then
because
it's
all
based
off
of
the
new
list.
It's
all
based
off
of
the
API.
So
as
long
as
the
API
is
only
returning
packages
that
are
in
core
it'll
be
fine,
so
yeah
there's
a
little
bit
of
risk
there,
but
it's
it's
doable
in
the
front-end
I
think.
A
The
other
goal
of
doing
this
is
that
we
could
drive
more
community
contributions,
I
think
we've.
Maybe
a
bunch
of
people
have
seen
some
of
the
questions
in
the
composer,
mr,
as
well
as
the
cargo.
Mr
and
terraform
people
are
asking
well.
Why
should
I
contribute
this?
If
it's
not
going
to
be
available
to
me
once
I,
once
it's
actually
I'm
only
making
it
available
in
the
premium
edition,
so
knowing
that
it's
really
important
to
us
to
get
community
contributions
for
these
package
managers,
I
think
that's
another
way.
A
A
But
as
part
of
that
argument,
so
I
have
to
make
an
argument,
not
just
that
we're
going
to
drive
usage,
but
that
we
also
have
a
path
to
driving
revenue
for
a
good
lab,
because
we
do
have
to
consider
both
sides
of
that
we
have
to
consider
the
broader
community
but
revenue
as
well.
So
for
me,
the
first
thing
that
I'm
going
to
is
what
we
have
the
see
proxy
as
an
ultimate
feature.
What
can
we
do
to
improve
that
offering?
C
It
I
was
like
oh,
but
to
follow
up
on
that
question.
I
had
the
first
comment,
but
a
little
bit
anyway,
I'm
interested
to
see
if
the
team
in
terms
of
implementing
for
other
package
type
is
whether
the
team
feels
like
a
research
issue
would
be
necessary
whether
we
could
just
go
okay,
we
think
we
can
do
it.
We
understand
it
well
enough
to
be
able
to
go
and
just
figure
it
out
and
we
get
a
milestone.
That's
kind
of
what
I
was
wondering
about
I.
Think.
E
E
We
might
be
able
to
say
alright
we're
going
to
do
the
investigation.
You
know
and
then
create
the
issues
this
week
and
that's
kind
of
just
like
the
goal,
and
we
can
start
scheduling
the
issues
from
there.
I
don't
know
if
the
overall
investigation
needs
to
take
that
much
time.
It's
more
almost
a
discussion
of
architecture
than
investigating.
A
A
E
A
Way,
I
mean
the
way
that
I'm
envisioning
the
dependency
proxy
working
now
is
that
I
think
using
NPM
as
an
example,
so
David
just
launched
this
feature
of
using
NPM
org
as
a
remote
repository,
so
I'm
imagining
you
have
the
gate
lab
NPM
registry.
If
you
try
to
pull
a
package,
that's
not
available
in
that
it
will
look
to
your
remote
repository.
If
it's
looking
to
actually
know
if
it's
not
available,
it
should
first
look
in
the
virtual,
your
virtual
repository,
which
is
the
dependency
proxy,
so
look
for
any
package.
A
First,
that's
cached
and
that
could
be
hosted
in
either
the
local
get
lab
repository
or
it
could
have
come
from
NPM
gorg.
So
first,
look
in
the
virtual
repository
then
look
in
the
local
repository
and
if
it's
not,
there
then
go
and
grab
it
from
NPM.
That's
the
way,
a
kind
of
envisioning
it
does
that
mean.
Does
that
make
sense?
Why.
A
First,
because
the
idea
is
that
if
let's
say
that
you
have
let's
say
I,
have
a
package
Hoke
hosted
in
my
NPM
registry
called
like
Tim
package,
1
2
3.
If
it's
already
been
pulled
from
the
NPM
registry
and
it's
cached,
then
we
should
use
the
cached
version
first,
so
that
we
don't
have
to
have
any
download
time
at
all,
even
though
it's
happening
locally
within
the
web
application.
E
A
Of
where
I've,
what
I've
been
thinking,
and
so
do
you
think
that
we
should
do
what
like
that
we
should
roll
that
out
for
maven
and
nougat,
and
or
do
you
think
we
should
trace
one
all
the
way
through?
Should
we
continue
moving
in
pm
and
try
say:
okay,
now:
we've,
where
we're
pulling
that
the
from
a
remote
repository,
then
we're
cashing
them
and
then
we're
providing
some
additional
layer
of
efficiency.
On
top
of
that,.
E
I'd
have
to
throw
that
back
to
the
product
manager
to
you
know,
talk
to
to
give
the
voice
of
customer,
and
you
know
like
how
important
would
that
be
for
NPM
users
now
versus
adding
that
other
functionality
for
the
other
package
managers
like
which
one
has
more
weight
at
this
point
in
time.
Well,
the
reason
I.
A
B
Just
going
to
say
from
the
users,
I've
talked
to
being
able
to
go
out
and
get
them
from
the
NPM
yes
org
place
and
pulling
it
in
is
more
important,
and
then
the
cash
would
be
an
additional
part.
On
top
of
it
just
the
way
that
they've
talked
about
it.
That
would
resonate
with
them.
You
know
first
step
we're
getting
them
all
from
the
same
place
and
then
the
next
step
is.
We
have
that
speed
inducing
caching
service
I.
D
I
want
to
add
that
something
on
this
I
think
if
we
proceed
horizontally
so
adding
if
the
first
type
of
feature
to
every
package
is,
for
example,
just
proxying
right,
we
have
less
risk
to
stumble
in
on
something
that
we
release
the
full
chain
of
service
for
NPM
and
now
for
some
reason,
we
realize
it
on
Khan
and
me
that
architecture
is
not
it's
not
available
right.
Instead,
if
we,
if
we
move
by
step,
we
will
always
be
aligned
and
discovered,
is
no
problem
simultaneously,
more
or
less.
A
That
makes
that
makes
architectural
sense.
I
guess
my
initial
thought
just
to
play
devil's
advocate
was
we
can
measure
what
is
the
impact
of
solving
this
for
our
most
popular
registry?
Like
do
we
see
a
significant
significant
increase
in
usage
and
and
in
and
people
wanting
to
sign
up
for
the
ultimate
feature,
and
but
I
am
sensitive
to
wanting
to
roll
it
out.
Logically,
maybe
we
can
meet
in
the
middle
and
do
two
or
three
package
managers
and
not
five
of
the
just
simply
forwarding
requests
and
passing
them,
and
then
we
could
move.
D
G
Don't
we
have
this
non-applicability
problem
with
future
types
of
package
managers
like,
even
even
if
we
could
verify
that
all
package
managers
we
support
now,
can
do
everything
that
we
want
NPM
to
do.
We
have
unknown
future
package
managers
which
could
have
different
sort
of
limitations
in
sort
of
different
attributes,
so
does
doing
it
horizontally.
G
E
A
But
I'll
another
benefit.
I
like
of
focusing
on
NPM
for
like
a
few
months
is
the
product
leadership
team
has
asked
us
to
pick
a
North
Star
metric
for
like
per
quarter.
That
will
measure
and
evaluate
ourselves
on
so
I
like
the
idea
of
using
maybe
something
like
number
of
NPM
packages
pushed
and
pulled
or
just
pushed,
and
then,
if
we
invest
in
NPM,
we
can
see
at
the
end
of
that
three
month
cycle.
What
was
the
impact?
Did
this
help
us
grow
revenue?
Did
this
help
us
grow
adoption?
A
Okay,
now
see
if
we
can
repeat
that
for
Maybin
or
you
get
and
then
restart
the
process,
that's
kind
of
where
my
initial
thinking
was
I
mean
it
sounds
like
there
is
some
risk
associated
with
that,
but
we
won't
be
able
to
mitigate
all
of
that
risk
regardless
I
could
go
ahead.
I
didn't
my
stuff,
you
see,
I
can
select
and
I
finished.
Oh.
C
Yay
so
now
I
was
going
to
say
that,
like
logically,
if
we,
if
we
already
have
in
the
instances
of
package
managers
or
package
repositories,
we've
already
implemented,
we
already
have
variation
there.
That
could
mean
that
implementation
of
this
functionality
is
potentially
problematic
implementing
it.
E
I
think
one
thing
that
we
could
ask
users
is
like
which
what
what
what
causes
them
wait
times
like.
We
know
that
when
people
use
CI
and
they
and
have
to
wait
for
the
node
image
to
download
every
time
that
that
causes
a
backup
and
the
dependency
proxy
fixes.
That
so
is
there
the
same
thing
for
node
or
for
maven,
and
if
so,
you
know
like
which
one
would
have
the
biggest
impact
and
that
can
kind
of
determine
which
one
we
move
forward
with.
First.
A
Looking
at
the
data,
I
could
see
that
many
more
packages,
NPM
packages
are
pulled
then,
and
then
it
so
I
think
we
see
around
absolutely
saw
over
10,000
NPM
packages
pulled
yesterday,
which
is
really
cool,
whereas
maven
and
maybe
like
less
than
400
that
are
pushed,
whereas
mavens
the
opposite.
We
see
thousands
that
are
pushed
and
less
that
are
pulled.
So
it's
that's
why
I
thought
it
NPM
would
be
a
good
first
test
just
because
we
see
the
most
that
are
being
pulled,
so
those
may
be
the
greatest
opportunity
to
just
speed
up
pipelines.
I.
E
A
And
speaking
of
expanding
this
right
now
for
the
caching
images,
we're
only
caching
images
from
docker
hub
I
know
right
now,
we're
in
feature
freeze
in
terms
of
adding
container
registry
functionality.
But
can
we
is
it
possible
to
add
images
that
are
hosted
in
the
gitlab
container
industry
to
have
those
be
cached
as
well.
G
G
If
how
100%
applicable
this
is
to
this
use
case,
I'm,
not
sure
it's
usually,
it's
definitely
meant
to
be
a
local
service,
local
to
an
installation.
So
I
don't
know
if
s
something
that's
applicable
to
get
live.com
for
instance,
but
it
seems
like
something
that
could
be
used
for,
like
a
self
managed
instance,.
A
Yeah
I've
seen
some
I've
been.
Oh
man.
Well
time
is
coming
up
really
fast.
Okay,
I
I'll
skip
the
docker
conversation
and
just
say
like
another
aside
from
rolling
this
feature
out
when
we
think
about
making
this
feature
more
visible
for
people
making
it
so
that
people
are
aware
that
it
exists
and
then
that
it's
really
easy
to
use,
especially
from
CI
I.
Think
Nick.
You
had
a
comment
on
the
agenda.
Do
you
want
to
vocalize
that.
F
Yes,
I,
my
client
will
say
to
enable
usage
of
the
dependency
proxy
as
it
stands
right
now.
It
really
is,
as
Steve
says,
you
just
add
a
year
out
your
gait
lab
CI
young
file,
so
my
Forte's
being
like
we
could
automate
that
all
make
that
easier
for
the
UI
actually
visibly
or
forcibly
suggest
this
to
people
like
if
they
have,
if
they're
on
ultimate
and
the
dependency
proxy
is
available
in
their
environment
except
to
etc.
We
can
display
a
message
saying
speed:
you
can
speed
up
your
build
by
enabling
the
dependency
box.
F
A
You
mean
like
a
like
a
you,
could
use
a
word
in
your
Yama
file.
That
would
call
the
dependency
proxy
AG
right
now
we
do
things
like
for
artifact
expiration.
You
could
say
expire
in
seven
days
and
get
lab,
interprets
that
as
well.
You're
actually
saying
is
expire.
All
you
know
we're
translating
basically
the
get
lab
API
to
a
simple
text.
Could
we
do
that
for
the
dependency
protein
you
mean
I.
F
Mean
well
yeah.
That
could
be
an
alternative
way.
It
sounds
like
it's
possible
to
expose
what
I
what
my
intention
was
with.
That
idea
was
not
to
have
anything
in
the
gamma
file
at
all,
so
that
the
yanil
file
isn't
what
is
dictating
the
use
of
the
dependency
proxy.
So
there's
a
setting
that
lives
somewhere
else
that
you
turn
on
or
off
and
can
be
managed
in
a
number
of
different
ways
and
that
setting
because
otherwise
you're
going
to
have
to
make
commits,
is
going
to
affect
your
get
history.
F
C
But
I
guess
my
wonder,
word
from
a
user's
perspective.
If
there's
any
concerns
around
where
you
know
just
having
the
dependency
proxy
always
on
like,
what's
the
what's
the
consideration
from
a
user's
perspective,
whether
they
would
want
that
or
not
like
I
mean
clearly,
let's
say
it's
operating
effectively
and
there
aren't
any
issues:
bla
bla,
bla,
bla
everything's
working!
Well,
why
would
you
not
have
it
turned
on
and
so
I
wonder
whether
like
in
this
case,
just
to
sort
of
flow
in
from
next
thought
process
here
is
to
say
once
you're.
C
D
But
we'd,
like
the
dependency
proxies,
something
is
senior
to
attach
every
caching
layer.
You
really
need
to
switch
to
turn
it
off
and
because
you
know
it
can
be
one
of
the
t-nut.
You
want
to
do
like
cut
it
off
and
go
fresh
and
you,
for
example,
that
like
to
have
a
pipeline
that
say
if
the
main
Bev
line
fails
around
the
second
with
the
cashing
off
and
see
if
these
actually
solve
the
problem
so
and.
C
That's
that
that's
totally
fine,
but
is
that
the
same
was
just
invalidating
the
cache
and
having
it
refreshed
or
is
the
site
permanent
setting
like
if,
in
that
scenario,
we're
really
talking
about
having
functionality,
we
just
sort
of
you
know,
invalidate
the
cache
have
a
tree,
pull
everything.
That's
something
we're
already
talking
about.
Is
that
the
same
functionality
like
I?
Your
point
is
correct:
100%
I
know,
we've,
probably
all
in
there
where
we
like
this
cache
is
weird.
C
A
What
are
you
expecting
to
see
as
a
as
a
user
if
you're,
using
something
from
the
cache
I
really
liked
Nick
opened
an
issue
that
would
say
something
like?
Oh,
you
just
saved
this
much
time
using
the
dependency
proxy
or
you
know,
maybe
even
it's
it
happens
once
a
week.
You
get
a
notification
saying
you
decreased
your
build
times
by
50%
by
using
the
dependency
parts
you
keep
it
up
or
something
like
that
like
is
there
anything
else
that
you're
expecting
to
see
it?
A
B
Would
you
really
but
Kelly
I
would
say
the
users
that
I've
talked
to
you
about
this?
It's
been
pretty
light
and
as
a
user
UX
person
I'm
definitely
saying
some
research
is
in
the
future,
but
that's
how
they
talked
about
it.
They
don't
really
care.
What's
in
it,
they
just
want
their
pipelines
to
run
faster
and
be
more
stable
and
then
they're
really
happy
if
they
never
have
to
think
about
it
again.
That's
the
dream
state
as
I've
understood
it
I,
don't
know.
Tim
you've
had
similar
reactions
as
you
talk
to
users
about
it.
I.
A
Haven't
talked
to
too
many
people
about
the
dependency
proxy,
to
be
honest,
I
think
that
could
be
worthwhile
I.
The
few
people
I
have
spoken
to
have
had
that
similar
sentiment
and
I
think
a
lot
of
the
concerns
come
around
when
it
comes
to
you
like
well,
how
do
I
know
that
it's
using
the
right
image
or
a
package?
A
C
But
at
that
point
like
do
we
do.
We
think
the
idea
of
just
having
retention
policies
in
the
cache
is
kind
of
like
a
TTL
in
the
cache
is
the
way
to
handle
that,
like
I,
think
there's
some
considerations
around
how
we
think
about
a
cache
in
terms
of
that.
What
we're
doing
right,
like
so
I'm
building
code
and
I,
have
a
particular
version
that
I'm
always
pulling
should
that
go
away
ever?
Should
that
always
be
in
the
cache?
C
If
that
that
there's
a
security
patch
to
that
particular
version,
that's
released
on
the
server
that
I,
auto
update
to,
but
I'm
still
pulling
the
sort
of
dodgy
version
with
problems,
because
it's
in
my
cache
that
never
gets
invalidated
is
that
a
thing
you
know
is
that
early?
We
want
to
account
for
if.
H
C
Yeah
I
think
I
mean
the
point.
There
is
yeah,
there'd
be
a
new
version,
but
if
you're
pinning
versions
to
a
specific
version
for
your
local
instance
and
that
version
exists
in
the
cache,
it's
gonna
go
get
that
version
from
the
catch
right,
and
so,
if
I
we
permanently
never
remove
them.
That
would
require
a
manual
action
from
an
administrator
to
figure
out
what
happened.
So
do
you
want
them
to
have
a
cache?
That
is
just
the
TTL.
It's
basically
like
hey.
C
A
Been
leaning
towards
thinking
about
it
that
way,
setting
up
I,
think
I
forget
what
I
wrote
in
the
issue,
specifically
if
it
was
30
or
60
or
90
days,
but
basically
just
emptying
anything
out
anything
from
the
cache
that
hasn't
been
used
and,
let's
say
30
days,
just
emptying
it,
because
the
worst-case
scenario
is
it's:
just
gonna
go
fetch
it
and
it's
not
like
it's.
Nothing
is
gonna
break
I'm
really
concerned
about
getting
into
a
similar
situation.
We
were
in
with
the
container
registry
storage,
so
I
thought
we
could
just
handle
this
early
on
nico.
A
D
I
mean
sometimes
you
have
time
constraints
right.
You
may
have
stopped
a
timeout,
but
that's
definitely
a
first
approach
is
is
good.
Maybe
a
second
approach
will
be
like
expired
stuff
that
are
not
touched
it
even
like
after
one
week.
If
they
are
not
it,
you
trash
them
and
just
keep
stuff
that,
like
is
kept
being
pulled
down.
It
will
also
save
the
bandwidth
of
keep
transferring
it
back
again,
because
if
you
something
that
is
used,
you
will
go
pick
it
up
again
as
soon
as
you
dropped
it
right.
C
But
that's
the
that's
the
lens
upon
the
same
problems
and
were
like
you
have
an
item
in
there
that
you
know
have
used
or
individually,
and
it's
just
the
wrong
things.
It's
a
security
consideration
right,
I
mean
it
like.
So
in
my
understanding,
which
could
be
like
off
base
here,
a
little
bit
is
that
one
of
the
big
concerns
we
have
around
is
that
we
have
independent
tests
that
are
setting
up
and
tearing
down
in
a
build
process
and
they're
independently
going
getting
the
same
thing.
C
And
now
there
are
settings
to
mitigate
that
by
storing
some
of
those
locally
and
you
can
pull
them
locally
but
like
if,
in
a
single,
build
we're
pulling
the
same
thing
multiple
times,
we
can
invent
validate
the
cash
off
the
build
right
and
then
it's
gone
like
and
does
that
solve
the
big
part
of
our
users?
Problems
at
that
point,
but
as
far
as
I
think
the
fundamental
question
here,
Tim
was:
what
do
people
want
to
see?
I
think
you
definitely
want
some
indication
of
like
one's
cashed
can
I
validate
the
cash.
A
Some
policies
like
never
pull
a
version,
that's
not
marked
stable
or
you
know,
what's
something
or
never
people
may
want
to
say
never
pull
something
that
has
a
license
of
X
or
something
like.
Maybe
some
additional
policies
were
on
that
I
I
have
this.
This
is
not
really
a
tech
focus,
but
my
friend
used
to
work
at
a
car
wash
and
he
noticed
that
he
would
get
significantly
higher
tips
when
he
told
people
what
he
did
like
when
he
would
hand
him
their
keys
and
he
was
like.
A
Oh
I
just
want
you
to
know,
I
wiped
down
the
wheels.
I
you
know
armored
all
the
tires
I
did
and
he
noticed
when
he
would
do
that.
That
people
had
would
always
tip
more
and
I
kind
of
feel
like
for
the
dependency
proxy,
since
the
feature
will
be
essentially
in
the
background
running,
especially
if
we
auto
enable
it.
A
C
F
Was
just
gonna
can
I
suggest
something
really
that
might
be
really
really
stupid,
totally
wild,
but
so
be.
This
is
this
and
we've
been
talking
about
packages
and
just
proxying
packages?
This
entire
time
is
basically
how
we're
going
to
handle
caching
of
these
packages
by
the
sounds
of
things,
but
what
if
we
could
cache
a
stage
in
a
gitlab
CI
build?
So
let's
say
you
K
a
stage
and
one
of
your
stages
is
SAP
environment
and
set
in
parts
setting
up
the
environment,
would
download
all
ya
node
modules,
gmpm
tasks.
F
All
of
that
and
then
get
lab
yama
when
you'd
mark
that
as
your
cache
and
then
that
would
then
create
a
docker
image
which
we
would
store
in
our
container
registry
and
wherever
we
store
our
cached
images
and
then
for
every
other
stage.
Thereafter,
it
would
run
on
top
of
that
image
or
we
could
offer
configuration
options,
but
then
that
stage
would
only
ever
be
created
when
so
that
setup
image
would
only
ever
be
created
once
until
some
kind
of
thing
invalidates.
It
say.
F
G
G
Before
we
do
that,
because
that
was
my
first
thought
is
like:
oh
no,
because
that's
gonna-
if
because
these
are
something
way,
semi
ephemeral
is
that
I
think,
like
babies,
have
definite
lifetimes
you're,
not
gonna.
You're,
not
gonna,
be
like
oh
where's.
The
cash
to
mission,
my
build
environment
from
two
months
ago,
I
really
needed
that
these
are
gonna
have
like
a
definite
lifetime
and
so
being
able
to
clean.
These
up,
I
think
is,
is
really
important,
especially
if
they're
widely
adopted.
That
could
cause
a
lot
of
well.
C
Highly
I
think
I
think
what's
happening,
sorry
to
interrupt,
but
I
think
what's
actually
happening
here.
Is
we're
already
doing
this
and
creating
these
images
it
would
just
be.
We
prefer
them
in
all
the
stages
in
the
test,
because
this
they're
already
been
created
and
not
deleted,
as
in
the
registry,
as
it
is
right.
A
And
yeah
Nick.
That's
a
really
good
I,
wonder
where
the
caching
that
we
have
in
pipelines
now
like
artifact
caching
overlaps
with
the
dependency
proxy
is
a
really
good
question,
because
I
guess
I've
been
thinking
about
the
dependency
proxy
has
developed.
One
of
the
values
is
yes,
the
caching
is
good,
but
also
liked
niko
mentioned
earlier
you.
A
Okay,
so
I
think
we
are
have
gone
over
our
time
I.
Just
maybe
there's
a
lot
of
things
that
we
discussed
going
back
to
the
very
beginning.
We
have
some
work
to
do
on
the
maturity
targets
and
reviewing
those
and
some
follow-up
items
that
should
be
coming
in
in
the
next
couple
of
weeks
and
then
on.
The
dependency
proxy
I
have
to
make
I'm
leaning
towards
moving
forward
with
NPM.
A
To
now
that
we've
solved
the
remote
repositories
and
I
move
it
in
to
solve
some
problem
with
the
dependency
proxy
and
then
go
from
there
and
see
how
we
could
roll
it
out
further.
So
I
have
some
work
to
do
and
issue
creation
like
that
and
I
will
say:
Steve
is
on
fire
today.
As
with
his
tag,
what
his
market
is
the
chats
inside
the
group
chat
have
been
very
funny:
distracted,
I.
C
Feel,
like
I've,
missed
him
now
to
taking
notes
in
my
game,
not
paying
attention
I'm.
Sorry
I'm
really
have
to
go
breed
these
back
and
have
a
giggle
good.
What
is
there
some
action?
We
can
take
you
with
Nick's
idea,
I
really
like
that
idea
and
sorry
I
know
we
have
to
finish
out,
but
I
don't
want
to
I.
Don't
want
to
have.
This
goes
missing
in
action,
because
I
think
that's
yeah.
A
A
B
Dad
we
have
our
first
cross
stage,
think
big
tomorrow,
and
one
of
the
things
is
how
we
can
accelerate
and
speed
up
people's
pipelines.
So
I've
already
made
a
comment
about
how
the
dependency
proxy
could
help.
So
we
may,
if
your
issue
comes
together
quickly
and
ethnic,
we
could
bring
it
up
during
there
and
have
the
conversation
with
the
CI
team
and
the
strategist
and
maybe
plug
in
some
awesome,
think
bigness
and
be
like
our
think.
Big
was
awesome.
Had
this
idea
for
this
think
big
over
here
and
it'll
be
well-received.
A
All
right
well,
thank
you,
everyone.
This
was
really
helpful
and,
as
usual,
nikka
and
myself,
if
you
create
any
issues
that
come
out
of
this,
just
be
sure
to
use
the
think
big
label
just
because
it's
a
good
way,
abouts
marking
that,
where
the
these
the
issues
come
from
and
creating
visibility
for
folks
who
can't
make
these
calls,
but
other
than
that
I
think
I
will
stop.
Recording
and
thanks.
Everyone
talk
to
you
soon.