►
From YouTube: Adding access to settings under related feature menus
Description
Discussion about adding links to MR, CI/CD, Operations, and Repository settings under their related feature menus
A
All
right,
hey,
y'all,
thanks
for
joining
me
this
morning,
we're
here
to
talk
about
settings
and
the
short-term
plan
for
settings
specifically
in
areas
where
we
have
multiple
areas
where
we
could
put
settings.
I
think
there's
some
questions
about
that.
So
I
had
some
questions
for
you
and
just
wanted
to
see
what
your
answers
were.
So
the
first
question
I
have
for
y'all
is:
what
do
we
know
from
ux
research
about
how
users
expect
defined
settings.
B
Yeah,
so
we
ran
research
and
by
we
I
mean
mostly
catherine
in
13.9
for
exactly
that
question
for
the
different
aspects
of
settings.
How
do
users
expect
to
to
come
to
that
page
and
there
were
mixed
results
for
a
certain
subset
of
settings,
for
example
around
the
ci
cd
area.
C
Yeah,
I
don't
have
much
to
add
to
that
other
than
the
the
research
shows
that
the
the
mixed
results,
and
so
we
have
have
some
experiments,
queued
up
ready
for
fortino
to
see.
If
we
can
pull
references
to
the
settings
without
having
to
re-architect
all
of
the
settings,
views
themselves
to
to
split
them
up
and
break
away
from
this
monolithic
settings
experience
and-
and
so
we
can
see
if
that
improves
discoverability.
A
Okay
and
thank
you
for
bearing
with
me
I'm
taking
some
notes.
Okay,
so
I
want
to
repeat
back
one
of
the
things
that
I'm
hearing,
which
is
there
are
so
it
seems
like.
There
are
two
things.
One
is
there's
not
complete
agreement
on
where
users
expect
to
find
settings,
but
then
also
there
are
settings
that
do
not
fall
under
features.
So,
no
matter
what
we
have
to
have
a
settings
area
of
the
product.
A
C
Yeah,
I
know
we've
done
some
explorations
marcel.
I
don't
know
if
you
want
to
elaborate,
but
I
think
that
you,
you
called
out
specifically
one
of
the
the
roadblocks
we
have
to
to
breaking
away
from
that
settings.
Experience
is
that,
right
now
the
left
nav
is
organized
in
a
way
that
doesn't
map
feature
for
feature
where
there
would
be
a
clear
settings
section
under
each
top
level,
left
nav
item
and
that's
one
of
the
barriers
to
implementing
this
at
a
global
level.
C
So
we're
we're
we're
planning
to
start
small
by
introducing
links
to
settings
where,
where
it
does
make
sense
and
where
it
does
map
to
the
features,
but
it's
going
to
take
a
little
more
research
and
possibly
a
little
more
reorganization
of
the
left
nav
before
we
can
truly
break
away
from
having
a
global
settings
view.
A
C
B
Exactly
and
that's
that's
exactly
why
I
want
to
clarify
that
when
we
move
the
settings
link,
for
example,
for
merge
request
into
the
merge
request
area
of
the
left
sidebar,
we
are
not
going
to
remove
the
merge
request
settings
part
of
the
settings
area.
We
are
just
going
to
link
to
it
from
that
area.
C
Yeah,
that's
a
good,
an
important
clarification
for
the
for
the
near
to
near-term
validation
of
that
experiment.
I
would
also
say
that
we're
a
lot
of
our
initial
research
and
and
solutioning
that
we
were
working
on
kind
of
hinged
on
using
search
as
a
way
to
make
things
more
discoverable
and
we're
taking
iterative
steps
there.
We
can
now
search
within
a
page,
but
we
have
some
ideas
for
how
search
would
work
across
all
settings.
It's
just
gonna
require
a
little
more
back-end
architecture,
work
so
that
you
can
search
across
pages.
B
And
the
current
long-term
direction
idea
is
more
around
having
multiple
ways
to
get
to
one
settings
page
right.
This
would
also
allow
us
to
to
allow
for
multiple
workflows
from
different
user
types
from
different
personas
that
sometimes
work
a
bit
differently
and
so
showing
them
in
different
ways
for
these
different
kinds
of
users
would
allow
us
to
to
get
to
a
better
experience
for
everybody.
C
Yeah,
I
know
we're
talking
about
short
term,
but
we
do
have
some
ideas
for
for
more
medium
to
long
term
impact
here
in
the
settings,
experience
and
moving
towards
more
of
a
data-driven
model
of
building
the
settings
itself
themselves
and
being
able
to
access
that
from
multiple
places,
while
still
referencing.
Only
a
single.
You
know
settings
entity,
a
settings,
data
file.
A
And
from
what
I
understand,
the
reason
that
we
can't
do
that
today
is
based
on
the
way
the
settings
are
architected
in
the
code:
they're,
not
insular
blocks
of
code.
It's
all
kind
of
part
of
that
monolithic
experience
and
so
moving
to
where
you
can
access
them
from
different
ways
means
actually
breaking
all
of
that
code.
Apart.
C
That's
that's
my
understanding
too.
There
are
a
whole
bunch
of
disparate
haml
files
that
are
that
have
their
own
page
logic
and
there's
no
central
index
that
we
can
refer
to.
A
Okay,
so
I'm
just
going
to
repeat
this
back
to
y'all,
because
I
want
to
make
sure
that
I
understand
your
plan
is
to
start
with
taking
merge,
request
settings
moving
those
up
into
the
feature
menu
also
leaving
them
in
settings,
and
then
it
sounds
so
like
do.
I
remember
correctly
that
you
are
also
going
to
move
the
merge
request
settings
from
where
they
are
in
general
to
a
different
part
of
the
settings.
B
C
We'd
like
to
coordinate
all
that
for
14-0
we're
trying
to
limit
the
consecutive
releases
where
we
disrupt
this
workflow.
So
if
we
can
bundle
it
all
together,
we're
we're
working
to
towards
a
big
push
for
14-0.
A
Okay,
so
it
sounds
like
you,
don't
think
it's
risky.
If
we
okay,
let
me
back
up
so
we
cannot
move
everything
out
of
settings.
We
have
to
have
a
general
settings
section
of
the
product.
A
C
It's,
I
would
say
it's
primarily
architectural,
so
we
would
duplicate
the
code
by
leaving
them
in
both
places
by
implementing
a
new
view
for
settings
under
merge
requests
or
ci
cd
we'd
have
to
duplicate
all
the
logic.
If
we
wanted
to
also
have
it
in
a
familiar
place,
we
could
certainly
have
just
moved
it,
but
we'd
be
moving
logic
that
we
intend
to
refactor
in,
hopefully
the
near
future.
So
our
our
goals
for
14-0
were
primarily
around.
What
can
we
do
with
the
least
amount
of
impact
to
the
existing
architecture?
C
While
we
spec
out
and
plan
the
the
next
step?
That's
a
more
like
widespread
change.
B
I
actually
want
to
ask
one
clarifying
question:
was
the
question
you
just
asked
around
why
we
don't
show
them
in
both
places,
but
just
link
to
it
from
one
place
to
the
other?
One
was
the
question
whether
we
have
or
why
we
have
only
the
merge
request,
link
to
settings
and
not
also
ci
cd
operations
and
repository.
A
A
C
C
C
Yeah
we
could
have,
we
could
have
links
to
settings
but
again,
just
to
echo
marcel's
earlier
point,
they're,
essentially
just
deep
links
into
the
settings
views
as
they
exist.
Now
they
wouldn't
actually
be
moving
any
logic
into
the
features.
A
Okay,
is
there
any
downside
to
doing
that.
B
B
To
move
operations
into
three
separate
items,
so
that
brings
up
up
to
16
top
level
items
on
the
left,
sidebar
and
I
calculated
yesterday.
If
we
move
all
the
settings
into
the
separate
areas
on
the
left,
sidebar
we're
going
to
end
up
with
roughly
65
sub-level
items
on
the
left,
sidebar,
it's
a
considerable
amount
of
items,
and
we
have
worked
already
incredibly
hard
to
make
sure
that
these
items
are
all
more
in
view
for
users
even
on
smaller
devices.
B
That's
a
big
big
problem
that
we
had
previously,
where,
for
example,
settings
was
hidden
so
far
below
or
so
far
at
the
bottom
of
the
list
that
users
wouldn't
even
see
it.
This
is
one
topic
we
are
currently
attacking
with
a
big
visual
redesign
of
the
left
sidebar,
but
if
we
continue
pushing
more
and
more
things
into
the
left
sidebar,
we
are
going
to
come
to
that
spot.
To
that
specific
point
again,
where
we
need
to
rethink
how
the
left
cyber
works.
A
Okay,
so
moving
them
now
would
solve.
One
problem,
which
is
users,
would
be
more
easily
able
to
find
the
settings
it
would
create
a
problem
and
that
it
creates
more
visual
noise
in
the
left
nav,
but
it
sounds
like
we
have
plans
for
how
we
want
to
mitigate
that
over
the
long
term,
so
it's
kind
of
a
trade-off
right
now
of
which
is
which
is
better
or
worse.
Okay,
exactly.
A
C
My
team
might
get
angry
at
me
because
I
don't
think
I
have
points
on
that
issue
yet,
but
my
understanding
that
it's
it's
fairly
straightforward
to
add
the
link
in
there.
So
I
would
say
that
it
is
unlikely
that
we
will
have
to
push
anything
significant
off,
especially
given
the
1312
milestone.
That
was
just
added.
A
Yeah,
okay,
okay!
So
what
I'm
hearing
is?
Yes,
we
can
add
deep
links
to
the
other
three
items.
So
four
items
in
total
would
now
have
feature
level
settings
access.
We
do
not
based
on
user
research,
think
that
we
should
remove
those
items
from
the
settings
section
of
the
product.
Those
need
to
remain
there,
because
significant
number
of
users
still
expect
to
find
them.
There,
yeah,
okay,
cool,
okay,
I'm
going
to
stop
recording.
Thank
you.