►
Description
Presented by Iain Camacho for the Package team
A
I
am
really
excited
to
share
with
everyone
showcase
some
of
the
work
we've
been
doing
on
the
package
side,
specifically
I'm,
looking
at
sharing
how
we
are
planning
on
integrating
some
more
of
the
more
robust
data
coming
from
the
rest
of
gait
lab
into
the
package.
Interface
to
start
off
with
I
wanted
to
give
a
little
background
on
what
packages
we're
a
fairly
new
group
to
the
rest
of
gate
lab.
A
We
focus
we're
part
of
the
C
ICD
group
and
we
focus
on
taking
packaged
up
and
bundled
pieces
of
code
and
storing
it
and
then
enabling
distribution
when
it's
ready,
whether
that's
to
other
engineers,
whether
that's
to
production
or
just
to
be
shared
as
part
of
the
DevOps
community.
The
entire
team
was
involved
in
this
initiative,
but
I
definitely
want
to
call
out
the
Tim
and
I
partner
very
closely
tim
is
the
product
manager
to
understand
what
our
users
needed,
which
is
part
of
why
I'm
excited
to
share
this
part
of
the
initiative?
A
The
goals
of
this
initiative
were
twofold
because
we're
a
product
manager,
who's
focused
on
business,
so
Tim's
goal
was
to
improve
the
competitive
position
of
get
labs,
packaged
offering
by
providing
a
more
robust
experience,
but
a
deeper
integration
to
see
ICD
and
the
rest
of
get
labs.
Devops,
like
lifecycle
inside
of
the
package
interface,
to
counter
that
as
a
user
I
had
a
user
goal.
Written
up
is
a
nice
little
job
story,
but
this
could
be
someone
who's,
an
engineer
or
a
DevOps
manager
or
someone.
A
Anyone
technical
really
when
I'm
troubleshooting
a
bug
related
to
a
package
I
need
to
quickly
be
connected
to
the
data
related
to
this
version
of
the
package.
So
I
can
identify
the
problem
area
and
create
an
informed
action
plan
moving
forward
when
we
were
looking
at
this,
we
kind
of
generated
two
hypothesis
looking
at
what
we
are
hearing
in
general
from
our
users
in
issues
as
well
as
casual
conversations
and
looking
at
our
current
UI,
which
you
can
see
on
the
right
side
of
the
screen.
A
We
had
two
hypotheses
that
we
dove
into
research
with
one
was
that
enriching
the
current
package
interface
with
more
robust
data
would
enable
our
users
to
better
manage
their
packages
and
troubleshoot
issues
more
effectively,
and
the
other
was
that
the
package
offering
here
at
gitlab
had
a
unique
position
by
being
directly
connected
with
the
rest
of
gitlab.
We
could
leverage
that
to
create
a
more
fluid
experience
for
that
troubleshooting
or
that
moving
forward
for
our
engineers.
A
So
if
you
take
a
look,
the
package
list
view
in
the
detail
view
they
are
showing
the
basic
information
you
need
to
use
the
package
and
not
a
lot
else.
So
we
wanted
to
dive
in
and
see
what
information
would
be
helpful
to
our
users.
I
am
a
huge
proponent
of
research.
Anyone
has
interacted
with
me
regularly.
You'll
know
I
talk
about
it
all
the
time
and
I'm
super
nerdy,
and
it's
very
exciting.
We
split
this
into
two
different
initiatives.
A
We
started
off
with
quantitative
data,
so
we
sent
out
a
survey
and
ask
around
we
got
about
300
responses
of.
Why
do
you
visit
the
UI
in
the
first
place
and
what
data
is
most
important
when
you
do?
This
was
definitely
focused
more
on
the.
What
so,
what
pieces
of
data
matter
to
you
we
got
like
I,
said:
300
responses.
There
were
about
17,
unique
insights,
so
every
package
manager
had
some
details
as
well
as
some
patterns.
A
We
saw
across
all
of
the
data,
as
well
as
just
some
backgrounds,
information
on
why
people
come
to
DUI
in
the
first
place.
In
terms
of
you
know,
what
are
they
trying
to
accomplish
following
that?
We
did
qualitative
research.
This
was
moderated
interviews
with
some
activities.
Really
we
were
focusing
on
asking
our
users
why
we
understood
from
the
survey
what
data
was
important
now,
what
we
needed
to
do
was
ask
the
users.
Why
is
this
piece
of
data
relevant?
When
does
it
help
you?
Why
are
you
needing
it?
A
We
sat
down
and
spoke
with
eight
individuals
around.
This
got
a
lot
of
really
consistent
information,
which
is
always
really
great.
When
you're
doing
research,
we
did
a
card
sorting
exercise,
so
we
understood
how
they
related
different
pieces
of
data
together,
as
well
as
that
insight
into
why
certain
pieces
of
data
are
more
relevant
than
others.
A
Following
that,
the
entire
team
got
involved
in
this
and
I
was
really
excited,
and
the
part
of
what
I
wanted
to
share
today
was
the
entire
package
team,
whether
the
marketing
or
content
and
technical
writing
or
engineers
or
management
or
product
management,
all
got
involved
in
the
conversation
of
how
we
could
take
this
data
and
enrich
the
experience,
we
did
it
in
two
main
ways.
One
was
our
think
big
conversation,
which
is
a
regular
meeting.
A
We
have
it's
nice
and
synchronous
to
discuss
as
a
team,
the
future
package,
so
we're
focused
on
ideas,
two
milestones
plus
out
of
what
can
we
do
as
a
team
to
better
enable
our
users?
It
was
a
great
opportunity
for
us
to
share
the
results
of
the
research
with
the
team,
get
everyone
on
the
same
page
and
open
up
discussions
for
possible
ideas
of
how
we
could
solve
for
that.
The
data
that
we
received.
We
also
did
something
that
was
really
fun
and
a
bit
challenging
where
we
did
an
async
brainstorm.
A
We
base
this
on
a
workshop
that
I
run
in
the
past
I'm
sure
a
lot
of
you
don't
something
similar
where
you
have
a
series
of
prompts,
and
you
ask
individuals
in
a
group
to
do
certain
tasks
when
exploring
different
parts
of
the
interface.
We
did
this,
the
entire
team
got
involved.
You
can
see
some
screenshots,
we
started
off
a
bit
silly,
asking
them
to
what
their
day
into
a
sandwich
as
well
as
how
do
you
organize
this
data,
then
we
wrapped
up
with
some
low
fidelity.
A
How
would
you
actually
build
this
screen
lots
of
lessons
learned
from
it,
but
it
was
really
exciting
to
get
everyone
involved,
especially
in
that
async
manner
that
gate
lab
is
so
famous
for
from
there.
Once
we
had
all
of
our
ideas
collected,
we
drove
into
some
iterative
design
or
not
to
explain
anyone
why
that's
so
exciting
and
important.
There
was
some
feedback
aspects
with
the
rest
of
the
team
kind
of
divided
into
three
areas.
A
One
was
just
the
async
design
iteration,
which
is
kind
of
exciting,
to
follow
the
design
tab
and
getting
mentions
because
we
used
it.
It
was
really
cool.
The
entire
team
could
pinpoint
exactly
what
they
wanted
to
talk
about
and
start
discussions
really
powerful
for
again
that
async
conversation,
we
also
did
two
synchronous
design
feedback
sessions.
We
did
them
with
airing
or
I.
Think
big.
One
of
the
things
that
was
important
to
us
was
this
sink
time
during
the
think.
Big
is
precious
and
very
important,
and
so
we
wanted
to
use
it
as
effectively
as
possible.
A
We
followed
a
very
formal
design
review
process
where
each
person
had
a
turn
they
can
produce
or
share
one
piece
of
feedback,
and
then
we
moved
on
to
the
next
one.
We
generated
all
of
that
feedback,
move
them
back
into
the
design
tabs
and
started
the
discussions
again
asynchronously,
which
was
a
really
great
experience,
because
everyone
had
the
opportunity
to
talk
about
it
and
then
went
to
that
asynchronous
idea.
After
the
fifth
iteration,
we
moved
into
the
solution,
validation,
which
is
always
really
exciting.
A
When
you
go
in
with
a
new
design,
we
spoke
to
five
different
users
and
ask
them
to
complete
different
tasks
of.
Could
you
answer
these
questions
with
the
current
UI
and
we
followed
up
with
the
same
asked
in
the
new
UI
and
then
wrapped
up
with
he
had
a
magic
one.
It
could
change
anything
about
the
design.
What
would
it
be?
We
got
really
great
results.
Lots
of
consistent
feedback
and
I
think
we're
all
very
confident
that
the
solution
we're
putting
forward
could
be
considered
validated.
A
A
One
so
sorry
I
lost
track.
My
thought
you
can
see
you
have
a
big
group
view
that
these
are
my
NPM
packages.
These
are
my
navy
packages,
these
my
Koenen
packages
and
also
get
an
idea
at
a
very
high
level
how
many
of
each
one
there
are.
This
helps
individual
engineers
try
to
find
packages
that
they're
looking
for,
but
also
real,
helps.
The
DevOps
managers
get
that
full
picture
view
of
the
package
registry
that
we
weren't
really
offering
before.
We
also
surfaced
some
of
the
data
that
they
were
requesting.
A
Those
frequently
the
example
I
would
give
is
a
quick
copy
for
the
commit
shop.
There's
a
lot
of
organizations
that
use
that
hash
code,
as
the
identifying
mark
of
what
package
should
be
used
in
the
codebase
so
being
able
to
copy.
It
was
really
really
useful
for
them
and
accelerates
a
lot
of
their
process,
as
well
as
adding
just
some
additional
metadata
to
help
navigate
the
different
packages.
A
Second
view
that
we
focused
on,
which
was
the
detailed
view.
This
is
where
we
got
a
lot
more
of
that
robust
data
that
our
users
were
looking
for.
So
one
of
the
big
parts
of
the
initiative
was
to
bring
the
detailed
view
of
the
package
into
kind
of
the
gitlab
style
and
make
it
look
consistent
and
feel
as
polished
as
the
rest
of
gitlab
is
there's
a
really
important
part
of
the
experience,
as
well
as
enriching
it.
A
With
information
like
connecting
the
package
that
we
have
in
front
of
you
to
the
code
base,
it
came
from
directly,
which
is
something
none
of
our
competitors,
can
really
do
effectively,
as
well
as
some
rich
historical
data
of
what
is
the
commit
that
triggered
the
pipeline,
the
pipeline
to
built
the
package
got
uploaded
to
the
registry,
etc.
These
were
common
threads
from
the
research
that
users
really
wanted
this
and
they
were
working
around
the
fact
that
it
wasn't
available
by
using
that
commit
shot
to
go,
find
it
elsewhere.
A
So
here
we
have
presented
a
way
to
directly
connect
it
where
users
are
intending
on
going.
We
also
first
in
future
state
we
added
some
usage
data
that
they've
been
looking
for
in
terms
of
how
often
is
this
package
being
pulled
and
organizing
the
information
and
a
little
bit
of
a
different
way
to
allow
us
to
expand
package
and
offerings
as
we
move
along
using
that's
the
tabs.
For
example,
we
could
show
all
the
different
versions
and
give
a
history
of
what
happened
in
each
version,
which
is
something
that
we
were
really
looking
for.
A
Thank
you.
Everyone
for
are
giving
me
the
chance
to
present
and
I
also
wanted
to
give
a
special
thanks
to
Laurie
and
Emily
for
being
so
heavily
involved
in
the
research
and
jumping
on
board
whenever
we
had
an
issue,
as
well
as
the
entire
package
team
for
being
involved
from
very
beginning
all
the
way
to
now
in
generating
these
kind
of
ideas
and
moving
us
forward.