►
From YouTube: 2021-05-11 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
Awesome
pedro
you've
got
the
first
couple
up.
B
Yeah
the
first
point
about
the
this
issue:
overwrite
squash
commit
message
before
merging
something
that
users
have
been
crying
about
and
people
want
it,
and
it
makes
a
ton
of
sense,
of
course,
and
it's
one
of
the
most
popular
issues
that
we
have
in
code
review.
And
I
put
it
here
because.
B
I
think
that
there
might
be
a
good
way
for
us
to
iterate
towards
this,
so
essentially
what
I
think
it's
two
things
that
are
happening
here
so
on
one
hand,
there's
the
necessity
of
the
people
that
are
not
going
to
merge
or
even
they're
they're
going
to
merge,
but
nonetheless,
the
authors
or
developers
of
the
merge
request.
They
want
to
be
able
to
set
a
merge,
commit
message-
or
in
this
case
a
squash,
commit
message
before
the
merge
request
is
merged.
B
One
way
that
we
could
do
that,
although
it
would
not
fix
the
second
problem,
but
the
first
problem
to
fix
this
could
be
possibly
to
add
these
fields
to
the
edit
merge
request
form
in
the
same
way
that
we
already
have
the
options
to
set
the
deletion
of
this
source
branch
or
to
say,
if
you
want
to
squash
the
commits,
we
could
potentially
add
those
fields
there.
B
It's
always
there
and
you
just
want
you're
looking
at
the
merge
button
and
that's
the
focus
and
with
all
of
the
clutter
of
the
ui,
the
the
ability
to
edit
the
commit
messages
gets
lost.
So
this
is
actually
a
good
segue
and-
and
I
I
didn't
know
that
sanjong
would
would
share
her
proposal
in
point
three.
B
But
we
were
talking
both
of
us
today
about
this,
and
it
actually
connects
very
well
with
what
she
has
next
and-
and
so
I
think
we
can
connect
both
this
issue
with
what
she's
doing
and
try
to
have
not
fix
it
in
one
go,
but
at
least
have
a
plan
of
how
we
can
fix
most
of
these
things
together
and
then
iterate
towards
that
ultimate
resolution.
B
But
I'll
stop
there
for
four
comments.
Before
sanji
jung
goes
to
her
point
in
case,
anyone
wants
to
comment
on
what
I
just
said.
A
A
I
think
the
other
question
I
have,
though,
is
this
is
like
a
complicated,
uncomfortable
configuration
question
is,
like
you
know,
the
other
thing
we
could
do
is
implement
a
project.
Setting
that
says
use
title
for
squash,
commit
message
or
use
first
multi-line
commit
for
this,
which
might
broadly
appease
both
groups,
who
are
have
different
workflows,
built
in
different
ways
around
this,
and
then
it
might
be
faster,
potentially
than
some
of
these
other
things
that
we
might
want
to
do.
I
guess
my
my
hesitation
and
risk
is
like.
A
I
don't
particularly
want
another
setting
to
deal
with
this,
but
it
also
feels
like
there
is
not
a
saying
default.
That
everyone
agrees
is
the
same
default
here,
so
I
don't
know
like,
and
even
our
own
engineers
are
now
running
into
this
based
on
the
new
changelog
stuff.
I
know
because
we
switched
out
the
behavior
underneath
them
while
they
were
building
a
changelog
feature
which
is
sort
of
interesting.
A
B
Controlling
the
default
is
could
be
could
be
helpful,
but
I
think
more
than
controlling
the
default
is
is
is
just
being
able
to
edit
it
beforehand.
I
think
that's
because
that
would
solve
all
of
the
problems
and
not
roll
up
have
to
rely
on
the
default.
B
The
default
would
just
potentially
make
it
faster
for
certain
cases
like,
for
example,.
B
Let's
use
the
merge
request
title
and
the
merge
request
description
as
the
squash
commit
message.
It
can
work
for
for
some
teams
for
other
teams.
They
might
not
rely
at
all
on
the
merge
request
title
or
the
merge
request
description,
because
I
don't
know,
could
it
be
another
thing,
so
they
would
always
have
to
change
the
squad
commit
message,
so
I
think
it
might
be
preferable
for
us
to
first
go
down
the
route
of
let's
try
to
solve
it
for
the
widest
audience.
B
First,
that
captures
all
of
or
most
of
the
cases
and
after
that
evaluate
if
we
really
really
need
a
project
setting,
because,
as
you
said,
it's
it's
another
setting
it's
another
thing
for
us
to
maintain
and
I
think
jumping
to
that
immediately
is
yeah.
I
think
it's
just
jumping
the
gun
too
soon.
A
You
think
there's
a
the
flip
side
to
that
is
like
a
project
setting
eliminates
the
need
for
any
additional
editing
options
or
controls
or
views,
or
prompts
for
this.
Because-
and
this
is
let's
just
say
like
if
you
look
at
the
two
issues.
The
original
issue
that
converted
squashing
to
multi-line
commits
and
then
this
issue
which
converted
well,
which
wasn't
gonna,
do
anything
and
then
a
community
contributor
converted
it
to
title.
A
Oh,
we
always
just
made
our
first
commit
like
this,
and
we
did,
you
know,
fix
up,
commits
all
the
way
to
that
and
that
was
sort
of
the
only
commit,
or
you
know,
maybe
if
there
were
other
commits,
but
we
always
we
always
knew
to
like
do
this
and
they
trained
people,
and
so
you
didn't
have
to
review
the
squash
merge
request.
The
squash
merge
message
merge,
commit
message
because
you
trusted
the
the
default
already
had
what
you
had
in
there
and
so
like.
B
B
I
think
that's
fair,
that
we'd
like
to
fix
to
have
the
best
default
for
everyone.
B
And-
and
some
teams
would
like
to
have
the
title
and
the
merge
request
description,
but
other
teams
will
not
want
to
have
that,
and
so
we
would
still
need
to
deliver
the
capability
to
edit
the
squash
commit
message
or,
as
you
said,
like
have
a
setting
that
turns
on
or
off
the
default
or
whatever.
That
is
there's
yet
another.
A
third
approach
which
is-
and
this
is
just
an
example
it
might
there
might
be
others
so
in
github
when
you
squash
and
merge
it
actually
takes
well.
B
In
this
case
the
two
commits
have
the
same
message,
but
it
lists
out
the
commits,
as
you
would
do,
with
a
as
an
optional
extended
description
so
and
it
takes,
I
think,
the
title
of
the
merge
of
the
pull
request.
Actually,
let
me
see
if
I
can
change
it
really,
quick.
B
Right
so
it
takes
the
title
and
the
id,
and
it
then
lists
the
all
of
the
commits
here
for
you.
So
this
is
yet
another
thing
that
actually
is
is
very
reasonable.
I
I
think,
for
a
team
to
have
to
do
this
if
they,
if
they
are,
writing,
really
good,
commit
messages.
Every
time
they'd
like
to
keep
that
history
as
bullet
points
on
the
the
commit
message
itself,
so
this
would
be
yet
another
default.
I
guess
right.
A
Yeah,
I
I
mean
I
don't
I
don't
have
strong
opinions
about,
which
is
right.
I
guess
is
maybe
the
way
to
say
that.
But
what
I
think
we've
seen
is
that
teams
have
a
strong
preference
about
which
is
right
and
to
me
I
think
when
we
see
that
teams
have
a
strong
preference
about
which
is
right
and
are
sort
of
not
easily
swayed.
A
And
we
don't
have
a
strong
preference
like
I
don't
as
the
people
not
working
in
those
projects,
I
can't
tell
you
which
commit
messages
are
better
or
not
or
more
valuable
or
not
right,
and
I
think
that
is
very
much
a,
not
a
concern
that
we
should
have
or
something
that
we
should
have
a
strong
opinion
about
like.
I
think
that
is
that
sort
of
person,
I
think,
if
we
were
gonna,
have
a
strong
opinion.
A
Our
strong
opinion
would
be
that,
like
the
malt,
the
multi-line
commit
is
the
correct
one,
because
we
think
commit
messages
are
important,
but
many
teams
do
not
think
that
commit
messages.
Are
that
important,
as
is
evident
by
most
projects
and
commit
messages
that
you
see
even
gitlab's
own
commit
messages
are
not
great,
but
I
think
when
we
see
that
there's
so
much
contention
there
to
me
that
feels
like
the
breaking
point
for
going
to
a
configuration
route
and
letting
teams.
A
A
Because,
even
if
we
put
editing
options
in
front
of
people
like
one
team
is
disadvantaged
if
the
if
the
box
is
pre-populated
with
title
and
description,
anyone
who
doesn't
want
that
is
now
disadvantaged
and
their
workflow
is
like
hampered
and
longer
and
takes
more
thought
and
their
cycle.
Time
is
therefore
slower
because
they
had
to
make
choices
and
change
things
every
time.
I
think
the
same
is
true.
If
we
made
it
the
first
commit
message,
anyone
who
doesn't
want
that
to
be
their
their
default.
A
Squash
message
is
now
at
a
disadvantage
because
of
xyz,
and
so
this
feels
like
one
of
those
things
where
like
where
as
much
as
like,
I
wouldn't
you
know,
I
think
we'd
all
agree
that
we've
got
too
many
settings
and
too
much
going
on
there.
A
We
recognize
that,
like
all
of
these
things
are
valuable,
and
then
that
gets
us
the
immediate,
like
fix
for
all
of
these
groups,
and
then
I
think,
if
there's
further
demand
right.
If
we
see
the
next
group
of
people
who
are
like
oh
well,
our
commit
messages
should
be
some
random
formula
of
all
of
these
things,
like
we
say:
okay,
well,
now
we're
into
editing
land
and,
like
you
know
you,
we
believe
that,
like
you,
should
verify
this
and
like
we'll,
put
some
editing
pieces
in
and
make
that
workflow
possible.
A
But
I
think
that
is
a
much
more
complicated
workflow
to
do
than
sort
of
just
like
adding
a
setting
today
and
saying,
like
here's,
the
default,
you
can
switch
between
these
two
options,
pick
whichever
one
you
want
and
then
and
then
move
on
from
there.
B
C
B
Don't
care
so
much
about
just
care
about
the
end,
result
and
yeah?
I
think
all
that
is
reasonable
and
yeah
we've
seen
in
that
issue.
B
One
they
should
be
able
to
override
it
before
the
merge
and
two
that
it's
what
you
said
like
they
don't
want
this
to
be
an
impairment
to
their
velocity
and
to
have
to
think
twice
about
it.
So
they'd
like
a
default,
but
then,
as
you
said,
like
one
team
wants
this
default.
Another
team
wants
that
default,
so
you
might
as
well
give
them
all
of
the
defaults
and
they
pick
because
I
think
you're
right.
A
I
already
have
two
questions,
one
just
confirming
so
like
a
setting.
We
all
sort
of
feel-
and
I
don't
know
catherine
and
sometimes
you
haven't
spoken
up,
but
we
all
sort
of
maybe
feel
that,
like
a
setting
not
ideal
but
given
sort
of
the
circumstances
might
be
okay
and
then
the
second
question
would
be:
do
we
actually
think
it's
a
priority
and
something
we
should
like
put
an
engineer
to
go.
Do
within
the
next
like
one
or
two
milestones
or.
B
Something
yeah
priorities
are
priorities
based
on
under
relative
compared
to
other
things.
So
I
hard
to
say,
I
think,
what
we're
focusing
on
right
now
the
performance
is
more
important
than
this.
B
That's
my
understanding
and
there
could
be
other
things
that
are
more
important
than
this,
but
I,
if
I
think
it's
if
we
come
to
an
agreement,
I'm
hopeful
that
and
if
we
have
a
direction,
I'm
hopeful
that
of
all
of
these
people
that
find
this
issue
very
important
to
them.
They
could
be
willing
to
contribute
something,
even
if
it's
just
one
of
the
settings
you
know
but
committing
someone
to
this
from
our
team
right
now.
B
I
don't
know
but
I'd
like
for
us
to,
if
possible,
to
deliver
or
continue
delivering
or
addressing
popular
issues
and
not
just
bug,
fixes
and
performance.
Although
the
performance
is
popular
with
everyone,
as
we've
seen
it's
one
of
the
top
things,
but.
C
Yep
and
to
me
like
this
seems
like
pretty
important,
but
as
pedro
mentioned,
I
don't
think
this
is
as
much
as
important
compared
to
what
we
are
currently
focusing
on.
I
mean
performance,
so
I'm
I
like
the
decision
that
we
just
discussed
like
about
having
a
setting
option.
I
think
that
makes
sense
because
it
aligns
with
organization
workflow.
B
B
Advocating
for
for
that,
on
their
own
other
than
saying
like,
we
started
using
this
because
this
was
the
way
to
to
have
the
defaults
as
we
wanted.
You
know
what
I'm
saying.
A
Wasn't
that
the
I
mean
that's
the
logic
of
why
it
got
changed
to
that
was
based
on
when
it
originally
changed.
That
was
that
this
is
like
the
better
form
of
a
commit
message
and.
A
B
Setting
so
there
are
people
that
want
the
description.
Other
people
don't
want
the
description.
There
are
people
that
want
a
list
of
the
commits,
like
I
showed
you
in
github.
B
The
multi-first
multi-line
commits
I
I
have
to
dig
through
the
past
discussions,
but
I'm
not
sure
it's
something
that
someone
asked.
I
I
don't
know
I'll
have
to
let's
go
and
find
it.
A
Yeah
I
mean
I
guess
I
would
we've
never
had
those
other
options.
I
guess
we've
never
had
title
and
description
and
we've
never
had
title
plus
other
commit
messages
as
options,
so
I
would
be
hard-pressed
to
introduce
a
setting
that
introduces
things
that
never
existed
before
versus
like
introducing
a
setting
for
like
changes
that
we've
made
sort
of
in
product.
If
that
makes
sense
that
way
like
I,
I
don't
wanna
and
I
think
that's
like
a
slippery
slope
and
why
we
need
to
be
cautious
of
the
setting.
A
Is
I
don't
want
to
introduce
the
setting
and
then
watch
three
more
merge
requests
come
in
that
add
four
other
options
to
like
that
drop
down.
Yeah,
because
that's
not
helpful
to
anyone
like.
I
don't
want
more
opinions
in
that
drop
down
than
like
sort
of
the
couple
that
we
that
we've
had
in
the
product
before.
B
That
has
the
first
implementation
of
the
first
multi-line
commit
message
and
before
that,
so
that's
when
we
allowed
overwriting
the
squash
commit
message
in
the
first
place
and
before
that,
what
it
reads
in
the
the
description
is
that
we
were
just
using
the
merge
request
title
at
the
squatch
commit
message.
A
What
the
options
are,
but
I
don't
I
don't
want
to
go
into
like
a
here's,
20
options
sort
of
deal.
I
wanna,
I
think
two
same
defaults
based
on
two
sort
of
like
same
options
based
on
commits,
which
we
think
are
valuable
or
titles
which
are
simple
and
short
and
don't
potentially
contain
all
the
caveats
of
descriptions
or,
like
all
these
other
things.
A
Those
have
both
been
in
the
product
both
for
for
multiple
years
at
a
time
and
so,
like
those
seem
reasonable
in
terms
of
like
things,
but
I
don't
think
we
should
introduce
like
new
things.
Along
with
this.
C
This
is
more
like
read-only
that
I'd
like
to
propose
it's
not
proposed,
but
I
like
to
create
an
issue
like
async
design,
created
issue
within
the
code
review
team
and
if
you
click
the
figma
file,
there
are
some
exploration
and
proposal
almost
ready
to
be
reviewed.
So
I'm
going
to
create
a
new
issue
and
ping
the
whole
team
together
more
feedback
and
rework
on
that
and
start
to
plan
for
another
another
solution:
validation.