►
From YouTube: 2021-11-02 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
All
right,
I
put
the
first
one
up
now,
the
second
one,
which
is
the
blocking
approval,
so
pedro,
and
I
met
about
blocking
approvals
last
week
to
go
over
some
of
the
problem-
validation
work
that
he
had
done
agenda
and
some
notes
from
that
conversation
are
down
below
and
there's
a
recording
on
youtube.
A
I
think
I
I
put
this
one
on
here.
I
know
pedro.
We
ran
way
over
last
time
and
I
think
there
were
things
we
wanted
to
follow
up
on,
I'm
not
clear
on
what
they
are.
There
is
two
bolded
asks,
and
so
I
just
wanna
make
sure
is
that
is
the
last
one.
Is
the
only
ask,
or
was
there
anything
else
that
you
recall
that
we
needed
to
follow
up
on.
B
Yeah
I
bolded
that
one
today,
because
I
was
looking
through
the
agendas
and
I
was
also
trying
to
understand
what
was
the
action
point,
but
we
were
already
over
time.
B
Yeah,
I
think
I
think
those
are
the
only
two
so
the
first
one
is
something
that
we
can
try
to
to
work
and
experiment
and
see
if
it
helps
mitigate
some
of
the
of
that
problem
of
clearly
informing
other
stakeholders
about
my
stance
towards
these
changes
and
the
blocking
merge
is
yeah.
I
think
we
need
to
understand
if
people
are
using
the
all
discussions
must
be
resolved
option
or
not,
and
if
they're
not
using
it,
why
they're
not
using
it,
because,
I
think
that's
the
biggest
problem.
B
I
don't
think
I
mean
approvals
is
related,
but
I
don't
think
it's
necessarily
the
problem,
but
but
anyway
yeah.
I
think
you
can
ask
about
approvals
as
well,
and
let's
see
what
people
say,
I'm
I'm
that
issue
has
a
lot
of
people,
hundreds
of
participants
and
I'm
not
sure
what
will
be
the
signal
to
noise
ratio.
B
And
but
yeah
we
can
try
it
and
and
see
what
we
get
worst
case
scenario.
We
select
a
few
of
those
participants
and
customers
that
we
know
and
ask
them
directly.
A
Yeah,
I
think
that
makes
sense.
That's
that
was
my
understanding
as
well
was
just
follow
up
on
the
one
about
controls
that
are
in
place
and
whether
or
not
people
are
using
on
it
and
then
I
know
you
had
mentioned
trying
to
schedule
some
interviews
with
people.
I
think
we
can
do
that
too.
Depending
on
how
that
comes
back,
I
think
we
just
need
a
little
more
data
there,
so
we'll
try
that.
A
Okay,
this
one
I
just
tossed
on
here
too,
the
reporter
permissions-
I
linked
to
the
issue
where
this
came
up,
and
this
is
sort
of
the
second
one
that
has
come
up
around
permissions.
We
had
some
other
conversations
about
permissions
recently.
A
A
But
I
was,
I
would
agree,
probably
that
if
we
think
reporters
should
be
able
to
comment
on
a
merge
request,
they
should
probably
be
able
to
resolve
their
own
threats,
because
no
one
else
can
resolve
like
everyone
else
has
that
capability.
So
that
makes
sense.
I
think
my
question
is
more
like
was
that
the
right
permission
there
to
begin
with?
A
B
Yeah
I
mean,
I
think
I
mean
annabelle.
You've
you've
been
here
longer
than
me,
so
maybe
you
have
some
thoughts
as
well,
but
I.
B
I
think
that's,
I
don't
think,
there's
a
problem
with
leaving
comments.
B
The
problem,
a
potential
problem
can
arise
when
those
comments
block
merge
requests
which
they
do
by
default,
and
that's
the
other
issue
or
or
problem
that
I
highlighted
blocking
versus
non-blocking
threads
and
today
they're
blocking
by
default
and
there's
a
need,
even
for
you
know,
in
a
in
a
normal
feedback
and
review
space,
where
you
have
two
developers,
the
author
and
the
reviewer,
the
reviewer
might
want
to
leave
a
comment
that
is
not
blocking
and
that
doesn't
even
need
to
be
resolved.
It's
just
a
general
comment,
so
yeah.
B
I
think
they
should
be
able
to
to
comment.
I
I
saw,
I
think,
one
or
two
users
or
customers
mentioning
that
they
have
guests
and
or
reporters
coming
in
and
leaving
comments
on
on,
merge
requests.
I
don't
think
that's
a
problem.
B
You
know
changes
to
the
repository,
but
I
think
in
the
same
way
that,
let's,
let's
imagine
like
they
have
an
external
member
who's
a
reporter
and
they
report
a
bug
and
the
developer
creates
a
merge
request
to
address
that
bug
and
the
reporter
can
then
review
that
merge
request
and
you
know,
provide
some
feedback
hey
this
is
this
is
working.
This
is
addressing
my
need
or
not.
B
I
think
if
we
blocked
that
behavior
it
wouldn't
be
so
good,
because
they
would
now
have
to
go
back
to
the
issue
to
leave
comments
on
the
merge
requests
that
they
can
see.
So
I
think
if
they
can
see
something,
they
should
be
able
to
comment
on
it.
The
problem
is
when
they
block
it,
which
is
if
it's
it's
a
bridge
that
we
will
have
to
cross
at
some
point.
But
I
think
it's
separate
from
this
specific
issue
that
you're
into.
A
Okay
and
then
I
think
all
that
makes
sense,
I
think
logically
I
can
see
through.
Like
I
mean
I
imagine
in
some
companies,
pms
are
reporters
I
had
to
like
think
about
how
they
might
dole
out
permissions,
and
so
that
makes
sense
that
they
might
comment
in
a
merge
request.
A
C
So
what
I'm
understanding
is
that,
when
a
reporter,
like
reports,
a
bug
and
there's
a
merge
request,
if
they
comment
on
that
report,
the
merge
request
can
no
longer
be
merged.
Without
addressing
that
comment
like
it
blocks,
the
actual
merge
request
from
being
like
going
through.
A
There's
a
feature
of
merge
requests,
which
is
that
all
threads,
so
all
comment
chains
have
to
be
resolved.
It's
as
simple
as
clicking
like
a
resolve
thread
button,
and
so
anyone
who
can
comment
on
a
merge
request
can
leave
a
comment
that,
without
their
thread
being
resolved
effectively
blocks
a
merge
request.
Assuming
a
combination
of
settings
exists
that,
like
actually
has
that
enabled
for
people.
A
A
A
Role
for
that
role
to
be
playing
in
the
merge
requests
like
would
you
want
to
again?
Let's
assume
a
pm
is
a
a
reporter
in
other
companies
like.
Would
I
go
through
and
resolve
threads,
I'm
trying
to
just
think
through
that
to
make
sure
that,
like
because
this
I
mean,
on
the
one
hand
like,
I
think
this
is
being
reported
as
a.
A
I
guess,
it's
a
feature
request,
but
changing
permissions
is
one
man's
feature
request
and
one
man's
bug,
one
person's
as
we've
as
we've
seen
with
some
other
permission,
changes
we've
made.
So
I
don't
know
I
just
like
thinking
through
that.
Does
that
make
sense
for
that
role,
or
I
know
you
said
yes
already
but
sort
of
interesting
to
talk
about.
A
It's
interesting
because
we
don't
have
a
control
in
place
that
allows
you
to
specify
that
you
could
only
resolve
your
own
threads.
We
only
have
the
ability
that
you
can
either
resolve
threads
or
can't
resolve
threads.
So
if
you
were
thinking
of
a
new
control
that
was
like,
you
could
only
resolve
your
own
threads.
B
Yeah,
I
think,
yeah,
that's,
I
think
what
would
make
sense
for
for
guests
and
reporters.
I
think
it
would
be.
You
know
too
much
power
for
a
reporter
or
a
guest
to
resolve
other
people's
threats
in
in
emergencies.
D
B
That
they're
they
can
be
blocking
right.
So
if
someone
brings
up
a
security,
analyst
brings
up
a
critical
security
vulnerability
and
they
say
hey.
This
must
be
fixed
before
this
goes
in.
If
a
guest
comes
in
and
resolves
it
or
a
reporter,
it
might
be
missed
by
the
developer
and
they
don't
have
a
chance
to
address
it,
but
if
they
can
resolve
their
own
threads,
I
think
that
might
be
acceptable,
but,
as
you
said,
we
don't
have
that
today.
D
So
from
what
I
understand,
are
we
talking
about
two
different
things?
Either
guests
and
reporters
are
able
to
resolve
their
own
threads
and
only
theirs,
or
are
we
talking
about
making
threads
created
by
guests
and
reporters
non-blocking
by
default,
so
they
can
comment
all
over.
They
can
do
what
they
want.
They
can't
resolve
it,
but
it
doesn't
matter
because
it's
not
blocking.
B
Yeah,
it's
so
those
two
things
exactly
and
the
second
one
their
threads
blocking
or
not
is
we'd
have
to
look
into
it
because
you
know
some
teams
might
say,
oh,
but
we
have
reporters
and
and
guests
in
our
projects
that
we
want
their
threats
to
to
block
because
of
xyz.
I
don't
know
so
that's
a
separate
thing
that
exists
and
we
would
have
to
look
into
it.
But
the
the
issue
that
was
opened
three
weeks
ago
was
about
the
ability
for
reporters
or
guests
to
resolve
their
own
threats.
B
No,
they
can't
they
can
create
threads
in
merge
requests.
They
are
resolvable,
they
block,
they
can
potentially
block
the
merge
request
depending
if
the
project
has
the
allow.
All
discussions
to
be
must
be
resolved
and
and
yeah,
and
they
can't
resolve
it.
So
they
have
to
wait
for
someone
with
that
is
a
developer,
maintainer
or
owner
to
to
resolve
them.
B
I
mean
if
we
want
to
if
we
want
to
take
some
inspiration
from
the
approval
feature
you
can
only
and
and
amy
I
don't
know
if
you're
still
on
the
call,
but
you
you've
been
working
on
or
you
worked
recently
on
the
documentation
for
approvals.
B
B
Them
specifically
to
a
rule,
I
don't
think
they
and
they
need
to
have
developer
or
higher
permission.
So,
if
you
add
a
guest
or
a
reporter
to
a
specific
approval
rule,
they
cannot
approve.
I
think
that's.
B
Actually,
yeah,
I'm
seeing
in
the
documentation.
Now
let
me
paste
that
in
the
chat,
apparently,
you
can
add
them.
Something
called
merge,
request
approval
segregation
of
duties.
B
You
may
need
to
grant
users
with
reporter
permissions
permission
to
approve,
merge
requests
before
they
can
merge
to
a
protected
branch.
Some
users,
like
managers,
may
not
need
permission
to
push
or
merge,
but
still
need
oversight
and
proposed
work,
and
you
can.
A
Was
done
by
ci,
or
actually
this
was
done
by
release
for
environments?
I
know
where
this
feature
came
from.
B
E
I
dropped
in
a
link
that
states
it
a
little
more
clearly.
We
should
probably
sorry
just
not
going
to
say
that
the
following
users
can
approve
merge
requests
if
they
have
developer
or
higher
permissions
users
added
as
approvers
at
the
project
or
merge
request
level
or
users
who
are
code
owners
of
the
files.
B
So
yeah
so
yeah
in
addition
to
that
report,
a
reporter
can
approve
if
they,
if
the
project
is
shared
with
a
group
that
has
that
person
as
a
reporter.
So
it's
complicated,
but
I
think
it's
fair
to
say
that
by
default
and
unless
you
have
to
do
all
of
these
things,
reporters
cannot
be,
cannot
approve
and
cannot
be
added
to
an
approval
rule.
B
Yes,
and
also
us
discussing
it
here
now,.
A
Yes,
I
appreciate
all
the
indulgent
on
my
permissions
venture
that
I've
been
on
as
we've
as
we've
worked
through
more
and
more
permissions
issues
recently.
So.
D
This
is
somewhat
related,
but
I
still
think
that
the
conventional
comments
is
the
coolest
thing
if
we
were
able
to
like
if
someone
started
typing
non-blocking
and
we
had
like
a
little
tag
that
popped
up
or
something
and
you
could
click
it
and
it
would
make
that
thread
not
blocking
you
keep
going
or
praise.
I
hate
that
right
now,
if
someone's
like
praise,
I
love
what
you
did
here.
This
makes
sense,
and
then
they
comment
and
then
they
immediately
resolve
it
because
it's
like,
I
don't
want
to
block
this.
D
D
B
Don't
worry
ben,
I
think
we
have
more
important
things
for
you
to
work
with
okay,
great,
but
but
thanks
for
asking
yeah,
I'm
kai
I'm
inclined
to
to
keep
this
in
in
the
backlog
and
waiting
for
more
people
to
respond
with
their
use
cases,
but
yeah.
I
don't.
I
don't
see
this
as
a
very.
A
I'm
going
to
like
re
rewrite
the
issue
to
make
it
more
clear
about
some
of
those
things
that
we
discussed
just
so
if
someone
does
decide
to
pick
it
up
or
I
find
the
issue
again
in
six
months-
remember
what
we
talked
about
and
why
why
we
got
to
where
we
were
so
yeah,
I'm
going
to
rephrase
the
problem
proposal
to
be
more
specific
about
adding
an
additional
control
for
like
those
those
users
to
resolve
only
their
own
threads,
because
I
think
that's
sort
of
the
nuance
that
I
had
missed
before
and-
and
I
think
that
makes
it
more
clear-
I
was
thinking
resolving
all
threads
and
that
felt
that
felt
like
a
power
too
far.
A
Cool,
if
no
one
has
anything
else
enjoy
the
rest
of
your
tuesday
and
I'm
sure
we'll
chat
again
soon
see
you
everyone,
bye-bye.