►
From YouTube: 2021-03-09 Create:Code Review Weekly 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
Yeah,
so
I
have
the
first
second
and
third
points
of
the
agenda.
Yeah
welcome
sunjung,
and
for
those
of
you
who
are
not
aware,
syndrome
will
be
with
us
in
code
review,
helping
us
for
three
milestones
and
the
official
start
milestone
will
be
1311
and
that's
why
I'm
already,
including
her
in
as
many
things
as
possible,
while
being
mindful
of
her
existing
commitments
with
geo
and
the
distribution
team.
And
so
thank
you
so
much
for
being
here
with
us
and
for
helping
us.
A
Thank
you.
Thank
you,
yeah.
I
noticed
that
this
meeting
happens
outside
your
working
hours
in
june,
but
I
am
also
not
sure
how
well
it
lands
on
other
people's
schedules.
Should
we
move
it
a
bit
earlier,
I'm
not
familiar
with
how
you
plan
your
work
day.
B
C
E
A
Okay,
okay,
yeah
yeah.
I
don't
think
it
will
work
if
we
move
it
sooner,
but
I'll
take
a
look
and
see
what
I
can
do
and
I'll
if,
if
anything,
I'll
ping
you
in
slack
with
with
a
proposal,
if
I
find
anything
interesting.
A
Yeah
kai
kai
suggesting
leaving
it
as
it
is,
and
maybe
adding
an
additional
sink
if
needed,
yeah,
let's
keep
it
as
it
is,
and
maybe,
when
sunjun
is
already
with
us,
we
will
change
things
yeah.
So
for
this
partnership,
it's
still
in
the
beginning,
and
I'm
still
thinking
through
this
and
to
think
about
the
best
way
to
handle
it.
I
know
you
kai,
I
have
been.
You
were
involved
in
the
conversations
leading
up
to
this
transition
of
sunjung
and
yeah.
A
My
my
framing
for
this
and
I'll
then
want
to
hear
your
thoughts
as
well.
Is
that
I
don't
think,
there's
an
expectation
that
mrs
will
be
completely
redesigned
and
that
it
will
be
a
much
better
place
in
just
three
months
also
because
I'm
already
thinking
that
it
will
be
just
like
two
active
months
like
the
first
month
will
be
kind
of,
let's
see
how
it
goes
and
also
making
sure
that
she
is
comfortable
and
up
to
speed
on
everything.
So
I
think
the
ideal
outcome
is,
of
course,
to
validate
that.
A
This
is
something
that
is
needed
for
code
review
and
it
will
provide
hopefully
much
needed
ux
improvements
that
are
visible,
small,
yet
impactful
and
that
prove
that
and
also
enabling
other
teams
to
contribute
to
the
merge
requests.
Ux,
that's
that's
my
framing,
but
I
like
to
give
your
thoughts
as
well.
C
Yeah,
I
think
I
haven't
fully
adjusted
to
the
idea
of
a
temporary
move,
yet
I
think
right
when
we
sort
of
originally
thought
about
this.
We
were
thinking
it
would
be
someone
that
would
come
in
full
time
and
I
had
sort
of
the
way
we
had
thought
about.
It
was
that
they
would
pick
up
sort
of
some
of
the
in-flight
design
work
to
get.
You
know,
issues
that
needed
that
feedback
done
like
that
were
in
dev
during
the
milestone
done,
and
they
would
help
out
on
merge,
request,
reviews
and
those
other
pieces.
C
I
don't.
I
don't
know
that
that's
valuable
now
in
the
sense
that,
like
this
is
short
term
and
I'd
rather
and
marcel,
brought
up
some
good
opportunities,
and
I
think
I
think
reframing
it
to
be
less
about
tactical
day-to-day
and
more
about
these
other
things
is
sort
of
the
right
approach,
but
I
would
also
like
to
like
keep
the
problem
space
small.
C
I
think
it's
too
hard
to
like,
say,
like
hey,
look
at
merch,
request,
widgets
and
look
at
reviewers
and
handoff
and
looking
at
catching
up
on
an
mri
like
all
of
those
are
sort
of
like
deep
problem
spaces
and
would
be
challenging
for
anyone,
and,
I
think,
like
we
should
just
pick
one
of
them
and
sort
of
use
that
as
a
way
to
like,
have
an
impact-
and
I
think
that's,
I
think,
you've
put
some
good
options
up.
I'm
curious
like
what
you're
what's
high
on
your
list
and
what?
E
A
Yeah
and
the
other
thing
we
need
to
think
about
is
when,
when
tsunjung
is
no
longer
with
us,
like
we
don't
know
what
will
be
the
end
of
this,
and
if,
if
we
will
renew
this
partnership,
if
yeah,
we
don't
know
what's
going
to
happen,
so
I
think
we
also
need
to
prepare
for
the
situation
where,
unfortunately,
she
will
move
on
to
other
things
after
code
review
and
what
investment
will
we
make
with
these
three
milestones
and
what
help
she
can
give
us
and
so
yeah.
A
A
Yeah
in
terms
of
the
the
priorities
there,
those
are
just
I
know
some
themes,
ideas
that
I
had
in
mind.
So
the
first
one,
the
merge
request,
merge,
widgets,
there's
a
an
issue
there.
I
think
it's
something
that
we
can.
I
hope
we
can
prioritize
for
13
11..
If
not,
I
think
it's
even
if
it
doesn't
go
into
1311,
I'm
not
super
concerned,
but
it's
something
that
I
think
will
be
more
or
less
aligned
so
that
we
can
work
on
it
whenever
there
is
engineering
capacity.
A
Basically
related
to
that,
I
didn't
link
the
issue
there.
Well,
let
me
see
if
I
can
find
it,
but
there's
an
issue
that
I
created
for
amy
to
help
us
improve
the
ui
text
of
the
merge,
widget
and
all
of
the
messages
that
appear
there,
because
they're
all
many
problems
inconsistent,
it's
difficult
to
understand
what
they
mean
sometimes-
and
I
think
these
two
things
ui
text
and
the
specific
issue
that
I
have
there
to
restructure-
that
merge
widget
just
slightly
but
enough
to
have
a
specif,
a
good
usability
impact.
A
C
Yeah,
I'm
just
gonna
say,
is
this
like
being
mindful
of
like
how
much
time
we
have
now
to
sort
of
get
through
five
of
these
is
you've
already
spent
a
bunch
of
time
on
the
merge
request.
A
No,
no,
no
you're
you're
right
yeah.
No!
That
was
not
my
intention.
I
mean,
of
course,
xunjung
will
be
aware
of
this
because
everything
is
connected.
She
will
need
to
not
know
deeply
about
this,
but
be
aware
of
what's
happening
and
with
the
work
that
we've
done
here,
but
but
no
that's
not
my
intention,
because
there's
a
lot
a
lot
to
work
on
merge,
request,
widgets
in
terms
of
breaking
it
down.
A
I
already
did
some
of
that
and
I'm
experimenting
with
like
using
the
right
score
for
specific
elements
of
the
or
aspects
of
designs
and
and
that's
why
I'm
I'm
aiming
for
this
restructuring
and
also
this
issue
here,
ui
text
improvements
that
I
think
will
have
the
biggest
benefit
so
right
now.
This
is
more.
I
think
this
first
point
is
more
of
a
and
not
so
much.
Let
me
add.
A
The
other
thing
is
the
framework
for
other
merge
request,
widgets,
which
again,
I
also
don't
don't
think
this
is
something
that
syndrome
should
work
on,
but
it's
something
and-
and
here
the
reason
I'm
I'm
explaining
all
of
this
is
because
the
partnership
is
not
only
what
tsunjung
will
be
working
on,
but
also
what
I
won't
be
working
on,
or
what
I
think
would
be
a
better
use
of
my
time
doing
and
specifically
for
the
framework
of
other
merge
requests.
A
Widgets
we're
still
waiting
for
the
the
research
to
provide
some
light
on
the
next
steps
forward,
and
if
we
need
more
research,
if
we
there
are
things
that
we
can
start
exploring
today
or
not,
but
I
believe
that
the
most
reasonable
way
for
us
to
make
some
progress
here
without
giving
soon
jung
a
lot
of
knowledge
that
we
don't
know
if
she
will
stay
around
in
code
review
and
also
for
my
time
and
other
things
that
I
feel
could
be
more
impactful
is
perhaps
trying
to
delegate
this
job
to
another
group.
A
While
having
me
with
more
freed
time,
given
that
syndrome
will
handle
other
parts
of
the
design
work,
I
will
be
leading
them
and
helping
them
navigate
this
task
of
the
framework,
but
not
being
in
the
weeds,
doing
all
of
the
more
detailed
work
and
that's
I
that's
my
proposal
and
what
I
think
could
be
reasonable,
given
everything
else
on
this
list,
but
I
think
this
will
probably
become
clearer
once
we
go
through
all
of
the
steps
but
I'll
I'll
stop
there,
and-
and
I
see
that
catherine
has
a
comment
about
the
research.
A
D
Like
the
different
elements
that
are
in
the
widget
and
trying
to
pull
together
the
research,
so
the
hunt
for
the
different
elements
was
very
interesting
because
in
a
lot
of
the
issues,
quite
a
few
of
them,
just
kind
of
didn't
provide
much
context
on
who
it
was
for
and
why
it
was
created.
It
kind
of
was
just
created
and
the
the
widget
was
just
growing
over
time
because
of
these
new
opportunities
to
prevent
more
information.
D
So
sometimes
there
wasn't
necessarily
a
cohesive
reason
for
why
it
was
added,
but
something
that
did
come
out
of
it
was
some
like
a
bit
of
the
the
top
people.
The
information
is
supposed
to
be
communicated
towards
which,
I
would
say,
are
software
engineers,
devops
engineers
and
security
analysts
with
some
other
people
in
the
mix.
D
So
what
I've
kind
of
gathered
from
this
is
that
it's
kind
of
been
designed
piece
by
piece
by
different
contributors
over
time,
and
so
what
I
think
the
next
phase
of
research
would
be
is
an
evaluation
of
the
overall
experience
of
like
the
high
level
job
to
be
done,
which
is
consuming
information
about
the
impact
of
changes
that
are
introduced
by
your.
Mr.
D
So
I
think
what
comes
next
is
coming
up
with
some
research
questions
around
the
entire
mr
widget
experience.
But
there
also
is
the
opportunity
to
test
some
designs.
If
you
wanted
to
do
that
as
well,
so
I'm
not
sure
if
it
might
be
a
combination
where
we
do
some
usability
testing
of
the
current
experience,
but
also
present
some
designs
of
where
you
think
it
might
go.
D
That
is
an
option,
but
that's
what
I'm
going
to
flesh
out
in
a
in
a
new
research
issue,
which
will
just
be
an
evaluation
of
how
this
kind
of
works
cohesively,
because
the
widget
basically
has
a
bunch
of
different
audiences
and
different
jobs.
It's
trying
to
accomplish
all
in
one
place.
That
is,
that
is
basically
the
outcome
of
what
I.
What
I
learned
from
that
yeah,
so
the
next
step
for
me,
will
be
to
create
a
research
issue
to
come
up
with
a
plan
for
evaluating
the
overall
experience.
A
Okay
yeah
this
is
this
is
great.
Thank
you
so
much
for
sharing
yeah
and
I'm
I'm
I'm
it's
a
bit,
I'm
happy
and
and
a
bit
it's
bittersweet
sweet
because
yeah.
I
knew
that
this
was
a
daunting
task
and
basically,
I
think
the
the
outcome
is
that
we,
we
know
a
lot
about
the
merge
request,
widget,
but
we
still
don't
know
enough
right
and.
D
Yeah,
because
what
was
interesting
was
going
through
all
the
different
research
studies.
There
were
studies
where
it
was
kind
of
included,
but
not
the
main
focus
of
the
study.
The
main
focus
probably
was
just
accessibility,
workflows
in
general,
and
then
they
might
include
a
task
about
looking
at
this
design
for
including
information
about
it
in
the
mr
widget.
So
that's
what
I
noticed
from
the
collection
of
studies.
There
wasn't
like
a
focus
here
is
the
mr
widget:
what
is
the
information
on
this
page
describing?
What's
the
purpose
of
it?
D
How
do
you
navigate
through
it
and
read
all
this
kind
of
information
at
once?
Do
you
even
need
to
do
that?
So
I
think
that's.
The
research
study
that
we
need
to
do
as
a
result
of
this
is
something
more
about
the
holistic
experience
of
it,
and
that's
why
I
think
I
don't.
I
didn't
find
anything
that
would
say
the
changes
you're
planning
to
make
to
that
the
merge
widget
shouldn't
be
applied
to
others,
but
that
might
be
something
to
explore
further.
D
A
D
Yeah
one
part
of
it
could
be
us
kind
of
outlining
the
questions
that
we
find
most
important
for
the
widget
or
the
things
that
are
most
important
for
us
to
figure
out
before
we
make
any
changes,
because
I'm
not
sure
what
our
main
concern
is
is
our
main
concern
kind
of
like.
Is
it
too
big?
Is
it
too
cluttered
like
if
there's
something
like
that
that
we
can
dive
more
into?
A
Yeah,
I
I
don't
know
I
have
the
feeling
that
it
will
be
hard
to
find
a
cohesive
story,
because
all
of
the
widgets
are
different
and
I
assume
that
they
all
cater
different
personas
and
at
different
points
in
time
of
the
review
process
as
well,
but
but
but
yeah
I
get.
I
I
get
what
you're
saying.
I
would
really
want
us
to
make
some
progress
on
this,
but
I
think
that
the
biggest
issue
is
just
yeah.
A
That's
lacking
that
overall
sense
of
exactly
what
we
need
to
to
to
do
about
all
of
the
widgets,
not
just
one
widget
but
all
of
them
and
how
helpful
they
are
and
etc,
etc.
Okay,
okay
yeah.
We
can
talk
about
this
separately
because
I
think
it
warrants
that
and-
and
maybe
creating
that
issue
is-
is
the
next
best
next
step
here,
but
again.
Coming
back
to
my
original
point,
I
this
is
something
that
we
need
to
work
on,
but
I
think
there
are
other
things
that
we
can
do.
A
That
will
hopefully
alleviate
the
pain
of
the
merge
request
widgets,
because
one
thing
that
we
have
certainly
validated
is
that
it's
just
too
much
right.
It's
there's
just
so
many
it
or
there
could
be
so
many
merge
requests
widgets
that
push
down
important
actions
on
the
page
and
that's
my
point
h
below,
but
I'll
talk
about
that
when
we
get
there.
D
Yes,
so
see,
so
that's
a
that's
a
great
point
right
there,
because
that,
I
think,
is
what
will
help
so
what
you
just
said
about
it
being
too
much
and
pushing
things
down.
I
think
a
question
that
comes
out
of
that
is
maybe
maybe
around
usage
like
what
which
ones
are
most
interacted
with
or
which
ones
could
potentially
be
surfaced
in
other
parts
of
the
product,
so
I
would
just
say
higher
level
higher
level
questions
like
that
would
be
helpful.
D
D
A
Okay,
moving
on
reviewers
in
handoff.
A
The
other
angle
is
the
merge
request
list,
but
I
don't
think
that's
as
much
related
to
handoff.
I
mean
it
is,
but
not
in
the
the
review
flow,
and
I
don't
have
a
clear
sense
of
how
high
or
low
this
is
in
the
list
of
priorities,
so
that
this
this
one
is
when
I
need
help
from
yukai.
C
I
see
sort
of
this
and
the
next
one
as
different
but
related
because
part
of
understanding,
like
handoff
and
where
things
are,
is
also
related
to
understanding
sort
of
the
state
of
what's
been
reviewed.
What
hasn't
been
reviewed?
What
what's
changed
since
the
last
time
I
looked
at
it
and
sort
of
all
of
those
things
together.
C
C
C
How
does
the
application
help
communicate
that
progress
to
other
people
so
that
people
know
where
in
the
process,
the
merge
request
is
part
of
that
is
the
handoff
right,
and
I
think
that
is
like
a
very
small
subset
of
tracking
all
of
this,
but
I
think
you
can
do
both
of
them
sort
of
separately
and
we
sort
of
are
working
on
both
of
them
at
the
same
time
but
separately.
C
C
Well,
let's
surface
that
information
in
the
merge
request
like
how
do
we
show
people
that
I
have
reviewed,
seven
of
10
files
in
a
merge
request
to
me,
the
obvious
place
to
do
that
is
sort
of
over
in
the
reviewers
bar,
but
now
we're
we're
very
quickly
overloading
like
the
reviewers
area
with
more
information,
but
that
is
sort
of
the
the
place
where
you
talk
about
what
that
reviewer
is
doing
and
communicating
that
status.
C
A
A
Best
mvc
and
states
right:
where
would
you
say
okay,
this
is
good
for
now,
people
are
using
this,
let's
wait
for
more
usage
and
then
we
will
see
what
other
interesting
problems
arise
and
now
we're
able
to
prioritize
them
better,
because
we
have
this
buffer
of
time
and
usage.
C
Yeah,
I
think,
for
reviewers
and
handoff
that
is
sort
of
that
last
piece
that
we've
been
talking
about
in
terms
of
the
waiting
for
me,
filter
sort
of,
is
what
we're
calling
it.
I
think
that's
sort
of
the
place
we
have
to
get
to
with
reviewers,
and
I
think
we
have
to
do
that
pretty
quickly.
C
I
don't
think
we
need
to
you
know,
there's
a
lot
of
stuff
that
we
want.
I
would
like
to
do
in
terms
of
surfacing
the
right,
reviewers,
better,
auto
assigning
and
those
things.
C
I
think
those
are
sort
of
nice
to
haves,
but
I
think
getting
that
that
handoff
piece
in
there
in
sort
of
the
very
simplified
way
that
it's
all
manual,
where,
like
you,
click
I'm
done
or
I'm
not
done,
and
that
that
to
me
gets
us
to
a
point
on
reviewers
where,
like
I
feel
really
good
about
what
that
is
and
where
that,
where
that's
at,
and
so
I
think,
there's
there's
that
amount
of
work
there
right
and
I
think
that's.
C
We
talked
about
five
or
six
themes
in
that
bigger
issue,
but
that's
probably
the
one
that
I
think
for
me.
I
know
we're
up
on
time
so
catching
up
on
an
mr.
I
think
I
have
less
clear
understanding
of
where
this
might
stop.
I
think
the
big
one
is.
We
know
there
is
a.
C
We
see
a
lot
of
feedback
around
communicating
what
I
have
reviewed
and
how
much
I
have
left
to
review,
and
so
I
feel
like
we're
close
when
we
introduce
the
checkbox
for
viewed
file.
I
think
the
goal
here
is
like
how
do
we
persist
that
information
and
then
how
do
we
share
that
information?
It's
sort
of
the
the
final
pieces
there
and
I
think
that
would
get
us
again
to
a
stopping
point
where
we
can
say:
okay,
here's
everything
that
you
can
do
now.
C
You
can
now
see
pedro
has
reviewed
seven
under
the
ten
files
in
emr.
That's
great!
I
understand
that
we're
all
happy
now
like
now.
Let's
see
what
other,
what
other
things
we
need
to
do
as
part
of
that
right,
there's
lots
of
things
that
people
want
to
do.
They
want
to
change
the
view
so
that
they
only
have
to
review
the
five
files
that
they're
marked
as
the
code
owner
for
not
all
10
files
right,
like
that,
that's
an
important
distinction
in
and
which
files
you've
reviewed
and
why
you've
reviewed
them.
C
A
A
Yeah,
I
also
don't
know,
what's
what
would
be
the
first
piece
like
in
the
same
using
the
same
terminology,
that
of
the
reviewers
and
handoff
like
what
is
the
best
first
mvc
that
we
can
deliver
here,
but
I
think
that
it
might
be,
as
I
wrote,
a
shallower
problem
space
compared
to
other
things.
Of
course,
it
can
go
as
deep
as
we
want,
but
to
provide
relief
to
users
of
this
current
problem.
I
think
there
are.
A
There
could
be
some
things
that
we
can
do
that
are
not
a
huge
effort,
but
have
a
big
impact
on
catching
up
to
an
mr,
and
because
this
is
yeah,
as
I
said,
more
shallower
problems
in
space
and
then
I
think
we
can
more
easily
determine
okay.
This
is
what
is
what
is
good
like
this
is
where
we're
going
to
stop,
and
maybe
sun
jung
could
could
drive
this,
because
it's
it's
fairly
new
and
I
think
it's
easy
for
someone
to
get
acquainted
with
what
it
is.
C
When
you
call
it
catching
up
on
an
mr
that
problem,
space
to
me
is
very,
very
big
and
much
more
difficult
and
complex
when
we
call
it
tracking
of
like
review
status
or
like
what
you
viewed.
The
problem
taste
is
much
more
focused
and
like
easier
to
digest
like
when
you
say
catching
up
on
an
mr
to
me.
That's
like
a
totally
different
thing.
Almost
that
is
I,
as
a
user,
come
back
to
an
mr
after
I
have
reviewed
it
requested
the
author
make
changes
I
come
back.
C
I
now
need
like
a
sort
of
entirely
different
view.
That
tells
me
like
here's,
the
diff
of
the
diff
of
the
last
time
and
what
you
need
to
look
at
this
time
and
that
to
me
feels
much
more
complicated
than
like
tracking
status
and
sort
of
me
as
a
reviewer
getting
a
tool
set
to
say
this
is
what
I
have
done
this
time
around.
I
guess
I
think
that
the
phrase.
A
But
yeah
we
can.
We
can
discuss
this
separately,
but
these
are
just
proposals
and
the
last
one
I
wanted
to
cover,
which
I
think
could
help
solve
a
little
bit
of
the
reviewers
and
hand-off
is
a
bit
of
that
pain
and
also
the
merge
widget
and
the
framework
for
merge
request.
Widget
is
trying
to
consolidate
all
of
the
global
mr
actions
in
a
single
place,
and
if
we
could
move
the
merge
button
into
a
more
visible,
always
present
location,
the
approve
button,
the
like
whatever
global
actions.
There
is
the
merge
request.
A
Widgets
won't
be
as
much
of
a
priority.
There
will
still
be
a
priority,
but
I
think
lower
on
the
list,
because
it
would
be
easier
for
people
just
to
get
to
the
actions
that
they
want
and
if
they
then
want
more
information
about
this
checks
that
are
failing
or
who
has
approved,
who
hasn't
approved.
A
They
then
go
to
the
emerging
quest
leader,
but
they're
not
required
to
go
through
it
to
find
the
most
important
actions
in
the
merger
request
page
and
that's
something
that
I
think
ties
well
with
everything
else
and
his
basic
basic
usability.
A
Having
the
global
actions
always
present
or
in
an
easily
accessible
location,
yeah,
I
don't
we
don't.
We
don't
need
to
talk
about
the
the
other
points,
but
we
can
talk
about
that.
Async.
Any
any
comments
about
this
last
one
before
we
wrap
up.
C
Did
you
have
like
a
preference
of
what
you
wanted
to
work
on
or
do
I
know
you
commented
back,
but
like
code
review
is
sort
of
more,
it
has
a
ui
and
it's
feature
facing
and
geo
might
not
it's
like.
That's
something
that
you
wanted
to
like.
C
Go
and
like
flex,
the
muscle
in
terms
of
like
ui
design,
thingies
versus
I
said
thingies,
which
is
not
super
helpful
but
like
ui
work
versus
sort
of
like
the
work
you
might
have
done
in
geo
or
other
places
where
there's
less
of
that
is
that
that
may
help
too
like-
and
I
would
say,
like
all
of
these
things
are
priorities.
C
Code
review
has
an
unlimited
amount
of
opportunity
and
just
a
a
small
amount
of
pedro
and
so
like.
That's
not
that
he's
a
bottleneck,
but
that
is,
we
do
have
lots
of
engineers
and
so
like.
If
we
can
feed
lots
of
engineers,
then
like
we
can
get
lots
of
stuff.
So
if
there's
something
you
wanted
to
do
that,
you
might
not
get
to
do
in
geo,
like
I'm
also
happy
to
like
explore
those
those
things
as
well.
B
So
I
already
commented
on
here
about
like
it's
really
about
the
team
and
teams
priority
if
engineers
are
waiting
for
some
of
the
design,
I'm
happy
to
deliver
something
super
fast,
of
course,
in
a
very
smaller
scale
at
first
time.
So
I
think
what
I'd
like
to
do
is
maybe
just
starting
from
the
small
ui
pieces,
I'm
not
so
sure.
If
we
have
that
any.
I
think
I
need
to
double
check
the
details
that
pedro
shared
with
me.
B
He
shared
with
me
some
of
the
links,
but
I
haven't
checked,
like
an
apologies,
that
I
think
I
should
have
more
prepared
for
this
meeting,
but
I
was
just
like
chiming
today.
So
sorry
I
I
really
not
prepared
for
today,
but
I
think
probably
for
the
next
week's
meeting
I'll
be
more
prepared
and
then
I'll
just
start
to
picking
up.
B
If
you
don't
mind,
I
can
just
assign
myself
and
just
crafting
things
for
the
front-end
engineer
so
that
they
can
work
on
something
and
in
the
meantime
I
can
also
look
and
go
through
the
katherine's
work
and
some
of
the
prior
research
so
that
I
can
understand
the
common
behavior
on
this
page
and
how
does
mr
widget
related
to
other
teams
feature
so
that
I
can
have
also
the
high
level
big
picture,
but
normally
that
takes
some
time.
So
I'd
like
to
start
with
the
small
ui.
A
Business
yeah.
I
think
there
will
be
a
lot
of
those
issues
and
in
tomorrow's
participation
session
I
think
we
will
cover
some
of
them.
So
if
you
could
join
that's
that's
good.
If
not
we,
it
will
also
be
recorded
so
yeah.
There
will
be
certain
issues
for
you
to
work
on
that
are
small.
We
have
lots
of
bugs.
A
We
have
lots
of
depth
issues
and
ui
polished,
so
there's
no
shortage
of
that
in
this
stage
and
yeah
I
didn't
cover
those
here
because
I
for
me
those
were
given
so
to
speak
because
it's
part
of
the
job.
Basically,
these
were
more
the
the
themes
and
projects
that
need
a
bit
more
focus
in
the
strategic
work,
but
yeah
for
sure.
We
can
start
now.
A
C
E
A
For
others,
if
you
understand
the
call,
that's
also
okay,
but
I
can
stay
all
right.
A
Well,
that's
amazing.
Okay,.
A
Yeah,
so
so
that
issue
it's
a
very
interesting
one
and
I
won't
cover
the
context,
but
but
soon,
if
you're
interested,
you
can
read
it
async,
but
basically
we
ended
up
involving
almost
all
engineers
or
all
engineers
in
the
code
review
group
to
provide
feedback,
and
it's
very
debatable
topic
with
many
different
points
of
view
and
we're
starting.
I
was
trying
to
get
to
an
agreement
on
one
proposal
that
could
alleviate
the
current
pains.
So
so
yeah,
it's
a
really
long
issue.
A
A
I'm
just
not
sure
about
the
mr
drop
down
because
of
changing
that
and
moving
away
from
the
drop
down
and
having
just
one
link
and
if
that,
when
you
so
first
of
all
when
you,
when
you
left
that
comment
that
I
quoted
here,
we
should
get
rid
of
the
mr
drop
down
in
the
main
nav
and
just
move
to
the
simplified
model.
A
A
I'm
assuming
that
people
will
be
confused
about
just
showing
things
that
they're
that
others
are
waiting
for
them,
and
how
can
I
see
all
the
ones
that
I'm
assigned
to
because
it's
it
won't
be
just
a
one-click
thing.
C
Yeah,
I
think
if
you,
if
you
go
back
in
time,
45
days
or
60
days
before
we
introduce
the
drop
down,
that
was
the
only
way
you
could
do
it
right.
You
clicked
on
it
and
it
went
to
a
list
of
things
where
you
were
the
assignee
and
the
reason
we
put
the
drop
down
in
is
because
now
there
were
sort
of
places
that
you
could
be.
You
could
either
be
an
assignee
or
you
could
be
a
reviewer
and
it
was
confusing,
and
how
did
you
get
to
one
versus
the
other?
C
C
That
count
went
from
two
to
one
and
you
had
one
more
thing
to
do
and
when
you
clicked
on
that
button,
you
were,
you
only
saw
the
one
where
you
had
something
to
do,
and
so
I
think,
by
going
back
to
waiting
for
me
or
like
waiting
for-
and
it
would
be,
you
know
your
username-
that's
the
like
default
search.
We
essentially
go
back
to
what
it
was
before.
C
Where
that
is
a
to-do
list.
You
click
on
it.
It
shows
you
all
of
the
things
you
need
to
action
and
then
you
as
you
action
them
and
your
status
changes
and
it's
no
longer
waiting
for
you.
The
list
shrinks
right.
It
goes.
The
count
goes
from
six
to
five
to
four
to
three
to
two
to
one
to
zero
and
you
have
burned
down
that
version
of
the
basically
the
merge
request
to-do
list,
and
so
I
think
that's
what
everyone's
asking
for
and
you're
right.
C
C
My
concern
is:
we
got
an
inc,
I
mean
I
had
to
fight
with
every
other
product
manager
up
my
up
my
chain
in
the
dev
section
to
like
get
us
that
drop
down
sort
of
with
an
expectation
that
like
we
would
try
and
remove
it
at
some
point,
and
I
know
we
don't
have
to
remove
it
if
we
think
there's
a
better
ui,
but
but
I
also
know
that,
like
people
were
very
resistant
to
the
drop
down,
even
even
you
and
I
went
back
and
forth
like
we
argued
about
two
clicks
for
the
longest
time
and
now
you're
sort
of
like
well,
let's
keep
two
clicks
and
I
think,
like.
A
You're
right,
but
now
it's
done
now,
it's
done
so
one
thing
is
when
it
wasn't
done.
The
other
thing
is
when
it's
already
done.
We
already
had
the
precedent,
and
that
was
my
main
concern
is
was
was
mostly,
of
course,
the
clicks,
but
also
the
precedent,
and
how
could
we
now
we
have
the
drop
down.
How
can
we
elegantly
move
away
from
the
drop
down
and,
yes
sure
some
instances
haven't
been
upgraded
yet
and
they
probably
will
never
see
the
drop
down.
A
A
But
I'm
mostly
concerned
it's,
it's
not
just
it's
not
really
about
the
drop
down.
It's
okay!
It's
one
click
and
you
go
to
the
list
that
you're
waiting
for
and
that's
cool.
That's
that's
exactly
what
the
feedback
that
we
were
hearing
which,
by
the
way
I
don't.
I
don't
know
if
it's
just
internal
feedback
and
how
other
teams
would
respond
to
that.
But
let's
assume
that
yes,
that's
the
way
that
others
will
also
want
it.
A
How
can
I
then
see
other
merge
requests
that
I'm
assigned
to
or
that
I'm
the
reviewer
and
I
need
to
go
and
check
something
or,
for
example,
I'm
assigned
an
assignee,
and
I
I've
requested
a
review
from
someone,
but
it's
not
showing
up
on
my
waiting
for
lists.
So
how
can
I
go
and
re-request
a
review
from
the
reviewer
or
change
to
another
reviewer
or
see
what's
going
on,
like
maybe
they
forgot
to
click
the
waiting
for
assignee
button
or
something
like
that.
A
So
how
can
I
check
the
status
of
maybe
a
running
pipeline
or
I
set
mergement
pipelines,
so
you
know
so
I
I
don't.
I
think
there
are
other
things
that
people
need
to
do
with
merge
requests
that
may
not
fall
within
the
waiting
for
list
and
people
still
need
to
go
there
and
there's.
There
will
be
a
lot
of
friction
to
do
that,
because
they
would
have
to
remove
the
filter
they
would
have
to
type
assignee
and
then
go
and
select
their
username
or
use.
A
So
that's
that's
the
friction
that
I'm
seeing
here
and
since
we
already
have
the
drop
down,
an
iteration
would
be
to
use
that
space
to
yes,
make
it
better
and
remove
that
big
problem,
which
is
the
counter
right
and
now
you
have
a
focused
list
and
I
think
that's
the
biggest
benefit.
You
have
a
focused
list
of
things.
A
You
need
to
burn
down,
as
you
said,
but
we
can
also
still
use
the
drop
down
to
navigate
people
to
the
right
place
of
seeing
all
the
requests
they're
assigned
to
and
then
the
ones
they're
reviewing,
because
we
haven't
figured
that
out
in
the
list
itself
or
with
another
way.
Yet
right.
C
Trigger
the
complaint,
if
it
exists,
there's
not
always
the
best
thing
to
do
in
the
merch
request
group.
I
know
we've
been
a
lot
of
trouble
for
this
actually
in
this
group,
but
I
wonder
if.
C
It
might
be
better,
though,
if
like
gitlab
resent
notifications
or
like
triggered
a
to-do
for
me,
as
the
author
of
the
merge
request
and
like
said
hey,
this
merge
request
is
stale.
It's
48
hours
old,
like
we
have
the
gitlab
bot
that
like
goes
through,
and
it's
like.
This
merge
request
is
stale
and
it
sends
you
a
long
list
of
merge
requests
and
you're
like.
C
If
we've
given
people
sort
of
a
easy
loophole,
and
they
ignore
like
that
piece
of
it,
and
I
I
don't
want
to
force
the
issue
too
hard,
but
I
also
think,
like
that's
sort
of
the
point
of
of
getting
to
this
waiting
for
and
having
the
drop
down
is,
it
is
supposed
to
be
like.
These
are
the
things
you
should
care
about
in
action,
and
we
want
you
to
be
very
focused
on
these.
C
If
you,
in
the
back
of
your
mind,
don't
trust,
get
lab
to
be
identifying
the
things
that
you're
working
on
that's
sort
of,
like
always
going
to
be
a
nagging
concern
for
you
that
that,
like
what
are
all
my
mrs
there,
am
I
really
getting
everything
that
I'm
supposed
to
do.
Why
do
I
need
to
go
to
these
other
pages
right,
like
you
might
always
sort
of
like
doubt,
the
system.
C
And-
and
maybe
we
just
need
to
think
about
them
differently
and
it
could
be,
we
need
to
leave
the
drop
down
until
we
can
solve
those
in
the
more
elegant
way.
But
but
we
know
how
code
review
works
and
we've
got
5
000
issues
to
deal
with,
and
we
always
have
things
that
we
could
go
do
and
and
will
that
ever
rise,
the
cream
of
the
crop
being
versus
like
sometimes
when
your
hand
is
forced,
it
makes
it
easier
to
prioritize
things.
A
I
okay,
so
one
thing
technically
that
I
want
to
clarify
is:
if
we,
let's
imagine,
we
remove
the
drop
down
and
now
it's
just
a
link
if
we
were
to
use
feature
flags
for
that.
Let's
imagine
the
feature
flag
would
be
global
for
all
of
gitlab.com
and
we
can't
flag
that
just
for
the
yeah.
Just
I
don't
know
if
you're
aware,
but
it
was
just
to
fyi.
So
those
things
are
more
global.
Also
the
filters
we
can't
feature
flag
for
groups
or
projects.
A
A
And
yes,
we
could
solve
problems
more
creatively
and
I
mean
that's.
We
always
have
that
option
with
everything,
but
that
means
always
delaying
iterations
right,
the
same
thing,
with
the
drop
down
being
a
crutch.
Why
did
we
go
to
the
drop
down?
We
could
have
spent
more
time
researching
and
designing
the
other
options
like,
for
example,
the
other
ones
I
presented
there
wasn't
a
lot
of.
A
We
didn't
do
research
on
them
and
maybe,
if
we
had
done
it,
we
would
have
a
better
sense
and
make
a
more
informed
decision
that
okay,
this
is
actually
a
really
great
design
or
maybe,
if
we
tweaked
this,
it
would
be
better,
but
it
will
be.
It
will
take
us
longer
to
get
to
that
state
where
we
are
more
confident
and
probably
it
will
be
a
much
harder
iteration
to
implement.
It
would
have
taken
longer
like
one
milestone
or
two
milestones,
and
I
think
the
same
thing
applies
here.
A
The
drop-down
is
a
crutch,
but
it's
there
for
a
reason.
It's
there
for
us.
I
think,
in
a
way
to
delay
facing
the
problems
that
we
know,
because
if
we
are
going
to
face
them
now,
it
will
delay
everything
because
we
will
have
to
always
define
creative
solutions
to
the
problems
and
those
creative
solutions
can
likely
create
more
effort.
A
So
it's
a
bit
of
a
cat
and
mouse
game,
I
think
and
and
we
need
to
find
the
balance
between.
A
Decent
or
good
enough
and
perfect
and
the
perfect
would
be
just
one
click
well
which
actually
I
don't
know
if
it's
necessarily
true,
I
mean
we're,
assuming
that
what
people
want
is
one
click
but,
for
example,
just
just
as
an
aside
in
axure
devops.
What
they
actually
have
is
a
smart
drop
down.
A
Where
you
don't
go
to
a
list,
you
click
and
you
see,
I
think,
the
first
five
items
on
the
list,
so
you
don't
have
to
go
to
a
list
and
refresh
you
can
just
navigate
to
the
work
items
and
if
you
want
to
see
all
of
them,
you
then
go
to
a
list.
So
there
are
many
other
ways
also
for
us
to
work
with
a
drop
down.
But
with
this
iteration
of
a
drop
down.
A
C
With
yeah,
I
think
that's
fair,
I
mean
the
workaround
does
exist
in
like
the
global
search
bar
gives
you
both.
D
D
C
I
mean,
I
think,
you're
right,
like
I
think,
immediately.
Solving
the
count
problem
is
sort
of
the
most
important
and
if
we
left
assigned
to
you
and
review
requests
for
you
but
sort
of
they
didn't
belong
to
that
orange
number.
Then
then,
maybe
that's
okay,
and
then
we
can
think
about
those
other
things.
Some
more
because
yeah
I
mean,
I
think
we
all
agree.
The
most
important
piece
is
to
get
get
that
count
to
actually
be
able
to
go
down
yeah.
C
A
So
maybe
we
will
get
there
and
we
will
have
time
to
think
about
it.
I
mean
I
think
we
have
an
epic
for
it.
I
think
improving,
merge,
request,
lists
or
something
like
that.
C
A
One
thing
that
we
can
do
like
now
that
you're
thinking
saying
about
like
when
can
we
remove
the
drop
down?
What
if
we
move
forward
with
that
purpose
that
I
have
like
waiting
for
the
list?
The
number
is
the
number
of
the
waiting
for
list,
but
you
still
have
the
links
to
all
assigned
to
me
all
whatever.
A
It
is
all
review
requests
for
me,
but
we
instrument
those
links
some
way,
not
not
the
filters
themselves,
but
the
the
links
in
the
drop
down
and
not
the
requests
so
that
we
know
how
often
those
are
clicked.
Maybe
that
would
give
us
some
information
of
how
useful
they
are.
C
Yeah,
I
think
that
makes
sense.
I
also
think
we've
got
time
to
figure
that
out
right
if
we
think
about
the
waiting
for
you
stuff,
it's
probably
two
to
three
milestones
of
other
work
before
that
actually
gets
introduced,
so
we
might
have
better
ideas
there
as
well,
like
I
don't
think.
The
waiting
for
you
thing
happens
in
one
release
would
be
amazing,
but
I
don't.
I
don't
see
that
happening
in
one
really
release.
C
I
think
everyone
seems
generally
on
board,
and
I
will
also
say
the
reason
I
I
did
not
respond
at
first
is
because
I
I
typically
do
have
a
tendency
to
respond
first
and
then
that
sort
of,
I
don't
say,
discourages
the
rest
of
the
group,
but
I
wanted
I
wanted
all
the
engineers
were
the
ones
who
are
the
most
passionate
about
this,
and
I
wanted
them
to
like
provide
their
feedback
first,
which
is
why
I
sat
on
it.
A
And
so
interesting,
I
I
didn't
know
you
you
had
that
that
impression.
Well,
I
don't
know,
if
maybe
it's
true,
I
don't
know,
I
don't
find
that
the
case
for
myself,
but
maybe
it
discourages
others.
C
I
don't
know
yeah
I
felt
like
it
was
their
their.
They
were
the
ones
most
frustrated,
so
I
wanted
them
to
just
sort
of
go
through
it
and
rationalize
and
get
to
a
point
where
they
were
happy
and
then
yeah,
I
don't
know,
but
we
do
need
to
break
it
down.
We
do
need
to
figure
out
what
we
can
put.
A
Okay,
okay,
cool
I'll.
Do
that
and
then
collaborate
with
engineering
to
see
efforts
versus
ux
impact
and
let's
see
what
what
we
can
have.
But
probably
I
don't
know
if
we'll
have
something
for
for
tomorrow,
but
we
could
try
to
add
that
to
either
the
planning
issue
or
the
prioritization
session.
Although
I
already
have
a
lot
of
issues
for
the
prioritization
sessions.
So
if
you
want
to.
C
We've
talked
about
doing
this
right
where
we
give
engineering
an
epic
that
has
like
a
fully
fleshed
out
proposal,
and
I
think
you
have
a
fully
fleshed
out
proposal
at
this
point.
Right,
like
you,
have
a
here's.
What
the
mock-ups
look
like
for
in-state,
here's,
how
this
like
should
behave,
here's
sort
of
what
we
expect
the
user
interactions
to
be.
C
We
have
not
gotten
to
do
this
yet
where
we
give
engineering
that
epic
and
then
say,
please
produce
issues
and
how
to
break
this
down
and
like
go
and
solve
this,
and
that's
going
to
put
a
massive
crunch
on
them
to
like
sort
of
figure
out
what
maybe
that
first,
one
or
two
issues
are
for
1311.,
but
I
would
like
engineering
to
own
the
issue
aspect
of
this,
because
I
think
I
have
thoughts
like
I'm,
I'm
looking
at
it
and
I'm
like
well,
we
could
probably
just
build
the
back-end
database
model
to
like
do
waiting
for
you
and
we
could
ship
that
and
like
nothing
would
be
able
to
talk
to
it
but
like
that
would
get
in
and
just
we
have
a
tendency
in
this
group
to
like
compound
all
of
those
things
and
set
them
behind
one
feature
flag
and
then
like
reviewers.
C
It
was
six
months
worth
of
work
and
we
turned
it
on
and
it
was
scary
all
at
once.
But
I'd
rather
engineering
look
at
this
and
be
like
here's
the
end
state.
Here's
what
the
experience
we
want.
Please
figure
out
how
to
do
this
and
ship
every
single
one
of
these
issues
without
them
being
like
stacking
compounding
and
then
the
last
issue
that
you
ship
is
sort
of
like
the
front-end
feature
or
like
the
feature
flag.
C
C
This
is
a
small
enough
thing,
it's
big,
but
it's
still
like
small
enough
that,
like
this,
will
be
a
good
one
to
to
put
the
pressure
on
engineering
and
sort
of
like
let
them
give
them
a
little
bit
of
what
they've
asked
for,
which
is
the
ownership
in
terms
of
like
how
things
are
done
and
then
also
sort
of
forced
to
force.
The
iteration
conversation
a
little
bit
more
too.
A
I
I
love
that,
let's
do
it,
do
you
want
to
bring
that
up
async
in
the
binding
issue,
or
do
you
want
to
talk
about
it
in
the
code
review
call
tomorrow.
C
If
you
have
the
epic
like
set
up,
that's
got
like
problem
ux
expectations
and
designs.
I
think
we
just
go
over
it
tomorrow
in
the
weekly
and
we're
like
this
is
what
this
is.
The
next
thing
we
want
to
go
do
this
is
the
this
is
the
waiting
for
you
piece.
This
is
what
we
want
to
solve
and
then
let
us
know
what
else
you
need
from
us
like.
A
Okay
sounds
good
I'll,
also
list
the
must-haves
nice
to
have
them
could
have
so
that
can
help
with
the
breakdown,
but,
of
course,
the
actual
breakdown
in
navigating
those
decisions
be
up
to
them.
I
love
it.
C
Cool
well
thanks
for
sticking
around
and
thanks
sometimes
for
sticking
around
too.
I
know
it's
incredibly
late
on
your
side,
so
thanks
and
everyone
enjoy
the
rest
of
your
day.
Peter
I'll
see
you
tomorrow,
I
guess
a
couple
times.
I
think.
C
We're
excited
to
have
you
sometime,
good
luck,
hopefully,
code
review
is
everything
you
hope
it
is
and
not
we're
not
too
crazy.