►
From YouTube: 2022-03-22 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).
B
B
I
don't
actually
have
a
sense
of
timing
on
that
one,
but
from
what
I
understood,
they've
considered
a
couple
options
and
what
they're
likely
going
to
do
is
kind
of
break
them
up
in
the
settings
so
that
you
can
kind
of
pick
your
global
merge
strategy,
one
option
at
a
time
and
then
also
offer
those
options
in
the
merge
widget.
B
So
we
talked
about
the
merge
widget
and
how
it's
going
to
potentially
look
and
it
looked
like
it
was
going
to
be
adding
kind
of
a
bunch
of
check
boxes
and
each
time
that
you
are
merging
that
merge
request.
If
you're
allowed
to
you
can
select
different
merge
strategies,
and
so
that's
great
for
people
who
really
want
it
for
people
who
aren't
really
caring
about
that,
and
they
just
want
to
merge
it
and
they
don't
really
care.
They
just
want
to
know
what
their
settings
are.
I
feel
like.
B
B
We
were
talking
about
that
and
I
brought
up
that
two-step
merge
widget
again,
I
don't
know
if
that's
the
right
phrase,
but
you
know
you
hit
merge
and
then
you
get
that
pop-up
and
it
would
you
know
either
summarize
all
the
things
that
are
going
to
happen
when
you
merge
it
delete
the
branch
squash
the
commits,
and
then
that
would
be
a
good
place
to
also
introduce
those
new
merge
strategy
options,
because
you
don't
have
to
overload
the
widget
at
first.
B
B
I
believe
with
pedro,
and
I
wasn't
sure
if
that
was
something
that
we
had
just
kind
of
not
thrown
away
but
like
we
decided
not
to
move
forward
with
that
specific
issue,
but
that
design
I'm
wondering
if
we
could
pull
that
out
and
rethink
it,
and
maybe
prioritize
that
in
the
next
few
milestones
do
a
little
bit
of
research
on
just
that
two-step
portion,
so
that
by
the
time
that
these
new
merge
strategy
merge
options
come
up,
then
we
can
add
them
to
that
secondary,
merge
step
rather
than
putting
them
in
the
existing
widget.
C
Yeah,
I
sorry
ben,
were
you
gonna,
say
something
yeah
I
was.
I
was
writing
it
down.
I
think
I'm
not
sure
if
the
if
the
merch,
widget
and
adding
all
of
those
options,
I
mean
it
is
the
boring
solution.
But,
as
you
say,
it's
also
the
overwhelming
solution.
C
Right
and
even
with
I
mean,
let's
imagine
we
we
go
all
the
way
to
the
two-step
process,
where
you
don't
see
all
those
options,
you
click
somewhere
and
you
see
them
it's
still
overwhelming,
because
if
people
by
default
we
show
them
and
users
are
not
so
accustomed
to
these
options,
they're
like
oh,
what
do
I
need
to
do
and
they
might
actually
break
unintentionally
the
the
projects
conventions
on
how
you
should
commit
things
today
we
give
the
option
of
squashing,
but
that
is
not.
B
I
think
in
the
at
least
from
what
I
gather
from
the
settings
is
that
at
the
project
level,
you
can
restrict
that,
so
you
don't
need
to
give
developers
the
options
to
like
do
a
fast
forward.
Merge
you
can
deny
them
that
option.
So,
hopefully,
at
the
time
of
merge
you
can't
choose
whatever
you
want.
You
can
only
choose.
What's
been
granted
to
you
from
the
project
level,
settings.
C
Oh
so
so
the
this
proposal
is
to
to
mimic
what
we
already
have
for
squashing,
which
is
you
either
allow
or
you
deny,
or
you
enforce,
a
specific
setting
right,
yeah
and
that
that
is
better,
but
still.
B
B
Sorry,
I
was
gonna
say
the
worst
case
scenario
is
if
at
the
settings
level,
they
allow
everything
so
every
time
that
that
merger
press
is
going
to
be
merged,
a
developer
can
choose
one
of
many
options
and
it's
unlikely.
Anyone
would
ever
switch
between
fast
forward
and
semi-linear,
or
is
that
the
same
thing
whatever
they
shouldn't
be
switching
between
these
too
much
but
yeah
worst
case
scenario.
B
There's
like
a
you
know,
six
options
that
they
can
choose
from
every
time
they
merge,
which
you
know
that's
kind
of
weird,
so
we
talked
about
like
maybe
hiding
it
in
a
little
drawer
or
something
like
that.
The
actual
design
portion
can
come
later,
but
I
think
that
what
you
just
reiterated
is
correct
that
if
we
just
jam
all
these
into
the
existing
widget,
it
is
the
boring
solution.
But
it's
it's
gonna,
look
really
cluttered.
I
hate
using
that
word.
I
use
it
all
the
time
and
I'm
sorry,
it's
just
very
confusing.
C
No,
it's
it's
a
boring
solution
that
it's
like
taking
a
step
forward
and
to
step
back
at
the
same
time,
maybe
so
for
people
that
really
want
this.
They
will
upvote
the
issue
and
say:
oh,
this
is
great.
Now
I
have
what
I
want,
but
every
everyone
else
that
didn't
ask
for
this
and
then
don't
see
a
lot
of
value
in
it
will
be
disturbed
by
this,
so
yeah
I
just
wanted
to
so.
C
But
what
I'm
wondering
now
is
not
so
much
you
know
the
two-step
process
of
merging
or
showing
these
additional
merge
options,
and
you
know
giving
project
owners
and
maintainers
the
ability
to
say
hey.
I
want
to
enforce
this
setting
or
I
want
people
to
be
able
to
choose
right
now.
What
I'm
wondering
is
if
we
need
to
take
a
step
back
and
actually
solve
this
from
what
the
usual
organizational
convention
is,
because
that's
and
that's
why
I
quoted
this
part
from
the
issue:
users
expressed
that
there
are
times
that
they
want
a
specific
setting.
C
You
know
merge
commits,
for
example,
for
certain
branches
feature
branches,
but
they
don't
want
it
for
certain
other
kinds
of
work
or
branches,
and
this
is
something
I
chatted
with
mike
about
and
he
saw
that
pattern
where
there
seems
to
be
yes
for,
like
a
better
word,
like
a
pattern
where
okay,
I
want
this
every
time
for
this
kind
of
branches,
but
not
for
these
branches,
and
this
is
aligns
with
the
work
that
he's
doing
for
the
source
code
rules
where
ben
was
also
involved,
and
we
found
out
that
or
validated
our
assumption,
that
people
want
to
organize
the
rules
and
policies
of
their
source
code
according
to
branches,
and
so
I'm
wondering
if
we
should
actually
take
another
route
and
build
the
ability
for
people
to
specify
merge
options
per
branch
in
the
same
way
that
you
have
protected
branches
and
you
say
who
can
merge
in
who
cannot
merge
and
wild
cards
or
even
approval
rules,
approval
rules.
C
We
can
scope
it
to
specific
branches
and
wild
card
branches,
and
this
is
something
I
know
mike
was
thinking
about
doing
regardless,
because
we,
we
think,
there's
a
need
there.
I'm
just
wondering
is
that
maybe
the
next
best
step
that
we
can
take
instead
of
putting
all
of
the
burden
in
the
end
user,
in
the
merge
requests
and
in
the
merging
moment
we
actually
tried
to
solve
that
at
the
organization
level
in
the
settings
before
and
the
worst
case
scenario
is
for
some
reason.
C
Some
organization
thinks
that
for
certain
branches
they
want
to
give
developers
the
ability
to
choose
what
they
want.
I
think
that
should
be
the
worst
case
scenario,
not
something
that
we
immediately
allow
them
to
do
in
the
first
iteration
we
might
want
to
first
try
to
go
through
the
best
practices
approach,
which
is
to
set
patterns
and
rules
according
to
branch
types
yeah.
I
don't
know
if
I
talked
a
lot.
I
don't
know
if
that
makes
sense.
A
I
couldn't
join,
I
was
gonna
and
you
started
going
down
that
branch
like
train
of
thought.
It
wasn't
anything
that
crossed
my
mind
before,
but
it
was
like
light
bulby
and
like
why?
Isn't
this
just
a
setting
under
protected
branches
that
like
because
it
sounds
like
it's
features
and
protected
branches-
is
where
sort
of
this
distinction
is
so
like
for
the
protected
branches.
A
This
you
care
about
something
which
is
why
it's
a
protected
branch
to
begin
with
and
then
for
everything
else
you
sort
of
like
can
have
loose
organizational
policies
or
you
could
have
sane
defaults
or
you
could
do
whatever
that
sort
of
sounded
like
a
a
rational
way
to
do
this,
because
I
I
agree
with
you
too,
when
you
were
speaking
earlier
about,
like
the
two-step
merge
widget.
My
sort
of
first
question
was
okay.
A
A
That
was
that
would
be
super
helpful.
In
that
case,
I
do
like
the
two-step
merge
widget
for
like
other
reasons,
but
I
don't
know
if
it's
like
the
answer
to
this
one
but
yeah
I.
A
I
agree
that
maybe
it's
worth
like
going
back
to
mike-
and
I
I
also
I
was
thinking
about
this
in-
like
a
lines-
are
blurred
between
source
code
and
code
review
world,
in
that,
like
source
code
is
responsible
for
git
level,
operations
on
merging
and
sort
of
like
how
that
works
and
how
the
repository
is
controlled
and
that
sort
of
things
and
then
we're
responsible
for
the
user
experience.
So
I
think
it
is
sort
of
like
on
us
to
to
be
very
collaborative.
A
So
I
appreciate
that
we
are
being
that
way,
but
it
is
sort
of
on
us
to
think
about
how
we
want
users
to
consume
this,
because
that
is
a
an
integral
part
of
the
merge
experience.
B
I
I
kind
of
leaned
towards
not
doing
that.
I
don't
know
that
much
about
it.
I
just
I
suspect
that
most
organizations
are
just
going
to
restrict
it,
not
because
they
really
really
care
a
whole
lot
about
their
specific
commit
history,
but
just
because
it
is
easier
like
just
to
have
it
by
default
and
then
not
allow
the
developer
every
time
to
change
their
merge
strategy.
So.
B
B
And
then
don't
give
developers
those
extra
options
and
they'll
never
know
otherwise,
it
seems
a
little
more
flexible
that
way
to
me
and
the
people
who
really
really
want
this
feature
will
get
what
they
want.
The
people
who
don't
care,
will
not
notice
and
it'll
just
work
kind
of
for
everyone.
C
The
way
we
should
try,
this
is
my
personal
view.
We
should
try
to
think
about.
The
options
is
similar
to.
C
To
that
other
issue
about
media
uploads
and
diff
previews,
where
initially
we
try
to
find
a
pattern
that
fits
everyone,
and
that
is
in
the
back
end,
it's
not
visible.
It's
not
something.
You
control,
it
just
works
right,
but
then
we
realized.
Oh,
maybe
we
actually
need
a
setting
for
this,
but
let's
put
that
setting
at
a
level
that
you
just
have
a
good
default
and
you
just
set
once
and
then
change
it.
C
If
you
want-
and
you
forget
about
it-
we're
not
going
the
extra
level
which
is
the
the
most
flexible
would
be
users
choosing
at
their
user
preference
level
if
they
want
diff
previews
in
their
emails
or
not,
and
you
could
argue.
Oh
you
know
this
is
very
flexible
and
now
people
can
choose
whatever
they
want,
but
I
think
immediately
going
to
the
most
flexible
option.
While
it
solves
everyone's
problem
more
or
less,
it
might
just
create
more
problems
for
the
organization
and
more
work
for
us
in
the
end
and
a
more
and
a
heavier
experience.
C
So,
and,
and-
and
that
is
to
say,
I
think,
typically-
that's
what
we've
we've
done
at
gitlab
historically
is
go
immediately
to
the
most
flexible
solution,
so
that
we
can
please
everyone
immediately,
but
actually,
if
we
try
to
be
more
progressive
about
it,
which
we've
done,
for
example,
with
squash
commits,
if
you,
if
you
remember
we
before
we
just
had
that
checkbox
and
developers
would
be
able
to
choose
if
they
want
or
not.
C
C
So
we
actually
did
things
in
a
different
order.
We
should
have
probably
done
that
first,
the
ability
to
allow
require
and
so
on
and
then
surfacing
that
to
the
user.
C
D
Sure
yeah
just
a
data
point
from
the
benchmarking
when
we
had
tasks
that
related
to
changing
protected
settings
like
that
who
can
who
can
merge
whatever
no
one
looks
under
settings
repository
before
they
look
near
the
branches
themselves,
either
on
the
list
of
branches
or
on
the
main
repository
page.
That
was
a
universal
click
through
path
that
we're
not
possibly
we're
missing
something
there.
D
B
A
C
No,
no,
it's
yeah,
you
can
read
it,
but
I
think
it's
it's
aligned
with
what
we
want
to
do
with
that.
As
that
is
not
possible
today,
because
branch
rules,
as
you
know,
are
all
over
the
place.
You
have
approval
rules
in
one
place.
You
have
protected
branches
in
another
place,
but
the
work
that
mike
is
doing
to
consolidate
all
of
the
rules
would
allow
us
in
the
future
to
do
just
that
to
people.
C
You
know,
see
the
branches
list
and
maybe
have
a
link
that
says
I
want
to
configure
rules
for
this
branch
and
they
go
there
and
it's
everything
is
there
to
see
what
is
controlling
this
branch
and
what
is
applicable
to
it.
So
it's
it's
good
that
we
already
have
these
data
points
thanks
ben.
A
All
right
so
back
to
annabelle's,
maybe
original
point.
I
love
the
branches
idea
we
should
talk
to
mike
about.
It
seems
to
make
sense
in
terms
of
where
you
put
this,
but
maybe
that's
a
different
conversation.
I
think
the
question
still
is
even
if
we
put
this
in
branches
and
someone
decided
that
they
wanted
to
make
all
of
the
options
available,
there
would
still
have
to
be
an
experience
for
that
somewhere
in
the
merge
request.
A
And
so
I
think
the
question
becomes
like
how
is
the
answer
like
we
would
solve
that
by
just
making
the
merge
widget
a
series
of
incredibly
complicated
checkboxes
for
users
and
that's
sort
of
where
we
would
start,
and
we
would
recognize
that
that
is
like
a
subpar
experience,
but
that
subpar
experience
is
like
predicated
on
you
having
created
a
subpar
like
default,
or
would
we
or
do
we
need
to
also
think
about
this?
Like
do
we
need
to?
A
I
guess
the
question
is
really
do
we
need
to
solve
this
and
like
really
really
spend
some
time
thinking
about?
Where
do
we
want
these
to
be
in
the
merge
widget,
or
are
we
of
the
belief
that
it's
unlikely
that
someone
will
have
all
of
these
things
and
so
like
just
putting
them
in
a
checkbox,
is
whatever
and
we
move
on
with
our
lives?
Also,
I
love
the
split
drop
down.
I
wish
they
were
a
thing
in
gitlab.
I
don't
know
why
we
fight
them
so
hard,
but.
B
A
I
did
because
I
saw
it
because
that
is
my
most
favorite
view
of
the
merge.
Widget
is
the
split
drop-down
one
and
every
time
we
talk
about
split
drop-downs
people
get
all
like,
but
they're,
not
in
pajamas,
and
we
don't
know
how
they're
supposed
to
work,
and
it
becomes
this
like
contentious
argument
about
like
having
split
drop
downs
and
I'm
just
like.
I
mean
this
is
a
very
like
normal
ui
pattern
in
almost
every
other
application,
and
we
have
some
wild
aversion
to
that.
B
I
I
have
that
wild
version.
I
hate
them
too.
I
think
that
they
did
some
research
where
people
weren't
sure
like
okay,
you
click
on
the
drop
down.
You
select
that
that
second
or
third
option-
you
don't
know
if
clicking
it
right
away,
is
going
to
perform
the
action
or
you
still
need
to
click
it
again
and
we
have
mixed
use
of
the
john
gitlab
or
sometimes
you
have
to
click
it
again
and
sometimes
selecting
it,
performs
that
action.
B
So
it's
a
little
weird
I
it
is
nice
that
it
hides
the
things
that
you
might
not
necessarily
want
to
see.
I've
seen
a
competitor
do
this
and
I
was
kind
of
confused
at
first
when
I
saw
it
for
the
first
time
so
yeah
the
the
two
options
I
just
wanted
to
show
on
the
screen.
I
should
have
shown
this
earlier.
The
settings
that
I
was
talking
about
were
option
a.
B
B
B
We
should
do
it
anyway.
I
agree.
It's
got
lots
of
benefits
that
have
nothing
to
do
with
this.
I
just
didn't
want
to
add
this,
as
is
because
it
looks
like
a
mess,
and
I
didn't
want
to
offer
all
these
options
right
on
the
page
where
we
already
have
a
billion
other
options,
but
I
also
think
that
it
is
worst
case
scenario.
If,
if
you
allow
every
single
item
here,
then
you're
going
to
get
all
these
options,
I
don't
know
how
common
that's
going
to
be.
B
A
Could
it
look,
I
mean
if
you
go
back
up
to
the
other?
If
that
is
like
the
actual
settings,
I
know
we
do
this
thing
now
with
squash
commits
where,
if
you
say
require
we
check
it
and
gray
it.
I
think,
on
the
merge
widget.
A
I
know
we
now
we
now
have
this
like
new,
I'm
pointing
at
my
screen
this
new,
like
light
gray
line.
That
tells
you
what's
going
to
happen
that
doesn't
exist
today.
Yeah,
the
one
that
says
like
one
commit
and
one
merged
commit
will
be
added.
A
If
we
assume
that
people
will
say
like
enforcement
or
history
merger
commits
require
and
allow
squash
commits
when
merging
require,
we
could
just
not
show
check
boxes
and
add
that
to
like
the
metadata
below
right
and
really
only
show
checkboxes
if
you're
in
an
optioned
state
or
would
that
be
like?
Could
we
just
if
we,
if
we
have
a
belief-
and
this
goes
back
to
sort
of
pinteresting
of
like
protected?
A
If
this
is
branches
and
organizational
policy,
if
we
have
a
belief
that
people
don't
want
the
flexibility
for
whatever,
if
that's
the
higher
percentage
of
users
then
do
we?
Could
we
sort
of
build
the
experience
to
like,
if
you're,
using
things
that
aren't
options
to
begin
with,
like
we
just
don't
show
you?
B
A
B
Okay,
yeah.
I
think
this
is
another
wonderful
place
for
the
second
step,
merge
widget,
where
you
could
have
like
a
list
of
all
the
things
that
are
going
to
happen
in
that
merge,
and
we
don't
necessarily
have
to
put
these
disabled
inputs
that
you
can't
act
on
everywhere
and
then
you
know
it
would
list
it's
going
to
create
a
merge,
commit
and
then
maybe
like
it
could
say
something
about
it's
set
at
the
project
level
and
that's
why
it
wouldn't
say
it
like
that.
But
you
know
what
I
mean.
C
Yeah
yeah,
I
think
the
the
second
step
is
something
that
we
will
need
to
do.
One
of
other
great
benefit
is
the
ability
for
merge,
request,
authors
and
external
contributors
to
edit
the
commit
messages,
which
is
something
that
people
have
asked
for.
A
long
time
is
hey
when
they're
setting
the
squash
commit
or
something
like
that
being
able
to
say
hey.
C
This
is
the
commit
I
want
to
to
have
used,
but
but
to
go
back
to
kai's
question,
hey
suppose
we
did
go
to
the
branches
routes
and
someone
did
select
all
the
options.
We'd
still
have
to
solve
that,
and
I
think
we
don't
have
to
solve
that
at
least
initially
and
then,
until
we
have
validated
that
people
actually
need
that
right,
because
if
we
give
if
we
meet
the
users
where,
with
where
they're
saying
their
behavior
is
and
they're
saying
that
sometimes
they
need
it
for
certain
branches,
and
sometimes
they
don't.
C
We
can
then
see
if
there's
there's
still
a
real
need
to
give
developers
the
ability
and
the
power
to
choose
options
at
the
merge
moment,
and
maybe
it
isn't
that
much
of
a
big
deal
and,
to
be
honest,
I
I'm
skeptical
of
giving
a
developer
or
anyone
and
the
ability
to
create
a
merge
commit
if
they
want,
and
how
do
you
choose
if
you
want
to
merge,
commit
or
not
at
the
merge
moment,
you
know
squashing
like
it's
your
commits,
maybe
or
you
will
review
the
list
of
commits.
C
I
know
I
want
to
squash
them.
It
makes
sense
for
this
merge
request,
but
a
merge
commit.
You
probably
have
to.
You
know,
get
your
information
elsewhere,
hey
does
this
warrant
a
merge
commit
or
not?
So
I
don't
think
that's
the
best
moment
to
make
that
decision
so
yeah.
I
think
we
don't
need
to
cross
that
bridge
right
now
of
giving
developers
the
options
in
the
merge
moment
if
we
solve
the
branches
first.
B
So
just
so,
I
understand
what
you're
talking
about
with
branches.
Are
you
saying
like
if
your
branch
begins
with
the
word
feature,
then
yeah?
Don't
don't
squash,
create
a
merge,
commit
yeah.
C
B
D
C
Okay,
yeah,
I
think,
or
for
example,
you
only
want
merge
commits
when
you
merge
to
main.
For
example,
you
know
for
the
other,
every
other
branch
you
don't
need
merge,
commits,
for
example,
I
don't
know-
or
maybe
the
opposite.
Maybe
you
want
to
squash
everything
every
time
you
merge
into
main,
and
you
want
to
keep
the
more
granular
history
in
the
future
branches.
C
C
To
begin
with,
that
would
be
my
suggestion
is:
try
to
solve
it
at
the
settings
and
organization
level
first,
and
if,
after
that,
if
people
really
need
it,
and
we
think
it's
worth
solving
for
that,
we
will
then
show
those
options,
but
then
we
will
run
into
that
problem.
That
probably
then
needs
okay,
the
two-step
merge
and
we
needed
another
area
and
to
set
the
merge
options.
A
Cool,
I
think
I
think
the
takeaway
is
is
like
we
want
to
go
back.
I
I
will
once
this
video
is
uploaded
I'll
make
sure
we
share
with
mike,
I
assume,
annabelle
or
pedro.
One
of
you
will
probably
meet
with
mike
about
this
again
at
some
point,
so
we
can
also
continue
to
discuss
that.
That
way.
A
I
appreciate
annabelle
you
bringing
this
up.
Is
it
sorry?
We
derailed
it
from
two-step
merge,
but
it
was
good
to
talk
about
this
teacher
in
general
and
and
help
get
everyone
up
to
speed
and
get
some
more
clarity
on
options
and
ideas
here,
because
this
will
be
a
an
interesting
change
to
watch
unfold.
So
it's
good
good
to
talk
about
it.
Early
ben.
You
got
the
last
one
we're
up
against
time,
but.
D
Just
have
a
look,
and
let
me
know
if
you
have
any
questions
or
comments
or
otherwise,
and
I
appreciate
you
guys
taking
some
time
for
this.
A
That's
it
all
right!
Well,
thanks,
everyone
enjoy
the
rest
of
your
week
and
day.