►
From YouTube: CI UX recommendations for Merge Requests part 1
A
Here
we
go
all
right.
Thanks
in
preparation
of
this
meeting,
I
created
a
mural
board
with
that
we
can
do
a
little
bit
of
visual.
You
know
prioritization
direct
things
around
and
in
that
way
and
up
with
the
list
that
we
want,
the
idea
is
that
we
can
create
a
list
of
at
least
a
top
three
items
that
we
want
to
schedule
as
soon
as
possible,
but
additionally
find
out.
A
A
So
you
will
see
this
thread
being
generated
and
when
we
go
down,
we
can
see
hey.
These
issues
are
to
be
converted
into
the
following
format
and
say:
hey
this
issue.
We
put
a
milestone
on
it.
It
can
also
be
backlog,
but
we
should
give
a
reasoning
so
like
hey,
why
can
we
not
you
know,
schedule
this
directly
or
hey?
We
need
additional
work
on
this
or
hey.
A
It
is
not
important
or
whatever
our
reasoning
is,
and
the
idea
is
that
we
at
least
you
know,
come
up
with
like
a
list
of
three
issues
that
we
are
intending
to
schedule
ideally
seen
and
hear.
Inside
of
the
comments,
I've
created
a
neural
board,
which
you
can
see
here
so
I
would
love
for
you
to
join
here
and
then
the
meeting
from
this
point
onwards
will
happen
inside
the
mural
board.
B
A
So
here
we
have
like
the
little
little
buttons
that
we
can
put
on
the
issue
themselves
and
here
on
the
right
side
and
now
they're,
not
fancy
sticky,
sticky,
post
notes,
but
ideally
they're
kind
of
the
same
thing
without
color,
and
we
can
kind
of
point
them
around
in
here
and
see
which
ones
are
the
most
important.
So
I
suggest
we
have
around
25
minutes.
A
B
C
A
See
that,
like
I
thought,
you
were
anonymously
Lincoln,
but
it
has
your
initials,
that's
good,
so
to
go
over
what
this
is
a
little
bit
before
we
dive
into
this.
Is
these
are
all
issues
selected
by
me
that
have
some
correlation
towards
the
merge
quest,
widget
or
the
merge
request
page,
and
in
that
case,
some
of
these
issues
will
cover.
Of
course,
the
category
merge
trains,
as
there
is
improvements
to
be
made
there.
Why
are
we
doing?
A
This
is
this
is
because
we
want
to
aid
the
queue
to
UX
OPR
that
intends
to
up
the
lovability
around
merge
quest.
This
has
now
physically
by
our
CEO
and
leadership
and
I.
Think,
especially
from
a
CI
perspective,
we
can
makes
an
impact
and
improve
on
some.
You
know
much-needed
items
regarding
pipeline
squillion,
emergence
widget.
A
B
A
A
The
much
way
did
give
some
Bish's
right
instructions.
This
was
recently
created
by
Marcel
Marcel's
by
the
way,
the
one
that
kind
of
pushed
this
effort
forward
to
begin
with,
but
from
a
create
perspective,
and
now
we're
doing
it
from
a
verify
and
release
perspective.
So
we
recently
inherited
the
merge
train
category
as
part
of
continuous
integration.
I
do
not
know.
How
is
this
been
so
recent?
How
much
and
dive
into
that
category
so
much
doesn't
know.
I.
D
B
Of
the
20,
some
issues
that
are
out
there,
I
have
one
issue
scheduled
for
next
milestone
and
then
I
think.
Just
recently,
Shinya
did
a
technical
handoff
to
the
engineers
on
CI
team,
but
we
haven't
been
in
the
code
yet
yeah
the
so
we
have
one
issue
just
start
doing
some
changes
in
March
change.
Next,
milestone,
which
issue
is
up.
B
Is
the
one
I
can
get?
The
issue
number
give
me
a
second:
it's
it's
in
the
planning
issue
for
or
13.2,
but
it's
to
provide
notification
when
an
EMR
is
dropped,
because
right
now
the
user
has
no
idea
when
lurching
drops
there.
Mr,
and
so
it's
it's
kind
of
a
an
emergency
fix
on
a
really
bad
user
experience
that
I
was
getting
pinged
on
in
slack.
B
B
Yeah,
that's
the
one
it
adding
or
removing
that
you
do
task
the
the
adding
of
it
is
to
solve
under
problem
description.
There's
no
notification
that
the
user
to
the
user
when
mr
is
dropped,
so
they
actually
Shinya
created
the
title
as
the
solution
to
the
problem.
The
segment
there
instead
of
stating
the
problem
at
the
time.
E
A
A
A
B
Engineer
has
has
reviewed
this
and
weighted
it
so
Marius,
because
I
added
it
as
a
weighting
issue
in
our
current
milestone,
13.1
in
anticipation
that
I
wanted
to
implement
in
13.2.
So
he
looked
at
it
a
week
ago
added
a
weight
of
two
and
made
a
comment
that
says
I
think
and
then
he
named
a
a
code
area.
B
B
B
A
Alright,
so
we
have
the
next
one:
I'll
put
it
here
underneath
the
little
buttons
at
the
top
merge.
We
did
gave
some
Big
E
Sui.
So
that's
the
same
one
we
were
at
just
a
minute
ago
with
this.
The
idea
is,
let
me
see
when
a
project
has
merge
strains
enabled
the
initial
state
of
the
merge
button
widget
after
merge
request
has
been
created,
contains
contradictory
information.
A
The
primary
button
here
is
start
murdering
when
pipeline
succeeds
just
a
couple
of
pixels
further
below
the
UI
states.
This
merge
request
will
start
a
merge
strain
when
pipeline
blahblah
succeeds.
I'm,
not
sure
whether
that
now
means
that
I
have
to
press
the
button
to
start
the
merge
drain
or
if
it
has
already
been
activated
in
Dimitri
I.
Can
there
I.
C
A
A
Points
us
at
the
documentation
for
severity
and
I
said.
Let
me
see
broken
feature
in
the
functional
row,
broken
feature.
We
don't
expect
an
accepted
lis.
Complex
workaround
uses
the
metrans
than
to
work
around
them
likely
to
ask
for
support
versus
severity.
Three
broken
feature
with
a
workaround
use
ourselves
sufficient
in
completing
the
task
with
the
workaround.
However,
it
can
cause
significant
delays.
Maybe
this
is
more
of
an
s3,
though.
What
do
you
think.
A
D
A
Links
us
to
the
general
severity
and
priority
label
triage
documentation
as
I've
been
pushing
for
you,
except
to
be
triage,
the
same
way
as
bugs,
and
there
will
be
soon
some
requests
that
improve
on
those
documentation
a
little
bit.
But
mostly
the
idea
is
to
look
at
this
issue
at
this
row,
which
is
the
functional
row
which
applies
to
user
experience
and.
D
A
B
A
B
A
A
B
B
A
Shittaka,
could
you
help
me
out
with
the
like
this
thing,
which
channel
have
highlighted
within
the
mini
early
document?
These
are
all
issues
we
still
need
to
convert
to
the
little
like
nice
nicely,
formatted,
thumbnail,
rich
links,
I,
don't
know
how
you
want
to
call
them
if
you
take
like
the
bottom
part
here,
shuffle
them
to
the
right
side
and
I'll
do
the
left
side.
C
A
A
A
A
Work
alongside
with
us
in
this,
the
idea
I
have
is,
as
we
have
shuffled
them
around,
even
though
it's
like
incomplete
and
not
as
cross-functional
as
we
want
it
to
be.
Probably
the
most
important
items
are
gonna,
be
here:
you're
somewhere
towards
the
right
top
corner:
let's
discuss
those
ones
and
then
we
can
probably
fit
it
in
within
the
next
10
to
15
minutes,
and
then
in
that
way,
and
not
extend
this
meeting
by
more
than
half
an
hour
sounds
okay,
yeah.