►
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
I'm
playing
around
with
new
video,
I
apologize
if
it
doesn't
look
great
so
talking
about
today,
merge
requests
how
to
identify,
merge,
requests
that
may
warrant
attention
just
quickly.
A
We
did
a
little
lily
and
I
did
a
little
preview
of
the
slides,
we're
not
going
to
go
over
slides,
but
I
do
want
to
touch
on
what
are
we
trying
to
accomplish
increase
merge
requests
per
month,
reduce
time
to
merge
and
also
do
the
above
efficiently
without
creating
low
value,
work
or
busy
work,
aka
busy
work
for
engineering
managers,
so
we've
got
a
document
with
a
number
of
questions
that
after
people
look
at
the
slides
in
the
video.
A
So
with
that
I'll
turn
it
over
to
the
first
question,
which
is
from
which
is
from
seth,
let's
see,
is
seth
on
no
does
some
of
you
want
to
verbalize
for
seth.
B
Sure
I'll
verbalize
besides,
mr
account,
is
there
any
way
to
understand
how
impactful
or
valuable
these
mrs
are
not
all
mrs
deliver
the
same
value.
One
very
challenging
mr
may
deliver
several
x
several
times
the
values
of
a
bunch
of
small
ones.
A
So
thanks
everybody,
so
I
think
I
think
that's
a
great
question.
So
what's
the
value
of
an
mr,
I
think
that
I
put
some
notes
in
here.
You
know
what
is
the
you
know,
knowing
what
the
value
of
an
mr
is
is
important,
whether
it's
something
idle
or
otherwise
kind
of
tagged
for
may
need
attention
or
not.
So
perhaps
one
way
is
the
number
of
upvotes.
But
what
does
everybody
else
think.
C
I
have
concerns
about
the
last
line
there,
the
one
very
challenging
mr
may
deliver
x
value
of
a
bunch
of
small
ones.
That
to
me
implies
that
the
mr
is
too
big
right
that
there's
probably
too
much
going
on.
We
want
them
to
be
the
smallest
possible
increment,
but
it
might
be
over
analyzing.
This
comment,
aside
from
that,
I
I
don't
know
how
we
could
justify
impact
or
weight.
I
think
that
would
be
fairly
subjective,
so
I
I
don't
know
that
we
can
measure
this.
A
D
C
D
Yes,
sir,
we
have
a
lot
of
automation
built
on
the
issue
side
around
that
deliverable
label
the
milestone,
advancing
and
then
applying
like
missed
labels.
D
Miss
13,
1,
miss
13
2,
so
combining
those
with
like
okay,
here's
an
issue:
that's
had
an
mr
open
for
for
two
releases
right
and
it's
directly
related
to
something
we're
trying
to
deliver
and
so
being
able
to
dial
those
in
and
understand.
D
E
E
D
On
our
team,
that's
not
the
case
though
we
have.
We
have.
We
have
two
giant
buckets
of
work.
Every
every
release,
one
bucket
comes
from
the
product
team
and
the
in
the
things
that
they
want
to
see
and
the
other
bucket
of
work
comes
from
other
teams
needing
things
like
new
gems
or
from
the
security
team.
They
need
a
new.
E
D
Not
from
a
product
perspective
again,
we
use
the
deliverable
label
specifically
to
work
with
product
to
help
us
understand
that
these
are
things
that
we've
agreed
to
with
the
product
team
and
then
again
we
use
that
automation
each
month
to
help
us
sort
of
gauge.
You
know
how
many
things
are
we
rolling
over?
What's
our
say,
do
ratio
look
like
there's
other
things
that
we
can
derive
from
things
that
we
specifically
label
as
as
a
deliverable
issue.
A
Can
we
do
it
become
sorry?
Can
we
do
a
quick,
zoom
style
pull
with
using
reactions?
Does
your
team
generally
put
the
deliverable
label
on
mrs
for
the
if
they
are
part
of
something
that
is
deliverable
or
not?
So
if
you
are,
please
put
it,
give
it
a
thumbs
up
via
zoom.
A
So
I'm
seeing
I'm
seeing
zero,
so
we
know
it's
at
least
one,
but
it
sounds
like
we're
not
doing
it.
We're
not
doing
it
consistently
so,
which
is
not
not
not
good
or
bad
just
is,
but
there
were
some
other
comments
from
others.
B
Thanks
daniel,
I
was
just
gonna
say
that
there's
so
much
flexibility
in
the
way
we
all
work
that
it's
really
hard
to
find
one
thing,
one
one
I
don't
want
to
say
the
wrong
word,
one
thing
that
would
probably
address
all
of
our
concerns,
but
I
did
want
to
bring
up
the
fact
that
if
an
mr
is
really
old,
it's
possible
that
the
code
is
stale
and
it
would
need
to
be
closed
or
addressed
quickly.
A
Yeah
good
point
dave
you
you
got
interrupted
twice,
apologies.
Did
you
get
to
verbalize,
you
wanted
to.
E
Yeah
on
that
point
I'm
happy
I
was.
I
had
a
question
that
I
actually
put
in
the
document
around
this
discussion,
which
is
got
a
little
sidetracked.
I
I
think
in
general
on
the
deliverable
label.
I
don't
really
see
it
as
necessary,
necessarily
directly
and
only
exclusively
related
to
workers
product.
E
In
my
mind,
at
least
it's
whatever
we
plan
to
deliver,
regardless
of
where
it
comes
from,
and
our
say
do,
is
it's
not
related
to
whether
product
asked
for
it
or
not?
E
It's
whatever
we're
prioritizing
in
the
cut
line
for
our
ems
in
my
head,
I'm
not
saying
anyone
else
has
to
do
that,
but
the
question
I
have
what
comes
up
for
me
and
this
original
comment
from
seth
is:
how
do
we
define
value
in
the
context
of
mrs
because
I
I
don't
think
stephen
to
your
point
that
the
work
you're
all
doing
to
help
the
the
keep
the
lights
on
as
it
were,
is
any
less
valuable
than
the
work
you're
doing
to
deliver
on
product
priorities,
it's
just
as
valuable.
E
D
Yeah
for
us
it's
more
about
scheduling,
right,
there's
things
we
know
about
that.
We
have
to
do
that.
We
have
heads
up
from
from
the
product
team
we
sit
out
and
talk
about.
You
know
upcoming
initiatives
and
then
there's
other
work
that
we
really
don't
know
about
until
someone
else
completes,
maybe
a
deliverable,
and
they
discover
that.
Oh,
I
need
a
new
component
in
omnibus
or
some
other
configuration
change
or
a
new
correct.
A
common
one
is
hey.
I
need
a
new
configuration
directive
in
omnibus
so
that
we
can
turn
something
on
and
off.
D
We
don't
need
we're,
not
usually
even
aware
of
that
until
some
of
the
work
ahead
of
it
is
completed
and
again
the
product
folks
never
see
that
for
us
it's.
The
deliverable
thing
is
more
about
communicating
to
product
that
this
is
the
set
of
issues
that
we
intend
to
complete
on
a
schedule
as
a
planned
item
versus
things
that
that
sort
of
just
happened
to
us.
E
Yeah
that
totally
makes
sense.
I
think
different
teams
are
going
to
have
different
workflows,
depending
on
how
much
sort
of
like
reactive
work
they
have
during
a
milestone.
Yeah,
that's
what
you're
saying
is
that
correct.
E
But
I
guess
I
guess
again
just
I
think
I'm
belaboring
a
little,
so
I
want
to
stop
talking
because
wayne's
call
out,
but
I
think
there's
just
as
those
mrs,
regardless
are
just
as
valuable,
whether
they're
scheduled
or
not
I'll
leave
it
to
wayne.
Sorry
great.
A
Discussion
interesting
topic
a
little
bit
off
topic
from
what
we're
trying
to
discuss
today,
but
still
very,
very
important,
so
thiago
who's
not
on
right.
Now,
of
course,
is
it's
it's
his
time
as
what
are
some
of
the
actions
we're
looking
for
from
engineering
managers
when
they
receive
the
triage
email?
The
list
of
mrs
that
might
might
require
attention.
A
A
F
D
A
D
B
I
was
actually
gonna
comment
on
the
last
item.
I
was
trying
to
read
through
all
the
comments
I
like
it
when
I
get
a
triage
email,
and
it
tells
me
to
ask
questions
like
okay
check
on
this
think
about
this.
B
You
know
not
necessarily
tell
me
what
to
do,
but
just
give
me
ideas
of
things
that
I
should
look
into,
because
even
on
the
same
team
for
different
mr's,
there
could
be
different
reasons
why
it's
open,
and
the
next
item
was
so
what
I
usually
do
when
I
get
the
triage
email
I
go
in
into
the
triage
issue
and
in
parentheses
I
add,
I
mentioned
the
engineers
names
so
that
they
and
they
are
they're
all
aware
of
this
issue
and
how
it
works
anyway.
So
they
know.
Okay.
A
F
F
G
A
A
Okay,
you
know,
as
long
as
you
don't
listen
link
to
the
issue.
The
item
direct
the
issue
directly.
It
doesn't
update
right
yeah,
that's
something
we
were
definitely
the.
I
should
say
the
mr
directly
doesn't
do
that,
so
I
did
a
little
copy
and
paste
from
the
slides
which
of
these
should
we
pursue
and
with
what
priorities.
So
you
know
I
added
these
are
just
thoughts
that
lily
and
kyle,
and
I
and
others
who
commented
you
know
prior
came
up
with
of
potential
things
to
do
so.
A
Let's
see
maybe
use
the
zoom
or
video.
You
know,
give
a
thumbs
up,
asking
engineering
manager
so
basically
making
the
idol
the
idol
triage
issue
and
the
sightseeing's
dashboard
part.
You
know
codify
that
in
the
handbook
saying
that
is
something
we
want
engineering
managers
to
do
periodically
to
their
own
based
on
their
own
needs,
but
basically
it
added
to
the
handbook
good
idea,
not
a
good
idea.
Let's
see
a
thumbs
up
on
if
it's
a
good
idea.
E
Yeah,
I
was
just
I
was
kind
of
doing
this
already
with
package
group.
While
I
was
still
managing
that
team,
we
had
a
spreadsheet
using
the
api,
which
is
all
public
apis,
and
we
were
looking
at
mrs
that
were
sitting
around
too
long
and
asking
people
what
was
going
on
they're,
just
following
up
pretty
regularly
with
the
team
anyway,
which,
which
is
pretty
much
the
equivalent
of
the
triage
email.
E
So
I
agree
with
that
that
we
should
be
actually
having
an
action
item
that
we
should
care
about
these
things
just
to
at
least
acknowledge
the
work
that
people
are
doing
and
if
it's
not
valid
anymore
great,
just
close
it
no
big
deal.
It's
not
it's
not.
I
don't
think
there's
any
negative
side
effect
from
closing
an
mr.
That's
no
longer
relevant.
So
I'm
in
favor
of
that.
H
Actually,
there's
a
lot
of
positives
cleaning
up
and
closing
out,
mrs
just
otherwise
we'll
have
over
time,
it'll
become
a
problem
and
people
run
across
it
and
they
think
something's
happening
when
there's
no
activity.
A
A
The
dashboard
shows
idleness
and
a
number
of
other
characteristics
that
just
encourage
questions
to
be
asked
or
not
necessarily
issues,
often
not,
but
just
questions
to
be
asked.
So
should
we
add
things
from
the
dashboard
to
the
triage
issue,
so
it
detects
more
than
idleness,
but
other
things.
B
I
had
a
question
on
that.
I
thought
you
couldn't.
I
thought
there
was
certain
data
that
was
not
available
to
us
in
the
issue
but
was
available
on
the
dashboard.
A
Yeah,
it's
definitely
the
case.
We
could
get
the
data
from
sisense
rather
than
from
the
gitlab
api.
For
some,
some
of
the
things
are
in
the
gitlab
api.
We
could
add
some
things
we
can
get
from
sci-sense,
but
we'd
rather
not
do
that.
We'd
rather
enhance
the
api,
because
if
we
need
it
likely,
you
know
users
need
it.
So
it's
definitely
not
easy
to
add
other
things,
many
of
the
other
things,
but
some,
but
that
doesn't
mean
we
shouldn't
do
it.
You
know,
if
they'd
be
very
valuable.
I'd
still
like
to.
B
A
So
I'm
gonna
skip
c
and
it's
just
an
idea
and
a
lot
of
work
ideas
about
about
using
machine
learning
trends,
so
adding
a
number
of
adding
no
I'm
going
to
actually
skip
v2,
let's
individually.
Let's
talk
about
it,
so
e
you're,
using
a
label
for
intentionally
like
one
pattern
that
I
wasn't
aware
of,
is
that
some
merge
requests
are
intentionally
idle,
they're
out
there
for
test
purposes
etc,
and
they
still
show
up
in
the
idle.
A
The
idle
merge
request,
triage
issue,
it's
mouthful
and
you
know
it
encourages
people
to
ignore
it
or
to
close
out
the
merge
requests,
and
they
really
didn't
want
to
do
that,
so
it
stopped
showing
up.
So
should
we
have
a
intentionally
idle
flag
so
that
the
tree,
so
I'm
seeing
some
nodding
jake
you
wanna
verbalize,.
G
Sure
yeah
most
of
the
issues
that
are
the
merge
requests
that
the
triage
issue
has
raised
for
for
my
group,
the
per
I
you
know
contact
the
author
and
they're
like
oh
yeah,
I'm
just
keeping
that
open
as
an
alternative
path
that
I
might
take
or
as
for
for
discussion,
I
think
there
is
some
value
in
that
workflow
of
like
having
something
that
you
can
just
sort
of
have
and
your
teammates
can
comment
on
it
and
things
like
that.
They
can
see
what
you're
working
on.
I
sort
of.
G
I
think
I
agree
with
christopher
that
over
the
long
term
it
can
create
mess
and
if
those
things
don't
get
cleaned
up
after
they're
no
longer
relevant.
You
know
that
that's
where
you
want
to
do
some
cleanup,
but
that
might
be
on
a
much
longer
time
frame
than
we
would
consider
a
healthy.
Like
start
to
finish,
for
a
merge
request
that
was
delivering
something.
So
I
think
a
label
might
be
a
good
way
to
you
know
to
deal
with
that
and
still
allow
us
to
clean
things
up,
while
supporting
that
workflow.
C
This
one's
good,
I
agree.
I
have
a
couple
engineers
who
use
mrs
to
organize
their
thoughts
and
they
are
intentionally
idle
because
it
might
be
something
we're
not
going
to
look
at
for
a
while,
and
they
just
want
to
kind
of
tinker
with
their
spare
time
if
they
want
a
context
switch
from
what
their
weekly
daily
job
is
right
and
what's
the
alternative
for
them.
C
If
they
can't
use
this
process,
they
have
to
come
up
with
another
one
or,
as
one
of
my
engineers
said,
I'd
have
to
use
notepad
or
something
to
store
it
somewhere
else.
So
this
further
encourages
gitlab
usage,
and
if
we're
you
know
constantly
pinging
them
like
hey
close
this
move,
this
do
something
they
might
not
be
as
excited
to
use
gitlab.
C
A
This
seems
like
a
an
easy
win:
it's
important
process
overall,
dan
and
clement
getting
to
add
before
on
this
one.
Before
we
move
on
to
see,
if
some
comments.
E
Yeah,
I
was
just
I
was
suggesting
workflow
label
intentionally
idle
or
idle,
and
then
it
would
just
be
able
to
align
with
how
it
is
in
the
workflow.
But
I
don't
really
mind
if
people
use
whip
instead
seems
to
be
a
good
way
to.
I
We've
overloaded
labels
a
lot
and
further
adding
yet
another
label
for
a
use
case
where
we
have
alternative
conventions
like
draft
or
whipped,
and
the
work
and
the
mr
title
could
achieve
the
same
thing
without
getting
it
into
the
solid
bar
of
labels.
We
have
on
the
right
rail
so
because
is
there
a
convention
we
can
introduce
in
the
title
that
would
make
this
more
easily
scannable
or.
A
Should
we
I,
like
the
idea,
should
we
not
consider
work
in
progress
and
draft
ones
at
for
idleness?
Basically,
if
it's
work
in
progress
or
draft,
don't
look
at
it
as
don't
consider
it
right
on
this.
Would
that
be
a
good
way
to
go?
There's
no
change
in
process
for
people
and
how
they
work
with
the
mrs.
It's
just
that
we
change
people
be
in
favor
of
that.
B
The
only
problem
I
have
with
titles
is
it's
hard
for
searching
if
you're
searching
through
issues-
and
you
have
if
you're
searching
on
the
title,
you'll
likely
correct.
The
performance
is
a
little
bit
better.
So
labels
have
better
performance
when
searching.
A
We'll
we'll
think
about
this
and
come
up
with
something
an
improvement.
Iteratively,
it's
good
stuff
effigy.
I
don't
know
if
anybody
wants
to
discuss
those,
my
guesses,
those
are
kind
of
future
things
and
probably
not
on
making
things
like
this
part
of
the
product
itself.
I
think
one
product
manager
was
interested
in
this
in
the
past
that
haven't
heard
from
that
person
recently,
but
that
doesn't
mean
they're,
not
just
they're
busy
and
potentially
writing
a
blog
article
about
this.
You
know
in
the
gitlab
blog
about
just
our
findings.
A
F
Yeah
I
linked
to
an
issue.
I
welcome
feedback
and
ideas.
There's
a
number
of
proposals
on
some
simple
solutions
that
are
out
there.
It's
a
problem
affecting
a
lot
more
than
idle,
so
the
scope,
I
would
say,
is
beyond
just
idle
idle.
Mrs
and
right
now
I
would
say
this
isn't
prioritized
for
the
team
kind
of
looking
at
work.
That's
more
aligned
with
our
okrs
for
q3,
but
if
it
is,
if
it
is
a
problem
in
multiple
different
different
facets,
that's
where
I
can
look
to
re-prioritize
it
for
the
team.
A
Yeah
and
yeah
it's
taken
a
lot
of
manual.
I've
also
gone
through
a
lot
of
them
and
tried
to
manually
clean
them
up
when
they're
staged
and
not
group
or
group,
and
not
stayed.
Sometimes
the
automation
is
not
able
to
catch
those
there's
quite
a
few
that
have
neither
and
it
I
think
it's
just
built
up
over
the
years,
and
it
needs
a
manual
cleanup
as
well.
F
Yeah
one
of
the
things
we're
pivoting
to
on
the
ep
team
is
we
look
at
unlabeled
issues
in
the
quality
department
and
we're
trying
to
shift
that
to
be
on
what
we
call
untriaged
issues
so
any
issue
without
a
type
group,
and
if
it's
a
bug,
a
severity
label
would
end
up
end
up
in
a
triage
report
that
the
quality
department
triages
every
day
to
apply
to
kind
of
meet
that
minimum
level
of
completeness
that
that
should
hopefully
catch
this.
But
it's
not
a
focused
effort.
A
That's
great
and
interesting
time
we
don't
drop
down
to
5b
so
I'll.
Just
so,
could
we
add
a
trendline
to
the
dashboard
lily?
That's
a
great
question
for
you.
J
E
I
think
I
think
what
I'm
trying
to
look
at
for
look,
for.
There
is
good
signal
like
are
we
doing
a
better
job
overall
or
over
time?
Are
we
doing
a
worse
job
and
when
you
add
in
the
unlabeled
issues
or
mrs,
it's
actually
really
tough
to
pull
out
the
signal
from
the
noise?
It
looks
like
we're
trending
down,
so
I
think
that
relates
to
the
other
question
of
just.
Could
we
clean
up
the
data
to
make
it
a
little
clearer,
what's
actionable
and
how
we're
doing.
A
And
then
dan,
you
want
to
verbalize
your
next
one,
yeah.
E
I
was
just
sort
of
following
up,
and
then
I
was
asking
also
subsequently
about.
Does
it
make
sense
to
have
stuff
in
that
report?
That's
not
actionable.
I
think
it's
important
to
know
that
we
have
350
sitting
out
there
that
haven't
been
labeled
in
a
way.
That's
like
good
and
good
for
us
to
clean
up
and
take
action
on
super
helpful,
but
is
it
actionable
for
for
engineering
managers
to
know
about
those,
I
would
say,
probably
not.
A
Not
until
we
figure
out
what
who
who
the
dri
would
be
on
deciding
if
they
should
be
closed
or
they
should
move
forward
and
if
so
and
yeah
it's
my
suspicion
was,
is
a
number
of
them
were
abandoned
community
contributions,
but
that's
been
studied
as
not
the
case.
I
found
a
handful
like
that,
but
that's
not
that's,
not
the
large
number
of
them
the
so
I'd
want
to
do
a
one
round
of
manual
cleanup.
A
A
It's
not
perhaps
removing
the
report
because
they're
not
they're,
definitely
not
actionable
for
engineering
managers.
So
I'm
going
to
skip
d
and
go
to
e
lily
and
I
can
work
out
d
e
craig.
Do
you
want
to
verbalize.
C
Yeah,
I
have
another
note
after
this
one,
so
past
companies
I've
worked
at,
we
had
a
timeline
and
we
would
just
go
through
and
close
issues
and,
mrs,
if
they
exceeded
you
know
six
months
a
year.
Whatever
the,
however
deep,
your
backlog
is,
will
depend
on
the
timeline
and
if
you
close
it
and
you
get
no
response,
it's
a
win.
If
you
close
it
and
you
get
a
hey,
what
the
heck
I'm
still
working
on
this,
it's
still
a
win,
because
then
you
can
engage
that
person
and
say:
okay!
C
Well,
you
know
we'd
like
to
see
some
more
information.
Add
some
labels
free
baseline
whatever.
So
I
think,
I'm
fully
in
favor
of
doing
something
like
this
and
then
to
your
point
about
having
350
mrs
other
companies.
C
I've
worked
at
we've
had
bug
scrubs
triage-a-thons,
where
you
just
got
a
group
of
people
together
and
just
ran
through
them
in
a
couple
days,
and
it
was
kind
of
painful
for
those
couple
days,
but
the
benefits
paid
off
for
a
long
time
after
that
to
clear
out
the
backlog
of
issues
and
mrs
that
were
lingering
past,
a
certain
timeline.
So.
A
Yeah
lots
of
people
are
dan,
did
something
similar
earlier
and
a
lot
of
people
seem
in
in
favor
of
this,
including
me.
What
I've
done
is
I've
closed
it,
a
really
old
one's
like
that
hadn't
been
touched
in
years.
He
said,
I'm
closing
it
if
you
disagree,
feel
free
to
reopen,
and
I
did
that
on
about
30
or
40,
really
old
ones,
and
people
commented
on
one
or
two
and
reopened
them,
which
is
great.
That
actually
was
a
great
triage.
A
But
if
you're
nice
about
the
comment,
when
you
close
it
as
to
why
and
feel
free
to
reopen,
then
it
it
tends
to
work
pretty
well
yep.
A
I
know
we're
over
on
time,
there's
no
number
six
unless
there's
any
thing
we
missed
or
that
we'd
like
to
go
back
to
or
anything
else.
I
think
it's
been
a
great
discussion.
I
think
we're
done
anything
else.
We
want
to
discuss.
A
Thanks
everyone
lilly
and
kyle,
and
I
will
look
at
all
these
great
notes
and
ideas
and
look
to
improve
things.
Interestingly,.