►
From YouTube: Dev-Manage/Plan/Ecosystem UX Design Review - 2021-03-29
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Now,
no,
I
keep
defaulting
to
the
first
thing
I
list
on
share
screen
and
goes
to
whiteboard,
sometimes,
and
so,
as
I'm
considering
putting
this
component
in
the
pajamas
figma
library,
I
want
to
be
able
to
make
it
easy
for
designers
to
show
or
hide
the
color
swatches
so
where
I
was
thinking
about
having
this
land
would
be
underneath
messages
defaulting
to
being
hidden,
and
then
this,
like
color
picker,
section
being
in
the
input
box,
also
default
to
hidden,
but
you
could
go
into
it
and
show
it
if
you're
working
on
that
area,
the
only
downside
to
it
is.
A
B
I
I'm
just
guessing
here,
but
on
us
kind
of
a
side
note,
I
think
the
wrapping
is
possible
using
the
auto
layout.
Okay,
I
could
be
wrong
because
I
know
figma
is
you
know
web-based,
and
I
believe
that
auto
layout
is
just
using
kind
of
a
mix
of
display
and
flex
properties.
A
A
B
A
C
B
A
Yeah,
I've
gotten
some
feedback
from
jeremy
and
nadia
just
on
the
component
itself,
really
I'm
just
trying
to
replicate
what
we
already
have
in
gitlab,
because
I
got
really
tired
of
making
the
color
picker.
So
I
assumed
somebody
else
would
probably
get
tired
of
it
too.
Maybe
maybe
alexis,
but
I
was
just
hoping
to
at
least
get
this
in
there.
So
we
could
stop
copy
and
pasting
probably
the
same
thing
over
and
over
again.
D
Yeah
austin,
I
think,
as
far
as
sorry,
I
think
as
far
as
hiding
it,
I
think
that's
pretty
standard
I've
seen
it
in
a
lot
of
other
components.
You
know
even
like
it
kind
of
reminds
me
even
just
the
regular
form
input
field
right.
We
hide
the
you
know,
error
text
and
message
text
without
your
concern,
I'm
just
hiding
that
whole
bevel.
A
Area
there
yeah,
because
I
want
to
make
it
a
part
of
this
component,
so
I
want
when
you
go
in
here,
that
you
can
open
up
messages
and
find
color
swatches
just
by
default,
it's
going
to
be
hidden
so
that
way,
if
you
need
it,
it's
there
for
you,
because
that's
where
it
shows
up
in
our
ui,
but
I
wasn't
sure
if
anybody
else
had
thoughts
on
it
being
a
part
of
the
input
text
or
anything
else
generally.
So
this
is
kind
of
like
what
it
you
know.
D
Yeah,
I
would
check
with
jeremy
too
then
I
think
that's
a
good
idea,
just
because
yeah
I
know
jeremy
has
some
thoughts
on.
You
know
where
you
know
we're
on
the
line
maybe
like.
If
it's
adding
too
much
bloat
to
the
component,
you
know,
but.
A
A
A
C
Yeah,
I
will
one
thing
that
I
noticed
at
least
when
I
was
playing
auto
layout
is
the
way
the
the
layers
are
labeled
and
that's
not
labeled,
wherever
they're
in
the
hierarchy
of
their
order
has
a
bit
of
a
problem
with
that
too,
like
if
you
put
something
on
the
top,
it
wraps
things,
even
though
it's
not
physically
above
any
content
for
some
reason.
So
that
was
my
only
other
experience
with
that.
A
C
No
yeah
so
I've
linked
it
to
like
the
figma
file
and
not
the
primary
epic
that
the
settings
work
is
originated
from,
but
one
that
specifically
deals
with
the
re-engineering
and
redesign
in
the
ux
work
that
hayana
and
michael
lay
are
working
on,
and
I
had
this
initial
thought
of
like
well.
What
austin
had
mentioned
about
like
how
should
settings
behave
the
standard
behavior?
What
should
the
sheddings
the
settings
do?
I
was
thinking
well
something
that
mike
had
mentioned
previously
was
how
they're
written
the
vocabulary.
C
I
thought.
Maybe
that
would
be
an
interesting
way
to
go
about
and
relook
at
everything.
But
if
I
jump
down
to
point
c
that
maybe
the
mvc
that
I
should
be
thinking
about
are
the
first
steps
that
I
should
be
thinking
about.
At
least
we
bring
parity
between
the
environments
first
before
we
start
rewriting
things
and
that's
something
that
I've
already
been
started
as
well.
With
the
bringing
the
admin
screen
from
selfmanage.com
I'll
share
the
screen
real,
quick.
C
So
I
had
already
done
like
an
inventory
of
all
the
settings
in
the
admin
screen
and
tried
to
define:
what's
a
gitlab
environment
setting
what's
a
hardware
environment
setting
or
what
overlaps
so
things
like
this
overview
or
monitoring
and
then
within
the
settings
panel.
C
So
this
is
the
admin
screen,
and
this
is
the
settings
link
within
the
admin
screen
and
then
so
trying
to
break
things
out
and
I've
gotten
a
lot
of
feedback
from
the
support
folks,
which
is
really
helpful,
and
so
then
I
just
recategorized
everything
trying
to
think
of
how
we
could
reorganize
it
breaking
things
down.
The
initial
proposal
was
to
try
and
minimize
the
stuff
in
the
left-hand
nav
and
so
for
merging
those
environments
that
can
kind
of
help.
C
C
C
If
you
look
at
the
top
level
group,
this
is
the
settings
you
have
within
the
environment,
and
so,
if
you
go
to
top
level
group,
you
should
have
the
same,
but
you
don't
have
this
admin
area
right.
The
idea
is
that
we
want
to
attach
this
and
these
settings
to
some
place
in
this
screen,
so
either
added
here
as
another
item,
so
there's
that
idea
of
parity,
but
then
also,
if
you
look
at
specifically
the
settings
where
you
have
all
of
this.
C
One
of
these
days-
but
that
was
what
I
was
saying-
is
that
there's
not
parity
between
the
environments,
mostly
because
of
the
problem
where
some
of
the
settings
in
the
dot
com
environment
don't
exist
here.
Are
they
they
just
don't
make
any
sense
here
specifically.
C
C
C
That's
does
that
help
illustrate
the
problem.
C
Well,
that's
what
I
was
doing
with
the
the
figma
file
going
through
there
and
trying
to
categorize
everything
to
try
and
see
what
made
sense
to
at
least
bring
over.
Logically.
Luckily,
I
got
a
lot
of
feedback
from
the
support
folks,
cynthia,
it's
been
very
helpful,
but
yeah.
That's
part
of
what
I
was
thinking
about
right
now,.
A
I
had
added
a
comment
more
type
to
your
initial
thing.
You
were
discussing
about
the
cascading
settings
from
the
visibility
section
between
groups
and
subgroups.
I
had
a
loom
link
this
morning.
I
was
just
talking
through
the
different
options
in
that
one
section,
because
there
are
three
different
inheritance
styles
and
then
potentially
go
forth
with
the
way
that
you
guys
are
building
out
the
enforcement
piece.
A
With
this
that
was
reported,
I
think
it
was
around
like
enabling
or
disabling
restrict
committers
from
like
unverified
accounts
or
something
and
teams
expected
it
to
cascade
down
to
projects
and
it
didn't,
and
then
they
had
this
like
security
risk,
I
guess-
and
so
now
we
have
to
go
tackle
that.
But
if
we
had
to
find
a
better
enforcement
model
than
an
inheritance
model,
we
wouldn't
have
that
bug
today.
So.
C
Yeah!
That's
exactly
what
I
was
thinking
about
going
through
and
looking
at
the
settings
to
see
how
they're
written,
because
I
think
a
lot
of
the
problem
is
based
around.
That
is
that
the
way
that
they're
written
doesn't
necessarily
translate
because
of
problems,
the
way
that
it's
not
really
defined
on
the
enforcement
or
the
way
that
we
have
that
setting
logically
defined
within
the
environment,
kind
of
like
what
you're
trying
to
bring
up
this
loom
file
that
you
linked.
Is
this
a
new
one,
because
I
remember
seeing
the
other
one
that
you've
done.
A
Yeah,
I
just
did
this
one
this
morning.
It
was
more
like
me
thinking
through
it,
so
I
don't
know
who
else
would
benefit
from
it?
It
was
just
me
talking
through
it
myself.
I
thought
well
might
as
well
in
case
it's
helpful
for
somebody
else,
but
yeah.
I
was
just
kind
of
comparing
and
contrasting
them
for
myself
to
see
like
okay.
If
I
hit
check
box
on
this
one,
how
does
it
behave
here?
If
I
check
this
one?
How
does
it
happen
if
I
uncheck
this
one?
How
does
it
affect
this?
C
So
mike
I
see
you
had
a
couple
of
comments.
The
first
question:
was
there
an
issue
about
parity
in
the
environment?
So,
yes,
there
is,
I
don't
have
it
off
top
my
head,
but
I
can
link
it
here.
The
nintendo
once
I
figure
it
out
and
then
specifically,
the
problem
is
not
an
individual
problem.
Apart
from
make
the
settings
screen
better
and
so
the
direction
for
that
is
multi-pronged,
which
we
kind
of
all
know,
but
at
least
from
access
perspective,
bringing
parity
to
the
environment.
C
The
cascading
settings
were
the
two
that
I
was
looking
at
and
trying
to
work
around
with
so
that's
sort
of
where
the
problem
that
I'm
trying
to
solve,
but
as
it
moves
up
to
the
bigger
problem,
the
main
problem
we're
trying
to
solve
is
to
try
and
again
two
issues
actually
clean
up
the
left-hand,
nav
and
also
clean
up
the
settings
environment
or
the
settings
screens
because
they're
more
kind
of
related.
You
know
the
left-hand
navigation
is
full
of
stuff
a
lot
of
its
settings
and
we're
trying
to
clean
that
up.
C
E
Does
when
I
hear
you
know,
make
something
better,
that's
pretty
that's
there's
a
lot
of
possibilities
there.
I
know.
I
see
this
epic
was
created
by
hayanna
and
I
see
all
of
the
issues
associated
with
it
and
it's
it's
all
solutions.
I
I
don't
see.
E
Maybe
if
I
click
into
it
and
read
the
paragraph
or
the
description,
I
mean
it
might
see
a
problem
statement
but
yeah
there's
a
lot
of
risk
in
just
trying
to
make
settings
better
rather
than
identifying
a
problem
or
problems,
prioritizing
the
problems
and
then
pursuing
solutions.
And
you
know
what
I'm
seeing
now
is
just
a
big
bucket
of
potentially
really
good
ideas.
E
We
do
not,
I
can't
yeah.
Thank
you.
Thank
you
for
reminding
me
yeah.
I
I
lose
sight
of
what
the
original
problem
is
when
I,
when
I
see
a
lot
of
the
like
lower
level
things
so
appreciate
that
really
love
to
see
it
documented,
though,
because
I
was
reading
the
epic
didn't
see
that
yeah,
that's
kind
of
where
I
would
expect
to
see
that
the
re-architecture
epic,
okay.
C
There,
the
one
that
says
main
settings,
epic
setting.
E
Oh,
no,
I
mean
oh
we've
got
you.
Thank
you.
C
C
E
E
Okay,
that's
good
and
then
yeah,
I
think,
clarity
around
the
proposal
and
I
think,
if
I
understand
it,
it's
make
the
settings
for
features
that
are
currently
in
admin
accessible
to
com
users,
and
is
that
why
we're
talking
about
the
cascading
stuff
or
is
that
a
totally
separate
concern.
C
Just
to
the
settings
in
general,
just
because
of
when
what
austin
had
made
a
comment.
You
know
how
they
had
implemented
something.
But
then
it
was
didn't
work
as
expected,
because
it
was
assumed
that
it
worked
off
of
some
inheritance
that
didn't
exist
so
because
we
don't
have
a
defined
inheritance
model
or
a
way
to
do
enforcement
of
inheritance
of
settings
or
behaviors
that
that
needs
to
be
added
as
a
feature.
C
But
that
kind
of
ties
into
this
as
well,
maybe
not
directly
because
it's
not
redoing
the
settings,
ux
it's
more
about
the
gitlab
environment
and
some
of
the
problems
that
exist.
Because
of
this
weird
assumed
inheritance.
That's
not
actually
an
inheritance,
but
as
it
exists
that,
since
it's
tangentially
related,
might
as
well
just
kind
of
connect
the
dots
anyways
as
well
as
it
would
make
sense
in
this.
B
E
Okay,
I
mean
it
looks
like
a
sort
of
a
road
map
has
been
laid
out
here
in
the
main
epic
conduct,
ux
research
to
understand
baseline
findability
and
usability,
and
that's
this
epic
and
phase
one
first
step
is
checked
off
understand
how
users
expect
to
access
settings.
It's
been
checked
off.
That's
this
one.
E
And
this
is
still
open
and
looks
like
I
don't
know
if
there's
been
much
movement
on
it,
but
I
think
that
I
don't
think
we
want
to
take
on
settings
improvement
and
the
cascading
thing
at
the
same
time,
just
because
of
scope,
I
mean
I'm
just
talking
out
loud.
Does
anyone
agree
that
those
two
things
are
pretty
big
or
this
is
really
big
in
scope
and
we
might
want
to
focus
on
a
smaller
problem
than
this
or
continue
to
pursue
this
and
leave
the
smaller
things
aside
for
now,.
A
I
don't
know
what
access's
prioritization
roadmap
looks
like
so
I'll.
Leave
that
one
up
to
daniel,
I
know
for
compliance.
The
cascading
settings
is
routinely
a
question.
That's
brought
up.
C
Yeah,
it's
kind
of
high
priority
for
us,
because
we've
already
defined
the
well
not
yet
because
we
have
this
big
engineering
spike,
but
we
have
the
work
already
defined
in
the
back
end
of
how
to
implement
this
and
how
we
want
to
provide
a
front
end
for
that,
so
that
users
can
interact
with
it.
So
we
can
start
getting
data
off
of
or
getting
feedback
on
this
feature
yeah,
and
so,
as
we
move
forward,
we're
going
to
try
and
implement
that
to
all
the
settings.
C
But
that's
where
it
connects
to
that
epic.
That
I
linked
is
that
well,
if
I'm
going
to
implement
this
across
the
environment,
to
all
the
settings,
I
want
to
make
sure
that
I'm
jumping
in
at
the
right
place
the
right
time
and
just
instead
of
coming
in
ahead
of
everyone
or
after
the
fact
saying.
Oh
wait.
You
gotta
do
everything
over
again
because
we're
in
pla
doing
this
enforcement
of
enabling.
E
Why
do
we
need
to?
Why
do
we
need
to
do
the
cascading
in
all
of
the
sites.
C
E
Okay,
and
so
we
have
an
inventory
of
which
settings
need
to
cascade.
C
Well,
right
now
again,
this
is
only
like.
The
initial
proposal
was
that
delete
project
or
project
deletion
enforcement
because
we
needed
one
touch
point
to
get
into
the
back
end.
To
connect
the
dots
to
see.
Does
this
functionally
work?
Can
we
provide
a
front-end
experience
for
a
user
to
test
this
and
get
the
nvc
outright
so
in
terms
of
categorizing
it
or
doing
it
for
the
rest
of
the
environment,
that's
sort
of
where
I'm
relying
on
everyone
else
to
say
hey.
C
I
have
also
a
setting
that
needs
to
be
done,
cascading
or
whatnot,
and
that's
where
austin
and
michael
lee
have
been
really
helpful
about
that.
So
again,
it's
a
collaborative
thing.
But
again,
that's
why
I
wanted
to
say.
If
I
look
back
at
this
other
settings,
epic,
I
want
to
make
sure
that
I'm
joining
in
or
doing
the
work
with
everyone
at
the
right
place
at
the
right
time,
and
not
just
saying
I'm
doing
this
cascading
project
and
it's
done
now
and
you'll
have
to
go
redo
all
the
work
you've
done
already.
A
Yes-
and
I
wanted
to
say
why
the
cascading
thing
is
important
to
me-
is
we
have
customers
on
the
compliant
side
that
ask
for
a
setting
from
the
project
level
to
be
exposed
at
the
group
level,
but
because
we
don't
have
a
defined
pattern
in
pajamas,
which
pattern
do
we
copy?
What?
How
do
we
know?
What's
the
right
direction
to
go
so
the
one
video
I
just
posted
about
loom?
A
I
talk
through
these
different
ones,
so
like
prevent,
sharing
a
project
to
sibo,
email
notifications
and
enable
delayed
project
removal
all
have
different
inheritance
models,
prevent
and
disable
these.
These
two
here
will
inherit,
but
if
you're
a
group
owner
you
can
modify
this
one,
but
you
can't,
if
you're
a
group
owner
for
this
one
can
be
modified.
The
group
level
and
then
enable
enable
delayed
product
removal
only
affects
children
projects,
but
not
subgroups
and
projects
of
those
subgroups.
A
So
then
it
becomes
a
challenge
because
then
you
have
to
do
things
like
add
an
enforcement
option,
which
then
leads
to
issues
with
things
like
this,
where
you
have
users
trying
to
deselect,
reject
unverified
users
in
project
settings,
push
rules
and
then
expecting
that
reject
unverified,
be
off,
and
then
it's
not
inheriting
right,
because
there's
no
defined
pattern.
It's
confusing
users
about
like
did
my
setting
affect
all
the
projects
that
I
intended
it
to,
or
does
it
not?
A
E
Well,
it
looks
like
the
settings
is
owned
by
the
same
stage
group,
that's
working
on
navigation
and
I
think
they're
currently
focused
on
navigation.
E
That's
the
editor
group,
so
it
kind
of
feels
like
that's
on
hold
and
we
just
have
to
keep
our
problem
space
more
narrow
for
now
and
for
the
cascading
thing
you
know,
let's
take
it
one
one
one
problem
at
a
time,
rather
than
all
of
it
looks
like
holly
ducked
out
because
we're
at
time,
but
thanks
for
coming
everybody,
and
thanks
for
coming
libor,
hope
to
see
you
again
next
week
and
thanks
everyone
for
the
help.