►
From YouTube: Package: Think BIG 12-04-19
Description
In which we talk about project level registries, metrics and review designs
A
B
B
We
have
the
ability
to
just
push
packages
to
a
project
without
having
to
have
any
sort
of
naming
restriction
or
any
sort
of
connection
to
the
whatever
code
is
in
that
project
at
all
whatsoever,
and
so
there's
that
example
project
that
I
have
up.
There
called
the
package
registry
project
where
I
didn't
push
any
code,
but
I
published
a
handful
of
packages
from
various
projects,
none
of
which
were
even
pushed
to
get
lab,
and
that
was
just
sort
of
like
an
interesting
epiphany
of
like.
Is
this
useful?
B
So
on
the
project,
so
there's
no
there's
no
code
or
anything.
But
if
you
go
to
the
packages
list,
page
you'll
see
that
there's
I
think
six
different
packages
pushed
so
I've
got
two
versions
of
an
NPM
package
called
alert
package
and
then
another
NPM
package
called
NPM
publish
test.
There's
a
maven
practice,
though
there's
a
few
different
maven
packages
that
are
from
various
places
with
different
names.
B
So
those
are
all
completely
different
packages
from
different
code
bases
and
all
I
did
was
like.
For
example,
NPM
I
went
into
the
project
added
the
published
config
and
pointed
it
to
this
project,
updated
my
NPM
RC
with
my
auth
token
and
then
pushed
it.
I
did
NPM
publishing,
and
here
it
is
and
pretty
much
the
same
deal
with
maven
may
even
update
the
to
the
pom.xml
file,
if
I
remember
and
quickly
and
pushed
it
to
this
location,
and
so
that
kind
of
just
is
an
interesting
idea
of
like
I
could
create
a
project.
B
That's
maybe
a
public
project
like
this,
and
it's
not
actually
a
project
in
any
way.
But
it's
pretty
much
acting
as
my
registry
for
all
of
my
public
packages,
if
I
wanted
it
to
or
I,
could
create
a
private
project
and
push
all
of
my
packages
that
I
want
to
be
private
and
they
will
all
be
seen
as
sort
of
like
private
packages
and
one
of
the
sort
of
use
cases
that
I
kind
of
talked
a
little
bit
about
with
Tim
was.
B
We
could
like.
Someone
could
conceivably
set
up
a
pipeline
that
automatically
publishes
packages
from
other
projects
to
a
private
project.
So
like
something
like
this,
where
all
of
the
packages
live
its
private,
only
one
or
two
people
maybe
can
access
it.
And
those
are
the
people
that
have
the
authority
to
like,
validate
or
verify
a
given
package
and
then
once
they've
done
that
they
could
maybe
kick
off
a
pipeline
from
here.
B
B
A
Okay,
so
you
had
me
or
sorry,
you
had
me
with
the
project
and
you're,
pushing
these
packages
here
and
it's
a
private
project,
but
then
I
got
lost.
How
would
you
do
it
creating
moving
them
to
a
public
project,
because
you
have
all
these
individual
projects
that
are
building
these
packages
and
publishing
them
here?
How
would
they
then
get
published
to
a
public
project
where
you
share
them?
No,
no,
that's
your
I
mean
I
haven't
like
done.
B
This
yet
so,
but
but
there
would
be
some
sort
of
another
CI
job
somewhere,
either
in
the
original
project
or
maybe
somehow
tied
into
this
project.
That
allows
the
sort
of
like
the
admin
users
of
the
packages
to
publish
them
to
another
place.
If
that
makes
sense
like
I'm,
not
exactly
sure
how
it
worked.
But
I
feel
like
it's
something
we
can
do.
C
Steve,
did
you
actually
try
to
pull
them
again
down
with
that
package
manager,
because
I'm
afraid
that,
due
to
the
mismatch
of
scope,
then
you
will
not
be
able
to
pull
them
down.
You
can
pull
them
out
because
that's
a
different
mechanism,
but
the
pulldown
actually
relies
on
the
package
name,
and
so
the
scope
will
be
off
I'm,
not
sure.
B
About
that,
don't
try
I
think
with
so
with
NPM,
so
with
NPM
I
think
it
would
still
work.
I
should
test
that.
It's
a
good
point
because
I
believe
the
way
I'm
cam
works
is
it
will
find.
So
this
is
under
the
s
Abrams
namespace,
so
it
will
find
all
packages
in
the
s
Abrams
namespace,
and
then
it
will
find
the
package
that
has
the
same
name.
It
doesn't
necessarily
have
to
do
with
the
project
itself.
C
Okay,
so
if
that's
true,
we
may
want
to
consider
to
touch
the
documentation,
because
I
was
going
through
this
recently
because
I'm
trying
to
have
actually
a
pipeline
that
published
some
of
my
view,
my
open
source,
stuff
inside
or
reject
registry,
and-
and
we
clearly
state
that
the
package
should
have
the
scope,
is
the
group
or
the
user.
And
then
the
name
of
the
package.
There
right.
D
C
B
E
C
Just
at
least
for
NPM
I
think
this
whole
place.
The
part
that
is
defined
with
the
add
so
when
you
do
add
full
slash
buds,
that's
the
that's!
What
NPM
I
think
is
a
school
right,
but
in
our
case
we
will
be
like
prefixing
it
with
the
legs,
SS,
Abrams
or
or
whatever
test
group
correctly.
But
this
means
that
there
can
be
your
registry
with
at
full,
slash,
pads,
and
my
registry
would
add
four
slash
pads
right.
This
is
this
okay
in
all
the
cases.
So
yes,
so.
B
A
B
I
mean
first
I
should
I'll
check
to
make
sure
that
I
can
install
things
as
I
expect,
but
assuming
that
that
works
I,
guess
we
just
kind
of
have
to
decide
whether
or
not
we
need
to
like
validate.
If
this
is
useful
in
some
way
like
it
seems
kind
of
like
a
shortcut
to
creating
sort
of
like
you
know,
group
level
and
instance
level
registries,
which
I
don't
know
if
that's
useful
or
not
I
think
that's
worth
validating
so.
D
I
can
I
can
jump
in
here
a
little
bit.
I
think
that
group
level
and
instance,
level
view
and
organization
is
something
that
our
users
are
looking
for,
especially
at
the
larger
sized
organizations.
They
would
like
to
be
able
to
say
this
is
our
official
registry
of
all
packages
and
then
the
project
level
package
registry
seems
more
like
a
these.
Are
the
packages
needed
to
function
at
the
project
level,
and
then
it
goes
out
to
that
shared
group.
D
Just
from
the
usability
standpoint
of
having
like
a
project
that
is
devoted
to
being
a
registry
kind
of
feels,
I'm
gonna
steal
a
little
bit
of
Haley's
language,
but
it
looks
a
little
here
hacky
and
we
want
to
make
sure
they
we're
offering
that
it
is
in
a
good
way,
so
I'm
wondering
if
we're
so
close,
there's
a
way
to
like
take
it
and
just
move
it
like
an
inch
and
then
it'll.
Be
that
really
robust
experience,
but
I
can
validate
that.
It's
something
they're
looking
for
yeah.
B
Like
the
the
thing
that
made
me
think
was
that
like
in
reality,
unless
a
package
is
built
by
a
pipeline,
there
is
no
connection
between
a
packaging
project
at
all
like
ever,
except
for
the
fact
that
the
package
record
might
have
a
project
ID
connected
to
it,
but
that
still
technically
doesn't
matter
because,
as
you
can
see
here,
all
six
of
these
packages
are
attached
to
this
project,
but
they
don't
have
to
do
with
what
the
project
has
to
do
it.
So.
F
And
I
get
to
talk
about
the
UX
a
bit
I
think
it's
not
necessarily
bad
right
now.
I
think
we
could
eventually
smooth
it
out.
It
would
be
I
think
it'd
be
valuable
to
document
this
and
advertise
it
and
and
then
see
like
what
people's
workflow
actually
is
when
they
are
using
that
and
then
we'll
have
a
better
understanding
of
what
action
needs
to
be
done
to
make
this
more
of
a
first-class
kind
of
experience,
rather
than
something
that
kind
of
happens
to
work.
B
And
the
other
thing
that
I
was
going
to
mention
before
I
forget
of
where
this
could
be
useful
is
so
we
have
a
lot
of
like
naming
restrictions
at
the
instance
level,
which
we
want
to
eventually
kind
of
work
through
and
fix.
But
this
kind
of
proves
that
if
I
have
code
in
a
different
place
on
get
lab
or
on
github
or
on
a
completely
different
area
and
want
to
move
my
packages
to
get
lab,
but
don't
want
to
worry
about,
like
how
am
I
gonna
have
to
rename
these
am
I.
B
Gonna
have
to
do
something
else.
I
can
just
change
my
remote
on
my
existing
code
and
push
the
package
to
get
lab
and
then
worry
about
the
rest
later.
So
it
could
be
kind
of
like
a
simple
first
step
to
help
with
that
migration
process
to
an
extent
because
it's
not
dependent
on
the
code
living
in
the
same
place.
At
the
same
time,.
A
Yeah
I've
great
point,
Hayley
I,
think
documenting
this
and
showing
it
off
like
if
we
could
put
in
our
documentation.
How
do
you
set
up
your
own
project
as
a
private
registry
or,
like
example,
workflows,
and
we
walk
through
people
how
to
do
it?
How
to
create
their
pipelines?
How
to
pull
down
the
packages?
I
think
that
would
be
really
useful
to
start,
and
then
we
can
get
feedback
from
people
saying
this
work.
This
didn't
work
or
it's.
This
is
missing.
A
Maybe
the
step
before
that
is
for
us,
like
you,
said
just
to
test
pulling
it
down
into
like
a
quick
work,
flow
diagram
that
we
could
all
view
and
and
wrap
our
heads
around
of
like
here's.
You
have
many
projects
and
subgroups,
but
here's
your
your
repository
project
and
then
here's
how
you
pull
and
push
things
how
it
works.
Logically,
I
think
that
would
really
help
to.
C
C
So
if
we
advertise
this,
can
we
actually
generate
a
way
where,
if
I
want
Steve,
do
not
publish
any
package?
I
just
go
on
my
registry
and
programmatically,
because
I
can
do
that
with
two
line
of
code
publish
dummy
packages
with
all
the
names
that
I
know
that
you
use
and
it's
not
able
to
use
our
registry
anymore.
Well,.
C
B
C
Not
a
problem
yeah,
but
so
the
reason
why
I'm
talking
about
this
because
I
see
this
kind
of
bickering
happening
with
other
packages,
so
say
that
you
have
the
organization
foo
right.
Am
I
your
competitor
buzz
now
I'm
publishing
all
my
ad
food
under
my
bars
and
completely
block
you
to
publish
packages
right?
It's
connections.
B
Yeah,
that's
correct
for
NPM
and
yeah.
That's
something
that
we
want
to
fix
with
NPM
by
properly
setting
up
the
project
group
and
instance,
level
remotes
right
now
that
is
not
set
up
on
NPM
at
all,
so
like
with
maven
you,
you
could
have
different
remotes
for
different
projects.
So
at
the
same
company
one
project
can
have
a
package.
Foo
Baz
and
another
project
can
also
have
the
same
package,
foo
bass.
And
so
that's,
let's
do
the
project
level
aspect.
B
C
E
Got
like
if
anyone's
that
through
the
iteration
office
hours
by
seed,
there
was
a
really
strong
push
to
just
document
it
and
we're
an
open
source
company.
You
can
read
our
code
and
the
fact
that
no
one's
figured
this
out
using
this.
We
shouldn't
be
like
hiding
it
to
avoid
the
chance
that
someone
might
have
problems
with
the
thing.
That's
there
I'm
not
suggesting
that
we
go
and
say,
hey
everyone.
This
is
a
perfect
thing.
You
know
it
could
just
be
an
MVC
to
say
look!
E
This
is
a
thing,
that's
possible
for
people
that
think
they
might
want
to
use
it.
Please
give
us
feedback,
and
that
would
be
in
the
form
of
documentation.
That
seemed
like
a
good
first
step
here.
Do
you
agree
with
that
Tim
in
terms
of
the
iteration
value
or
not
so
much,
because
I
could
be
overstepping.
E
That
would
be
just
described
that
this
is
a
thing,
maybe
in
a
way
that
you've
set
it
up
Steve.
Let
people
know
that
it's
possible.
Let
people
know
that
there's
a
chance
that
there
could
be
conflicts
and
problems
with
the
package
naming
and
they
could
be
problems
in
that
way.
But
for
organizations
where
this
works
we
immediately
provide
a
feature,
that's
kind
of
viable,
and
then
we
figure
it
out
from
that
I
mean
to
agree
with
Haley
on.
B
That
front
as
well,
and
just
to
be
clear
that
the
naming
conflicts
don't
have
to
do
with
this.
The
naming
conflicts
exist,
regardless
of
where
you
publish
them.
So
with
NPM.
If
I
publish
to
one
project,
that's
si
Abrams
and
the
projects
is
foo
and
I
published
package
baths
and
then
I,
go
and
publish
to
another
project
and
try
to
publish
Baz
like
I
can't
do
that.
Even
if
it's
like
five
subgroups
down
I
cannot
have
the
same
package
name
currently,
so
it
doesn't
have
to
do
with
where
you
publish
it
at
all.
E
So,
like
you
know,
we
can
look
at
it
and
say
how
do
we
make
this
better
and
I
think
we
should,
because
it's
obviously
I
mean
I
expect
to
have
people
go.
Oh,
you
know,
do
everything
in
there
and
then
something
catches
fire,
but
if
it's
still
there
like
trying
to
hide
it,
it's
weird
to
me:
it
doesn't
feel
very
get
lab'.
This
sort
of
like
like
try
and
keep
a
secret
about
how
someone
could
be
using
the
product
in
a
way
that's
valuable
to
them
right,
that's
my
opinion
and
I.
B
F
B
A
B
A
And
if
we
create
a
demo
video,
we
could
share
it,
we
could
post
it
to
unfiltered
and
we
could
get
feedback
on
it
on
YouTube
like
that,
might
even
be
a
shorter
path
like
just
you.
We
can
record
a
video
you
and
I
of
you
walking
me
through
how
you
set
this
up
and
why
it's
useful
and
a
couple
of
example
use
cases
that
could
be
like
a
good
first
step
and
maybe
it'll
clarify
the
documentation.
We
have
right.
A
Next
II
that
I
really
like
that.
That
idea,
it's
really
helpful
and
thanks
for
bringing
that
forward,
so
we
have
two
more
items
on
the
agenda:
I
added
one
to
talk
about
metrics.
So
in
the
past
several
months,
we've
seen
steady
growth
and
we're
looking
at
page
use
for
package
in
the
container
registry
if
they're
steadily
going
up,
but
it's
also
making
it
clear
that
we
need
more
and
better
metrics
to
make
decisions
still
feels
like
we're
in
the
phase
where
we
would
want
to
where
we're
measuring
adoption
and
usage.
A
But
ideally
we
get
to
the
point
where
we
can
launch
a
feature
like
docker
tagging,
expiration
policies
and
the
next
milestone,
we'll
know
to
people
use
this.
Where
did
they
get
stuck
on?
Is
there
something
that
we
can
improve,
or
do
we
need
more
data
and
go
back
and
forth?
So
we
are
still.
You
know
if
you,
some
of
you
may
know
the
challenges
of
collecting
data
at
get
lab
and
it's
it
hasn't
been
easy
and
there's
some
parts
of
the
process
that
are
confusing,
but
I
didn't
want
to
just
talk
about
what
metrics.
A
We
think
that
we
should
be
measuring
success
and
failure
for
our
stage
and
what
do
we
when
we
add
a
new
feature?
What
is
the
data
that
we
should
always
make
sure
that
we
absolutely
add
right
away
and
then
how
do
we
move
faster
or
more
efficiently?
I
should
say
on
defining
the
data
instrumenting
it
and
then
making
sure
that
it
shows
up
in
the
dashboard
and
is
visible
to
the
team.
A
So
I
created
an
epoch
that
tracks
all
of
our
data
collection
and
reporting
issues
and
I
created
this
spreadsheet
to
start
on
a
list
of
metrics
that
we
are
tracking
or
would
like
to
track
and
then
I
think
May
I'm
wondering
what
would
be.
Maybe
I'll
just
pause
there
and
get
some
real
feedback.
What
I
just
add.
B
A
We
have
to
have
a
caveat
that
all
our
data
is
grossly
understated,
because
we're
really
not
including
anything
in
that
metric
except
for
I-
think
it's
just
package
registry
enabled
so
it
doesn't
include
container
registry
enabled
it
doesn't
include
any
activity
from
any
of
the
API
or
from
the
user
interface.
As
well,.
A
The
reason
I'm
asking
is
I'm
I'm,
trying
to
figure
out
for
myself
like
when
we
think
about
our
stage
when
we
think
about
what
what
would
make
us
feel
successful.
Well,
what
data
would
you
see
that
you
would
that
you
could
say?
Oh
we're,
seeing
an
increase
in
usage,
we're
seeing
an
increase
in
adoption?
What's
like
the
metric
that
we
should
come
down
to
and
say
that's
one
of
our
KPIs,
if
we,
if
we,
if
we're
doing
well
in
that,
we
know
that
we're
doing
well,
overall
I.
B
How
much
like
how
often
are
not
I'm
going
to
start
often,
but
are
they?
Are
people
continuously
creating
packages,
because
I
could
see
a
lot
of
people?
You
know
they
create
one
package
like
maybe
for
fun,
to
see
if
it
works,
but
that
doesn't
mean
that
they're
using
it
regularly
we'd
want
to
see
if
it's
like
in
continuous
use
on
any
given
project.
A
A
C
If
we're
tracking
on
the
UI
there,
we
could
at
least
say
that
definitely
somebody
clicked
the
page
or
somebody
clicked
a
button
or
somebody
access
the
details
and
we
could
actually
have
different
events
for
what
is
Sunday
Pia
and
what
is
in
the
UI
and
start
measuring,
like
80%
of
our
user
used
the
API
to
do
everything
and
for
eighty
percent
use
the
interface
or
unbending
think.
Maybe
that
will
be
valuable.
I.
A
Like
that,
yeah
I've
been
kind
of
thinking
of
it
as
like,
we
have
these
general
adoption
metrics,
which
is
like
how
many
times
did
someone
do
a
thing?
How
many
times
did
some
I'm
like?
What's
the
difference
between
the
and
API,
but
then
also,
as
we
start
to
launch
specific
features,
I'm
interested
in
more
in
building
like
a
behavioral
analysis
of
those
new
features
so
like
as
an
example
for
the
doctor
expiration
policies
like
we
really
want
to
know
how
many
like
we
want
a
bunch
of
data
for
that
particular
feature.
A
We
want
to
know
how
many
people
enabled
or
disabled
the
feature.
We
want
to
know
how
many
people
changed
the
the
setting.
We
want
to
know
how
many
times
it
was
updated,
for
instance,
and
I,
think
the
idea
of
like
building
a
feature
and
then
thinking
about
the
use
case
for
that
feature,
and
then
tracking
a
funnel
through,
like
those
metrics,
would
be
really
valuable
that
that's
sort
of
the
more
advanced
case
that
I
would
like
to
get
to
and
I'm
sure
you
would
love
to
see
that
data
too
and
he's
designing
things.
Does.
B
Anyone
know
how
so
we've
got
like
event
based
metrics,
where
it's
like
we're
counting
the
number
of
times.
Someone
does
something,
and
then
we
have
something
like
the
exploration
policies
where
maybe
we
want
to
see
like
you
know
how
many
expiration
policies
have
been
changed
from
the
defaults
at
any
given
time?
That's
something
that
we
don't
need
to
necessarily
need
an
event
to
track.
We
just
need
a
query.
We
can
query
the
database
and
say
oh,
which
you.
B
E
The
daughter
team
quality
team
would
probably
be
the
two
points
of
call
their
data
team
is
a
little
bit.
You
don't
exactly
have
a
huge
team
right
now.
I
think
they
were
pretty
overloaded
with
a
lot
of
the
work
they
have
to
do,
but
the
quality
team,
particularly
cloud
Weaver's,
has
been
super
helpful,
a
lot
of
extra
queries,
but
in
terms
of
hats
of
a
pen-and-ink
code
that
might
be
worth
asking
in
development
or
something
like
that:
I'm
not
exactly
sure
how
to
adding
code
either.
A
It's
like
the
question
I
had
to
like
in
terms
of
okay.
Let's
say
Steve,
you
add
tracking
for
Conan,
and
it
goes
through
the
system.
It
shows
up
in
snow.
It
shows
up
in
snowplow.
How
do
we
get
it?
Added
to
the
dashboard,
should
I
be
responsible
for
that
it
seems
like
we're.
Not
gonna
get
the
support
from
the
data
team
to
like
continuously
add
metrics
for
us,
and
so
I'm
wondering
is,
should
the
should
product
developers?
A
The
way
I've
seen
it
work
in
the
power
at
the
p.m.
usually
maintains
those
dashboards
and
builds
those,
not
necessarily
the
developers,
but
I
could
probably
use
some
help
with
my
sequel,
refreshing.
It's
been,
it's
been
kind
of
a
while,
so
maybe
we
can
collaborate
on
it
for
a
few
metrics,
just
getting
the
initial
dashboard
built
and
then
I'll
be
up
to
speed
and
I
could
I'll
be
refreshed
on
my
sequel
skills.
B
A
E
Would
say
it's
better
if
you
do
async
team
I
mean
I'm
happy
to
help
that
I
can
do
a
lot.
A
sh
board
work
and
I've
worked
with
dashboards.
We've
already
got
some
happy,
elección
and
walk
through
this
with
you.
Obviously,
everyone's
welcome
to
come
and
like
be
involved
in
that
it's
not
like
a
you
know,
manager,
PM
type
situation,
it's
just
a
like.
How
do
we?
How
do
we
get
these
dashboards
set
up
so
that
they
useful
for
the
team
so
anyone's
welcome
to
show
up
to
that?
As
I
said,
okay,
I'll.
A
Be
awesome,
yeah,
I
think
if
we
could
just
get
a
few
reports
up
and
running
and
then
I
could
be
really
useful.
There's
still
a
lot
of
confusion
for
me.
I
met
with
the
data
p.m.
and
one
of
the
analysts
yesterday
I'm
working
on
it,
but
there's
still
a
lot
of
confusion
about
the
process.
For
me
at
least
yeah.
E
A
Well,
we
didn't
I
think
we.
My
original
question
was
what
metrics
do
we
think
are
really
important
like
how
do
we
measure
success
and
it
sounds
like
we're
just
saying
for
now:
we
think
that's
overall
usage
and
then
in
the
future.
What
we
think
would
be
really
valuable
is
if
we
can
use
datum
to
understand
if
a
feature
was
successful
or
not,
or
if
there
were
any
problems
or
anything
like
that,
and
there.
A
Think
that's
fine
tracking
at
the
product,
I
think
there's
a
technical
limitation
that
we
can't
currently
track
unique
users,
not
that
we
can,
but
not
that
we
can't
try
because
I
think
any
data
we
are
tracking
people
have
opted
into
I.
Think
it's
more
just
the
way
that
we're
tracking
the
data
we
don't.
We
can't
tie
it
to
a
session
or
unique
user.
It's
all
just
like
counts
of
events,
but
you
might
be
able-
and
some
of
you
that's.
E
I
think
we'd
wanna
like
to
me
I,
don't
know
if
people
feel
like
this
is
a
scenario
where,
for
each
of
our
different
sort
of
categories,
we
have
a
different
measure
of
what
we
deem
to
be
success
or
failure
right
I
mean
there's
a
Jedi
thing.
Is
it
there'd
be
a
general
sense
right,
because
if
I
can
upload
a
package
to
NPM
and
download
the
package
again,
that
could
be
one
measure,
but
it's
contained
a
registry
is
that
that
that
doesn't
necessarily
encapsulate
everything,
so
it
might
be
worth
like
talking
about
specific.
A
One
thing
I've
been
thinking
about
is
like
the
success
rate
for
each
service.
It's
like
for
the
dependency
proxy.
We
would
want
to
know
like
the
cache
hit
ratio
so
like
what
percentage
of
images
were
pulled
from
ended
up
pulling
from
the
dependency
proxy
versus
ended
up
pulling
from
docker
hub,
and
ideally
we
should
see
that
number
grow
over
time,
like
as
the
dependence
of
proxies
in
production.
A
We
should
see
more
images
being
pulled
from
the
cache
versus
you
know
not
being
pulled
from
the
cache
for
the
container
registry,
sometimes
I'm,
thinking
yeah
how
many
images
are
pushed,
but
also
like
how
many
images
failed.
How
many
errors
did
we
and
like
we're
tracking
page
views
to
the
container
registry,
but
we're
not
tracking
pages
of
500
errors?
E
E
I'm
gonna
get
a
bunch
of
misses
and
if
I
change
them
all
the
time,
remaini
early
development,
I'm,
switching
dependencies
and
stuff
like
that
I'm
you
might
get
a
heap
of
misses
and
then,
if
I'm
changing
the
dependency
around
I'd
seen
this
is
this
is
probably
an
edge
I'm
kind
of
thinking
along
the
lines
of
like
I'd
want
to
know.
We
made
a
request
for
this
proxy
I
failed.
It
was
a
mess.
We
pulled
down
the
dependency
that
we
were
trying
to
query
tryna
load
and
then
subsequently
we
got
a
bunch
of
hits.
E
So
it
was
the
miss
and
then
the
hits
that
were
useful
and
associated
with
a
specific
package
and
I
forget
I,
don't
know
actually
how
its
implemented
right.
Now,
whether
we
have
a
org
specific
or
a
group
customer
customer
group
project
level,
specific
cache
or
whether,
if
we're
pulling
down
a
version
of
the
package,
that
happens
one
time
and
then
everyone
likes
a
on
Gilad
com
gets
the
same
version
because
it's
the
same
version
is
they
uniquely
destructive
described?
They
have
to
be
I.
Think.
A
There
is
a
there's,
a
problem,
though,
because
I
really
wanted
that
same
information,
I
think
that'd
be
really
valuable,
but
again
we're
really
only
counting
events,
so
we
really
only
know
like
we
don't.
We
don't
know
that
Dan
during
your
early
development
process,
for
changing
the
dependencies
a
bunch
of
time,
so
everything
was
pulling
manually.
A
B
B
Can
you
explain
a
little
more,
maybe
like
what
use
cases
that
are
for
that
or
maybe
like?
If
there
is
a
way
we
can
take
it
that
usage-
and
you
know
like
make
our
way
to
being
able
to
create
some
of
those
metrics
cuz
I
feel
like
that's
one
thing:
I'm
not
like
I'm,
not
seeing
how
that
works,
necessarily
how.
B
E
A
Know
like
Steve,
did
this
thing
or
a
user
did
this
thing?
We
have
to
change
the
way
that
we're
doing
data
instrumentation
I,
think
that
was
the
idea
behind
pendo.
Why
we
wanted
to
track
that
because
it
gives
you
the
ability
to
sort
of
track,
that
user
level,
information
and
session
level
information,
but
I,
don't
think
that
we
can
do
that
in
our
current
implementation.
A
So
it's
something
that
the
telemetry
team
is
it's
working
through
I
met
with
Sid
yesterday,
who
said
ready,
not
said
our
CEO
and
who's,
the
PM
for
the
data
team
he's
new
and
he
was
saying
that
they're
working
through
this
so
they're,
you
know
the
in
case.
Everyone
doesn't
know
there
was
this
issue
where
we
tried
to
add
pendo
to
all
good
lab
instances.
It
didn't.
It
didn't
exactly
go
over
well
with
our
customer
base,
and
so
they
they've
since
then
they've
gone
back,
they've
gone
and
come
up
with
a
plan
for
why?
A
How
this
could
work,
how
we
could
add
this
and
how
it
could
make
sense
for
our
customers
and
they're
running
they're,
doing
them
doing
an
internal
review
and
then
they're
gonna
run
that
by
are
sort
of
like
customer
advisory
board
or
a
user
advisory
board
which
one
which
one
it
is
and
then
they'll
work
on
actually
adding
in
this
in,
because
this
functionality
is
really
important
because
we
are,
we
are
flying
blind
in
terms
of
behavioral
data
until
we
get
this
so
that
should
be
coming
out
soon.
Ish,
but
I
I.
A
Don't
think
that
they're
gonna
rush
it
out.
They
want
to
really
be
careful
so
that
that
is
really
what
we
need
to
get
to
that
level
of
data.
So
for
now
I'm
like
if
we
could
just
understand
even
just
general
trends,
then
when
we
have
acts
to
that
data,
we
could
start
asking
more
intelligent
questions
about,
like
okay.
Well,
now
think
about
zooming
into
the
user
level
or
to
the
instance
level,
and
how
do
we
make
better
decisions
with
data
at
that
level?
Generally,.
E
An
engine
I
would
say
that,
generally
speaking,
some
of
them
are
architectural
slash.
You
know
success
level.
Decisions
are
generally
going
to
be
an
aggregate
anyway,
and
one
would
hope
there
ain't
aggregate,
because
we've
really
good
enough
users
that
we
need
to
dig
into
specific
uses
that
we
might
probably
have
a
smile
problem
anyway.
But
you
know
using
that
educated
data
that
doesn't
have
issues
around
QPR
and
PII
is
just.
E
Of
cases
will
be
completely
sufficient
for
us
to
at
least
have
a
directional
sort
of
idea
of
what's
being
used
and
what
is
in
and
so
I
don't
I,
don't
think
we
should
be
considering.
This
is
sort
of
a
blocker
in
any
way
to
gathering
enough
data
to
help
us
start
making
better
decisions
around
what's
actually
being
used.
E
A
Good
son,
you
know
okay,
so
follow
up
steps
for
me.
I
think
what
will
be
great
is
we
have
recently
added
a
bunch
of
metrics,
so
Gigi
and
I
think
Steve.
You
just
are
working
on
adding
some
metrics
and
now
for
the
container
registry
as
well.
I
think
you
have
an
issue
assigned
to
you
and
Nick
you're,
adding
in
some
front-end
tracking
for
the
NPM
and
maven
installs.
A
So
if
you,
if
we
could
do
the
asynchronous
review
and
give
any
feedback
in
that
spreadsheet,
that
would
be
really
helpful.
And
if
you
see
something,
that's
missing
that
you
think
would
be
worth
tracking.
Just
add
it
yourself
or
comment
or
anything
like
that.
That
would
be
really
helpful,
because
I
want
to
at
least
have
a
roadmap
to
to
how
we
track
all
these
metrics.
So
what's.
A
Say
I'm
like
for
Bayern
I
will
I'll
leave
this
up
as
an
agenda
item
for
our
next
think
big
session,
maybe
just
as
a
reminder.
So
let's
say
two
weeks
from
now:
it's
not
urgent,
because
I
have
enough
dashboarding
work
that
I
could
do
in
the
meantime
and
but
it'll.
It
will
be
helpful
to
get
feedback
by
then
and
I
need
to
give
everyone
access
and
I
realize
sorry
just
hoarding
out
how
hoarding
on
my
work.
A
D
D
So
that's
what
we're
gonna
do.
Give
me
one
second
and
I
will
share
the
actual
design
for
a
quick
overview
case.
Is
your
first
time
I'm
going
to
spend
minimal
amount
of
time
explaining
the
design
or
and
asking
about
where
I
want
feedback?
Then
we
do
a
turn
based
approach.
The
turns
are
in
the
agenda
and
you
give
one
piece
of
feedback
and
then
move
on
to
the
next
person.
One
of
the
big
call-outs
is
when
you're
done
giving
feedback
make
sure
to
call
out
the
next
person.
So
we
can
move
around
pretty
quickly.
E
D
D
Please
please
so
this
is
a
package
detail
view.
It
is
one
of
the
most
complicated
views
that
we'll
have
because
I'm
kind
of
demonstrating
a
lot
of
different
points.
This
is
supposed
to
help
users
with
the
focus
of
troubleshooting
a
problem
with
a
package
that
seems
to
be
a
big
priority
that
happens
with
our
users.
So
I
wanted
to
present
the
data
in
a
way
that
was
really
digestible,
end
of
overview
learning
from
the
last
time,
Steve,
when
you
are
ready,
you
are
the
first
person
to
go
the
hot
pressure
seats.
B
D
Theoretically,
the
dependence
would
be
packages
that
use
other
sorry
outside
packages
that
use
this
package
in
order
to
build
it.
So
this
could
be
here
at
an
organization
level.
This
could
be
the
base
package
and
then
somebody
else
includes
that
package
in
their
other
package,
and
so
I
just
wanted
to
surface
a
way
to
see
those
kind
of
connections
for
DevOps
it'd
be
really
useful
for
say
how
many
times
is
this
package
caused
a
problem?
There's
a
way
to
do
that
or
how
big
of
an
impact
would
a
problem
have
with
this
package.
B
A
Well,
I'm
trying
to
think
of
my
feedback.
I
left
you
a
bunch
in
slack
and
I'm,
trying
not
to
look
at
it
and
cheat
I
I,
really,
okay,
something
I
like
so
I,
really
like
to
add
to
project
button
is
the
is
clear
now,
instead
I
think
before
it
was
like
blue
and
green,
and
when
we
and
we
iterated
on
it,
I
like
that,
it's
cleared
I
was
designed.
C
G
E
For
me,
I
find
the
placement
of
the
NPM
the
sort
of
detail,
information
and
then
the
two
warnings,
and
then
this
sort
of
tabs
to
be
really
kind
of
awkward
to
my
eye
and
pretty
awkward
dude
though
so.
Maybe
it's
not
awkward
and
I
am
but
yeah
so
layout.
They
seems
a
little
weird
like
a
like
an
arrow
sandwich.
E
D
F
Yeah
so
Joan
cannot
hit
mine,
but
I.
Think
I
would
care
Engineering
I'd,
like
maybe
to
see
like
the
history
and
the
usage
data
and
the
metadata
maybe
to
be
moved
under
the
readme,
because
that's
as
a
developer,
that's
where
I
I
want
to
look.
First.
Is
you
know
just
some
like
the
readme
is
like
really
the
first
thing:
I
go
for
almost
much
everything
so
having
that
kind
of
be
above
the
fold,
I
think
would
be
a
big
and
Steve
is
next.
B
D
A
D
C
E
It's
to
me
there's
like
a
whole
lot
of
stuff
and
then
below
the
fold,
there's
other
stuff
that
I'm
just
and
I'm
not
actively
developing
these
days.
So
I
look
at
it
and
just
gonna
go
okay!
Well,
what
else
is
down
here
and
so
I'm?
Maybe
you
want
me
to
be
stoked
about
scrolling
down
the
page.
I'm
not
really
sure,
but
I
would
want
to
see.
E
E
H
D
The
verification
tab
I
have
buried
that
I
have
not
solved
the
verification
problem.
Yet
I,
don't
know
what
is
necessary
for
that
for
users.
Is
it
a
really
grand
process?
Is
it
just
an
admin
can
check
it.
So
first
I
want
to
explore
the
idea
as
a
developer.
This
is
useful
and
then
once
I
know
it
is.
If
it
is
then
I'll
move
into
the
verification
and
flush
it
out.
It
could
sit
somewhere
else,
not
in
a
tab
but
I'm
not
sure.
What's
involved,
that's
why
it's
kind
of
buried.
D
Am
actually
going
to
interrupt
even
though
I
loved
that
we're
gonna
be
bored,
we
got
two
rounds
in
in
ten
minutes.
That
is
success
and
Daniel
is
gonna,
be
really
happy
because
we
did
it
on
time.
Thank
you.
That
was
all
really
useful
feedback,
and
we
did
it
really
quickly.
So
I
feel
like
we
got
our
efficiency
down
just
like
last
time.
I'm
gonna
create
an
issue
and
ask
that
you
give
feedback
on
the
round
robin.
D
The
reason
is,
if
it
was
useful
or
not
useful
is
other
teams
and
other
product
designers
want
to
know
how
we
do
it
and
implement
it
as
well,
so
this
could
kind
of
ripple
out,
so
your
feedback
is
gonna,
be
really
really
helpful.
I'll
post
that
into
the
slice,
Channel
and
I'm
done.
You
stand
for
time.
This.