►
From YouTube: 2021-09-28 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
I
put
this
on
the
agenda,
but
I
think
animal
is
really
your
question
so
like.
If
you
want
to
ask
the
question
and
then
I
have
some
thoughts
and
then
a
pedro
might
have
thoughts
and
then
maybe
you'll
have
more
questions,
but
maybe
we
start
there.
B
Yeah,
so
with
this
last
week,
it
has
to
do
with
the
the
fluid
versus
fixed
width
for
inline
yeah.
I
just
wasn't
sure
how
we
really
typically
work,
because
back
in
years
ago,
we
would
kind
of
just
make
these
changes.
B
We
didn't
have
feature
flags,
but
we
would
just
make
changes
and
see
what
happened
good
and
bad,
obviously,
but
it
was
kind
of
nice
to
see
that
immediate
feedback
and
for
this
change
I
was
thinking
it
might
not
be
the
best
idea
to
move
forward
with
it
without
looking
into
it
more
so
I
suggested
like
an
mvc,
but
it
kind
of
got
pushed
through
anyway,
and
I
wasn't
sure
why
I
don't
necessarily
disagree
with
the
issue.
I
think
it's
an
interesting
proposal
and
it
might
be,
might
be
the
way
forward.
B
I'm
just
not
sure
why
this
one
was
confidently
pushed
forward
when
it
was
only
opened
a
couple
weeks
ago,
as
opposed
to
some
other
changes
and
then
behind
a
feature
flag
and
then
how
often
do
we
want
to
do
this
kind
of
stuff
testing
things
within
gitlab
with
future
funds.
A
A
First,
this
issue
came
out
of
the
planning
session,
which
is
the
thing
that
we
do
monthly,
where
we
sort
of
bring
issues
that
are
potentially
less
likely
to
be
prioritized
otherwise
and
use
a
and
like
we
get
to
talk
about
them
and
sort
of
vote
and
discuss
them,
and
so
I've
been.
This
also
looks
funny.
A
I
put
this
one
on
the
board,
because
it
was
something
that
I
had
been
thinking
about
in
terms
of
feedback
that
I
had
heard
about
white
space
on
the
page
and
how
code
review
should
be
the
focus
and
take
up
the
whole
page,
and
so
I
knew
we
had
fluid
width
and
usually
when
someone
opens
one
of
those
issues,
I'm
like
go
turn
on
fluid
width
and
everyone
says,
oh
sure,
that's
sort
of
what
I
was
thinking
and
and
people
move
on.
A
So
I
brought
this
up
and
then
we
put
it
in
the
session
and
it
got
prioritized
quickly
because
it
got
voted
highly
in
the
session
and
we
had
the
capacity
to
do
that.
Not
everything
that
gets
voted
highly
in
the
session
gets
prioritized
quickly
and
because
we
don't
always
have
the
capacity,
but
that
in
this
case
we
did
because
of
needing
front-end
only
work
that
doesn't
involve
back-end
and
other
things.
So
that's,
I
think,
my
that's
probably
my
answer
for
why
it
got
prioritized.
A
If
you
had
ideas
for
ones
and
they,
if
they
got
voted
on
highly
then
like,
we
would
have
just
put
those
up
too,
like
it
wasn't,
necessarily
that
it's
the
best
idea
or
the
most
researched
idea
or
anything
other
than
like
it
seemed
like
it
was
achievable
by
a
group
of
people,
and
so
that's
why
it
got
there.
A
A
C
I
don't
I
don't
know
it's
it's
difficult
to
say
it's
like
what,
if,
because
we've
been
doing
them
for
so
long
now,
I
just
think
that
it
helps
create
a
space
where
you
have
where
you
describe
a
number
of
issues
and
you
think
about
all
of
them
together
and
how
you
would
prioritize
all
of
them
together.
If
you
had
to
choose
one
issue
over
another.
B
Okay,
so
going
forward
now
that
it's
well,
I
don't
know
if
it's
been
merged,
I
approved
it.
I
don't
know
what
the
status
of
it
is
and
we
turn
that
feature
flag
off
or
on
I
don't
know
we
display
it
on
gitlab.
What
are
we
looking
for,
like
I'm,
assuming
some
people
will
like
it,
and
maybe
a
vocal
minority
wouldn't
strongly
dislike
it.
What
is
our
plan
going
forward.
A
We
tend
to
probably
deploy
with
more
feature
flags
than
other
groups,
because
we
need
to
be
able
to
back
out
changes
whether
we
agree
or
disagree
with
that.
We've
we've
had
to
like
sort
of
rework
things
before
when,
when
users
weren't
comfortable
and
so
having
feature
flags
gives
us
that
way
to
do
that,
and
so
that's
why
we
probably
do
more
feature
flags
in
this
specific
case.
A
To
your
next
question
about
what
are
we
looking
for?
Typically
in
code
review,
we
get
really
prompt
feedback
from
internal
users
when
we've
turned
things
on
and
so
we're
just
looking
for
feedback.
I
don't.
We've
never
necessarily
had
like
thresholds
for
how
much
or
how
little
I
mean.
Even
with
virtual
scrolling,
we
had
a
very
small
minority
of
developers
inside
of
gitlab
who
were
providing
feedback,
but
the
feedback
was
like
pretty
breaking
to
their
workflows,
and
so
we
had
to
like
deal
with
that
versus
you
know.
A
Usually
it's
pretty
effective
for
us
to
do
that
and
watch
like
watches
this
known
in
questions
and
see
like
what
do
people
start
to
say
and
how?
How
recurring
are
those
trends?
And
so
I
don't
there's
nothing
in
my
mind
that
I'm
necessarily
looking
for.
I
think
what
I'd
like
to
you
know.
If
nothing
comes
out
of
it,
then
good,
where
we
have
more
confidence.
If
people
say
like
this
completely
broke,
my
workflow,
I
can't
do
xyz
anymore.
A
So
I
think
that's
that
I
think
yeah.
I
think
that's
that
I
think
that's
how
I'm
thinking
about
it
and
why,
like
feature
flag
in
this
case,
makes
sense.
It's
a
issue
that
we
sort
of
loosely
threw
together
had
some
ideas,
we're
putting
it
in
the
product
really
quickly,
but
it's
not
validated,
not
tested,
not
anything
else,
and
so
just
all
of
that
makes
us.
So
we
should
be
more
cautious
and
just
sort
of
see
how
that
goes.
B
Okay,
yeah,
that
makes
sense.
I
guess
I
I
wasn't
as
clear
on
the
purpose
of
that
prioritization
session.
I
just
kind
of
grabbed
issues
that
I
was
interested
in,
but
in
the
future
I
can
include
ones
that
I
add,
like
maybe
reducing
some
padding
in
places
like
that
things
that
won't
break
workflows,
they'll
have
minimal
effort
and
they
might
have
a
they
might
have
a
huge
impact
or
okay.
It
won't
be
a
huge
impact.
It'll
be
small,
the
feature
flag.
I
like
that.
I,
like
the
concept.
I
know
it's
not.
B
I
know
it's
a
little
bit
more
overhead
for
development
having
to
wrap
all
these
things
in
feature
flags
and
then
open
an
issue
to
remove
all
of
it.
So
I
just
also
wasn't
sure
how
I
understand
we
use
them
more
in
code
review
and
that
makes
sense
as
opposed
to
somewhere
like
secure
but
yep.
I
think
that
that
all
makes
sense.
A
Yeah-
and
I
think
the
prioritization
session
is
the
place
to
sort
of
bring
and
it
doesn't.
I
would
say
this.
One
was
different
too,
because
we
were
looking
explicitly
for
front-end
things,
because
we
were
trying
to
avoid
back-end
and
then
front-end
capacity
when
andre
and
I
went
through
and
did
planning
was
actually
like.
A
The
planned
and
known
work
ended
up
being
a
lot
lower
than
we
expected
so
more
prioritization
issues
even
got
in
than
like,
I
had
originally
thought,
would
fit
in
into
planning
this
one
was
a
little
weird,
I
think,
but
in
general
to
me
that
session-
and
it's
been
helpful
to
me-
is
it's
one
of
those
things
where,
like
several
days
before,
you
start
going
through
like
what
was
that
nagging
issue
that,
like
I've,
seen
a
lot
of
people
talking
about
but
is
listed
as
like
a
p4s4
bug
that
maybe
we
could
just
like
bring
in
and
get
other
people's
like
quick
thoughts
on
it
or
what
is
this
other
piece?
A
And
I
think
it
helps
to
do
that.
It
also
helps
to
highlight
everyone
has
like
different
perspectives
on
like
what
users
are
experiencing
you're
not
experiencing.
A
It's
been
interesting
to
see
like
issues
andre
brings
or
issues
that,
like
I
get
pinged
on
or
issues
that
pedro
brings
that
are
like
feature
related
issues
that
are
not
things
that
we're
talking
about
on
a
regular
basis,
but
like
other
stuff
like
that,
and
just
have
those
conversations
with
that
group
to
sort
of
see
like
what
do
we
want
to
work
on.
What
do
we
not
want
to
work
on
and
there's
there's
always
no
guarantee
that
anything
gets
picked.
A
I'm
sure
pedro,
there's
been
multiple
milestones
where
things
have
ended
up
in
this
top
right
corner
and
then
like
don't
get
in
or
they
end
up
there,
and
then
we
like
actually
go
to
scope
it
and
we're
like.
Oh,
that's
way
more
work
than
like.
We
thought
it
was
when
we
sort
of
had
a
five
second
conversation
about
it,
and
so,
but
it
gets
everyone
to
start
thinking
about
those
and
then
bringing
the
same
ones
up
over
and
over.
A
I
think
we've
brought
the
the
retaining
position
on
like
or
when
you
hit
like
jump
to
next
thread
like
that
one,
I
think,
has
hit
the
board
like
five
milestones.
Maybe
of
someone
bringing
it
to
planning
and
has
never
been
prioritized
just
for
whatever
reason,
and
so
like
it
finally
made
it
the
cut
this
time
for
for
some
reason,
but
like
it's,
those
it's
those
kinds
of
like.
Sometimes
you
just
need
to
remind
everyone
like
once
a
month
like
hey,
we
should
really
fix
that.
C
I
think
that
was
the
case
for
many
of
the
issues
that
we're
doing
now.
Yeah,
I
think
the
way
I
look
at
future
fights
other
than
what
kai
said:
the
user
base
of
code
review
being
a
high,
visible
and
high
impact
area.
C
We
suggest
people
use
feature
files
is
when
you
have
invasive
changes
to
the
user
interface,
and
I
think
it's
go
just
it's
down
to
how
we
increase
confidence
on
the
solutions.
So,
if
we
think
it's
an
invasive
change
or
something
else,
we
can
do
more
easier
research
and
invest
in
user
research,
or
we
can
just
put
a
feature
flag
like
we
could.
C
We
could
do
zero
solution,
validation
and
just
implement
things
behind
future
flights
right,
but
that
that's
sometimes
it
it
doesn't
pay
off
right
and
it's
better
for
you
to
do
the
solution.
I
think
in
this
case
it
was.
It
was
better
to
do
the
feature
fly,
because
we
were
quite
confident
on
the
solution.
C
C
So
the
feature
flag,
I
think,
was
a
good
mechanism
to
control
that
validation
through
usage
yeah,
and
I
think
there
are
more
things
that
we
would
do
and,
as
kai
said,
like
one
thing
is
changing
the
color
of
something
or
very,
very
small
changes
in
high
usage
areas
that
it's
we're
not
likely
going
to
revert
it
because
of
user
feedback.
But
another
thing
is
this
very
big
change.
That
is
not
only
visual,
but
it
affects
how
people
read
and
consume
reviews.
Sorry
changes.
C
B
Yeah,
that
makes
sense,
and
thanks
for
linking
to
the
the
documentation,
because
I
see
an
example
of
when
to
use
feature
flags
is
the
removable,
is
the
removal
of
a
sidebar
and
I'm
just
really
excited
about
the
potential
for
removing
a
sidebar
on
the
changes
commits
and
pipelines
tab
so
I'll
just
feature
flag
it.
I
think
that
would
be
I'm
not
going
to
keep
harping
on
it,
but
I
think
that
would
be
a
perfect
way.
It
kind
of
to
me.
It
falls
in
line
with
what
you
just
said
about
testing.
B
It
is
going
to
be
kind
of
more
of
an
effort
trying
to
find
out
how
people
use
the
sidebar
on
the
commits
tab,
or
I
mean.
Luckily
we
have
that
data
that
you
posted
yesterday
too,
which
is
super
useful
and
we've
got
that
15
percent
of
users,
but
it
might
be
worth
pushing
that
one
through
two,
maybe
maybe
I'll.
I
don't.
C
Know
I
don't
know
it's
it's
interesting.
I
think
you
know
15.
As
I
said
it's
not
a
small
number.
I
mean
it's
a
small
15,
it's
small
in
number,
but
when
you
see
in
terms
of
number
of
users,
it's
it's
a
lot
of
users.
C
Yeah,
none
in
the
pipeline's
implements
exactly.
I
think,
that's
that's
very,
very
small,
and
I
mean
we
don't
have
that
skill,
but
I
remember
that
example
that
sometimes
people
give
of
facebook
changing
something
for
one
percent
of
the
user
population
and
it
affects
millions
of
people
and
it's
so
you
know
it's.
C
It
depends
at
the
end
of
the
day.
We
have
to
see
it
in
a
case-by-case
spaces,
but
nonetheless
I
like
the
way
that
you're
thinking
about
removing
things,
I'm
I'm
I'm
on
that
team
as
well.
A
Yeah,
I
also
say
I'm
I'm
pedro
and
I
will
differ
in
this.
I'm
I'm
all
for
shipping
things
and
with
feature
flags
and
skipping
on
the
research,
sometimes
more
than
more
than
pedro.
It
is
so
so
that's
another
reason
that
someone
probably
got
pushed
through.
Is
it
looked
like
you
know?
If
I
can
get
pedro
on
board
without
doing
the
extra
research
and
shipping
something,
then
I
always
count
that
one
as
a
win
too
so.
C
You
know
it
also
it's
curious,
because
when
you
joined
kai
co-review,
you
were
well,
I
wouldn't
say
against
feature
fights,
but
you
were
skeptical
of
how
we
were
using
feature
flags
which
is
similar
to
what
we're
doing
now
with
the
fluid
diff.
Sorry,
full
width,
diff.
A
Yeah
I
came
out
of
a
group
where
we
got
to
ship
everything
without
future
flags.
It's
frustrating
to
to
walk
into
future
flagland,
but
there
are
some
benefits
that
we've
had.
A
A
Cool
does
that
answer
all
your
questions?
Do
you
feel
I
just
wanted
not
to
I
it
wasn't
to
try
and
like
push
something
through
like
because
we
wanted
to
push
it
through
either
like
that.
Wasn't
the
intent
of
like
using
a
feature
flag
and
doing
all
that
it
was
sort
of
like
going
with
the
flow
of
needing
to
fill
capacity
and
other
things.
A
So
I
just
want
to
make
sure
we
didn't
like,
and
the
goal
of
those
sessions
is
not
to
like
step
on
toes
and
push
work
through
that,
like
I
want
done
or
anything
else
it
just.
A
It
happened
that
way
this
time,
and
so
I
want
to
make
sure
that
that
you
also
feel
comfortable
and
about
like
bringing
up
whatever
issues
you
want
to
that,
those
that's
really
what
those
sessions
are
for
and
then,
in
my
experience,
people
are
incredibly
open-minded
in
those
to
like
be
pretty
rational
about
voting
on
feasibility
and
importance
and
and
making
decisions
as
a
group
about
what
makes
sense
and
what
doesn't.
Ultimately,
then,
it
becomes
a
capacity
problem,
but
but
feel
free
to
bring
whatever
kinds
of
things
are
interesting
to
you
to
those
sessions.
B
Yeah
yeah-
that
sounds
great.
That
totally
makes
sense
now
that
I
understand
more
about
the
purpose.
C
Yeah
yeah,
I
think
it's
makes
sense
to
highlight
that
change
of
the
full
width
diff
in
the
in
slack
and
ask
people
to
direct
feedback
to
the
issue.
I
don't
think
we
do
that
for
most
changes
and
most
feature
flags,
but
in
this
case
I
so
the
inline
inline
diff
mode
is
the
default.
If
I'm
not
mistaken,
and
I
believe
most
people
don't
change
that
from
the
defaults.
C
So
most
gitlabbers
will
see
that
change,
but
they
might
not
understand
if
it
was
something
that
we
did
or
something
that
they
changed
in
their
preferences
or
something
like
that.
So
I
think
it's
worth
pointing
that
out.
Like
hey.
This
is
actually
something
that
we
did.
Don't
panic,
you
didn't
break
anything,
give
us
your
feedback
in
in
the
issue.
I
think
that
might
be
worth
doing
that
once
that
is
in
in
production,
I
thought
yeah.
I
thought
the
merge
request
was
already
merged,
apparently
not.
B
B
A
good
idea,
because
I'm
I'm
anticipating
people
posting
in
the
is
it
known
channel
that
it's
a
bug
because
it
is
gonna,
look
like
a
bug
at
first,
so
yeah
and-
and
I
say
that
like
it's,
I
like
the
idea
still
because
it
sounds
crazy
and
then,
when
you
think
about
when
you're
working
locally,
it's
full
width.
So
I
mean
why?
Wouldn't
you
have
full
width
here.
B
A
Guess
it's
it's
set
to
merge.
Although
the
merged
result
pipeline
failed,
it
looks
like
it
looks
like
it
got,
kicked
out
yep.
I
don't.
B
I
don't
know
the
process
anymore
and
I
don't
know
for
feature
flags
and
it
has
to
go
through
staging
and
then
it
makes
it
onto
canary.
And
then
someone
turns
the
feature
flag
on.
C
A
Yeah
phil
will
be
responsible
for
turning
the
feature
flag
on.
We
can
just
maybe
a
note
in
the
issue
and
ask
phil
to
like
let
us
know,
and
then
we
can
post
in
the
channel
when
that
happens.
C
I
think
it's
reasonable
to
ask
phil
to
post
a
message
once
once
he
activates
it
to
be
more
efficient
and
we
can.
If
you
want,
you
can
post
a
message
there
for
field
to
copy
paste
or
something
like
that.
B
B
A
A
A
Well,
there's
two
one:
I
have
no
idea
why
the
commits
tab
exists,
except
for
the
handful
of
users
that
want
to
do
like
commit
based
reviews
like
I
just
don't.
I
don't
entirely
understand
why
it's
there
and
it's
not
something
that
like.
I
think
we
have
a
ton
of
research
to
understand
why
it's
there
like
how
it
exists.
I
think
it's
like
it
got
at
it
at
one
point
and
now
I
think
if
we
were
to
take
another
look,
the
question
would
be,
would
we
add
it
again?
A
A
You
can
also
like
see
your
historical
pipeline
runs
if
you
really
wanted
to
in
like
other
places,
and
so
when
you
think
about
like
what
is
the
purpose
of
the
code
review
page
the
commits
tab,
we
could
probably
figure
out
a
different
way
to
get
you
to
that.
If
you
wanted
the
pipelines
tab,
I
don't
know
why
it's
there
and
then
the
overview
and
changes
tab
is
historically
incredibly
confusing
for
people,
because
the
overview
tab
contains
all
discussions
that
have
ever
happened
in
the
merge
request.
A
A
We
consider
that
a
tag
or
a
version,
and
then
that's
what
we
show
commits,
and
so,
if
you're,
in
the
changes,
tab
and
you're
trying
to
go
through
and
see
if
you've
responded
to
all
the
feedback,
you
can't
actually
do
that
unless
you
go
to
the
overview
tab
and
like
go
through
the
overview
tab.
But
then
the
overview
tab
isn't
showing
you
the
complete
set
of
changes.
A
This
is
also
like
why
we've
we've
been
resistant
to
secure
wanting
to
add
another
tab
is
because,
like
I
sort
of
don't
understand
why
these
these
other
tabs
exist
in
the
first
place,
so
adding
more
places
that
people
need
to
go
to
solve.
The
completeness
of
the
mr
seems
like
a
maybe
not
the
path
that
we
would
take
if
we
had
enough
time
to
research
and
figure
that
out
and
like
what
would
that
flow
be
and
look
like.
A
C
I
think
what
annabelle
you've
been
working
on
is
is
not
exactly
that,
but
it
includes
that
and
and
yeah
that's
that's
one
of
the
assumptions
that
we
have
when
doing
the
research
so
far.
Is
that
confusion
between
overview
and
changes
and
being
having
to
go
to
multiple
places
to
get
your
work
done
so
yeah,
that's
what
we're
hoping
to
explore
and
maybe
yeah
the
best
solution
would
be
to
remove
all
tabs
or
maybe
not
or
just
have
a
few
of
them
or
have
useful
tabs
right.
C
So,
let's,
let's
see
how
that
goes.
A
Yeah,
but
it's
something
I'm
happy
to
talk
about
more
or
if
you
need
me
to
like
write
it
up
or
I've
looked
at
there's
another
code
review
tool
out
there
that
doesn't
have
tabs,
but
it
has
like
a
versions
concept,
which
is
something
pager
and
I've
talked
about
like
is
potentially
part
of
that
that,
like
I
think,
would
make
makes
that
clearer.
B
Me
it's
worth
opening
an
issue
just
just
so.
We
have
something
to
refer
to
and
post
brain
dumps
ideas.
Anything
like
that.
I
think
historically,
the
tabs
are
there
because
competitors
have
those
tabs.
So
that's
just
what
everyone's
used
to
and
that's
just
what
we
did
and
never
thought
to
change
it,
because.
C
A
Cool,
I
will
add
that
to
my
list
of
things
that
I,
which
I
accomplish
and
we'll
go
from
there
but
yeah.
I
appreciate
the
ask
on
that
as
well.
Well,
yeah
we're
over
at
this
point,
but
everyone
enjoy
the
rest
of
your
week
and
day
and
we'll
talk
again
soon.