►
From YouTube: Code Review/Compliance Sync on External Checks
Description
Code Review and Compliance sync on https://gitlab.com/groups/gitlab-org/-/epics/3869 to get some clarity on the direction and help collaborate on paths forward.
A
B
Yeah,
so
I
just
wanted
to
level
set
before
we
really
dig
into
it
around
what
the
goals
we're
trying
to
get
out
of
this
meeting
are,
since
we
only
have
about
25
minutes.
I
figured
that'd
be
a
good
thing
to
discuss
up
front
based
on
the
initial
issue
discussion.
It
wasn't
clear
to
me
if
this
was
intended
to
be
hey.
B
A
A
B
I
actually
saw
an
mr
that
I
think
would
be
really
helpful
for
us
here.
I'm
hoping
we
can
discuss
the
concerns
in
this
meeting
and
we
don't
have
to
talk
through
stuff
work.
I
saw
an
image
korea,
though,
about
escalate
early,
so
kai,
if
you-
and
I
can't
figure
this
out
together,
we
can
always
you
know,
put
something
together-
talk
to
david
about
it
and
get
him
to
make
a
decision
with
us
and
that'd
be
how
I
proposed
we'd
move
forward,
because
at
this
point
we're
not
really
prepared
to
to
stop
work.
B
A
Everyone
wants
their
things
on
the
merge
request
page
and
then,
at
the
same
time,
we're
under
a
constant
barrage
of
performance
and
usability
concerns,
and
all
these
other
things
going
on
and
they
all
fall
on
us.
Even
though
we,
we
largely
don't
add
sort
of
new
features.
It's
other
groups
that
do
this,
and
so
we're
trying
to
figure
out
how
we
balance
making
sure
that
product
and
design
are
engaged
much
earlier
in
this
moving
forward.
A
Yeah,
I
think
we
can
do
that.
I
think
the
first
one
up
is
the
terminology,
and
this
is
probably
the
easiest
one
to
solve.
It
may
depend
on
some
of
the
answers
to
the
below
one,
but
right
now
I
would
say
we
have
a
concept
of
approvals
and
we
have
a
concept
of
merge
checks
and
those
are
the
two
things
that
exist.
A
This
took
both
of
those
mashed
them
into
one
and
then
from
a
like
ui
placement
put
them
in
approvals,
and
so
I
think
it
would
be
good
probably
to
understand
what
this
is
and
what
the
user
experience
is
to
decide.
If
it
is
one
of
these
two
things
and
if
not
do
we
actually?
Are
we
really
committing
to
introducing
a
third
concept
of
some
kind
into
the
merge
request?
Is
that
a
path
where
we
want
to
go
down
here.
C
I
initially
thought
the
approver
section
worked
well,
I
was
kind
of
taking
it
off
of
what
daniel
mora
had
initially
suggested,
since
he
was
in
my
role
before
I
joined
git
lab
and
because
we
saw
it
was
like
an
optional
thing
and
we
thought
you
could
have
optional
approvers.
It
felt
like
a
natural
place
to
just
start
with
an
iteration
now
its
final
destination,
I
think,
could
totally
be
up
to
debate.
C
It's
farther
down
the
list,
but
I'll
highlight
where
pedro
provided
a
suggestion
around
like
status
checks
being
introduced
into
branch
policies.
I
think
that
really
does
represent
well
the
intent
of
what
our
customers
are
looking
for.
So
I
do
think
a
third
type
of
check
is
necessary,
but
the
way
we
integrate
it,
I
totally
see
evolving
over
time.
A
C
Just
awareness
we
do
have
like
a
follow-up
issue
that
we
like
to
build
upon
to
give
the
user
the
ability
to
retry
an
api
if
it
fails
the
first
time,
but
it
was
just
cut
from
scope
for
the
initial
release,
because
it
was
just
too
much
functionality
to
bacon
all
at
one
time,
so
we
were
trying
to
roll
it
out.
Incrementally.
C
Okay,
in
terms
of
actually
using
the
term
approval
gate,
I
really
don't
have
a
strong
opinion
on
it.
I
was
purely
going
off
of
what
I
had
heard
from
other
team
members
from
their
experience
with
interacting
with
customers.
Since
this
kind,
this
idea
kind
of
existed
before
I
joined,
so
I
was
taking
a
lot
of
what
other
people
had
already
sourced
for
information.
D
C
D
C
Sigma
so
like
this
case,
where
we
have
like
these
questions,
this
questionable
link,
that's
failed.
We
don't
want
to
block
the
ability
to
approve.
We
don't
want
to
block
the
ability
to
merge
just
because
this
didn't
pass.
We
just
want
to
give
these
users
in
gitlab
the
ability
to
see
that
a
api
that
they're
relying
on
similar
to
that
status,
check
that
you're,
highlighting
in
azure
as
a
way
just
to
keep
people
informed
about
the
other
systems
that
are
relying
on
these
different
changes.
C
B
Security
and
compliance
in
general
we're
going
to
be
taking
a
fail,
open
sort
of
approach.
You
know
I
I
know
sid
and
matt
had
a
number
of
videos
discussing
like
if
people
need
to
push
to
production,
we
can't
block
to
that
case
in
default.
So,
like
austin's
saying
this
is
really
to
raise
awareness,
hey,
there's
a
problem,
you
should
probably
act
on
it,
but
you
can
still
go
ahead.
Merge
because
if
your
app
is
down,
that's
the
most
pressing
thing.
D
That
is
what
we
have
today
for
security
vulnerabilities
where,
by
default,
we
just
make
users
aware
that
there
is
like
a
critical
security
vulnerability,
but
it's
by
default.
It
doesn't
block
the
merge.
It
would
only
block
the
merge
if
you
set
up
the
vulnerability,
check,
approval
rule
and
make
it
required.
D
There
are
humans
involved
and
they
use
the
gitlab
ui
to
make
that
happen,
and
you
assign
them
as
reviewers.
So
there's
there's
a
with
approval
rules.
What
we're
trying
more
and
more
is
to
keep
things
on
the
human
level
right.
So
to
like
this,
this
is
a
button
that
you
press.
You
have
reviewers,
you
see
the
status
of
approvals
by
those
people
and
the
moment
we
start
to
mix
these
concepts.
I
think
it
could
become
more
confusing
about
what
what
is
what
is
an
approval
in
the
end
and
what
is
an
approval
rule?
D
I
think,
in
a
way
what
you're
describing
would
be
to
allow
customers
to
define
their
own
merge
requests
widgets
in
a
way.
So
today
the
the
ones
we
have
baked
into
the
app
are
code:
quality
security,
vulnerabilities
browser
performance,
blah
blah
blah.
We
have
all
of
those
lines
all
of
those
different
widgets
and
it
seems
like
what
you
would
like
is.
C
That
sounds
like
a
really
great,
like
long-term
vision,
for
how
you
could
provide
a
lot
more
flexibility
for
customers
or
users
really
to
define
how
they
want
their
merge
request.
Experience
to
play
out-
and
I
guess,
as
a
example
of
that
need,
would
be
the
number
of
variations
that
we
have
in
terms
of
the
different
checks
that
come
into
emerge.
Request.
C
Going
back
to
your
initial
point
on
the
approvals
section
being
tied
to
specific
people
and
approvers,
I
think
that
makes
total
sense.
I
think
when
we
initially
designed
and
discussed
this
feature,
I
don't
think
vulnerability.
Checks
have
been
introduced,
yet
I
think
that
maybe
came
after
this
was
going
back
to
last
august,
so
I'm
not
100
sure
on
that.
C
D
That's
a
good
question
because
we
also
we're
also
facing
a
lot
of
challenges
with
the
existing
widgets.
So
in
a
way,
what
this
is
doing
from
an
experience
standpoint
is
just
like.
Instead
of
creating
a
new,
visible
widget
is
placing
that
information
inside
of
a
collapsed
area
which
you're
showing
here
and
that
collapsed
areas
happens
to
exist
inside
of
the
approval
rules
area,
it
does
and
to
be
honest.
B
B
B
I
wonder
if
we
could
do
something
like
say:
hey
austin
is
the
admin
for
third
party
compliance
system.
If
this
is
blocking,
you
know,
go
ping
him
that
gives
the
person
someone
actionable
to
go
reach
out
to
if
they
don't
understand
what
it
is
or
if
it
is,
you
know
like
acme
compliance.
They
can
just
go
into
that.
Do
the
thing
and
unblock
themselves,
one
to
throw
that
out.
There.
A
C
B
The
other
side
of
this
api
it
may
or
may
not
have
a
human
attached
to
it.
It
might
be
some
process
that
just
scans
code
in
the
mr
and
gives
an
automated
pass
fail,
or
it
could
be
a
ping
that
goes
to
a
human.
They
review
something
they
manually
click
a
button
and
it
communicates
back
so
just
based
on
this.
We
don't
necessarily
know
if
it's
computer
or
human
generated
with
the
past
fail
status.
D
Yeah,
I
think
I
think
a
good
way
to
to
look
at
this.
If
we
were
thinking
about
the
human
and
not
human
is
is
that
concept
of
that?
I
was
saying
before
and
mimicking
what
the
security
scanning
is
doing
or
what
the
license
compliance
widget
is
doing,
but
from
an
api
standpoint
you
would
create
these
customers
would
create
these
on
the
fly.
D
D
And
if
you
want
it,
you
could
also
have
an
approval
rule
for
it.
So
I
think
what
we're
talking
about
here
is
two
things.
One
is
giving
the
information
from
an
external
service
that
is
posting
information
to
the
merge
request
because
it
scanned
the
changes,
and
this
is
what's
happening,
so
we
create
and
give
that
information
on
the
fly
and
then
as
a
a
second
step.
D
If
you
want
to
do
something
about
it,
if
you
want
to
block
the
merge,
you
have
two
things
that
you
can
do.
You
could
just
block
it
directly
and
say:
hey.
This
is
a
merged
check
and
it's
not
passing
the
check
and
it's
blocked
and
you
need
to
fix
this
or,
alternatively,
you
use
approval
rules
as
an
override
mechanism
and
that's
what
the
vulnerabilities
check
and
the
compliance
check.
D
C
D
C
A
People
make
an
active
choice
to
click
a
button
and
do
something,
and
if
it's
not
a
people,
making
an
active
choice,
we
sort
of
it's
not
it's
not
part
of
that.
Okay
just
makes
sense
for
fun.
I'm
gonna
throw
out
like
a
crazy
alternative
idea
if
it
were
possible
to
not
just
approve
but
to
reject
like
under
the
approvals
umbrella,
to
say
no,
I
disagree
with
this
and
then
have
overrides.
A
I
would
say,
rejection
is
a
hotly
debated
topic
and
I
think
the
code
review
group
has
long
had
an
opinion,
and
I
I
am
the
torchbearer,
I
guess,
of
this
opinion.
Now
we
don't
want
anything
that
can
block
a
merge
request,
and
so
there
are
lots
of
people
that
come
from
garrett
and
other
systems
that
want
down
votes
and
blocks
and
rejects
until
you
fix,
whatever
I've
told
you
to
fix
they're
four-year-old
issues
with
hundreds
of
upvotes
and
we
sort
of
actively
say
no
on
a
regular
basis
to
that.
A
A
C
point
c:
actionability.
I
think
we
talked
about
this
a
little
bit.
One
of
the
things
that
you
know
we
want
to
make
sure
of
for
pieces.
Is
that
as
an
engineer,
if
you
are
told
something
you
can
action
it
and
I
don't
necessarily
mean
action
to
retry.
One
of
the
benefits
of
approvals
is
like
we
tell
you
who
can
approve
it,
and
so
you
know
who
to
go
ping
in
a
comment
right.
A
It
would
not
be
helpful
if
you
told
me
in
an
mr
that
my
code
reduced
the
code
quality,
but
then
didn't
tell
me
how
to
like
make
that
code
better
to
get
above
the
threshold
that
I
need
to
merge,
because
I
may
not
know
how
to
do
that
or
who
to
ask
to
do
that
thing,
and
so
this
is
less
about
like
a
retry
button
and
doing
that
and
more
about
like
if
this
fails.
What
do
I,
as
engineer,
do
to
get
my
code
into
the
the
merge.
D
D
B
Yeah,
I
would
agree
with
that
and
that's
certainly
something
we're
going
to
have
to
figure
out
before
we
do
a
sort
of
on
by
default
approach.
I
do
think
there
is
a
nuance
that
there's
a
difference
between
saying,
hey,
there's,
a
problem
and
here's
how
you
can
fix
a
problem.
There
is
still
value
in
throwing
the
red
flag
up,
even
if
I
have
no
idea
how
to
fix
it
right.
B
C
Yeah,
I
think
that,
in
my
mind,
what
would
make
sense
is
like
a
follow-up
to
this.
If
we
continue
building
it
out
is
before
we
really
turn
this
on
by
default.
We
should
have
an
experience
more
closely
aligned
to
security
scanning
and
license
compliance
using
this
informational
section,
as
opposed
to
dedicating
it
to
the
approvers
area.
A
Yeah,
I
think
that's
the
informational
piece
right.
None
of
those
that
block
right
there,
that
you're,
showing
with
all
those
widgets
there
sort
of
impact
the
merge
right,
there's
they're
purely
like
informational,
and
that's
fine,
to
alert
that
it's
when
you,
when
you
want
to
go
and
impact
the
merge,
you
need
to
help
people
figure
out
how
to
get
through
that
step.
The
merge
button
does
this
with
merge
checks
like
that
merge
button.
A
A
B
A
Yeah,
I
would
if-
and
I
think
this
is,
if
you
move
that
out
of
approvals
right,
if
I
think
we're
all-
maybe
agreed
that
that's
not
the
right
spot
yet
in
the
way
it's
functioning
and
it
goes
to
an
informational
widget,
then
it
doesn't
need
to
be
as
actionable.
It
can
be
much
more
informative
down
there,
because
it's
not
in
this
like
area,
that's
sort
of
designed
for
action.
A
C
B
Like
another
time
check,
we
only
have
three
minutes
left
and
I
want
to
make
sure
we
we
talk
through
next
steps
on
this.
I
know
we
didn't
get
through
the
the
whole
agenda
document,
but
what
I'd
like
to
propose?
Is
we
go
ahead
and
create
an
issue
to
finish
some
of
these
discussions
that
we
either
started
or
didn't
get
to
start?
We
can
do
that.
Asynchronously.
B
From
my
perspective,
the
feedback
was
great.
We
really
appreciate
it.
This
is
going
to
help
make
it
lab
the
product
better.
This
doesn't
sound
like
blocking
feedback
to
me
still,
though
so
kai.
I
don't
know
if
you
still
feel
like
this
needs
to
be
a
stop
work,
conversation
or
feedback
for
future
generations,
but
you
and
I
can
probably
work
through
that
asynchronously
as
well,
unless
you
yeah.
A
E
This
to
me
as
well
sounds
the
changes
that
you've
described
sound
more
like
front
end
changes
than
back
end
changes.
Nothing
we've
discussed
as
far
as
I
can
tell
would
change
any
of
the
work
I'm
doing,
but
we
will
need
to
discuss
with
robin
yarn
our
front
and
engineers
to
potentially
change
what
they're.
A
Yeah-
and
I
think
I
think
those
are
fine
for
next
steps-
the
only
other
one
would
be
performance
just
as
an
fyi.
Our
group
is
gonna,
spend
q2
working
on
performance
for
probably
the
second
time
in
a
year,
and
so
just
keep
in
mind
with
everything
that
you
do.
We
get
to
be
the
the
brunt
of
the
feedback
when
performance
goes
awry
in
the
merge
request,
and
so
your
your
thoughts
about
that
when
you're
implementing
things
are
appreciated.