►
From YouTube: 2021-10-19 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
Read
only
read
only
so
we'll
skip
them
first,
one
is
category
maturity
scorecard.
So
I
completed
the
first
like
pilot
test.
I
did
a
run
through
this
morning
with
tomas
of
the
maturity
scorecard
like
script
and
stuff
for
the
editor
extension.
A
A
It
went
fine
but
yeah,
I
just
some
feedback
would
be
good
and
I've
got
a
couple
questions
that
I
want
to
add
and
then
two
about.
We
are
testing
the
vs
code
extension.
I
mean
we
can
answer
this
one
now
we're
testing
the
vs
code
extension
and
for
the
first
scenario
I
explicitly
say,
imagine
you're
working
in
vs
code
for
the
second,
we
don't
say
anything
sort
of
explicit
about
vs
code.
A
It
was
tomas,
so
he
just
used
the
s
code,
like
sort
of
naturally
to
do
that,
and
so
I'm
trying
to
figure
out
if
we
should
be
more
leading
or
less
leading
about
that.
So
something
to
think
about
in
terms
of
like
so
we
want
to
test
vs
code.
I
also
don't
necessarily
want
to
say:
go
do
this
in
vs
code,
but
maybe
that
is
the
right
thing
to
say.
Given
what
we're
trying
to
do
here,
it's
a
little
bit
different,
I
think
than
other
gitlab
things.
C
C
A
Awesome
amy
you've
got
number
four.
D
C
Amazing
yeah,
I
wrote
I
was
looking
at
what
I
had
written
in
in
in
that
epic
and
I
was
intending
to
break
that
down
even
further
with
specific
issues
for
each
message
of
the
merge
widget,
but
I
just
haven't
had
the
time
or
in
other
words
did
not
make
time
for
it
because
of
other
things.
C
So,
if
you
could
what
I
would
love,
of
course,
we
already
already
identified
a
few
things
and
in
the
epic
you
have
that
section
proposed
changes
which
already
has
you
know
some
suggested
things
that
we
can
do,
but
what
I
would
love
is
for
you
to
go
through
the
mapping
that
I
did
in
the
past
with
all
of
the
states
and
the
screenshots.
C
Some
of
them
could
be.
You
know
slightly
outdated
because
we
already
updated
some
of
the
messages,
but
for
most
of
them
I
don't
think
we've
touched
them
yet.
So
if
you
could
go
through
them
and
either
you
know
create
issues
for
them
or
at
least
identify
the
most
problematic
ones
or
the
ones
that
could
have
a
bigger
impact
if
we
were
to
improve
them.
That's
ideally
what
I
would
like
to
see
if
you
have
time:
okay,.
D
Okay
sounds
good
move
that
over
to
the
things
amy
is
picking
away
at
screen
and
then
the
next
one
I
think
pedro's
answered
that
pretty
well.
I've
just
been
opening
lots
of
new
issues
for
merch
requests
and
every
time
I
think
now
I
have
to
add
18
labels.
Why
and
there's
a
really
good
reason
why
we
don't
do
it,
but
I
thought
I
would
ask.
A
B
C
Exactly
good
point:
okay,
yeah
yeah.
I
wanted
to
discuss
next
steps
for
the
problem,
validation
of
blocking
approval,
and
so
I
went
through
all
of
the
feedback
from
that
very
popular
issue
of
blocking
merge,
requests
with
a
negative
approval
signal
and
also
other
related
issues
and
customer
comments,
and
so
on
and.
C
C
In
the
same
way
that
I
mean
we're
building
a.
C
C
We
had
a
lot
of
implicit
signals
and
communication
when
we
did
not
have
the
reviewers
feature.
We're
planning
the
attention
requests
to
have
a
clear
signal
of
things
that
you
need
to
take
a
look
at,
and
we
also
have
you
know
the
approve
button,
which
is
a
very
clear
signal
that
you
approved
it's
explicit.
C
C
Yes,
it's
it's
clear
that
you
have
not
approved
and
you're
requesting
changes,
but
it's
a
very
manual
way
of
doing
it
and
we
cannot
extract
any
additional
value
from
it.
C
And
so
the
true
problems
to
me
that
I
actually
wrote
as
two
potential
solutions.
So
one
of
them
is
hey.
We
can
add
the
ability
to
reject
or
to
request
changes
in
the
same
way
that
some
competitor
tools,
you
know,
allow
you
to
say,
I'm
not
approving
this,
I'm
requesting
changes
or
I'm
waiting
for
your
response,
and
so
my
sense
is
clear
and
we
can
surface
that
in
other
places,
or
even
you
know,
sends
smart
email
notifications
saying
that
this
person
is
requesting
your
changes.
C
A
C
You
know
very
clear
to
everyone,
and
so
who
resolves
the
threat.
Is
it
the
merge
request
author
who
is
going
through
them
and
addressing
it
them
or
is
the
person
who
created
the
thread
and
I
think
we
could
solve
that
problem
and
it
would
make
things
easier
for
the
implicit.
C
Non-Approval
and
so
when
you've
finally
resolved
all
of
them,
it
means
oh,
the
reviewer
is
probably
happy
because
we
resolved
all
the
threads.
There
are
no
open
threads
they're
they're
going
to
approve
right.
So
that's
the
implicit
thing,
but
on
the
other
hand
we
have
that
other
problem.
That's
it's
not
explicit
that
you
are
requesting
changes
or
that
you
have
things
you
want
to
see
addressed.
C
On
one
hand,
work
out
a
potential
solution
for
reject
or
request
changes
and.
C
How
we
could
bake
that
into
the
product,
regardless
of
the
thread
permissions,
and
we
could
create
another
issue
if
it
doesn't
exist
today,
just
talking
about
and
discussing
the
resolvability
of
threats,
because
I
think
that's
that's
another
issue
that
we
need
to
not
necessarily
solve,
but
that
we
need
to
have
an
opinion
on
so
that
that's
probably
what
I
would
do.
C
You
know
create
two
issues
for
those
two
things
I
mean
we
already
have
an
issue
for
the
requests,
changes
or
reject,
which
is
the
you
know
that
that
one
to
block,
although.
C
Although
this
this
would
not
necessarily
block
the
merge
requests,
because
we
don't
have
functionality
today
to
we
only
have
functionality
to
require
approvals.
We
don't
have
functionality
that
says
you
know
if
someone
requests,
changes
or
rejects,
you
cannot
merge
it,
so
we
would
have
to
look
into
those
things
as
well.
So
I
think
in
the
end,
what
I'm
trying
to
say
is
that
I
think
we
have
successfully
validated
these
problems.
At
least
these
two
main
problems
are
also
other
parallel
problems
and.
A
A
Is
that
a
is
that
an
outcome,
that's
possible
or
do
you
think
like,
and
I
I
sort
of
asked
that
in
the
sense
that
like
if
you
look
at
sort
of
the
philosophy
that
gitlab
has
largely
taken
around
all
of
these
things
for
the
last
well
10
years
there
there
haven't
been
blocking
measures
in
the
product
and
they're
sort
of
like
everything
is
more
permissive,
rather
than
less
permissive
sort
of
like
the
philosophy
that
gitlab
as
a
product
has
that's
starting
to
change
right.
We
have
them
compliance
groups
and
they're
doing
other
things.
A
C
I
think
it
depends
on
how
you
frame
it.
You
know,
approval
rules
are
are
blocking
measures
and
they
block
things
from
merch.
The
moment
you
you
know
sets
something
you
need
at
least
one
approval
if
it
doesn't
get
that
approval,
it's
blocking.
C
So
do
you
mean
so
I
think
you
mean
like
implicit,
implicit,
blocking
and
implicit
blocking
if
threads
must
be
resolved.
I
just
need
to
create
a
thread
and
it's
blocked
until
someone
resolves
it
even
as
a
guest
or
even
as
a
reporter
role,
I
can
go
into
emerging
quests
and
create
a
resolvable
thread
and
it's
not
going
to
be
merged,
so
I'm
already
blocking
it
explicitly.
C
As
a
first-class
status,
saying,
I'm
not
approving
this
I'm
requesting
changes
or
I
need
to
see
some
responses.
First
then,
there's
also
the
blocking
parts
where
I
click
a
button
or
something
and
it's
the
opposite
of
approving.
So
it's
blocking
the
merge
requests
without
having
to
create
a
thread
and
then
there's
also
the
problem
of
merge,
request,
authors
or
someone
else
resolving
my
threads
and
I
don't
want
them
to
be
resolved
because
I
only
want
this
to
be
merged
when
they
are
resolved.
C
So
I
don't
think
I
don't
think
we're
doing
anything.
I
don't
know
I
to
be
honest,
I
don't
know
where
that's
what
you
were
explaining
right
now,
like
the
what
we've
done
in
the
past.
I
don't
know
where
that
comes
from
and
because
it
just
means
it.
A
A
A
Today,
you
could
use
approval
rules
but
like
in
many
cases
like
multiple
people
are
assigned
to
approval
rules
but
like,
if
you
think
about
threads
today,
you
know
one
of
the
complaints
in
the
blocking
thing
is
like
well,
anyone
can
resolve
a
thread,
but
if,
if
we
go
down
a
path
where
we
say
like
well,
let's
make
the
reviewers
position
clear:
they're,
either
rejecting
it
because
they're
requesting
changes
or
they're
approving
it.
Well,
it
doesn't
really
matter
because
I
don't
actually
need
their
approval.
C
C
That
was
not
the
impression
that
I
had
and
I
didn't
see
anyone
explicitly
ask
for
that
actually
saw
the
opposite
or
the
opposite,
not
a
different
perspective,
which
is
yes,
I
want
to
block
it
or,
but
I
want.
I
am
also
aware
that
if
I'm
unavailable
or
if
for
some
reason,
there's
someone
senior
to
me,
they
should
be
able
to
merge
it
right
and
they
should
be
able
to
unblock
things
so
there's
there
always
needs
to
be
an
escape
hatch.
For
this,
the
only
I
mean
the
only
way.
C
Let's
imagine
we
designed
this
this
perfect
system.
The
only
way
that,
like
your
merge
request,
could
be
effectively
blocked
forever
is,
if
you
only
have,
for
example,
you
know
one
project
maintainer
and
they
could
be
the
only
person
to
unblock
it
and
they
are
saying
I'm
not
going
to
unblock
it.
But
that's
that's
also.
That's.
B
Also,
the
only
person
who
could
merge
it
so
if
you're
talking
about
resolving
threads
at
the
maintainer
and
above
permission
level,
those
only
people
that
can
merge
it
anyway,
so
that
sounds
like
it
kind
of
makes
sense.
C
A
C
So
so
yeah,
I
think
kai,
I'm
adam,
I'm
not
afraid
of
of
that,
because
I
don't.
I
didn't
see
that
in
this
feedback-
and
everyone
was
talking
about
for
everything
that
they
wanted
escape
hatches
like
for
resolving
threads.
If,
for
some
reason,
the
person
that
created
the
threat
is
not
there
to
resolve
it
or
if
someone
senior
thinks
like
hey,
we
need
to
unblock
this,
I'm
going
to
override
this.
They
are
able
to
resolve
it
and
so
on.
C
I
think
what
what
people
are
talking
about
is
especially
the
emerge
request
author
being
able
to
to
merge
things
without
having
everything
addressed
or
if,
if
even
if
we
have
all
of
the
required
approvals,
if
someone
like
from
security-
let's
imagine
that
they
don't
have
you
know
security
approval
rules
set
up.
I
have
all
the
necessary
approvals
like,
for
example,
three
reviewers
approved
everything,
but
then
a
security
engineer
comes
in
and
creates
an
issue,
a
thread
and
says
hey.
This
is
security
vulnerability.
C
C
And
again,
all
I
think
all
of
these
are
exceptions.
These
would
not
be
the
norm
right
because,
usually
the
developer,
you
know
in
in
a
healthy
environment.
They
look
at
reviewers
comments,
they
address
them,
maybe
they
resolve
the
threat
or
the
reviewer
resolves
them.
They
approve
and
everything
goes
well.
C
These
are,
I
think,
for,
for
the
exceptional
cases.
A
I
think
that's
fair.
I
think
I
would
like
to
see
us
as
part
of
this
and
sort
of
before
we
go
down
this
path.
No
nowhere
we're
gonna
draw
the
line,
particularly
like
with
regards
to
settings
or
how
granular
we'll
get
or
how
how
hard
we
want
to
be
about
blocking
things,
because
I
think
this
is,
I
think,
you're
right.
A
Potentially
these
two
things,
don't
don't
come
with
explicit,
maybe
hardcore
blocks
that,
like
could
lock
a
merge
request
until
that
one
person
gets
back,
but
they
they
crack
open
pandora's
box
on
how
many
settings
and
options
we're
willing
to
add
to
make
that
possible,
and
so
I
think
we
need
to
be
very
careful
about
this,
like
even
just
like.
I
was
reading
your
feedback
on
like
the
threads
piece
like
that.
Immediately
to
me,
I
feel
like
you're,
going
to
get
four
or
five
different
versions
of
settings
that
people
want
right.
A
People
are
going
to
want
developers
they're
going
to
want
maintainers
they're,
going
to
want
developers
plus
maintainers
they're,
going
to
want
to
be
able
to
pick
specific
people,
they're
going
to
want
to
say,
merge
like
there's
like
immediately
10
options
that
you
could
put
in
there
and
like
that.
That
doesn't
feel
correct
if
we
need
10
options
to
sort
of
deal
with
it,
and
I
think
similarly,
like
you,
know,
a
change
request
like
it
doesn't
really
matter.
A
If
I
can
say
I
request
changes
but
like
anyone
could
go
back
and
approve
it,
because
they
just
bypassed
my
approval
and
got
a
different
maintainer
right,
like
I
think
I
these
are.
These
are
nervous
paths
to
be
on
because
I
think
they're
gonna
open
this.
Like
natural
edition
of
I
want
more
settings,
I
want
more
settings,
I
want
more
settings
and
I
think
we
just
need
to
be
able
to
have
a
stronger
opinion
about
what
that
is,
and
I
think
up
until
we
sort
of
like
done
this
problem
validation.
A
Our
opinion
has
largely
been
like.
Oh,
you
have
developers
and
maintainers
and,
like
you,
should
trust
them
to
like
work
appropriately
and
respond
appropriately
and
behave
appropriately
and
like
merge
your
merch
request
and
so
like.
This
is
a
divergence
from
from
that
behavior
we're
sort
of
like
saying
we
don't
trust
teams
to
operate
like
grown-ups
anymore,
to
some
extent
it's
what
that
is.
C
Yeah
yeah
yeah.
I
think
that's,
that's
why
I
said
I
think
the
the
comment
resolution
or
the
thread
resolution
is
the
trickiest
to
get
right.
There
might
be.
You
know
some
very
small,
quick
wins
here
regarding,
for
example,
guests
and
reporters,
and
you
know
things
like
that,
but
other
than
that,
I
think
we
will
get
into
a
very
big
options
space,
because
it
will
largely
depend
on
how
people
want
to
work.
C
I
think
the
reject
or
request
changes
is
something
that
we
could
work
towards,
for
example,
if
a
reviewer
or
if
someone
in
an
approval
rule
specifically
they
reject
or
request
changes.
You
cannot
merge
it,
for
example,
in
the
same
way
that
anyone,
I
think
we
should
do
the
opposite
of
what
we
do
with
approvals
today,
like
anyone
in
the
project
can
approve
any
developer.
C
But
if
you
have
required
approvals,
only
certain
people's
approval
counts
and
I
think
the
same
thing.
If
we
do
the
same
thing
for
rejection
or
requesting
changes,
it
would
be,
you
know
easy
to
understand
and
it
would
block
the
emerge,
but
anyway,
we've
gone
over
time.
I
will
look
into
the
issue
again
and
digest
this
a
bit
more,
but
I'm
I'm
happy
to
for
having
this
conversation.
A
Yeah,
I
think
I
think
it's
a
worthwhile
conversation
and
I
I
want
to
talk
about
it
more
I'll-
probably
put
some
other
time
on
your
calendar,
because
I
want
to
talk
about
whatever
the
last
item
number
seven,
whatever
number
it
is
on
the
agenda,
but
I
also
have
to
jump
so.