►
From YouTube: Settings UX - Package
Description
In this video we discuss the Settings UX effort with Package https://gitlab.com/groups/gitlab-org/-/epics/3535
A
A
Nor
does
it
seem
to
align
with
documentation,
and
so
we've
already
heard
from
our
users.
We
have
one
thing
of
settings
and
they
were
like.
We
have
no
idea
where
it
is,
and
once
you
say,
oh
it's
in
ci
cd
under
the
package
thing
they're
like
oh
okay,
but
that's
not
natural,
considering
that
package
isn't
normally
under
ci
cd
anyway.
B
B
A
We
heard
a
couple
of
times
that
knowing
the
users
were
struggling
to
know
where
that
setting
would
be,
and
that
tend
to
bubble
up
to
settings
in
gitlab
are
hard
yeah.
So
even
if
it's
not
just
about
whatever
we
were
talking
about
during
problem
or
solution,
validation,
that
kind
of
came
up
as
a
theme
of
just
it's
hard
to
know
where
settings
are
actually
going
to
be.
B
A
B
A
Well,
as
start
looking
into
new
features
of
preview,
the
results
of
this
setting
and
how
the
group
level
and
project
level
are
different
for
these
sets
of
settings.
So
that's
like
the
next
step.
We
also
have
with
the
dependency
proxy,
which
is
something
that
we're
we
are
doing.
Solution
validation
on
now
and
will
start
building
soon
has
its
own
settings
that
it
will
need
in
terms
of
yes
it
does
it
caches
things
or
it
doesn't
cache
things.
It
allows
everything.
It
does
not
some
stuff
like
that.
A
We're
also
going
to
add
cleanup
policies
for
packages
which
matches
the
tag
stop
as
well
as
each
package
manager
will
have
a
couple
of
new
settings
like
do.
We
allow
maven
to
have
uploads
of
duplicate
packages,
and
it's
the
same
for
npm
and
stuff
like
that,
so
those
are
the
things
that
we
know
are
going
to
be
coming
up
and
then,
after
that,
a
ways
down
the
road.
We
know
we're
going
to
have
some
catching
settings
relating
to
the
dependency
proxy
for
the
kind
of
free
tier.
A
If
we're
going
to
include
just
simple
request,
forwarding
where
the
admin
can
say.
Yes,
our
team
can
automatically
request
stuff
from
the
public
domains
so
npmjs.org,
for
example,
if
we
can't
find
it
in
gitlab,
we'll
go
check
there
and
then
limiting
the
file
size
or
the
file
types
and
making
that
adaptable
at
the
group
level
and
at
the
project
level.
A
B
A
B
A
B
Yeah-
and
that
was
my
main
question
like
because
you're
also
looking
at
the
group
settings
for
releases
right-
we
want
to
not
only
releases,
but,
like
environments
deployments,
we
want
to
show
all
these
things
at
the
group
level.
So
I
think
it's
interesting
to
see
how
the
how
to
set
up
all
these
functionalities
like
the
release
in
relation
to
the
package,
because
I
think
that's
that's
definitely
a
pain
point
right
now
is
that
you
go
to
cisd
settings
and
everything
is
there
right?
B
So
it's
it's
a
bit
problematic
at
the
project
level
and
when
we
do
that
right
now,
if
I
don't
look
at
anything
else,
when
I
look
at
the
group,
we
start
including
new
settings
functionalities
or
whatever
there
it's
just.
So
I
don't
know
it's
just
not
natural,
the
the
workflows
you
know
in
in
the
in
the
group
level
for
where
to
find
things
and
yeah
how
even
how
we
link
some
functionalities
in
the
in
the
settings.
B
A
And
that's
one
of
the
things
is:
we
don't
have
a
lot
of
settings
right
now,
but
once
we
start
getting
more
settings
directly
for
package,
we
have
an
issue
devoted
to
moving
it
out
of
ci
cd
and
into
its
own
like
high
level
setting
just
so
it
matches
the
navigation
and
the
documentation
and
that's
what
our
users
have
kind
of
said.
They
wanted
and
I'm
just
not
sure,
on
the
broader
scale.
A
B
B
B
How
do
you
call
it
how
they
call
it's
like
the
the
per
menu
section
like
they
want
to
have
in
context?
A
lot
of
users
say
that
they
want
to
have
settings
in
context
with
the
section
in
the
menu,
but
I'm
not
I'm
not
100
percent.
Confident
in
that
giving
like
that
sorry
bring
party
like
the
workflows
are
so
they
overlap
so
much
and
not
knowing
the
you
know
the
flow
from
let's
say
the
ci
cd
flow
for
persona,
a
b
and
c,
it's
very
difficult
yeah
to
make
a
decision
in
that
sense.
B
C
B
B
Of
course
we
have
the
big
problems,
but
then
the
proposal
of
this
effort
is
to
look
at
these
big
questions
and
put
them
in
a
bucket
so
that
we
can
discuss
as
a
ux
department,
but
also
we
have
feature
proposals
and
also
bugs
that
relate
to
settings
and
what
we
call
bugs,
or
you
accept
white
polish
white
text.
Just
you
know,
beautification,
let's
say
and
yeah.
B
The
purpose
is
really
to
identify
what
are
the
the
low
hanging
fruits
like
things
that
we
can
improve
in
the
settings
right
now
that
don't
necessarily
need
ux
a
lot
of
ux
involvement,
and
I
just
wanted
to
highlight
this.
Actually.
This
happened
here.
United
chat,
this
epic,
where
there's
43
issues
related
to
design
and
one
of
the
things
that
we
wanted
to
suggest,
and
that's
of
course
we
have
to
discuss
with
pms
as
well
was
to
see
when
the
the
the
groups
can
pick
up
these
issues
so,
for
example,
release
management.
B
A
B
That
resonate
at
all.
Definitely
I
love
that,
and
it's
really
in
line
with,
I
think
what
maria
started
doing
in
configure.
She
has
an
epic
that
is
really
about
buttons.
I'm
gonna
add
here
to
the
chat
and
also
the
document
where
she
just
created
a
lot
of
these
issues
or
organized
at
least
the
issues
to
fix
buttons
in
settings,
and
that's
it
like
move
button
from
here
to
there
align
to
the
right
line
to
the
left.
B
B
You
fix
that
it
sounds
very
small
when
you
look
at
the
overall
like
the
overarching
goal
right
for
settings
which
is
to
improve
the
overall
user
experience.
But
there
are
issues
in
settings
that
are
so
small
they're
like
ux
enhancements.
They
are
there
for
two
three
four
years
and
my
gut
feel
is
that,
let's
try
to
you
know
close
those
blocks
so
that
we
can
look
at
the
user
experience
goals
on
the
fly
like
as
we
go
with
the
help
of
other
designers.
C
We
need
to
look
from
a
really
wide
lens
here
and
yeah.
I'm
just
like.
I
started
thinking
about
how
to
find
the
strategy
how
to
deal
with
that.
But
of
course,
like
kiana,
we
will
need
to
schedule
such
conversations
with
other
stage
groups
as
well
like
with
maria
with
everybody
else,
to
get
to
understand
the
space
we
are
working
here
with,
but
no.
B
C
B
B
I
don't
know
that
needs
to
go
and
manage
his
packages
right.
It's
very
specific.
I
love
to
continue
this
conversation
and
hear
more
from
others
as
well,
because
maybe
there's
people,
someone
is
already
doing
this
type
of
investigation,
and
you
know
it's
just
not
seeing
the
light
just
yet
and
another
thing
that
we,
I
think
I
think
we
discussed
this
as
well
nadia
is
that
as
we
go,
I
would
like
to
explore
the
working
group
approach
similar
to
what
the
you
know.
B
Some
people
did
in
the
past,
maybe
like
what
the
gitlab
ui
working
group
did
so
that
we
can
have.
I
don't
know,
designers,
ambassadors
or
whatever
you
know,
product
managers
that
can
spend
their
time
looking
at
this
continuously,
because
these
problems
they
all
exist
as
you're
saying
like
ian.
I
also
wasn't
expecting
yet
to
put
so
many
issues
here.
A
B
Yeah
and
then,
if
you
can
yeah
just
keep
the
conversation
rolling,
it
will
be
awesome
because
it
will.
It
will
be
a
time,
at
least
that
I
have
to
work
on
group
settings
and
I
would
love
to
work
on
top
of
what
you
already
have,
rather
than
start
the
whole
brainstorming.
You
know
it
just
it
makes
sense
so.
B
A
A
B
I
think
so
I
personally
think
so,
especially
that
we
can
do
validation
and
we
can
compare
both
versions
right.
We
can
usability
testing
and
say
here's
what
works
for
the
new
settings
page
and
here's
what
working?
What's
not
working
for
the
current
configure,
ci
cd
settings
whatever,
and
then
we
locate
our
case
on
top
of
that,
because
I
think,
as
we
go,
we're
gonna
start
finding
this
the
similarities
in
what
you
just
said.
The
user
needs
right,
you're
working
on
settings
and
something,
and
then
people
are
complaining
about
that.
B
I
think
that's
a
that's
a
good
direction
because
we
need
to
start
somehow-
and
I
one
of
the
problems
I've
seen
in
the
past
is
that
we
can
plan
as
much
as
we
want.
We
can
do
as
many
designs
as
we
want,
but
we
need
to
deliver
software.
So
if
we
have
that
implemented
and
then
we
can
say
here,
it
works
or
it
doesn't
it's
much
better
than
yeah
building
the
design
plan
and
polishings.
A
You
just
need
your
front-end
developer,
it's
a
front-end
weight
of
like
one,
and
you
can
just
build
it
and
you
would
be
done
and
you
would
look
really
good
on
your
stage
group.
I
wonder
if
that
is
another
area
we
could
explore.
Not
only
do
we
as
a
designer
say
these
are
the
new
patterns,
but
also
the
front
end
is
already
the
plug
and
play
it's
super
easy
just.
Do
it
yeah.
A
B
A
I
yes,
I
am
so
happy
we're
in
alignment
there.
I
also
wonder
if
we
can,
I
can
push
for
solution,
validation,
a
little
heavier,
and
then
we
can
share
some
of
the
broader
terms.
For
example,
we've
already
shown
the
revised
cleanup
policies
and
our
users
give
us
feedback
that
we
use
much
more
human
terminology
and
much
more
closer
to
sentences
and
less
titles
and
the
way
that
we
did
that
they
resonated
with
really
well
the
fact
that,
like
we,
it
was
more
conversational
and
human
as
opposed
to
technical.
A
So
I
wonder
if
there's
insights
like
that,
that
we
can
also
surface
when
we're
trying
to
come
up
with
these
patterns
of
like
users
really
liked
it.
When
we
explicitly
said
here's
a
whole
sentence
of
what
this
setting
is
going
to
do,
and
they
liked
it
instead
of
like
check
this
box,
it
does
a
thing
and
if
you
know
all
the
buzzwords
you're
good,
but
if
you
don't
know
the
terminology,
it
is
a
mystery
button.
B
C
B
B
Why
and
other
people
are
like,
I
just
know
what
this
is
about.
It
feels
like
the
application's
telling
me
I'm
stupid.
Why
do
I
have
to
read
this?
So
I
think
we
need
to
find
the
middle
ground.
You
know
in
that
sense,
and
also
like
another
point.
I
added
here
to
the
agenda
is
that
guidelines
in
pajamas
right.
We
have
guidelines
for
components
and
positioning
of
this
and
that.
B
A
A
Does
pajamas
afford
itself
to
be
at
the
higher
level?
Does
a
really
good
job
of
documenting
components?
Individual
components
like
this
is
the
rules
for
using
a
toggle?
Is
it
already
set
up
and
I'm
just
not
noticing
it
just
say
like
in
a
setting
situation?
Here's
how
you
should
architect
the
page
in
an
ideal
scenario,
so
it's
the
same
as
every
other
settings
that
we've
done
so
far
yeah
or
is
that
our
vision
and
dream
of
the
next
next
time?
What
are
your
thoughts.
B
Yeah
we
do
have
regions
so
empty
states,
navigation
search
things
that
are
really
high
level.
I
don't
think
settings
that
high
level
experience
like
my
first
thought
right
to
me,
feels
like
settings.
It's
a
section
within
the
project
with
the
product.
It's
like
a
almost
like
a
capability
built
in.
I
don't
know
how
to
explain
that
we
do
have
what
we
call
regions
and
then
oh
there's
objects.
This
is
new,
but
I
think
we
can
definitely
investigate
that
because
it
needs
to
be
documented
somewhere.
C
That's
actually
a
good
idea,
you
know
kind
of
like
as
we
go
as
we
define
those
best
practices,
it's
good
to
document
those.
I
don't
think
we
have
much
around
those
today
but
yeah
it's
it's
kind
of
like
that.
Next
maturity
level,
I
guess
to
which
we
have
to
vote,
and
I
also
wanted
to
say
that
it's
probably
like
whenever
ian.
If
you
are
going
to
be
the
first
person
to
touch
this,
it
would
be
good
to
have
an
example,
another
example,
but
I
have
a
little
bit
of
an
investigation.
C
I'm
curious
like
and
I'll
definitely
have
a
look
into
it,
but
I'm
curious
like
what
are
the
some
of
the
other
super
complicated
like
big
products
that
have
nice
well,
information,
architectural
settings
or
like
nice,
usability
of
settings
like
you
know
like
to
understand.
Where
do
we
even
want
to
go
with
this
like?
Because
it
is
complex
we
have
so
much
today,
so
much
features
to
cover
and
so
much
personas
and
stage
groups.
A
I
do
wonder
just
to
learn
that
exact
thought,
if
similar
to
what
hayana
was
saying
earlier,
was
that
if
we
should
have
a
like
developer
level
settings
that's
in
the
ui
next
to
what
you're
working
on.
So
if
you
were
looking
at
the
package
registry,
it
would
have
a
settings
button
and
then
there's
like
the
group
devops
admin
level
settings
which
a
developer
would
never
touch
and
they're
different
and
we
should
start
separating
them
out
and
make
them
feel
a
little
bit
more
different.
B
A
C
A
A
Example
that
I
could
just
like
pop
up
and
be
like
this
is
how
they
are.
They
did
it
expertly,
but
I'm
thinking
from
the
standpoint
of
we
experienced
this
a
little
bit
at
the
group
level
versus
the
project
level
for
package,
where
each
package
registry
has
its
own
settings
and
they
should
be
right
there
because
you're
looking
at
the
data,
and
so
you
should
click
on
a
button
and
edit
that
data
right
there
and
then
there's
other
things.
A
B
So
it's
more
like
a
contextual
access
to
settings
based
on
your
workflow,
but
also,
I
don't
know
your
personas,
your
access
or
whatever,
so
you
could.
Potentially,
if
understood
correctly,
you
could
potentially
just
I'm
here
working
on
packages.
I
don't
need
to
go
to
the
group
level
settings.
I
have
access
to
this
right
now,
because
this
is
my
job,
but
if
it's
not
part
of
my
workflow,
I
don't
really
see
that
in.
A
Does
not
accept
this
file
type
like
that's,
not
something
you
would
want
to
look
at
the
data
and
see
how
they
relate,
and
so
the
admin
has
a
different
set
of
questions
compared
to
the
the
people
actually
working
with.
What's
there
I'm
I'm
exploring,
I
don't
know
if
this
is
actually
true,
but
it
would
be
curious
if
there's
contextual
settings
right
there
and
then
an
admin
or
more
so
the
group
admin
kind
of
has
their
own
area
to
deal
with
that
only
specific
to
their
workflows.
B
Yeah,
that's
interesting,
and
I
think
that
if
it's
something
that
you
can
explore,
it's
definitely
well
done.
Definitely,
I
should
do
this,
but
it
sounds
like
something
that
we
could
yeah
explore
as
well
in
in
release
because
yeah
when
we
talk
about
all
these
personas
all
these
the
different
people
that
are
consuming
managing
releases
and
then
yeah,
everyone
is
forced
to
go
to
one
place,
even
though
it's
not
part
of
your.
You
know
your
flow
you'll
be
nice
to
get
inside
in
that
space.
A
B
A
B
Yeah
and
I
think
that
will
resonate
with
what
we
want
to
do
for
secrets
and
ci
variables.
For
example,
we
want
to
split
the
settings
and
also
they're
gonna
happen.
They're
gonna
leave
at
the
group
level
someday
this
year,
probably
still
but
yeah.
Maybe
we
can
leave
this
this
inside.
If
the
personas
are
the
same,
like
you
have
software
developer
and
yeah,
but.
C
Yeah,
it's
it's
great
like
whenever
it's
like.
I
liked,
where
we're
going
with
that,
because
if
you're
going
to
be
talking
to
each
of
the
different
stage
groups
who
are
planning
to
do
a
new
research
around
those
things,
we
can
ask
to
add
couple
of
questions
and
kind
of
like
do
the
research
around.
You
know.
Well
the
placement
of
settings
or
usage
of
those
to
the
studies
that
are
planned.
So
we
could
like
get
some
additional
information.
So
that's
really
helpful.
B
We
have
a
lot
of
next
steps,
that's
awesome,
but
I
think
maybe
we
can
regroup
in
a
couple
of
well.
We
can
always
catch
up
with
synchronously,
but
what
I
want
to
do
is
that
to
catch
up
with
other
designers,
they're
also
thinking
and
working
exciting,
so
maybe
maria
will
be
an
extra
good
option
and
then,
of
course,
you're
invited
to
join
so
that
we
can
have
the
same
brainstorming
and.
C
A
I
wonder
if
that's
the
the
avenue
to
take
when
it
comes
to
these
settings
so
that
you're
asking
everyone
in
planning
during
create
to
like
how
does
this
impact
you
and
ask
everyone
in
operations?
How
does
this
impact
yeah?
I
wonder
if
that's
a
good
way
to
facilitate
the
conversation,
so
there's
not
a
lot
of
synchronous
meetings,
but
also
we
get
a
lot
of
data.
B
A
B
Right,
yeah,
that's
exactly
what
I
want
to
do
so
do
kind
of
a
one-on-one,
because
we
get
these
calls
with
the
10
dries.
Then
the
conversation
will
really
have
the
focus,
because
now
we
can
really
talk
about
package
right
and
then,
if
we
go
over,
I
don't
know
how
many
groups
or
teams
we
have.
But
if
you
can
explore
unknown
the
teams
from
five
other
stage
groups,
and
then
we
collect
the
data
and
say
here's
what
we
discovered
and
then
now,
let's
continue
the
conversation
as
a
group.