►
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
All
right
so
everybody's
here
who
accepted
so
we'll
get
started
so
put
some
notes
and
and
thanks
for
responding
to
them,
looking
over
and
being
kyle
and
I
think
lily
you
did
as
well
looking
at
them
in
advance,
which
is
great,
even
though
I
just
started
updating
those
like
couple
hours
ago.
It
helps
us
move
along
efficiently.
A
B
So
I
think
the
most
resounding
feedback
that
we
got
is
using.
The
reports
is
hard
because
there's
no
leaks
and
that's
something
that
we
are
looking
to
correct
with
the
issue
that
I
linked
to
there's
an
mr
that
open
yup
b.
Sorry,
I
should
have
ordered
them
correctly
and
there's
an
mr
to
fix
that
before
the
next
generation,
which
I
think
runs
on
the
eighth.
A
A
B
A
A
B
So
like
that
was
a
comment
I
think
you
made
so
the
first
one
nudging
merge
requests
without
a
group
label.
I
kind
of
commented
on
this
down
below.
I
think,
instead
of
nudging,
a
better
behavior
here
might
be
to
try
to
just
apply
labels
automatically.
So
I
listed
some
suggestions
down
below
and
this
is
on
a
I'm
sorry
jumping
all
over
the
place,
but
I
have
some
suggestions
on
how
we
could
do
that.
I
don't
think
this
is
a
like
and
to
be
clear.
A
That
being
said,
one
thing
I
learned
last
week
is:
we
are
likely
going
to
have
a
a
kr
kr
that
goes
with
an
o,
an
objective
on,
or
maybe
just
a
metric
in
the
goal
on
percentage
of
merge
requests
that
take
more
than
30
days,
or
something
like
that.
I
heard
that
a
couple
times
in
discussion,
so
that
is
not
officially
something
we
want
to
do
yet,
but
it
is
being
discussed
so
definitely
need
to
keep
track
of.
We
can't
have
you
know
five
number
one
priorities
we
can
have.
A
A
D
A
I
think
the
priority
of
it
might
go
higher.
So
do
you
think
the
he
said
the
most
important
one
was
1a,
you
think,
but
you
said
that
one's
in
flight
already,
so
we
don't
need
to
we're
able
to
get
that
done
even
though
or
get
that
moving,
even
though
it's
not
one
of
our
top
priorities.
Is
that
accurate,
though.
B
One
b
is
in
flight
that
one
should
be
done.
One
a,
I
think,
is
the
next
item
that-
and
this
is
my
perception,
so
I
went
through
the
feedback
prior
to
the
meeting
and
tried
to
identify
what
I
thought
was
the
the
best
representative
feedback
from
what
I've
seen.
I
think
one
a
would
be
the
next
one
where
those
issues
are
invisible
to
the
triage
report.
B
A
A
D
B
B
I
I
just
wanted
to
pull
this
in,
because
I
thought
it
was
conversation.
It
was
like
discussion
that
was
left,
okay,
open,
and
maybe
there
was
a
closed
point.
So
thiago
was
kind
of
talking
about
some
counter
argument,
like
not
counter
arguments
but
just
counter
points
to
some
of
our
assumptions,
and
I
just
wondered
if
we
wanted
to
make
any
changes
based
on
the
suggestions.
A
A
E
A
If
you
click
an
item
number
two,
it
should
show
you
that
so
let's
jump
over
that,
so
I
didn't
see
a
downward
trend.
Yet
you
know
we
can.
Maybe
I
didn't
update
it.
Actually,
that's
not
true.
Okay,
I
did
do
the
update.
It
took
a
little
while
so
I
do
see
it
so
idle.
Mrs,
is
down
to
I'm
going
to
say
in
the
750
range.
It
hasn't
been
there
since
since
late
april.
So
maybe
it's
not
a
trend.
A
A
I
think
I
didn't
wait
for
the
refresh
in
sizes
to
complete,
so
it
is
going
the
right
it
seems
like
the
next
big
thing
to
go
after
is
the
items
that
don't
have
a
group
because
they
don't
have
a
group
that
that's
half
of
them,
roughly
half
yeah,
almost
exactly
half.
That
is
probably
the
reason
that
their
idle
is
that
teams
are
groups,
aren't
tracking
them
because
they're
not
on
their
radar.
Perhaps
it's
a
theory.
E
Wouldn't
that
solve
this
because
we
departed
from
that,
because
there
was
a
lot
of
focus
on
mr
rate
now,
which
is
member
based,
something
like,
and
also
the
cost
efficiency
that
we've
been
focusing
on,
but
that
that
should
help,
though
right,
because
if
you
know
who
the
author
is,
then
we
just
put
their
team
their
product
area
label
on
it.
Yeah.
A
And
if
you
have
that
issue
handy,
if
there
is
one
that
could
be
great,
if
you
could
add
it
yeah,
so
that
would
be
because
yeah
this
is
not
an
idle.
Mr
problem,
this
is
a
mr
problem.
It
just
happens
to
be
it's
a
large
percentage
of
the
idle
ones,
but
yeah
they're
so
and
kyle.
You
had
some
thoughts
too.
B
Yeah
so
mech
on
on
your
first
point,
we
do
have
that
inference
by
author.
It's
just
limited,
so
we
read
in
from
team
yaml
and
there's
some
deterministic
logic
on.
If
you
have
this
listed
in
your
department,
you
this
is
the
label
that's
applied.
I
can
dig
dig
up
that
information,
but
that
logic
is
implemented
at
least
somewhat.
It's
not
a
complete
one-to-one
for
every
author.
B
E
D
B
And
that
that's
where
we're
one
one
more
point
on
that
is
we're
kind
of
limited
in
what
we
can
infer
from
data,
that's
accessible
in
an
api
or
like
that
we
can
consume
in
the
yaml
file.
So
we
haven't,
we
haven't
really.
I
don't
know
how
we
can
digest
that
data
than
make
that
actionable
the
bamboo
data.
A
C
We
actually
had
a
dead
day
where
there
were
no
merges,
which
we
haven't
had
in
a
really
long
time
and
then
also
the
other
one
was
which
wasn't
from
friends
and
family
dude,
it's
the
saturday
after
friends
and
family
day
after
curiously
enough,
but
then
the
other
one
is
is,
is
this
could
be
affecting
it
too?
And
I
just
I
didn't
know,
I
think.
A
A
D
A
C
A
B
Do
so
step
step,
one
that
I
think
we
can
do
like
I'll
create
the
issue
that
mac
talked
about
to
close
the
gap.
Further
from
author
inference,
I
think
we
can
consider
project
like
more
default
project
labeling.
So
when
I
looked
at
the
distribution
that
lilly
shared
in
one
of
the
comments
up
above
I
noticed
there
was
just
a
number
of
projects
where
there
should
be
a
clear.
A
A
A
They
should
be
betting
them
trying
to
use
the
right
word
there
and
if
it's
not
in
their
group,
reassigning
it
right
the
the
unknown.
No
group
means
it's
not
it's
likely
not
on
the
radar,
the
wrong
group.
It
should
get
on
somebody's
radar
and
then,
if
that
somebody
is
the
wrong
somebody,
then
they
should.
You
know,
find
the
right
thing.
B
And
mac
just
to
dive
into
that
a
little
bit
more.
Are
you
talking
about
the
author-based
inference,
so
how
that
works
is
it
leaves
a
comment
that
says:
gitlab
bot
will
leave
a
comment
that
says
I'm
applying
group
ecosystem
based
on
this
person's
group,
so
the
intent
there
is
that
it's
clear
why
that
group
label
is
inferred
so
that,
if
a
participant
in
the
mr
wants
to
change
it
there's
a
signal
to
at
least
change
it.
It
mentions
the
author,
for
example,
right.
E
B
B
You
know
like
groups
clearly,
because
that's
what
that's
what's
being
used
and
then
there's
some
there's
some
gitlab
team
members
who
had
multiple,
so
we
can't
do
a
one-to-one
inference.
There
was
just
a
number
of
exceptions,
as
we
started
to
like
dive
into
that
that
needed
data
cleanup
that
we
just
didn't
pursue
in
the
first
iteration.
Those
can
all
be
things
that
we
pursue,
but
that's
why
I
think
the
default
label
solution
might
be
easier
to
start
with,
because
it
requires
less
collective
action.
E
B
I'll
run
the
default
labeling
too
by
the
team.
They
might
see
a
problem
with
that.
We
already
have
a
number
of
scheduled
pipelines.
This
would
add
one
for
every
single
project,
or
at
least
every
group
and
the
ep
team-
it's
already
a
little
unwieldy,
so
we
have
to
balance
that
trade-off
of
how
much
complexity
do
we
want
in
our
triage
our
batch
triage
process
for
the
benefit
lily?
I
think
you've
been
trying
to
say
something
for
a
while.
So
I'm
gonna
stop
talking
so
you
can
get
in
here.
D
No,
I
just
wanted
to
make
a
comment
from
before
about
how
the
graph
is
displaying
the
number
of
idle.
Mr,
so
basically
we
look
at
for
every
single
week.
How
many
mrs,
are
have
no
activity
in
the
past
28
days,
and
so
that's
charted
pi
week.
So
in
the
past
week
we've
dropped
100
in
total,
so
just
to
clarify
it's
in
the
past
28
days,
we
can
shift
it
to
past
14
days,
as
I
think
kyle.
That's
how
the
code
is
running
right.
The
triage
reports.
B
D
A
I'm
not
saying
I
should
change,
I
was.
I
was
just
remembering
wrong
yep.
Maybe
it
should
change,
but
that's
not
I'm
definitely
not
advocating
that
today,
at
least
cool.
So
five
minutes
left
in
scheduled
time
item
three
which
of
these
metrics.
So
we
did
idle
time,
which
is
great.
There
are
other
metrics.
We
want
to
look
at
and
potentially
add
to
that
triage
report
and
rename
it.
It
would
no
longer
be
about
idle
with
the
idle
and
other
things,
and
so
it
is
statistically
significant.
A
That's
maybe
strong
too
strong
of
a
term,
but
I'll
say
it.
If,
if
the
number
of
various
things
metrics,
like
assignments
pipelines
files
change
lines,
change
threads
are
more
than
x,
then
it's
likely
going
to
be
an
idle
it's
it's
likely
going
to
take
longer
to
emerge
than
we
want
it
to
be.
So
I
know
kyle
you
mentioned
in
the
past
that
for
the
data
that's
available
in
the
in
the
in
the
api,
it's
it's
it's
much
easier
to
enhance
things
versus
if
we'd
have
to
get.
B
My
understanding
is
none,
so
there's
no
way
to
say
for
an
mr,
how
many
assignments
pipeline
and
total
assignments
that
you
can
say
how
many
people
are
currently
assigned.
You
can't
get
how
many
assignments
have
happened
on
the
mr
and
I
might
be
wrong,
but
that's
my
current
understanding
is
all
of
these
things.
I've.
A
B
A
A
You
know
everybody
can
contribute,
but
you
know
we,
you
know
at
least
folks
on
the
you
know
on
our
teams.
May
not
it
may
take
us
a
lot
longer
to
do
it
than
the
teams
who
generally
do
it
and
the
third
is
we
get
the
data
in
the
interim
from
size
sets
which
path
or
paths
seem
the
best
ways
to
go,
maybe
in
the
short
term
and
separate
in
the
long
term,.
E
I'll
chime
in
I'll
vote
on
getting
more
more
facets
and
dimension
on
on
complexity,
I
think
we're
reducing
costs
by
by
a
lot
this
quarter.
If
you
look
at
the
charts
that
the
ept
has,
I
think
that
will
continue
to
go
down
so
calibrate
on
that,
maybe
a
bit
too
early.
I
think
we
should
get
more
data
on
complexity
if
people
are
breaking
down
things
far
enough
or
not,
because
you
know
christopher
wants
to
have
something
on
pipelines.
Another
thing
so
people
to
vocalize.
C
Yeah
I
mean
I
mean
pipelines
is
interesting
because
because
we
pay,
I
think,
two
dollars
per
pipeline,
and
so
there
might
be
cost
considerations
around
that.
But
I
don't
know
if
that
necessarily
relates
to
mean
time
to
merge.
So
I'm
highly
interested
in
seeing
that
one,
but
just
completely
unmotivated
for
this
particular
task.
C
I
think
I
think
mecca's
got
the
right
mindset,
which
is
the
complexity
aspects,
I'm
a
little
hesitant
on
lines
of
change,
because
when
kyle-
and
I
looked
at
this
before-
we
saw
high
variance
with
these
like
crazy,
you
know
1mr,
but
it's
doing
like
the
same
thing
everywhere.
So
it's
you
know
it's
it's
like,
basically
something
that's
with
it,
so
it's
really
hard
to
figure
out
like
just
because
it's
above
a
certain
threshold
that
it's
really
actually
complexity.
That's
the
issue.
E
Sorry,
if
I
interject,
I
think
the
unicorn
here
is
actually
the
level
structure.
That's
changed,
because
you
can
have
multiple
lines:
change
in
just
one
controller
and
that's
not
that
complex,
but
if
people
are
making
changes
in
very
in
a
lot
of
folders,
so
you're
touching
the
control
you're
touching
front
end
you're
touching
database
in
one.
Mr,
that's
the
complexity
we
want
to.
We
want
to
know-
and
I'm
not
sure
if
we
get
that
information
with
this.
Do
you
know
how
like
the
the
list
of
folders
that
were
changed,
not
necessarily
the
files
yeah?
A
B
B
Every
single
one
of
these
things
would
require
significant
time
from
the
ep
team,
so
pulling
it
in
from
psi
sense,
even
pulling
it
in
from
the
graphql.
We
don't
have
a
graphql
adapter
in
our
gitlab
triage
gem
right
now.
It's
going
to
require
a
lot
of
effort
so
focusing
on
one
and
then
saying
team
ep
team.
What
is
the
simplest
way
to
to
get
this
information
in
might
lead
us
to
a
more
creative
solution
than
what
we're
able
to
figure
out
on
the
call.
C
B
Yeah,
that's
what
I'd
recommend.
Let
me
ask
on
graphql
and
then
I
can
ask
the
team
it.
I
know
it's
very
inefficient
and
will
take
a
while.
If
there
is
one
thing
that
you
feel
is
the
most
important
we
can
do,
we
can
track
how
long
it's
going
to
take
and
pursue
that
one
thing,
or
at
least
see
how
long
that
one
thing
will
take
simultaneously.
But
I'd
like
to
pause.
No.
A
Absolutely
absolutely
another
potential
approach
is,
since
the
data
is
in
sense,
is
we
create
some?
We
added
the
dashboard
or
add
a
new
dashboard
on.
You
know
the
top
list
of
them.
So
not
not
not
an
issue,
not
a
triage
issue,
but
a
list
of
you
know
the
list
of
mrs
that
have
assignments
greater
than
10
or
pipelines,
greater
than
20
earned,
etc,
and
that
might
be
a
good,
simple,
boring
solution
first
and
also
low
cost.
A
It's
not
as
good
as
the
triage
issue,
because
it
doesn't
push
it
to
people
to
take
a
look
at
the
ones
that
are
theirs,
but
I
don't
know
lily.
If
that's
something
you'd
want
to
take
on,
but
basically
have
a
list
of
those
in
a
dashboard.
And
then
we
ask
the
engineering
managers
to
look
at
the
ones
that
are
on
that
list
and
it
won't
necessarily
say
who
who's
which
who's
belongs
to
who,
but
it
always
bring
light
to
those.
What
do
you
think.
D
A
A
Thank
you
and
then
it
might
even
be
good
and
we
can
work
on
the
list,
but
you
know
do
it?
Do
it
iteratively
and
you
know
minimal,
viable
change
as
you
go
is
one
idea
would
be
to
have
one
list
of
mrs
that
have
some
property
that
puts
them
flags
them
as
something
to
potentially
look
at,
and
then
you
put
in
the
list
why?
And
it
could
be
more
than
one
reason
it
could
be
because
it's
idle
it
could
be
because
it
has
more
than
x,
threads
or
or
whatever
or
maybe
separate
lists.
B
Maybe
one
more
so
that's
a
really
great
idea.
Maybe
one
thing
to
consider,
because
the
triage
report,
the
non-clickability
of
the
triage
report,
might
be
worth
getting
feedback
from
other
engineering
managers
just
to
see
if
what
we're
doing
in
the
triage
report
should
also
be
on
the
dashboard
where
it
could
be
clickable
and
probably
faster
for
action
from
them.
I'm
not.