►
From YouTube: Compliance: UX Office Hours (2021-07-09)
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
Hey
everyone:
my
name
is
austin.
It's
your
practice.
Center
gitlab!
It's
been
a
bit
since
last
posted
a
little
sick
last
week.
So
let's
jump
right
in
this
week,
we've
updated
the
color
picker,
so
it's
been
added
into
pajamas,
so
there'll
be
some
documentation
thanks
so
much
for
helping
implement
that
on
the
front
end
we'll
be
looking
to
get
that
added
to
get
lab
ui
as
well.
So
we
have
the
existing
components,
go
alongside
it,
but
at
least
the
behavior
has
been
documented
in
that
merge
request.
A
A
So,
if
I'm
reviewing
a
pipeline-
and
I
dig
into
the
jobs,
there
will
be
a
badge
that
appears
alongside
the
other
badges
that
would
appear
with
jobs.
Some
of
these
are
tags,
but
some
of
these
are
also
badges
to
identify
jobs
that
are
manual
or
allowed
to
fail.
There
are
different
conditionals.
I
can
kick
these
off.
Assuming
that
back
end
can
identify
a
way
to
show
where
this
job
originated
will
be
able
to
display
that
on
the
front
end.
A
It
was
a
vision
for
how
audit
events
would
grow
in
its
usability,
and
a
lot
of
these
were
super
applicable
to
the
competitor
evaluation
that
I
ran.
So
I
just
decided
to
continue
to
run
with
this
epic
cut
some
scope
from
smaller
ones,
close
some
older
issues
that
no
longer
applied.
So
these
are
a
lot
of
improvements
that
we
couldn't
make
to
make
the
usability
of
audit
events
better.
A
I
would
look
for
these
to
probably
get
scheduled
for
one
of
our
sus
issues
for
the
system
usability
scale
each
milestone,
so
we'll
look
for
small
incremental
ways
that
we
can
improve
audit
events
over
time.
Since
that's
one
of
our
popular
features.
A
Next,
I've
updated
a
couple
proposals,
so
these
issues
are
purely
for
a
proposal
sake
just
to
try
and
sync
with
some
other
stage
groups
on
a
direction
forward,
but
to
try
and
get
us
some
momentum
on
protected
branches.
What
we
are
thinking
about
doing
is
being
able
to
enforce
settings
at
a
group
or
subgroup
level
that
will
be
inherited
by
projects
for
a
new
project
specifically
or
existing.
A
If
it's
enforced,
I
would
say
the
way
that
this
is
scoped
is
it's
supposed
to
be
as
small
as
possible,
so
this
is
only
going
to
affect
the
default
branch
so
essentially
you're
creating
a
default
role
for
your
default
branch
to
protect
it.
That
way,
we
can
build
upon
existing
knowledge
or
existing
logic.
A
So
today
you
would
see
maine
have
maintainers,
be
allowed
to
merge
and
to
push
the
other
side
to
be
disabled,
so
this
would
be
essentially
being
able
to
change
that
so
that
when
that
repository
gets
initialized
it
would
be
set
to
what
needs
to
be.
That
should
really
help
a
lot.
I
think
the
main
concern
of
protective
branches
is
the
default
branch
and
that's
usually
the
one
that
organizations
care
about
the
other
one
from
the
merge
request.
A
A
Information
updated
for
the
date
range
picker,
so
value
stream
management
and
merge
request
analytics
those
pages
both
have
this
date
range
indicator
that
calculates
the
number
of
days
that
are
in
the
in
the
date
range
picker
just
to
show
you
how
many
days
been
selected.
This
is
useful
because,
as
we
know
with
audited
events,
we
limit
it
to
one
month's
view
or
31
days
so
being
able
to
quickly
know
how
many
days
you've
selected
and
compare
that
to
your
constraint
for
value
stream
management.
It's
like
365
days
and
for
merge,
request
analytics
it's.
A
I
think
it's
shorter
than
that.
So
this
gets
us
to
at
least
a
documented
portion
in
pajamas,
but
there
will
be
a
follow-up
to
try
and
get
this
into
gitlab
ui.
A
And
then
we're
also
really
close
to
getting
this
piece
of
documentation
merged
as
well,
so
this
will
help
clarify
when
to
use
the
help
icon,
as
well
as
including
a
pop-over
with
it.
I
think
this
will
be
helpful
for
keeping
that
behavior
more
standardizing
our
product.
Merge
requests
take
a
little
while
to
load,
so
just
go
through
it.
I
guess
so.