►
From YouTube: Overview of merge requests that may warrant attention
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
So
lily
and
I
are
going
to
give
a
quick
overview
of
identifying
merge
requests
that
may
warrant
attention,
we're
not
going
to
go
through
all
the
slides,
just
the
ones
avenue.
So
what
are
we
trying
to
accomplish
increasing
merge
requests
per
month,
reducing
time
to
merge,
especially
starting
ones
that
take
more
than
a
month
to
merge
and
doing
this
efficiently
without
creating
low
value
work
for
engineering
managers?
A
So
the
idle
merge
request.
Triage
report
has
been
in
use
for
a
month
or
so
now
and
it's
been
getting
good
feedback
from
the
engineering
managers.
It
finds
merge,
requests
that
are
open
and
have
been
not
touched
by
a
person
in
more
than
four
weeks,
and
then
it
creates
a
little
triage
issue
that
tags
the
engineering
managers
for
that
group
and
links
to
the
issues
so
that
it's
a
way
to
give
a
heads
up.
A
That's
that
something
may
need
attention
and
it's
definitely
helped
to
reduce
the
I
o
merge
requests
and
then
lily's
and
group
have
also
created
us
a
new
sisense
dashboard.
So
I
want
to
turn
over
to
lily
and
we'll
give
you
a
quick
overview
of
that.
B
Yeah,
so
we
created
this
dashboard
so
that
engineering
manager
can
go
in
and
practically
see
how
many
idol
mrs
they
have
currently
the
first
chart
just
tells
you
how
much
we
have
total
and
then
the
second
chart
breaks
it
out
by
stage
the
third
one
is
the
one
that
we
want
to
look
at
to
make
sure
that
trends
are
actually
downward.
Trending.
B
The
third
chart
the
time
series
chart,
and
here
it's
broken
out
by
stage
as
well,
and
you
can
see
the
volume
of
idle,
mrs
that
we've
had
over
time
and
the
next
chart
is
a
list
of
all
mr's
that
we
flagged
and
essentially
wayne
will
go
over
this
in
the
next
slide.
But
we
set
certain
thresholds
for
a
number
of
height
lines:
assignments
files,
change
lines,
change
threads
and
if
they
were
idle
so
that
you
can
managers
and
go
here
in
here
and
click
on
the
specific,
mrs
and
see
why
cool.
A
Yeah
and
where
we
landed
on
this
was
after
analysis
of
things
that
make
mrs
take
much
longer
to
merge.
We
did
some
analysis
and
showed
that
we
have
a
little
tool
tip
here.
So
if
assignments
is
greater
than
10,
it
tends
to
take
a
lot
longer
to
merge
or
pipelines,
greater
than
20
or
etc
threads
greater
than
15
etc.
So,
just
because
something
is
outside
or
is
an
is
an
exception
or
an
outlier
doesn't
mean
that
it's
there's
a
problem.
A
It
means
it's
something
to
potentially
look
into
and
where
ones
are
that
way
where
they've
exceeded
one
of
those
values
is
where
lily's
made
it
in
yellow
and
what
you
could
do
for
perhaps
is
go
to
a
group.
I
don't
know
I'll
pick
on
one
of
my
groups
and
say
you
know,
thread
insights,
say
there
are
these
and
like
this
one
was
listed
because
it
has
more
lines
changed
than
the
ones
that
tend
to
take
less
time
and
also
more
threads
or
this
one.
A
You
know
as
more
pipelines,
files
chains
line
chains
and
threads,
so
that
may
or
may
not
be
something
to
look
into,
but
it
is
something
to
kind
of
take
a
look
at
to
see
if
there's
something
that
should
be
done
differently
on
the
mr,
the
one
of
the
the
reason
why
we
don't
have
this
in
a
triage
issue
yet
is
because
the
gitlab
api
doesn't
have
many
of
these
variables
available,
so
it's
currently
only
available
in
sizes.
That's
something
we're
thinking
about.
A
So
with
that
you
know.
We
also
have
some
more
detail
here
on
the
individual
metrics
that
we
look
for
so
there's
some
limitations,
which
you
can
read.
Of
course,
potential.
Next
steps
just
wanted
to
cover
the
first
one
is
asking
engineering
managers
to
review
the
idle
mr
triage
issue
and
the
sizes
dashboard
periodically,
making
that
part
of
engineering
manager
responsibilities
to
look
for,
merge,
requests
that
may
warrant
attention
and
we'd
like
everybody's
feedback
on
it,
which
is
why
we
are
talking
about
it
first
here
anything
else
to
advil.