►
From YouTube: UX Scorecard - Package FY22-Q3 - Investigate metadata and historical information on a dev dependency
Description
A walkthrough of a UX scorecard conducted for the package group.
View the UX scorecard issue on GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/340253
A
After
selecting
the
job
to
be
done,
we
identified
that
the
persona
completing
this
job
to
be
done
would
be
sasha
the
software
developer
and
the
specific
scenario
that
sasha
is
following.
The
scenario
that
I
scored
is
you
are
collaborating
on
an
existing
project
in
gitlab
that
has
package
dependencies
to
troubleshoot
issues
related
to
a
specific
package.
You
need
to
see
historical
information
about
the
package
such
as
who
published
it
and
how
it
was
published.
A
You
also
need
to
see
information
about
the
package,
such
as
version
and
any
error
messages
related
to
the
package
and
the
tasks
to
complete.
The
scenario
are,
and
so
there
is
a
pipeline
failure
and
sasha
needs
to
investigate
why
the
pipeline
failed
notices
that
it
had
something
to
do
with
the
package
they
navigate
to
packages
and
registries
and
then
packages.
A
So
the
package
registry
has
already
been
set
up
and
often
authenticated
too,
and-
and
this
also
assumes
that
sasha
has
some
awareness
about
the
package
registry
either
when
they
were
onboarded
to
this
project.
They
were
informed
that
there
are
packages
package
dependencies
in
the
gitlab
package
registry
or
they
determined
it
from
the
source
code
of
the
project.
A
A
And
this
is
a
little
bit
intimidating,
but
basically
what
I
need
to
do
here
is
kind
of
scan
through
all
of
this
information.
So
I
can
see
that
on
line
61,
we
have
the
error
and
I'm
going
to
kind
of
scan
backwards
from
there
and
there's
something
here
about
a
syntax
error
and
then
on
line
44.
I
see
something
about
a
node
module,
and
so
I
know
node
refers
to
npn,
and
here
I
can
see
a
scoped
label
gitlab.org
and
then
a
jokes
package.
A
A
I
could
dig
through
the
source
code
and
kind
of
investigate
the
jokes
package
and
see
this
file
and
see
if
I
can
determine
what
has
caused
it
to
fail.
I
could
try
to
run
my
project
locally,
and
but
I
see
here
that
it's
from
the
gitlab
private
registry,
and
so
what
I'm
going
to
do
is
just
have
a
look
there
and
see.
If
I
can
get
any
more
information
that
might
be
a
little
bit
easier
to
process
here.
A
And
here
I
can
see
that
there
are
17
packages
and
there's
quite
a
lot
of
them
and
they
all
look
quite
similar.
So
I
remember
that
my
package
is
called
jokes
dash
package,
but
it
seems
like
there's
quite
a
lot
of
versions
going
on
here
and
there's
some
information
about
how
the
package
was
published.
But
what
I
was
really
hoping
to
see
was
perhaps
like
some
indication
that
there
was
a
pipeline
failure
that
had
something
to
do
with
one
of
these
packages,
so
just
to
make
it
a
little
bit
easier
for
myself.
A
A
A
Cool,
so
I'm
not
really
seeing
any
information
here.
What
I
would
have
liked
to
see
would
be
maybe
a
commit
message
like
when
this
package
was
was
published.
There
was
probably
a
commit,
and
there
might
be
a
little
bit
more
information
about
why
this
is
experimental
and
but
instead
I'd
see
a
sparse
history
and
installation
instructions,
and
I
don't
know
what
registry
setup
is
there's
not
that
much
information
about
what
that
is,
and
then
here
I
can
see
that
I
can
manually
download
the
file,
but
that's
not
what
I
want
to
do.
A
A
This
is
interesting,
so
this
has
a
lot
more
history.
I
don't
understand
why
the
1.6.0
didn't
have
this
history,
because
this
has
exactly
the
kind
of
stuff
that
I
was
interested
in,
such
as
the
commit
I'm
just
going
to
have
a
quick
look
at
this
commit
I'm
going
to
open
that
in
a
new
tab
cool.
So
I
can
see
a
commit
message
and
I
can
see
that
the
pipeline
has
passed.
A
Cool,
what's
a
little
bit
confusing
here
is
it
says,
plus
gitlab.org
jokes
package
1.6,
but
this
is
actually
1.5,
so
that
was
a
little
bit
unexpected
for
me.
So
what
I
can
do
now
is
google
how
to
install
a
specific
version
of
the
package,
but
I
think
I
know
how
to
do
that.
So
let
me
just
give
it
a
try.
A
A
A
A
Cool,
so
I
can
see
that
in
my
tests
I'm
actually
running
my
app
and
that
the
job
succeeded,
and
so
what
was
a
little
bit
tough
about
that?
If
I
navigate
back
to
the
package
registry,
is
it's
not
immediately
clear
how
this
list
was
sorted
and
I
needed
to
kind
of
manually
remember
in
my
head
the
name
of
the
package.
A
I'd
have
to
probably
dig
through
the
source
code
of
my
project
a
little
bit
and
when
actually
I
would
have
hoped
that
gitlab
could
help
guide
me
to
debugging
the
pipeline
a
little
bit
more,
and
so
that
was
the
the
scenario
that
I
followed
for
the
ux
scorecard
I've.
Given
this
experience,
a
2.5
and
so
there's
a
grading
rubric.
A
That
you
can
look
at
a
bit
more
in
the
handbook
page,
so
this
experience
I
had
to
especially
as
a
new
user.
I
had
to
kind
of
have
knowledge
about
a
lot
of
areas
in
gitlab
myself
and
there
wasn't
that
much
handholding
and
it
took
quite
some
guesswork
to
get
things
going,
and
so
that
was
the
ux
scorecard
for
investigating
metadata
in
dev
dependencies.