►
From YouTube: 2021-11-30 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
have
the
first
point:
hey
everyone
and
now
the
second
point.
Next
steps
for
make
merge,
requests,
ui
more
organized.
So
just
before
this
call
I
was
talking
with
annabelle
and
we
were
going
through
this
huge
problem
that
is
merge
requests.
The
merge
request
is
a
problem
and
yeah.
A
Essentially
we
we
decided-
or
we
agreed
on-
that
there
are
like
most
of
the
problems
that
she
was
able
to
identify
from
the
research
synthesis
that
she
did
when
she
joined
code
review
and
now
recently,
the
user
journey
research
that
she's
completing
most
of
the
problems
that
she
found
are
all
related
to
one
another
and
that
it
might
be
possible
to
solve
each
of
them
separately.
A
And
so
we
it's
in
a
never-ending
vicious
cycle
of
trying
to
solve
things,
and
it's
related
to
or
an
example
of
that
is
that
issue
that
I
was
reviewing
recently
of
san
jung's
work,
where
she
was
trying
to
consolidate
the
actions
and
information
of
the
merge
requests
at
the
top,
so
that
you
can
easily
find
the
buttons
and
all
of
that
and
it's
a
it's
a
good
problem
to
solve,
and
we
know
it
exists
and
it's
if
we
were
able
to
solve
it
would
be
amazing.
A
So
all
of
this
is
say
that
one
specific
problem
that
we
might
be
able
to
make
some
progress
on
in
the
short
term
is
part
of
an
okr
that
jeremy
elder
the
senior
product
designer
sorry
staff
product
designer
in
the
ux
foundations
team
he's
having
a
okr
where
he's
helping
to
redesign
areas
of
gitlab
what
he
calls
the
great
unboxing
of
gitlab,
trying
to
remove
things
out
of
boxes
and
remove
horizontal
aligns
and
dividers
just
to
make
things
look
more
polished
in
the
ui.
A
So
it's
more
of
visual
design
and
one
of
the
things
was
that
annabelle
suggested
that
he
helped
us
with
us
and
also
plan
with
the
activity
and
comments
area
so
trying
to
make
things
more
readable
easier
to
scan.
What's
the
comment,
what's
a
reply:
when
will
something
merge
and
try
to
emphasize
specific
moments
in
the
timeline
versus
others?
A
So
that's
a
specific
problem
that
we
might
be
able
to
solve
in
the
short
term,
but
everything
else
annabelle,
and
I
think
that
unfortunately,
because
that's
what
I
was
hoping
that
we
would
not
do,
but
it
we
have
to
do
it
apparently
is
we
have
to
do
a
big
redesign
and
we
have
to
go
down
in
our
hole
and
design
a
lot
of
things
that
come
up
with
a
big
vision
and
then
ta-da
this
is
it
let's
break
it
down
into
small
stats?
A
Because-
and
then
you
know
funny
things
aside
is
that
we
have
to
look
at
all
of
the
problems
at
the
same
time
in
trying
to
design
for
those
problems
at
the
same
time,
because
they're
so
dependent
and
they
affect
each
other,
a
lot
yeah
that
we
need
to
do
to
look
at
everything
together.
We
have
sort
of
a
plan
that
we're
hoping
to
to
start,
but
I'll.
Stop
there
for
comments
or
questions,
and
I
know
yeah
in
in
any
case,
we
will
always
receive
everyone's
feedback.
B
B
I
I'm
I'm
excited
to
see
some
really
wild
ideas
and
and
see
how
we
can
change
things
and
then
focus
things
down
into
a
more
cohesive
experience,
but
yeah,
I
think
pedro
articulated
it
really
well,
there's
so
many
dependencies
on
each
insight
that
I
wasn't
sure
how
to
make
an
actionable
insight
out
of
all
of
this
feedback
and
implementing
things
like
there's
too
much
clutter.
Well,
yeah.
We
could
unfix
some
things,
but
it's
not
going
to
change
too
much
for
too
many
people
by
itself
or
rearranging
the
metadata
again.
B
Some
of
that
metadata
is
in
the
fixed
elements.
So
where
are
we
going
to
put
it?
Do
we
need
to
remove
some
sidebars?
I
don't
know
it
just
it
was
all
interdependent
and
and
every
design
could
be
a
really
good
way
forward
and
we
talked
a
little
bit
about
the
way
that
the
navigation
was
updated
four
or
five
years
ago.
We
we
added
it
under
a
feature
flag.
I
think
for
the
first
time
and
users
could
opt
into
it
to
the
new
navigation
and
then
the
people
who
did
opt-in
were
providing
feedback.
B
Constantly
people
are
responding
on
twitter
on
hacker
news.
They
all
there's
so
much
feedback
in
that
issue.
We
can
dig
it
up
so
before
it
was
actually
released.
We
had
a
ton
of
extra
data.
I
wasn't
even
on
the
ux
team
when
we
did
this
actually,
but
I
think
it
was
pretty
successful.
So
we
could
do
something
similar
if
we
have
a
redesign
option.
D
No,
I
I
understand
the
the
want
and
intent
generally
concerned
with
scope,
because
these
things,
I
think,
it'll
what
you're
talking
about,
will
take
a
long
time
to
design
and
get
feedback
and
do
all
of
those
things
and
then
even
more
time
to
figure
out
how.
How
could
we
go
back
and
engineer
those
efforts.
D
And
it's
it's
on
the
one
hand
needed,
and
I
I
think
there
are
good
points
to
do
it
and,
on
the
other
hand,
I
think
is
concerning
from
that
perspective,
and
we've
also
talked
about
from
an
engineering
side
and
months
ago,
we'd
sort
of
brought
up
the
idea
of
like.
Should
we
think
about
what
an
alternative
like
merge
request.
Experience
would
be
if
we
were
going
to
restart
the
engineering.
D
And
so
maybe
these
two
things
combine
in
like
we
need
to
do
them
together,
but
that's
also
hard
to
coordinate
like
what's
engineering
technically
possible
and
what's
what
design
wants
to
do,
but
then
that
that
just
further
increases
scope
and
time
and
complexity.
D
And
makes
it
harder
to
move
the
ball
forward
on
other
things,
because
then
we
sort
of
we
end
up
in
a
vicious
cycle
of
like
any
new
feature
we
add,
has
to
be
accounted
for
in
any
new
ui
that
exists,
which
is
hard,
so
I
don't
know
I'm
I'm
processing
that
that
is
sort
of
the
path
we
want
to
take.
I
guess
I
hadn't
gathered
that
from
the
linked
comment
or
the
insights
that
I
had
read.
So
it's
interesting
to
hear
that
that's
the
path
that
we
want
to
go
down
so
yeah.
A
Yeah,
I
was
just
gonna
say
that
yeah
the
when
I
said
unfortunate,
it
was
yeah
my
the
kai
in
me
speaking.
A
It
was
mvc
pedro
speaking
and
because
yeah,
I
think,
redesigns
are
always
great,
and
the
designer
in
me
lives
for
these
redesigns,
but
I'm
concerned
about
that
as
well
and
and
about
the
the
link
there
in
the
agenda.
This
was
just
something
that
me
and
abel
were
talking
about
today,
as
we
were
looking
at
all
of
this
together,
so
it
hasn't
been
materialized
in
the
epic
or
in
the
comments
ben.
I
think
you
were
going
to
say
something.
C
Yeah,
I
was
just
echoing
the
the
part
you
said
about
you
know,
creating
this
big
plan
and
then
working
back
from
there
and
and
delivering
like
little
chunks
of
it
at
a
time
but
like
streaming
towards
a
unified
vision.
Didn't
you
mention
something
like
that
as
part
of
the
plan,
or
no
did
I
imagine
that.
C
Right
so
maybe
yeah
the
the
the
time
and
energy
is
really
in
like
the
the
upfront
design
right
and
then
yeah.
You
could
theoretically
prioritize
which
chunks
needed
to
be
done
first
and.
A
Yeah
yeah
yeah,
the
the
bulk
of
it
will
be
design
and
validation
and
yeah.
That's
why
I
said
it
was
unfortunate
because
I
know
that
we
will
be
in
that
for
some
time
and
we
won't
be
able
to
deliver
anything
for
some
time,
but
the
payoff
will
be
tremendous
and-
and
it
will
be
I'm
sure,
100-
that
that
will
be
what
will
get
this
out
of
this
hole
from
a
user
from
what
we
can
control
taking
out
engineering
out
of
the
actuation,
because
that's
what
kai
was
saying.
A
Okay,
even
if
we
do
all
of
this,
there
will
still
be
performance
concerns
and
all
of
that.
But
I
think
that
we
need
to
do
this
first
or
at
least
do
a
lot
of
this
work.
First
before
we
get
engineering
to
start
thinking.
Okay,
so
design
has
built
confidence
on
on
this
little
bit
of
the
the
the
road.
So
here
we're
confident
that
we're
going
to
build
something
like
this.
A
So
how
could
we
re-engineer
this
to
be
the
best
thing
possible
and
then
they
can
start
planning
it
and
we
can
start
and
we
can
finish
the
design,
but
I
think
we
need
to
do
that
first,
because
I
don't
know
imagine
that
the
best
experience
is
not
having
a
changes
tab,
but
you
go.
You
enter
the
changes
directly.
A
I
don't
know
if
that
is
the
best,
but
let's
imagine
the
engineering
approach
might
be
different
than
if
we
only
load
the
changes
on
demand
that
it
it's
more
or
less.
What
happens
today
so
yeah
everything
hinges
on
this
and
I'm
concerned
about
scope
as
well,
but
yeah.
That's
what
to
take
what
anybody
was
saying
that
example
about
the
navigation.
A
It
was
the
only
way
that
we
could
have
redesigned
the
navigation
to
what
it
is
today
compared
to
what
it
was
before
it
wasn't,
and
we
iterated
our
way
there
in
terms
of
implementations
we
had.
You
know
we
did
different.
We
shipped
different
things
across
milestones,
but
we
in
terms
of
design.
We
had
to
design
everything
at
once.
D
Say
is
the
next
step
like
so
this
epic
exists?
That's
got
insights
and
there's
been
a
little
bit
of
discussion.
It's
sort
of
the
next
step.
Then,
if
that's
the
proposal,
we're
going
with
to
sort
of
put
together
a
proposal
and
what
that
path
would
look
like
like
what
what
does
it
actually
take
to
redesign
and
what
are
the
the
pieces
we're
going
to
test
and
what
we're
not
going
to
test,
and
I.
D
D
If
we
are
going
to
embark
on
this
path,
based
on
what
I
know
about
how
long
it
takes
to
get
things
done,
it
feels
like
we're
in
the
six
to
nine
month
range,
probably
for
design,
and
I
say
that
because
our
cycle
times
for,
like
validation,
tend
to
be
long
and
revisions
and
other
things,
and
so
like
it
just
feels
comfortable
right.
I
I
don't
think
we'd
be
less
than
six
to
me
feels
like
it
would
be
extraordinarily
fast.
Just
given
the
pace
of
the
way
things
work
here
and
then
we're
probably
another.
D
I
don't
know
six
nine
months
plus
to
implement
anything
like
to
implement
the
complete
scope,
probably
even
longer
than
that,
but
so,
if
we,
if
we're
going
to
go
down
this
path,
if
in
order
to
not
be
future
derailed,
because
we've
had
some
of
our
efforts
derailed
with
engineering
allocations
and
other
things
we
need,
we
likely
need
the
buy-in
and
support
of
of
people
like
christy
and
scott
and
anu
to
say
yes,
we
agree.
D
And
yes,
this
is
the
most
important
thing,
because
we're
actually
not
that
this
isn't
iterative,
but
it
is
less
iterative
than
other
options.
And
so
therefore,
we
need
more
we'll
need
more
cover
and
more
support
that,
like
we,
are
invested
in
a
long-term
outcome,
and
that
takes
time
and
so
yeah
just
curious,
if
like,
if
you've
thought
about
that
piece
of
it.
D
A
That's
that's,
I
think,
that's
fair
and
I
think
it
actually
might
be
a
good
exercise
for
us
to
create
a
lean
opportunity.
Canvas
for
this
because,
as
you
said,
it's
a
very
big
investment
and
yeah.
I
mean
it's
also
part
of
our
jobs
as
ics.
B
A
Ics
to
bring
you
the
pm
problems
right
that
we
think
should
be
solved,
and
then
you
have
the
final
say
on
whether
we
prioritize
them
or
not.
I
think
this
is
the
most
important
problem
for
us
to
solve
from
a
ux
perspective,
but
maybe
that's
not
enough
and
I'm
I
think
it's
reasonable
if
we
were
to
put
together
a
quick
opportunity,
canvas
for
this,
so
that
you
have
not
only
for
yourself
more
confidence
but
also
ammunition
for
other
conversations.
B
B
Okay,
yeah,
I
was
gonna,
say
the
plan,
so
this
came
from
a
meeting
I
had
like
an
hour
ago
with
marcel.
He
was
like.
Are
you
thinking
about
a
redesign
or
something,
and
I
thought
yep
so
then
I
talked
about
it
with
him
a
little
bit
and
then
talked
to
pedro
about
it,
and
we
discussed
it
some
more,
and
I
think
the
next
step
today
is
to
create
an
issue
with
all
the
problems
listed
because
I
haven't
even
finished
the
the
user
research
slides.
B
I
can
link
them
in
the
agenda
I'll,
get
them
eventually
and
just
enlist
all
of
the
problems,
and
there
are
a
lot
of
them.
B
Sorry,
insights
or
actionable
insights,
whatever
they
are
and
and
just
have
everything
in
one
place
so
that
you,
when,
after
you
read
it
you'll
think
oh
right
now
I
see
why
they're
thinking
redesign
because
yeah
I
don't
want
anyone
to
be
like
what.
Why
would
we
do
that?
Why
don't
we
just
fix
these
problems?
We
talked
a
little
bit
about
getting
other
designers
to
collaborate
because
I'm
sure
others
are
fairly
passionate
about
the
merge
request.
B
Page
too,
as
long
as
it's
scoped
to
merge
request
as
a
whole,
not
hey,
why
is
no
one
looking
at
the
secure
widget
or
you
know
that
kind
of
stuff
we
still
the
the
telemetry
data
we're
getting
for
the
widgets
is
still
super
valuable
by
the
way.
So
I'm
glad
that
we're
still
doing
that
to
know
where
those
widgets
are
going
to
go
and
what
they're
going
to
be
doing
and
I
think
getting
buy
in
from
higher
product
people
and
chris
d2
will
be
excellent.
B
I
suspect
that
I
suspect
we'll
be
on
board
at
least
a
little
bit
right
away,
because
I
think
it's
kind
of
the
reason
that
we
wanted
to
add
more
designers
to
code
review
was
to
improve
this
experience.
This
is
the
feedback
we
always
get
on
hacker
news
and
and
twitter
and
all
those
platforms
that
it's
just
the
ui
isn't
their
favorite.
So
I
think
that
that
makes
sense.
I
don't
know
about
the
lean
opportunity
canvas.
I
don't
have
much
experience
with
that.
B
It
is
a
problem
that
we
have
validated
based
on
all
of
the
problem-
validation
that
we've
just
been
working
on
this
past
few
months,
but
if
the
opportunity
canvas
is
helpful
too
then
yeah.
That
sounds
great.
Is
that
something
that
pms
do
or
is
that
designers.
D
D
I,
I
typically
draft
and
then
invite
people
in
to
sort
of
make
sure
before
we
we
put
those
in
front
of
people
yeah,
and
I
don't
know
that
an
opportunity
campus
is
the
right
thing
and
I
think
I
I
think
we
knew
going
into
when
pedro
put
together
the
spreadsheet
of
like
prioritization
of
problem
areas.
D
This
was
the
like
the
cells
that
it
was
like
cells
that
were
this
long
and
this
long
and
this
long
and
this
one
was
just
sort
of
like
a
collection
of
all
of
the
cells
above
it
and
I
think
months
ago,
when
he
brought
that
up
and
we
looked
at
it.
I
said
that
looks
like
a
lot
and
I
agree
that
they're
all
related,
but
it
looks
like
a
lot,
and
so
I
think
it's
good
to
hear
that.
We've
like
validated
that
it's
a
lot,
we
think
there's
not
a
path
forward.
D
So,
like
I'm
on
board
there,
I
think
we're
just
gonna
need
to
be
able
to
sell
this
outside
of
the
group
in
a
way
that
we
get
the
time
and
space
that
we
need,
because
we've
we've
had
a
problem
with
time
and
space
over
the
last
several
months
and
there's
there's
been
good
reasons
for
that.
But
we'll
have
to
be
much
much
stricter
with
that.
If
we're
gonna
go
down
a
path,
this
large.
B
Yeah
and
as
a
side
note
an
exciting
thing
too
about
it
is
not
only
you
had
that
comment
about
moving
the
tabs.
I
was
like
wait
what.
Why
would
we
do
that?
We
can
explore
that
too,
but
also
when
github
went
sorry
when
gitlab
was
created,
it
was
created,
borrowing
from
other
platforms
that
were
more
established
and
that's
kind
of
one
of
the
main
reasons.
B
D
Awesome,
I'm
excited.
Thank
you
both
for
leading
this.
I
know
I'm
not
sure
this
is
what
you
signed
up
for
about
when
you
came
to
code
review,
that
it
would
be
mountains
of.
D
To
begin,
but
it
is
much
appreciated
and
I
think
getting
someone
else
ramped
in
the
space
has
proven
tremendously
valuable
in
the
past
for
us
too.
So
thank
you
for
all
of
all
of
your
work
and
effort
in
this
area
too.
A
Yeah
just
to
to
wrap
this
up.
So
what
I
understand
from
what
you
were
saying
kai
is
that
you
are
largely
on
board
with
this,
but
that
you
feel
that
having
a.
A
Structured
message
to
communicate
so
that
we
can
get
investment
on
this
might
be
necessary.
Would
you
if
that
is
true?
Would
you
like
to
first
talk
with
someone
about
this
before
we
put
in
the
time
of
creating
the
opportunity
canvas
or
do
you
think
we
should
yeah,
I
mean
they're
going
to
need
it
and
the
opportunity
canvas
is
a
good
tool
to
do
that.
D
I
think
the
next
step
is
get
an
epic
or
issue
or
whatever
the
like
next
vehicle.
Is
that
sort
of
outlines
the
problems
like
how
we
got
to
this
point
and
sort
of
why?
We
think
what
we
think
and
I
I
will
share.
A
If
you
want
okay,
let's
let's
do
the
following:
if
you
want,
you
can
think
about
it
a
little
bit.
We
don't
have
to
to
decide
today,
as
annabelle
said
she's
still
wrapping
up
that
research
as
well.
We
have
other
things
on
flight,
so
if
you
need
a
little
time
to
reflect,
we
don't
need
to
make
a
decision
right
now.
D
Yeah,
I
think
either
way
we
need
the
issue
or
epic.
I
think
that's
clear
like
if
we're
gonna
go,
do
it
and
we're
not
gonna
get
air
cover.
So,
like
that's
fine,
I
don't
think
we're
blocked
on
anything
doing
that.
I
think
let's
get
that
put
together
and
we
can
work
and
polish
that
and
then
all
yeah
I'll
try
and
chat
around
and
see
communication
vehicle
if
people
have
a
preference
for
for
how
we
we
go
up
awesome.
Thank
you.
Kai.
B
And
I
know
I
said
I
created
that
issue
today.
I
don't
know
why.
I
said
that
it's
not
going
to
be
today
and
I'll.
Do
it
this
week.
I
don't
know
why.
I
said
that
yeah
I
need
to
wrap
up
the
old
research
slideshow
and
then
I
will
put
everything
together
in
one
place
and
paying
everyone.
D
C
In
light
of
the
conversation
we
just
had,
I'm
not
sure
that
these
are
that
important.
They
could
probably
just
be
used
as
further
evidence
that
we
need
to
redesign
the
merge
request
experience,
but
these
are
just
a
couple
things
that
have
popped
up
recently.
I
know
we
sort
of
had
a
slack
discussion
about
the
two-step
mr
widget.
I
was
looking
through
the
sus
feedback
in
this
past
quarter.
A
number
of
people
mentioned
some
confusion
about.
You
know
the
merge
or
approve
buttons
being
close
together,
and
I
guess
thank
you.
C
You
know,
as
you
guys
think,
about
what
the
new
ui
should
look
like,
and
then
I
was
talking
with
anna
this
morning.
She
mentioned
this
in
product
survey.
I've
read
through
it
before
it
seems
like
something
that
would
be
good
to
do.
I
don't
know
where
it's
at
looks
like
the
last
comment
was
a
while
ago,
but
it
certainly
this
would
be
a
great
thing
to
have
some
engineering
investment
on,
especially
if
they
can
make
it
so
that
further.
B
C
Like
this
are
really
quick
and
easy
for
them
to
do.
This
would
be
great,
especially
if
we're
going
to
do
a
big
redesign
being
able
to
like
pull
some
metrics
of
like
a
before
and
after
kind
of
scenario.
Like
hey,
we
actually
really
improved
mr
performance
because
of
our
redesign
go
that'll
us
awesome.
A
Yeah,
the
thanks
ben,
I
think
so
the
in-product
survey.
I
think
we
should
do
that.
A
If
we
can,
we
should
do
that
regardless,
even
if
it's
to
set
a
baseline
for
when
we
release
the
the
redesign
yeah,
it's
so
much
better
compared
to
what
we
had
so
yeah
having
a
baseline
having
data
about
how
things
are
today
is
is
important
and
we're
doing
a
data
spike
during
this
milestone,
which
is
a
blocker
to
that,
because
we're
not
sure
how
easily
we
can
get
the
data
that
we
need
for
the
in-product
survey
so
yeah.
We
have
to
to
wait
for
that.
C
Thanks
for
that,
I
haven't.
I
hadn't
seen
this
issue
yet.
A
So
it's
clear
that
the
spike
blocks
the
main
issue,
the
two-step
mr
widget.
I
think.
A
I
think
it's
an
interesting
problem
to
solve
and
sun
jung
she
when
she
was
with
us.
She
designed
some
things
around
this.
A
We
didn't
act
on
it,
but
I
think
it's
part
of
those
that
big
bag
of
problems
that
we
know
are
worth
solving,
but
we
haven't
had
the
time
to
look
into
them
and
maybe,
as
you
said,
the
redesign
if
we
get
get
to
that,
might
help
build
the
foundations
that
we
need
for
this,
and,
even
so
even
today,
it
might
be
something
that
we
would
be
able
to
work
on
and
implement
today
if
we
wanted
to
have
a
confirmation
step
before
people
merge
but
compared
to
the
rest,
I
don't
think
it's
as
important.
C
Yeah
agree:
it
was
just
interesting
to
see
such
specific
feedback
from
like
three
or
four
folks
on
this
one
thing,
so
that
doesn't
usually
happen
unless
something
is
truly
affecting
people,
so
I
agree
it
doesn't
seem
like
it.
It
should
rise
to
the
top
of
anything,
but
just
yeah
happy
that
we're
already
aware
of
it.
B
C
B
D
D
I,
when
you
said
that
I,
like
I
made
faces,
that's
a
like
an
incredibly
interesting
insight
and
I
don't
recall
that
maybe
it
is
said
that
way
somewhere,
but
the
fact
that,
like
internal
gitlab
or
people
who
you
can
extrapolate
that
like,
if
you
are
an
ultimate
user,
that
is
potentially
less
of
a
problem,
because,
if
you're,
an
ultimate
user,
you
likely
have
more
of
those
widgets
in
place
and
so
like
there's
a
sort
of
a
correlation
with
like
your
product
here
and
and
the
spacing
that
you
might
have
there.
D
I
don't
re,
I
I
it
and
again
it
could
be
in
yourself.
I
don't
remember
you
having
phrased
it
that
way,
but
to
me
that's
that's
really
interesting
that
that
spacing
becomes
less
of
a
problem
when
we
potentially
make
the
ui
more
cluttered,
which
is
worth
interesting.
D
Worth
adding
somewhere
if
you've
got
if
you've,
if
you've
got
that
as
an
insight.
B
Yeah,
it's
also
not
just
the
clutter
that
helps
separate
the
two,
but
that
gitlab
team
members
prefer
quick
actions
because
we
know
about
them
and
external
users
might
not.
So
that's
another
interesting
point.
How
can
we
let
that
be
known
because
developers
love
typing
stuff
instead
of
clicking
buttons,
and
so,
if
we
can
make
that
more
apparent,
but
the
two-step
merge
request
widget.
B
It
is
it's
a
great
candidate
to
be
part
of
the
the
overall
redesign
concept,
but
also
it
feels
a
little
bit
separate
in
that
it
I
mean
I'm
biased,
because
I
opened
the
issue
because
I
accidentally
merged
something
five
years
ago
and
there
was
no
confirmation
and
then
it
sounded
like
other
people
had
had
the
same
problem.
Competitors
have
a
two-step
situation
and
what
sun
john
has
designed
looks
like
it
would
fit
in
with
the
it
might
it.
B
A
I
don't
know
if
you're,
if
the
rest
of
the
group
is
aware
on
on
point
six
of
amy's
updates
of
the
mr
widget
text.
I
don't
know
if
people
have
been
aware
of
that,
but
she
has
been
doing
a
tremendous
job
of
of
you
know
just
pushing
out
updates
to
these
messages
and
we're
starting
to
see
them
live
in
the
product,
and
it's
just
it's
just
amazing
how
much
you
can
improve
the
experience
just
by
tweaking
the
text
and
making
things
consistent,
and
you
know
just
more
predictable.
A
So
if
you
haven't
experienced
it
yet
live
in
the
product,
you
can
take
a
look
at
the
links
that
she
has
there
and
I'm
yeah
super
proud
of
of
her
and
the
rest
of
the
team,
also
the
front-end
engineers
that
have
been
reviewing
and
merging
them.
A
A
And
I
have
point
seven
of
adding
value
to
our
batch
comments
feature
by
integrating
frequent
actions
as
part
of
finishing
a
review.
So
this
is
something
I
brought
up
in
that
comment,
and
I
just
wanted
to.
A
How
we
should
prioritize
this
because,
as
I
wrote
there,
I
I
think
it's
something
that
will
be
needed.
I
mean
it's
already
needed
today
and
I
assume
that
this
is
one
of
the
reasons
why
we
don't
have
a
lot
of
usage
for
the
batch
comments
feature
and
or
that
people
most
of
the
time
complain
that
they
don't
use.
The
batch
comments
feature
preferred
to
you
know,
add
each
comment
one
by
one
is
that
we
don't
necessarily
add
a
lot
of
value
to
it,
so
that
people
don't
use
it.
A
So
I'm
just
curious
in
this
case
more
to
to
kai,
but
also
annabelle.
If
you
want
to
chime
in.
A
How
do
you
see
the
priority
of
this
and
compared
to
other
things
that,
because
this
I
mean
this
is
new,
would
be
new
feature
work
and
we're
deep
in
attention
requests
now?
D
This
could
be
the
next
thing
if
it's
something
that
phil
thinks
he
can
do
and
can
be
the
next
thing
and
that's
not
like
a
fair
answer,
but
it
it's
the
reality
of
like
the
situation
that
the
group
lives
in
sort
of
is
that
our
backend
team
is
is
fully
allocated
and
when
they
come
out
of
allocation,
we
are
now
six
plus
months
behind
on
mergeability
work,
which
is
like
a
critical
usability
blocker
to
the
merge
requests
sort
of
as
it
stands
today.
D
And
it's
becoming
more
and
more
problematic,
like
I
see
comments
fairly
regularly
on
those
issues,
so
the
backend
team
needs
to
go,
go
and
do
those
things
there's
also
some
performance
work
and
some
diff
work
that
probably
needs
to
be
cleaned
up,
but
primarily
mergeability.
D
D
I
would
say:
yes,
I
think,
like
one
of
the
things
that's
been
nice
about
attention
requesting
attention,
I'm
gonna
try
and
be
good
about
it.
Requesting
attention
is
that
phil's
been
able
to
do
that
and
contribute,
and
it's
been
able
it's.
It's
allowed
us
to
move
features
forward
where
we've
been
largely
stagnant
on
new
features.
As
a
group,
I
think
this
is
a
a
great
feature
it
if
you'll
remember
to
win.
We
contributed
the
comments
on
the
overview
tab.
D
We
had
a
long
discussion
about
whether
or
not
that
was
the
comment
on
the
submit
review
button
or
just
a
generally
a
comment
on
the
overview
tab
of
like
what
were
we
actually
trying
to
do
there
as
part
of
this,
and
I
I
had
always
been
under
the
impression
that
we
would
get
to
a
comment
box
on
the
review
button
and
like
these
other
actions,
and
so
I
think,
I'm
very
pro
in
doing
that.
But
it's
just
a
capacity
constraint
problem.
D
A
Yeah
yeah
my
this
would
be
okay,
assuming
that
we
can
get
investments
on
and
we
get
buy-in
for
the
redesign
of
the
merge
request
at
larger
vision.
That
will
take
time
and
I'm
thinking
about
things
that
we
can
still
make
progress
on
that
are
not
gigantic.
You
know,
for
example,
annabelle.
A
B
A
A
We
will
plan
so
that
the
team
can
have
work
to
do
when
they
get
back
whenever
that
is
right,
and
and
for
those
of
you
who
are
not
familiar
phil
hughes,
the
front-end
engineer,
he
has
been
acting
as
a
full-stack
engineer,
trying
to
help
out
with
also
some
backhands
and
not
only
the
front
end
with
in
this
case
the
attention
requests
feature,
or
else
we
would
be
yeah.
We
would
be,
you
know
just
frozen
in
terms
of
new
feature
work.
A
B
D
Tab
was
added
by
a
contributor
and
it
was
based
on
an
issue
that
had
original
mock-ups,
with
a
comment
being
added
as
part
of
the
submit
review
button,
and
so
when
they
implemented
it
pedro,
and
I
had
a
long
discussion
about
whether
or
not
we
wanted
the
overview
button
or
we
wanted
it
on
the
submit
button
and
how
we
wanted
all
of
that
to
work,
and
they
ultimately
contributed
to
the
overview
tab
which
left
that,
like
the
wrap
up
final
comment
from
the
submit
review,
button,
piece,
sort
of
still
the
missing
piece
and
that's
part
of
what
I
think
picture's
talking
about
here-
is
it's
that
last
comment,
and
also
all
of
the
things
that
you
have
to
do
when
you
leave
that
last
comment
which
you're
like
hey
I've
reviewed
this.
D
Let
me
reassign
it.
Let
me
request
your
attention.
Let
me
change
this
label.
Let
me
blah
blah
blah
blah
blah
approve
all
these.
Like
actions
you
take,
when
you
finish
yeah,
we
had,
we
had
thought
we
were
gonna,
get
close
to
that,
and
then
we
went
a
different
sort
of
direction,
and
so
that's
sort
of
the
missing
piece
that
we're
talking
about
here.
B
Okay,
yeah
that
that
totally
makes
sense-
and
that
sounds
like
a
really
great
idea-
internal
team
members-
that
I
that
I
interviewed
all
jam
their
their
quick
actions
in
that.
So
they
don't
seem
to
have
a
problem,
but
having
those
like
you
know,
suggested
buttons
would
would
be
great,
especially
for
people
who
don't
know
that
quick
actions
exist
and
it
turned
out.
No
one
really
knew
that
submit
review
was
a
quick
action.
So
I
posted
that
in
what's
happening
in
gillab
and
when
everyone
found
it,
they
were
excited.
B
You
would
write
their
comment
like
thanks
so
much.
I
have
a
few
comments.
You
know
feel
free
with
northern
whatever
and
they
do
like
slash,
approve,
unassigned,
slash
whatever
and
then
slash
submit
and
then
click
comment
and
then
all
those
things
would
be
applied
at
once
and
then
they'd
refresh
the
page,
because
it
would
never
appear
on
the
page
until
you
do
a
hard
refresh.
That
came
up
all
the
time
and
that's
like
our
number
one.
If
we
could
fix
any
small
thing
right
now.
B
D
D
Yeah,
okay,
yeah,
I
think
so
yeah
I
think
pedro
I'm.
I
don't
have
any
major
issues
with
that.
I
don't
think
there's
other
there's
plenty
of
usability
work
that
we
can
also
continue
to
do.
I
know
like
the
jump
to
next
stuff
was
reverted,
so
all
of
thomas's
fixes
were
reverted
last
week.
If
you
have
not
seen
really
they,
they
caused
a
regression
with
editing
comments
that
editing
comments.
D
All
of
the
your
previous
comment
was
visible
and
all
the
spacing
and
styling
was
off
when
you
edited
a
comment,
because
it
we
inserted
new
html
elements,
which
then
changed
where
things
got
positioned
on
the
page,
and
so
it
broke
a
bunch
of
stuff,
so
they
got
reverted
last
week.
D
There's
plenty
of
like
usability
things
that
we
can
still
continue
to
work
on,
but
I'm
I'm
not
opposed
to
to
handling
these
things
in
tandem,
like
lots
of
usability
things,
but
also
we
can.
We
can
certainly
try
and
get
a
new
feature
in
as
well.
D
A
Okay,
cool
so
yeah
I'll,
look
into
this
and
bring
it
up
with
phil.
A
I
think
you
will
be
excited
about
it
and
also
to
to
the
the
quick
actions
and
internal
users
relying
mostly
on
them.
A
I
think
if,
if
we
were
able
to
do
this,
they
they
wouldn't
have
to
to
rely
on
quick
actions,
because
this
might
be
even
more
efficient,
because,
instead
of
writing
an
approved
quick
action,
you
just
click
on
one
thing:
you
don't
have
it:
it
might
be
faster
to
click
on
a
radio
button
than
to
enter
slash,
approve
enter.
You
know
something
like
that.
A
A
B
When
you
see,
I
know
it's
not
the
way,
I
said
it
I
mean,
and
when
you
click
it,
I
still
think
the
people
who
are
using
quick
actions
today,
no
matter
how
amazing
this
like
suggested
action,
is
button.
Radio
button
is
going
to
be
they're
still
going
to
use
quick
actions
because
it
is
faster,
you're
already
typing
they.
Everyone
likes
to
thank
the
reviewer
and
give
them
a
nice
summary
and
they're
already
on
the
keyboard.
All
I
could
do
is
hit
slash
and
then
like
two
characters
and
then
it
pops
up.
B
So
they
hit
you
know
tab
and
then
it
auto
completes
and
it's
just
it's
very
natural
developer
workflow
to
keep
typing.
So
if
we
could
add
a
quick
action,
that's
like
add
comment
and
then,
as
soon
as
you
hit
enter,
it
submits
the
comment
I'm
kidding.
We
won't
do
that.
That's
a
terrible
idea.
Just
one
click,
though
we'll
do
everything
that
they
typed.
I
think
it's
great
yeah.
B
A
Okay,
yeah,
that's
what
I
wanted
to
bring
up.
I
don't
know
if
anything,
anyone
else
has
any
thoughts
or
comments
about
this
or
something
else.
D
No
thanks
for
bringing
it
up
and
thanks
to
both
of
you
for
everything
or
all
three
of
you,
everyone
who
contributed
a
meeting.
It's
it's
nice
to
see
everyone.
Again.
It's
been
a
while
even
even
pre-holiday.
It
had
been
a
while,
since
we
had
all
synced
up
and
chatted
so.
A
A
D
Awesome
well
thanks:
everyone
enjoy
the
rest
of
your
week.
Team
day
is
thursday
and
friday
make
the
time
make
the
space
go.
Play
games.