►
From YouTube: 2021-01-05 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
So
I
put
the
first
one
up,
which
was
just
thanks
for
putting
the
like
design
issue
together
to
talk
about
sort
of
reviewers
things.
I
started
commenting
on
some
of
it.
I'll
probably
comment
some
more,
but
just
to
thanks
for
like
thinking
through
that
and
adding
all
the
examples
of
what
other
people
are
doing.
B
So,
thank
you
yeah
yeah!
I,
it
was
something
I
wanted
to
do
last
last
week,
yeah
the
new
year's
eve
week,
but
yeah
I
got.
I
was
doing
other
things
with
my
free
time,
so
I
didn't
make
any
progress
on
that.
But
yeah
take
your
time
because
it's
a
lot
to
digest-
and
I
actually
want
people
to
to
take
some
time
to
reflect
on.
B
What's
there
as
food
for
thought
and
also
to
I
mean
if
they
want
to
do
their
own
research
as
short
or
long
as
they
want,
because
we
have
some
time
here
and
I
don't
want
to
have
too
many
intuitive
reactions
to
the
content.
I
want
people
to
think
about
it
and
reflect
okay.
If
we
went
down
this
path
or
that
path,
what
would
where
would
we
be
in
the
future?
Where
would
that
lead
us
would?
Would
it
be
a
good
place
for
us
to
continue
evolving
or
not
and
yeah?
B
So
there's
a
lot
there
and
I
thought
it
was
better
to
separate
that
from
the
main
issue,
which
could
would
probably
be
the
implementation
issue
and
also
from
the
epic-
and
I
put
it
inside-
of
the
using
our
iterations
feature.
So
I'm
planning
to
have
everything
I
mean
at
least
the
design
direction
wrapped
up
in
two
weeks
max
so
that
we
can
have
something
to
do
in
thirteen
nine
yeah.
But
I
mean
the
timeline
can
change
depending
on
on
how
people
collaborate
there.
A
Cool
the
next
one
was
just
an
fyi
really
that
james
noticed
sort
of
before
we
went
on
break
last
year
that
scm
so
like
source
code,
email
so
like
stage
monthly
active
users
for
for
well,
it's
gmail,
so
group
monthly
active
users
for
source
code
is
about
two
times
higher
than
monthly
active
users
for
code
review
based
on
the
way
those
two
are
currently
measured
and
so
source
code
is
measured
as
get
right
operations
and
at
the
time
when
james
pulled
this
code,
review
was
measured
by
people
who
open,
merge
or
close
a
merge
request.
A
It's
probably
the
most
correlated
group
of
people
that
you
would
have,
but
it's
like
a
two
times
difference,
and
so
and
then
the
code
review
numbers
look
in
some
cases
closer
to
the
verifying
numbers.
So
we
used
to
always-
and
this
is
important
because
historically
product
has
talked
about
how
like,
if
you
can
adopt
a
cm
or
if
you
can
adopt
source
code,
because
source
code
used
to
be
encompassing
a
code
review
and
there
wasn't
that
distinction
you
adopted
verify
and
like
that
was
like
the
flow
we
were
trying
to
like
promote.
A
And
so
we're
trying
to
figure
out
if
this
drop-off
is
real
or
if
there's
some
outliers,
and
so
I
just
wanted
to.
Thank
you
a
couple
issues
where
I
did
a
bunch
of
initial
investigation
on
some
really
terrible
queries
and
vlookup
like
comparisons,
and
then
I
opened
a
data
issue
when
I
got
back
yesterday,
and
so
I
think
matthew's
gonna
look
at
that.
A
Hopefully
this
week,
but
it'd
be
worth
taking
a
look
at
because
if
that's
true
that
there
is
that
sort
of
drop-off,
we
may
need
to
think
more
about
how
like
why
we
probably
have
to
dig
in
hardcore
and
figure
out
like
what
are
you
doing
for
code
review.
Then
at
that
point,
or
are
you
not
doing
it
at
all
and
like
sort
of
are
there
things
that
we
need
to
be
thinking
about
in
terms
of
driving
you
into
that
workflow
that
we're
not
addressing
so
something
to
keep
an
eye
on?
B
B
I'm
I'm
I'm
curious,
or
can
you
explain
why
in
the
page
ama
you
we
code
review
is
significantly
lower
than
verify
like
verify
for
october,
it's
in
the
hundred
thousands
and
code
review
is
only
25
000.
A
That
one
I
don't
know,
I
don't,
I
don't
understand
the
difference
on
the
paid
side
either,
because
it's
it
is
a
stark
drop
off
compared
to
like
the
free
users,
which
sort
of
doesn't
make
sense,
and
it
you
have
to
realize
too,
that,
like
paid
largely,
would
then
come
from
well
that
only
comes
from
self-managed,
so
that
comes
from
like
usage
ping
data,
I
guess
if
it's
filtered
by
paid
like,
I
wouldn't
expect
that.
But
I
don't
know
that's
why.
A
B
Yeah
you
can
use
with
the
yeah,
you
can
use
it
normally
just
every
time
you
commit
something,
it
builds
for
you,
and
then
you
can
push
the
results
to
another
tool.
If
you
want.
B
Yeah,
for
example,
yeah
yeah.
We
actually
support
that
external
ci
for
external
repos.
I
think
that's
the
name
yeah,
because
a
lot
of
teams
don't
want
to
migrate
everything
to
gitlab.
They
love
github
or
another
tool,
and
so
they
mirror
all
of
the
git
operations
to
gitlab.
So
they
have
like
a
copy
of
the
repository
in
gitlab
and
then
they
run
the
ci
in
gitlab
and
then
it
pushes
back
the
results
to
other
another
tool.
I
don't
know
how
common
that
is
or
how
popular
that
solution
is.
But
I
know
it's
possible.
A
Yeah
yeah,
I
don't
know
on
that
one
either
so,
but
james
pulled
that
top
set
of
data.
That's
in
the
issue
description
and
then
I
pulled
a
set
of
data.
That's
sort
of
like
the
last
comment
in
that
issue
that
was
correlated
and
my
data
actually
looks
a
lot.
My
data
is
more
perplexing
and
that
it
actually
shows
like
over
a
hundred
percent
of
mr
users
or
sem
users
which,
like
math,
doesn't
work
correctly
for
either
so
yeah.
B
No
yeah!
No,
I
think
it's
at
this
point.
It's
just
sharing
that
there
is
this
discrepancy
and
yeah
trying
to
understand.
If
what
is
wrong
yeah
one
one
curiosity,
why.
B
Why
do
we
only
have
paid
email
for
self-managed
and
not
for
gitlab.com.
A
I
think
for
gitlab.com
we
don't
have
good
data
segmentation,
sometimes
depending
on
what
you're
looking
at,
we
sometimes
can't
segment
data
and
I
think
those
queries
are
more
complicated
to
try
and
segment.
I
also.
A
Paid
and
not
paid
because
we
know
that
they're
on
a
plan,
but
lots
of
gitlab.com
has
like
if
you
have
public
projects
on
gitlab.com
those
appear
as
gold
things
right,
because
we
give
you
gold
for
free
on.com.
If
it's
a
public
project,
even
though
you're
not
paid
in
like
open
source
groups
right
right.
Okay,
so
like
our
data,
on.com
is
sort
of
messy
in
some
situations.
So
it's
much
harder
to
like
start
to
distinguish
what
is
paid
and
not
paid
versus
like.
What's
on
a
plan
and
not.
B
Yeah
yeah,
but
I
don't
know
why
at
the
group
level,
because
because
you
can
have
one
group
that
is
not
paying
and
you
have
active
users
there
and
then
you
have
another
group
which
is
paying
and
you
have
active
users,
and
so
what
would
you
count
as
being
paid
or
not
paid?
Yeah?
Okay,
so
so
the
not
paid
email
for
gitlab.com
is
everything
basically
right:
cool
yeah.
Thanks
for
for
sharing
this
definitely
interesting
and
yeah.
I'm
curious
to
find
out
the
results
for
this.
A
Cool
and
the
last
one
was
sort
of-
and
I
think
this
is
relevant
to
like
the
first
one
in
terms
of
the
issue
and
just
generally,
I
think
we
probably
need
to
get.
I
know
there's
lots
of
questions
internally
about
what
to
do
with
reviewers
sort
of
just
curious,
like
what
people
had
seen
what
you've
personally
seen
or
heard
from
other
people,
that
you
know
you
might
not
have
about
reviewers
so
far
on
gitlab.com.
B
I
think
we're
we're
mostly
on
top
of
it
yeah
when,
when
the
feature
was
enabled,
I
was
missing
the
quick
action,
because
I
used
that
a
lot
when
it
was
only
with
the
signees,
and
so
I
kept
an
assigning
reassigning
assigning
myself
and
others,
and
so
I
I
tried
to
do
that
out
of
habit,
but
it
didn't
show
up
so
but
but
we're
already
on.
On
top
of
that-
and
we
will
add
the
quick
action
we
now
have
access
to
the
review
requests
and
the
counter
is
working,
which
is
amazing.
B
I
think
the
author
is
usually
in
control
of
the
merge
requests,
feedback
loop,
but
the
reviewers
may
be
left
a
bit
outside
and
they
don't
know
what
what
is
happening.
So
I
think
the
re
requesting
a
re-review
is
is
really
important
other
than
that
I've.
Of
course,
I've
seen
people
requesting
other
things
like
having
an
indication
if
the
reviewer
has
approved
or
not
in
the
reviewer's
site.
There
are
many
other
things
that
we
could
do,
but
I
think
the
most
important
and
relevant
ones
we're
doing
and
we're
working
on.
A
C
A
A
Yeah,
I
would
generally
agree
pedro.
I
think
that
we
sort
of
addressed
the
immediate
things.
I
think
one
of
the
things
that
comes
up
and
one
of
the
things
that
I
commented
in
the
issue
from
the
first
item
was
in
my
mind.
I
sort
of
I
have
like
a
long-term
thought
that,
like
once,
you
go
into
the
reviewer's
field
you're
permanently
there
and
I've
expressed
that
in
like
a
couple
threads,
and
I
think
that
is
causing
some
heartburn
for
people,
because
it
doesn't.
A
A
But
I
don't
know
if
that
creates
more
friction
or
frustration
and
using
it
for
people
so
yeah.
I
I
haven't
seen
anything
otherwise,
it's
like
incredibly
frustrating
so
far,
and
I
think
I
think
getting
through
that
design
phase
issue
will
sort
of
help
us
figure
out
what
we
want
to
go
do
do
next
there,
or
at
least
plot
a
course
of
all
the
things
that
we
need
to
go
do
to
get
get
to
an
end
state.
A
A
Permanence
of
people
in
that
field,
like
do
we
all
agree
that,
like
there
is
an
in
state
where,
like
everyone's
in
there
or
do,
we
think
that
people
will
come
and
go
from
that
field.
I
think
that's
probably
one
of
the
biggest
like
I'm,
not
sure,
we've.
I
think
we're.
B
That
we
are
intentionally
not
prescribing
a
way
for
people
to
use
the
reviewers
field,
and
you
did
that
often
so
yeah.
I
think,
and
that
was
really
important
just
to
see
the
discussions
that
would
naturally
evolve
and
the
suggestions
that
people
would
have.
Okay,
how
do
we
use
it
or
how
we
we
shouldn't
use
it,
and
I
agree,
I
think,
at
the
end
of
the
day,
they
can
still
use
it
as
they
were
using
the
assignees.
They
can
an
assign
and
then
assign.
B
B
Is
that
now
we
have
the
assignee
fields
just
for
like
for
something
and
and
people
could
use
it
for
the
author
and
the
author,
never
changes
right.
So
would
you
stay
assigned
as
the
author
in
the
assignee
field
forever
and
if
so
I
mean,
reviewers
could
also
expect
to
also
be
assigned
forever,
or
maybe
they
would
unassign
themselves
once
they
have
given
feedback.
But
what
about
the
assignee?
How
do
you
request
the
author
to
look
back
at
the
merge
requests
right,
and
so
I
think
it's
it's
not
just
the
reviewer's
field.
B
I
think
it's
just
because
the
fact
that
we
have
now
two
fields-
people
don't
know
how
all
of
these
roles
and
what
they
should
do
with
the
two
fields
together,
because
if
we
only
had
reviewers
or
if
we
only
had
assignees
it's
that
and
people
would
still
use
it,
but
now
with
two
fields
it
could
be
confusing.
I
think
that's
the
main
thing
that
people
are
struggling
with
and
and
at
the
same
time
I
think
a
lot
of
the
feedback
that
we
received
regarding
how
we
should
use
it.
B
I
think
it
I
was
assuming
it
was
tangently
related
to
the
fact
that
you
couldn't
easily
access
your
merge
request
where
you're
a
reviewer.
B
So
I
think
that
kind
of
dilutes
the
problem
a
little
bit
yeah
and
I
agree
with
you,
I
think,
at
the
end
of
that
design
issue,
we
will
have
a
better
understanding
of
what
we
can
do
to
help
people
with
this
problem,
and
I
think,
at
the
same
time
we'll
have
a
better
understanding
of
how
much
of
a
problem.
It
really
is.
B
C
Yeah
this
is
this
is
interesting
because
I
definitely
will
want
to
see
how
that
issue
turns
out,
because
right
now
my
mind
is
going
towards
the
reviewers
kind
of
staying
permanent,
like
you're,
saying
because
you
know
who
needs
to
review
this.
Mr,
like
there's,
probably
an
outlying
thing.
These
people
need
to
review
it
and
then
the
assignee
is
like
the
transient
state.
It's
like
of
these
three
reviewers
who
is
currently
reviewing
it.
Maybe
they're
currently
assigned.
I
don't
know,
but
I'll
definitely
think
about
this
more
and
look
back
into
the
research.
C
B
You
know
if
you
look
in
the
issue
and
let
me
actually
share
my
screen.
I
think
it's
it's
better
if
we
see
it
visually.
So
one
of
the
approaches
that
I
shared,
which
is
a
very
interesting
way
to
solve
this
problem,
is
how
garrett
does
it
with
their
attention
set.
B
I
don't
know
if
it's
the
most
useful
approach
for
us
at
gitlab,
but
basically
it's
a
it
kind
of
automates.
All
of
this
requests,
and
and
like
you,
don't
have
to
necessarily
ping
someone
to
get
their
attention.
You
can,
if
you
want,
but
one
of
the
things
that
they
say
is.
If
you
reply
yeah,
if
you
reply
to
a
thread
or
a
conversation,
it
adds
all
of
the
persis
participants
of
common
conversations
that
the
user
is
replying
to.
B
So,
if
I
just
comment
on
something
that
you
and
kai
also
commented
on,
even
if
I
don't
mention
you,
because
you
were
part
of
that
conversation,
you
would
be
part
by
default
of
the
attention
set.
So
you
will
like
your
attention,
will
be
called
to
the
merge
request
and
you
there
there's
something
that
you
need
to
do
there.
Basically,
but
one
of
the
things
that
they
say
here,
it's
very
interesting
is:
oh,
they
have
a
section
just
for
assignee
right,
so
they
have,
I
think,
three
at
least
three
roles.
B
B
So
they
have
a
lot
of
different
roles
of
people
that
can
be
involved
in
in
the
change.
That's
what
they
call
their
merge
requests
in
garrett
and
they
also
have
the
assignee
and
they
actually
say
that
it
can
be
used
together
with
the
attention
set.
We
do
not
recommend
doing
so.
Using
both
features
is
likely
confusing.
B
The
distinct
feature
of
the
assignee
compared
to
the
attention
set
is
that
only
one
user
can
be
the
assignee
at
the
same
time.
So
it's
like
yeah
the
person
that
needs
to
take
action,
but
it
can
be
the
author
or
it
can
be
multiple
reviewers.
B
So
it's
it's
hard
to
use
just
the
assignee
field,
and
so
what
they
say
is
you
can
use
the
signee
field
to
single
out
one
person
or
escalate
if
there
are
multiple
reviewers,
but
since
every
reviewer
in
the
attention
that
is
expected
to
take
action,
it's
not
necessary
to
single
out
one
person
and
when
they
say
every
reviewer,
it
includes
basically
anyone
here.
So
it
can
be
someone
that
is
watching
the
change
or
someone
that
uploaded
the
change.
B
So
basically
the
attention
set
is
not
only
for
reviewers
it's
for
anyone,
so
they
say
that
using
the
assignee
field.
In
addition,
it
doesn't
bring
any
significant
benefits,
yeah,
so
yeah
this.
I
think
this
is
an
interesting
take
on
it,
and-
and
I
encourage
you
to
to
read
this
in
your
own
time
but
yeah.
This
conversation
reminded
me
about
this.
A
B
Oh,
it
looks
like
we're
we're
over
time,
just
yeah.
A
Cool
well
thanks
everyone.
It
was
good
to
see
you
all
again
enjoy
welcome
back
to
the
new
year
and
hopefully,
it's
off
to
a
good
start,
can't
be
ruined
yet
we're
only
five
days
in
so.