►
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
Cool
hello,
everyone,
I'm
sanjan,
I'm
on
the
enablement
group,
but
this
ua
showcases
is
about
the
experience
that
I
work
on
the
creek
stage
group
for
the
past
three
milestone
and
I'm
going
to
it's
not
introducing
but
to
walk
you
through
how
I
work
on
the
consolidating
action
button
in
the
merge
request
page.
A
Pointed
already
well,
the
red
box
area
is
the
possible
action
buttons.
So,
as
you
can
see,
it's
everywhere
here
is
the
proof
button,
and
also
here
is
like
mark
as
strap
button
and
also
add
to
to
do
button.
There
are
a
couple
of
other
action
buttons
here
around,
so
I
think
in
the
async
design
review
some
of
designers
already
pointed
out
that
it's
kind
of
scattered
and
we
also
received
some
similar
feedback
from
the
prior
user
research-
that
it's
not
easy
to
find
some
button
in
certain
contexts.
A
So
this
was
one
of
my
first
tasks
as
I
as
as
long
as
as
far
as
I
remember
so
I
I
was
thinking
for
a
while.
So
you
know,
gillab
is
just
a
complicated
product
and
what
could
be
the
happy
past,
because
that
was
my
first
question
popped
up
in
my
mind,
because
these
are
repositioning
or
hiding
or
do
something.
But
too
many.
A
So,
let's
imagine,
if
you
open
or
create
a
project
class,
then
the
normal
thought
process
would
be.
Okay,
I
put
some
of
my
code
changes
here.
Could
you
approve
some
of
my
code
changes
here
and
they
will
do
some
ping
pong
round
about
the
code
review
and
then
they
want
to
see
it's
approved
and
it
goes
to
merge.
A
B
B
A
A
So
I
just
started
to
explore
that
was
just
top
of
my
mind
at
the
very
first
time,
so
I'm
going
to
introduce
my
persona,
which
type
of
designer
am
I
but
you'll
see
later.
But
I
am
really
visual
focused
persons.
So
I
need
to
visualize
my
idea
first
so
that
I
can
talk
to
pedro
so
that
I
can
talk
to
the
user.
So
I
just
open
the
blank
fake
file
and
just
using
and
call
it
as
a
playground,
and
I
put
everything
that
was
into
my
mind
and
also
into
my
hat.
A
It's
not
pixel
perfect
at
all,
but
I
quickly
asked
feedback
with
pedro
and
also
the
pm
and
also
with
the
design
managers,
and
they
provided
me
a
really
nice
feedback
so
that
I
could
start
to
work
on
this
concept
very
well,
and
I
really
like
to
having
this
exploration
board,
because
it's
just
a
simple
thought
process,
and
also
it's
just
easier
for
me
to
get
feedback
really
quickly
and
even
we
can
also
do
asynchronously.
So
I
like
this
approach
and
for.
A
Because
it
was
not
a
full
formal
user
interview,
so
I
started
to
recruit
some
of
the
software
developers
and
the
product
manager
outside
of
the
co
review
team
by
asking
them
in
the
development
channel
and
also
ask
them
individually
in
dms.
Like
are
you
up
for
a
copy
chat,
and
I
also
have
a
design
question:
can
we
use
like
10
minutes
or
15
minutes?
A
So
they
said
yes
of
course,
so
it
seems
like
people
like
this
idea
because
of
the
accessibility
for
the
first
reason,
I
think,
probably
that
was
the
main
pain
point
for
them
like
when
they
are
reviewing
the
code
in
the
change
tab.
They
need
to
go
back
to
the
overview
tab
and
then
finding
the
proof
button
or
the
merge
button.
I
think
that
was
the
main
pain
point,
so
I
think
probably
this
direction
is
right
to
go.
A
So
after
that
we
opened
this
async
design
review
question
with
the
co-review
team.
I
was
so
surprised
and
really
excited
that
we
got
more
than
40
responses
from
the
engineers
and
also
from
the
pm,
and
we
I
tried
to
frame
this
question
because
it's
really
easily
getting
into
the
wider
discussion.
If
I
just
put
the
design
and
hey
what
do
you
think,
because
so
many
people
can
point
out
different
things,
so
I
use
this
question
framework.
What
do
you
like
about?
A
What
do
you
have
like
a
better
idea
for
a
certain
part
and
what
could
be
the
feasibility
issue
that
come
up
in
your
mind?
So
I
got
really
valuable
feedback.
So
this
would
be
the
final
outcome
after
the
step
three,
but
we
still
need
to
keep
that
in
mind.
It's
it's
not
yet
finalized
design.
So
I
just
named
this
action
like
things
to
be
considered,
so
this
was
the
idea
that
we
had
showing
the
different
buttons
in
the
different
tabs,
because
people
do
different
action
under
the
different
tab
in
the
overview
tab.
A
They
mostly
check
the
widget
and
also
check
the
discussion
in
the
comments,
but
while
on
the
change
tab,
they
need
to
check
the
div
and
also
the
file
browser
and
also
the
comments
in
the
code
line.
So
I
think
it
would
be
handy
to
have
a
finish
review
button
so
make
the
core
review
process
more
explicitly
that
okay,
I'm
done
up
the
review
I'll
just
approve
it
at
the
same
time.
So
I
think
it's
a
good
position
to
put
those
action
button
on
the
right
top
and
also
in
the
overview
tab.
A
I
I
have
seen
some
of
the
research.
It's
not
the
research
question,
research
analysis
and
also
coming
from
some
open
issue
from
the
community
member
that,
in
case
of
the
smaller
review,
they
would
like
to
use
the
web
id
because,
like
just
pulling
down
the
branch
and
then
working
on
the
local
friends,
that
would
take
some
time.
So
I
think
that
makes
sense.
A
So
we
can
also
have
to
open
in
the
web
id
or
the
vs
code
so
that
they
can
easily
check
the
smaller,
mr
and,
at
the
same
time
they
can
also
curve
and
merge.
In
the
overview
tab
so
that
they
don't
need
to
scroll
a
lot
through
the
merge
check,
widget
and
also
the
widget
below
the
description
section
and
another
new
user
flow
that
we
haven't
validated
with
the
user
yet,
but
with
the
team
was
to
provide
a
chance
to
select
the
merge
option
before
they
just
hit.
The
merging
button.
A
Pedro
also
pointed
out
that,
like
some
user
just
mistakenly
hit
the
merge
button
in
that
case,
what
should
they
do?
So?
I
think
it's
more
safer
and
become
more
conservative.
If
we
have
this
modal
window
and
if
everything's
okay,
then
they
can
also
hit
the
merge
button
and
then
they
will
see.
Okay,
everything
looks
good.
What
is
the
merge
option
and
they
can
just
hit
the
merge.
A
So
this
is
a
good
part
of
having
the
smaller
window,
but
only
downside
would
be
it's
adding
one
more
option,
so
probably
some
user
might
not
like
it,
but
I
think
so.
We
have
more
benefit
than
the
downside
for
this
idea,
and
this
was
also
have
coming
from
pedro
and
andre
during
the
design
review,
and
I
totally
understand
their
points.
A
So
if
you
just
remember
that,
when
we're
in
the
changes
tab,
we
already
have
so
many
different
sticky,
it's
not
the
sticky
header,
but
sticky
top
navigation
section
and
it
already
consumed
a
lot
of
height.
So
my
idea
to
going
forward
to
this
direction
would
be
reduce
the
current
height
of
the
sticky
header,
because
it's
pretty
heavy.
So
if
we
use
if
we
reduce
the
padding
or
margin
of
the
current
sticky
header
it'll
already
help,
and
if
we
have
more
chance
to
explore
this
comparing
tab,
I
think
here
somehow
we
can
incorporate
this.
A
The
last
thing
was
about
like
I
got
this
feedback
from
myself,
which
was
very
keen
I
have
to
admit,
and
also
a
lot
of
engineers
already
pointed
out
that,
like
what
do
you
see
like,
if
you
click
unmergeable
state,
what
are
you
going
to
show
like?
Are
you
going
to
show
the
modal
window
and
how
can
we
handle
that
situation
so
as
an
intermediate
step
like
the
second
screenshot,
was
my
idea
at
that
time?
A
But
it's
still
also
downside
that
we
are
hiding
the
disabling,
the
primary
action
button
in
this
sticky
header,
which
looks
not
cool
and
also
it's
adding
one
more
step
and
it's
a
bit
hidden,
even
though
it's
pretty
important
information.
So
we
need
to
discuss
how
can
we
handle
this
situation
in
a
better
way?
A
So,
as
a
next
step?
Of
course,
this
will
not
going
to
happen
because
we
have
amazing
engineering
team,
so
we
have
discussed.
Probably
this
would
be
the
first
step
to
start
implementing
this
design
so
that
we
can
have
some
actions
button
on
the
right
top-
it's
not
introducing
as
the
sticky
header
but
we'll
just
change
the
layout
and
also
some
of
the
layout
and
the
status
status.
It's
not
far,
but
status.
Sorry
and
the
title
and
the
pro
profile
picture
something
like
that,
but
this
should
be
discussed
also
within
the
ux
team.
A
So
we
need
to
discuss
with
the
ux
team
before
we
start
to
ship
this
design
to
make
sure
we
are
delivering
the
consistent
user
experience
and
it
was
a
long
and
also
short
journey.
I
have
to
say,
because
it
went
so
fast.
I
I
thought
that
the
first
time
like
milestone-
that's
not
that
long
or
probably
it
could
be.
Just
I
don't
know
it
was
so
fast,
and
I
have
to
admit
that
I
love
this
power
of
collaboration
and
I'm
not
so
sure
you
remember
this.
What
kind
of
designer
are
you
test?
A
I
think
it
was
shared
by
holy
as
far
as
I
remember
in
the
very
earlier
this
year
in
the
ux
slack
channel-
and
I
was
the
prototyper
like
if
you
see
in
this
slide
the
silly
look
like
monkey.
That
was
my
type
and
in
that
description,
the
opposite,
attract
was
conductor
and
pedro
was
the
only
conductor
on
our
team
at
the
time.
A
So
I
I
really
expecting
and
looking
forward
to
work
with
him,
because
we
are
having
very
different
perspective
and
I
think
we
could
over
overcome
this
by
collaborating
more
frequently
and
also
talk
to
each
other,
and
I
I
personally
learn
from
pedro
a
lot.
So
thank
you.
This
is
just
a
preview
that
we're
we're
going
to
share
our
experience
by
writing
a
blog
post
or
just
by
recording
our
conversation
like
what
we
learned
and
what
could
we
do
better.
So,
in
the
meantime,
you
can
check
out
our
retrospective
issue.
A
We
put
some
comments
during
the
screen
awesome
and
thank
you
for
everyone,
especially
the
ux
leadership,
who
gave
me
this
nice
opportunity
to
learn
more
about
the
gila
product
area
and
support.
It
was
really
helpful
and
I'm
so
happy
that
annabelle
is
moving
up
onto
your
toe
review
team,
so
yeah,
thank
you,
everyone
and
you
might,
if
I
share,
stop
sharing
and
just
give
me
one
second,
okay,
yep.
Thank
you.
A
D
C
Curious
about
how
users
are
mistakenly
hitting
the
merge
button.
That's
that's
new
to
me.
Haven't
heard
of
that
happening,
so
I
was
wondering
if
we
had
any
insight
on
how
often
that's
happening
and
whether
there's
any
difference
in
that
happening,
based
off
of
where
you've
placed
the
merge
button
and
whether
that
can
maybe
allow
us
to
avoid
using
a
modal
or
not
so
yeah.
I
guess
I'll
start
there.
A
So
annabelle
is
putting
the
issue
link
there.
I
I
actually
didn't
have
the
very
specific
data
I
just
got
with
feedback
from
that.
That
was
pretty
frequently
happening,
but
if
I
just
recall
my
experience
in
my
previous
job,
I
had
problem
finding
the
merge
button
not
mistakenly
hit
the
button,
but
I
couldn't
find
the
merge
button
at
the
first
time.
A
So
I
thought
that
this
could
be
a
placement
issue,
but,
as
you
mentioned
this,
this
could
be
just
a
hierarchy
of
the
page
could
solve
the
problem,
because
sticky
header
itself
is
a
hot
discussion
topic.
I
I
know
that
some
people
hate
it
and
some
people
love
it,
but
still,
I
did
think
at
that
time
like
if
we
just
having
like
one
centralized
comment
center
like
globally
accessible
from
everywhere.
I
think
it
could
be
more
unified
way
to
just
find.
Okay,
there's
merge
action
there
or
there's
a
proof
button
there.
A
So
I
think
it
could
be
easier
solution.
So
I
think
that's
actually
a
very
good
point.
If
we
are
going
forward
to
the
solution,
validation
and
if
user
probably
doesn't
like
this
approach,
then
I
think
we
I
we
need
to
rethink
about
this.
Probably
it's
just
a
hierarchy
of
the
page
problem
or
just
a
modal
window
could
solve
the
problem.
So
yeah,
that's
a
very
good
point.
C
I
was
also
curious
about
the
ability
to
revert
an
mr,
so
once
you
merge
it,
there's
a
button
that
says
revert
it.
B
A
A
I
think
it
depends
so
my
assumption
would
be
for
the
first
time
user.
Yes,
it
could
be
a
little
bit
difficult
to
find
at
first
time,
but
if
I
think
there
was
a
nice
sus
summary
earlier
today
shared
in
the
ux
channel
that
if
they
get
used
to
it,
they'll
find
it.
But
I
still
do
think
we
need
to
solve
the
problem
of
the
learnability
issue.
So
if
the
first
time
user
had
hard
time
finding
that
button,
then
we
need
to
do
something
for
them.
C
E
E
Yeah,
I'm
not
sure
why
that
was
so
common
for
me,
but
I
did
it
many
times
and
eventually
I
was
like.
Oh
my
gosh.
We
should
do
something
about
this
and
that
was
like
five
years
ago.
I
do
have
a
question
though,
and
it
was
brought
up
in
that
issue
I
linked
to
what
would
the
experience
be?
If
you
used
the
merge,
quick
action,
would
there
still
be
some
kind
of
two-step
approach?
Would
it
bypass
everything.
A
F
E
A
Think
it
has
both
good
side
and
also
the
downside,
because
I
think
at
the
same
time
we
want
to
make
confirmation
to
our
users
that,
if
everything
is
mergeable
or
if
not,
then
why
it's
not
mergeable
and
also
we
would
like
to
provide
the
merge
option
like.
I
think
there
is
a
lot
of
discussion
around
like
squash
comment
and
also
modify
his
comment
in
that
situation.
A
D
A
A
E
A
F
Yeah
yeah
great
great
points,
annabelle
and
tori
about
tori's
question
on
reverting
the
merge
requests.
It's
it's
interesting
because
we
make
reverting
very
easy,
but
it's
not
like
closing
and
reopening
emerge
requests.
For
example,
when
you
close
a
merge
request,
we
don't
ask
for
confirmation,
because
you
can
just
click
again
and
it
will
reopen
and
and
that's
okay,
but
when
reverting
the
original
merge
request
is
merged.
So
all
of
the
original
merge
request
information
discussion
is
lost
in
the
new
merge
request.
F
It's
like
a
completely
new
merge
request
that
just
yeah
just
reverts
the
changes,
so
it
inverses
what
you're,
adding
and
removing,
and
it
would
make
for
a
very
weird
review
if
you
clicked
the
merge
button
accidentally
because
now
you
have
to
revert
and
you
have
to
create
a
merge
request
to
add
those
changes
again.
So
you
can
continue
the
review
and
the
version,
the
version
history.
F
So
all
of
the
commits
they
are
changed
forever
and
unless
you
you
clean
up
the
the
commit
history
so
for
some
organizations
having
a
very
clean
commit,
history
is
important,
so
that
will
make
things
difficult
for
them,
and
I
don't
know
if
that
that
adds
some
useful
context
to.
C
C
I
wonder
if
there's
the
opportunity
to
do
something
like
we
do
with
to
do's,
where
it's,
maybe
it's
not
necessarily
a
revert
right
away
or
the
merge
doesn't
go
in
there's
a
delay
of
some
sort,
so
you
can
immediately
undo.
D
C
You
make
the
mistake
something
along
those
lines
to
look
into,
so
it's
not
not
technically
a
revert
at
that
stage,
but
I
don't
know
something
to
think
about.
F
Yeah
there's
a
very
interesting
approach
that
I
saw
on
in
a
tool
called
reviewable
where
they
you
have
to
click
and
and
press
the
merge
button
for
certain
seconds,
and
it
has
like
a
progress
bar
and
only
when
you,
when
it's
filled
it
merges.
So
if
you
release
it
ahead
of
time,
it
doesn't
merge
it
yeah,
it's
it's
not
very
accessible
and
it's
a
it's
a
weird
interaction,
but
it's
another
approach.
F
One
interesting
thing
is
that,
while
we're
still
exploring
this-
and
we
haven't
made
any
decision
to
to
proceed
with
this
confirmation
step
for
what
it's
worth
other
tools
like
github,
azure,
devops
and
bitbuckets,
they
also
have
a
confirmation
step
before
merging
and
yeah
and
those
are
our
main
competitors.
F
So
we
will
look
into
that
more
closely
and
one
other
point
of
context
I
wanted
to
add:
is
that
not
only
the
accident
points
that
we
were
discussing,
but
also
we
want
to
make
sure
that
users
are
aware
of
the
consequences
of
them
of
merging
and
also
all
of
the
merge
options
that
they
can
select
and
currently,
that
experience
is
all
jam
packed
into
a
very
small
area
where
you
set
the
deletion
of
the
source
branch
and
the
commit
messages,
and
all
of
that
and
we've
repeatedly
heard
that
people
miss
those
options
and
that
they're
not
discoverable
and
yeah.
F
In
the
middle
of
everything
in
the
page,
it
really
doesn't
yeah
bring
them
up.
Basically,
and
and
also
one
thing
that
we
were
discussing
today
and
this
week
is-
is
making
users
aware
of
best
practices.
So,
for
example,
there's
the
option
of
not
forcing
people
to
fix
security
vulnerabilities
or
fix
a
failing
pipeline.
You
can
there's
an
option
in
the
project
settings
where
you
can
say.
F
I
want
to
allow
merge
requests
with
failing
pipelines
to
be
merged,
but
we
want
to
encourage
users,
or
at
least
let
them
know
that
hey
you're
merging
this,
but
be
aware
that
there
are
security
vulnerabilities
or
that
your
pipeline
is
failing.
You
can
still
merge,
but
hey.
We
encourage
you
to
look
into
those
things
so
that
you're
not
making
a
wrong
decision.
Basically
so
yeah,
it's
a
lot
of
things
coming
together
and
then
yeah
we're
exploring
this
model
approach
first,
but
we'll
see.
D
D
Okay,
so
this
is
super
tactical,
I'm
just
thinking
about
patterns-
and
I
know
you've
got
a
lot
of
different
options.
You're
exploring
here
and
obviously
y'all
have
given
this
a
ton
of
really
deep
thoughts.
So
thank
you
for
that.
I
think
we've
done
user
research
on
the
split
button
drop
down
and
jerick
the
ux
showcase
on
that.
So
that's
something
I'd
want
to
really
be
aware
of
the
results
of
that,
and
then
I
see
us.
D
D
A
Yup,
that's
a
really
good
point
and
actually
on
my
previous
design,
I
was
using
this
built
drop
down
buttons,
the
first
time
and
after
watching
the
showcase
and
then
okay.
Maybe
I
need
to
rethink
about
this
approach
and
maybe
yeah,
so
I
slightly
changed
the
design
after
watching
the
showcase
and
also
agree
with
the
idea
of
adding
more
guidance
on
the
mobile
usage,
because
I
also
I
was
considered
at
first
time.
A
I
probably
it's
better
to
use
the
right
drawer,
because
I
know
that
we
have
that
pattern
in
the
different
section,
but
probably
it's
better
to
use
modal.
So
I
just
decided
to
go
for
modal,
but
if
we
have
more
guidance,
I
think
it
should
be
really
helpful
for
the
product
designer
which
component
to
choose
when.
D
Yeah,
I
think
my
my
gut
reaction
on
this
is
because
I
went
back
and
read
the
re-read
the
modals
documentation
the
other
day.
Just
again,
I'm
seeing
so
many
modals
lately
and
we've
got
some
really
specific
guidance
in
there.
But
I
feel
like
this
is
the
perfect
opportunity
to
actually
pull
the
ux
foundation's
team
in
and
they're
not
geared
to
help
solve
your
use
cases,
but
they
are
geared
to
help.
You
say
like
am
I
thinking
about
how
I
am
using
patterns
in
my
use
case
in
the
right
way
consistently
throughout
the
product.
C
D
F
Okay,
yeah,
I
just
I
just
wanted
to
to
know
if
you
could
go
back.
What
would
you
have
done
differently
in
this
in
this
process?.
A
Well,
I
think
probably
I
can
use
a
moderator
test
earlier
so
that
we
can
also
validate
this
idea
in
the
earlier
phase.
Of
course,
I
did
some
casual
coffee
chat,
look
like
interview
with
the
guild
lab
developers,
but
that
was
like
synchronous
meeting
and
it
took
some
time
and
I
was
really
surprised
like
how
we
could
easily
get
the
result
from
the
user
testing.com.
F
Yeah
that
that
makes
sense
yeah
that
that,
for
me,
that
was
also
something
that
you
mentioned
in
the
beginning,
and
I
think,
if
we
had
done
that,
a
little
bit
more,
that
could
have
sped
up
the
the
process.
So,
thanks
for.