►
From YouTube: 2021-07-06 Create:Code Review UX Sync
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
B
Yeah
so
last
week
we
had
a
chat
with
the
security
orchestration
category,
so
the
folks
from
the
secure
orchestration
category
from
the
container
security
group-
and
we
were
talking
about
that
epic,
where
essentially
the
idea
is
to
have
a
workflow
builder,
initially
focused
on
security
policies,
and
you
can
then
for
each
kind
of
policy.
You
have
different
figures
and
actions.
B
B
And
change
the
status
of
the
mergibility,
so,
for
example,
one
one
merge
requests
depending
on
the
the
policies
that
they,
that
the
project
has
one
merge
request,
may
have
a
vulnerability
check,
approval
rule
and,
and
so
the
merge
may
be
blocked,
but
another
one
depending
on
the
configuration,
could
be
good
to
merge
in
may
not
have
any
vulnerability
check
approval
rule.
So,
in
terms
of
the
merge
request,
experience
in
the
end
and
and
the
code
review,
experience
of
the
day-to-day
code
review
experience
it,
it
won't.
B
What
it
will
change
is
the
experience
of
setting
up
the
approval
rules,
and
then
we
also
have
the
larger
topic
of
how
this
new
way
of
setting
policies
and
this
kind
of
workflow
builder
with.
If
this,
then
that
structure,
how
does
that
fit
into
into
gitlab
as
a
whole?
Not
not
just
for
security
but
gitlab
as
a
whole?
And
if,
if
we're
okay
with
that.
A
Hidden
in
there,
I
think
one
of
your
biggest
ones
is.
Is
this
us
or
is
this
source
code,
and
I
would
say,
sort
of
in
the
absence
of
a
source
code
pm.
A
A
Part
of
me
feels
like
maybe
we
should
have
brought
approval
rules
to
code
review
and
I
know
why
we
didn't
at
the
time,
but
maybe
at
some
point
we
might
reconsider
that
and
figure
out
how
to
do
that,
because
I
think
that
experience
is
more
closely
related
to
the
merge
requests
than
it
is
to
why
we
left
them
in
source
code.
A
A
This-
and
I
think
you
brought
it
up
in
the
call
and
the
other
piece
is
I
I
am
maybe
less
con.
I
am
concerned
about
the
advanced
editor,
whatever
they
want
to
call
it
for
approval
rules.
I
think
like
that
is,
as
you
put
it
very
clearly
pandora's
box
in
terms
of
like
every
form
of
approval
rules
that
exist
someone's
going
to
now
say.
Well,
I
want
this
ver.
A
I
want
to
be
able
to
edit
them
this
way
and
like
it's
just
not
going
to
exist
that
way,
unless
we
all
stop
and
start
from
the
beginning
and
say
this
is
what
we
want
that
to
be,
and
I
think
that
goes
to
what
my
biggest
concern
here
is:
yes,
what
they
want
to
do
with
security
policies,
sort
of
logically
make
sense
in
terms
of
their
separation
of
permissions
and
how
they
want
to
slow
that
down.
A
My
biggest
concern
is
really
that
I,
as
a
pm,
can
probably
not
logically
explain
to
a
customer
how
and
where
they
would
now
go
in
the
application
to
configure
all
of
the
various
types
of
approval
rules
and,
like
let
alone,
could
we
then
go
back
to
amy
and
say:
hey
amy.
You
need
to
write
documentation
about
approval
rules
and,
depending
on
the
type
of
approval
rule,
you'll
have
to
send
people
to
like
four
different
places
in
the
ui.
A
They've
got
different
ways
that
you
can
figure
and
set
them
up
and,
like
all
of
that
happens,
and
then
this
is
how
it
works.
Once
you
get
into
an
approval
like
into
the
project,
I
think
that
to
me
is
the
the
larger
concern
I
have
is
that
this
gets
really
really
hard
to
explain
to
users,
because
we're
not
we're
not
someone's
not
holding
the
entirety
of
the
approval.
A
Experience
in
check
with
this-
and
I
think
that's
that's
probably
where
I'm
starting
with
a
concern,
is
that
that's
that's
the
piece
that's
hard
for
me
to
to
wrap
my
head
around
is
how
do
we?
A
How
do
we
talk
to
users
about
this,
and
that
comes
from
a
place
where
it
is
already
immensely
challenging
to
talk
to
users
about
the
difference
between
configured
approval
rules
like
explicit
approval
rules,
protected
branch,
approval
rules
and
code
owner
approval
rules.
Those
are
all,
in
theory
like
different
forms
of
approval,
and
that
leaves
out
everything
else
and
those
are
like
our
mess
that
we
created
and
then
we're
just
gonna
like
keep.
A
A
I
think
like
what
they're
trying
to
do
taking
it
away
to
me
that
that's
where
I'm
concerned,
I
guess
it's
not
an
answer
to
your
question,
but
that
I
think
that's
my
after
I've
thought
about
this
more
and
more
and
didn't
sleep
the
first
night
and
sent
you
that
super
long
message
that
I
haven't
posted
anywhere.
I
haven't
that's
where
I'm
at.
I
think
for
now.
B
B
So,
let's
talk
about
the
easy,
easy
or
thing
that
we
co-reviewed
don't
necessarily
need
to
worry
so
much
about,
which
is
that
pandora
box.
I
I
found
a
a
documentation
page
about.
B
B
While
I
was
looking
at
the
categories
page
and
I
it
doesn't
have
any
screenshots,
so
I
can't
say
for
sure,
but
it
looks
like
they
already
have
something
like
that
implemented
because
they
talk
about
a
visual
builder
below.
B
B
A
The
different
locations
that
you
now
go
to
configure
approval
rules
right,
like
the
you
as
a
project
owner
now,
need
to
visit
four
different
pages
to
configure
all
of
the
types
of
approval
rules.
It's
not
the
the
advanced
piece,
I
would
say,
is
part
of
the
workflow
builder.
What
I'm
concerned
in
that
pandora
box?
The
my
concern
is,
how
do
I
tell
you
as
a
project
owner
all
of
the
places
that
you
go
to
configure
approval
rules.
B
Yeah
yeah
links
to
an
issue
that
I
was
created
not
long
ago
well,
actually,
two
months
ago,
time
flies
framework
for
source
code
rules,
and
this
is
something
that
mike
nichols
from
soros
code.
He
is
taking
a
look
at
and
you
can
see
in
the
description,
a
screenshot
of
something
that
we
were
working
together
in
figma
and
it's
basically
it's.
It's
a
start.
B
It's
just
mapping
what
we
already
have
today
in
terms
of
yeah
rules
that
control
what
can
or
cannot
go
into
into
in
terms
of
source
code
management,
approval
rules,
protected
branches,
code
owners,
static
checks,
push
rules
and
protected
tags,
and
I
was
pushing
this
with
him,
because
I
want
us
to
look
at
this
holistically
and
understand
that
the
goal
is
the
same
like
when
someone
is
looking
across
all
of
these
features.
What
they
want
is
effectively
the
same
the
same.
B
They
want
to
set
the
rules
of
what
goes
in
or
not
or
what
requires
some
override
mechanism,
which
is
like
approvals
or
something
like
that,
and
so
I
think
this
is
something
that
first
of
all,
we
already
have
a
very
disjointed
experience,
and
this
is
something
that
we've.
B
I
think
it's
also
linked
here
in
the
beginning
of
the
issue
of
the
recommendations
from
a
category
maturity
scorecard
that
we
did,
which
there's
an
issue
to
improve
the
organization
repository
and
merge,
request
policy,
settings
and
there's
also
an
explanation
of
the
severity
of
the
the
problem,
and
this
just
compounds
that
problem.
So
basically
we
would
have.
B
I
don't
know
if
it
would
be
yet
another
column
for
this,
which
is
yet
another
location
in
the
ui,
which
will
be
very
difficult
not
only
from
a
user
experience,
the
user
experience
in
the
product,
but
also
what
you
said:
okay,
that
it
would
also
be
difficult
to
explain
to
users
or
customers
that
go
through
the
documentation,
because
the
way
we
organize
the
documentation
needs
to
make
some
sense.
And
if
the
experience
is
disjointed,
the
documentation
is
likely
to
be
disjointed
as
well
or
very
difficult
to
make
sense
like.
B
Maybe
you
need
to
preface
the
documentation
by
saying
hey,
we
know
the
experience
is
disjointed,
so
bear
with
us
in
this
documentation
page
but
anyway.
So
there's
this
and
mike
is
working
on
this,
and
I
haven't
yet
included
him
in
this
conversation
about
what
the
security
orchestration
category
is
thinking,
but
I
I
intend
to
do
so
in
in
the
short
term
and
yeah.
B
I'm
also
concerned
that
this
would
be
another
thing
to
support
in
terms
of
approval
rules
and
what
I
would
like
again
coming
back
to
what
I
was
going
to
say
in
the
beginning.
B
What
I'd
like
to
see
is
what
we
don't
usually
do
at
gitlab,
which
is
to
think
further
into
the
future
and
the
consequences
of
our
iterations
and
what
I've
heard
in
that
call,
which
is
legitimate,
was
sam,
saying
that,
yes,
there
are
what,
if
scenarios,
but
we're
iterating
our
way
there
and
we're
doing
this
as
a
first
iteration
we're
shipping
this
and
we're
going
to
learn
from
it,
which
is
valid.
B
B
But
the
experience
hasn't
been
thought
through
about
how
that
would
be
reconciled
with
the
other
kinds
of
approvals
and
what
you
said
like
now
that
you
have
to
go
to
another
location,
and
this
is
just
for
vulnerability
checks
in
the
beginning.
It's
not
going
to
be
for
licensed
checks,
and
we
don't
know
if
license.
Checks
will
be
on
board
with
this
or
not.
B
B
A
Yeah,
I
think
that
makes
sense.
I
think
the
work
mike
is
doing
is
good.
A
I
know
austin's
also
heavily
involved
in
that,
because
of
compliance
wanting
to
have
some
say
over
how
approval
rules
are
managed
and
configured
which
sounded
like
a
chief
concern
of
the
secure
group
was
that
there
were
some
policy
and
permissions
issues
with
how
people
could
access
those
and
how
they
flowed
down
that
compliance
feels
like
they're,
also
trying
to
solve,
which
means
we'll
we'll
also
end
up
with
sort
of
two
different
ways
that
we
solve
cascading
rule
sets
across
things.
So
I
think,
that's
another
area
that
we
need.
A
Yeah,
I
think
maybe
we
just
try
and
force
those
conversations
and
have
mike
take
a
look
at
this
and
have
austin
take
a
look
at
this
and
and
get
them
to
sort
of
lead
the
charge
on
how
we
do
or
don't
or
have
this
go
through
or
don't
have
this
go
through
through
the
process.
I
know
sarah
was
in
the
call.
Last
week
I'm
gonna
talk
to
sarah,
either
today
or
tomorrow
again
just
to
sort
of
get
her
her
take
on
this
and
see
how
she's
feeling
as
well.
B
Yeah
yeah,
I
think,
as
I
said,
I
think
this
can
compound
an
existing
problem.
B
And
I
understand
why
they're
doing
it
and
they
have
valid
reasons
to
or
at
least
the
problems
that
they
explain
are
valid
and
they
don't
want
to
go
out
of
their
way
to
fix
or
extend
our
permissions
model
to
allow
this
granular
level
of
deciding
who
can
change
the
policies.
B
But
the
thing
is
that
what
they
will
build
here
like
having
a
separate
project
that
has
the
security
policies,
it's
something,
as
you
said,
like
the
compliance
group,
will
want
that,
and
compliance
minded
users
will
want
that
as
well.
Perhaps-
or
maybe
they
want
it
in
the
same
product
and
the
same
thing
can
happen
for
someone
that
is
a
that
is
setting
up,
you
know
protected
branches
or
push
rules
or
protected
tags
or
even
other
kinds
of
approval
rules.
B
They
might
say
I
want
to
keep
those
separate
from
the
project
settings
because
maintainers
can
access
those
settings
as
well
and
change
them,
and
I
think
this
then
becomes
also
a
philosophical
discussion
about
how
we
want
to
structure
and
and
extend
our
permissions
model.
If
this.
This
is
the
way
to
do
it
like.
If
any
time
you
want
to
do
something
in
isolation,
we
need
to
do
it
through
a
separate
project.
Is
that
the
way
to
do
it.
B
I
think
there
are
so
many
different
considerations
here
that,
as
I
said,
it
feels
like
we're
just
okay,
let's
ship
this
as
it
is
and
then
see
how
it
works.
B
I
think
it
would
be
useful
to
do
more
user
validation
with
this
and
problem
validation,
and
not
only
from
security
standpoint,
but
also
from
the
other
points
of
views,
but
yeah
thanks
for
for
bringing
that
up
with
with
sarah
and
I'll
bring
it
up
with
with
mike
and
austin
I'll,
probably
send
them
the
recording
of
the
was
it
recorded.
I
think
it
was.
There
are
chats
last
week
with
them.
B
Sometimes
that's
needed,
I
think
that's
something
we
should
add
to
our
exceptions,
list
of
exceptions
for
synchronous
calls
and
meetings.
Is
you
know
exactly
like
psychological
safety
and
mental
health
anyway,
okay
amy,
you
have
yeah,
I
don't
want.
I
don't
think
at
least
for
my
part,
there's
nothing
else
that
I
want
to
bring
up
about
this
topic.
Kai.
Is
there
anything
you
want
to
talk
about
this.
B
C
In
the
long,
there
is
a
short-term
note,
which
is,
let
me
know
if
there's
anything
that
you
need
me
to
wrap
up
before
tomorrow
afternoon,
because
we're
going
on
a
road
trip
and
there
won't
be
a
laptop
but
long
term.
I
do
want
to
solve
the
problem
of
how
do
we
prepare
for
amy
to
go
backpacking
somewhere
interesting
in
the
world,
because
when
the
world
becomes
a
little
more
normal,
we're
getting
back
on
that.
B
Well,
thanks
for
letting
us
know,
I
I'm
very
excited
about
your
road
trip
it.
It
sounds
like
your
husband
is
also
excited
about
the
rocky
trip
and
yeah,
I'm
very
happy
that
you're
taking
this
time
off,
as
I
already
said,
and
yeah
we
will
survive.
I
guess.
B
Yeah
and
in
terms
of
redundancy
yeah,
I
think
that's
that's
an
interesting
discussion
to
to
have
but
yeah.
Fortunately,
the
kind
of
work
that
you
do
yeah.
I
think
it's
without
trying
to
talk
too
much,
but
I
think
it's,
the
kind
of
work
you
do
is
extremely
important
and
valuable,
but
it's
also
interesting
that
it's
very
easy
to.
E
B
On
and
and
if
something
is
not
right,
it's
very
easy
to
change
and
make
it
amazing,
which
I
think
sometimes
seems
to
lower
the
value
of
the
work
that
technical
writers
do,
because
it's
just
text,
you
know
right.
What's
what's
the
big
deal
about
text,
but.
C
C
B
Yeah
yeah
thanks
for
sharing
and
yeah,
you
should
take
time
off
and
go
on
road
trips
whenever
you
like,
and
don't
have
to
worry
about
our
work
here.
Excellent.
E
A
B
A
You're
taking
time
off
enjoy
your
enjoy
your
trip
time
off
is
good.