►
From YouTube: Manage:Analytics Weekly Meeting 2020-05-26
Description
The Analytics group talks about blockers, "on deck" issues, and cool stuff from the past week.
B
A
A
A
The
first
agenda
item
is
also
mine,
I'm
very
happy
to
welcome
Michael
donor
hours,
new
senior
front-end
engineer
for
the
manager
analytics
team,
so
Michael,
please
introduce
yourself
where
you
were
before
get
lab.
Why
you
wanted
to
try
and
get
lap
where
you
are
located,
and
what
do
you
like
to
do
in
your
spare
time?
Yeah.
C
Sure
hi
everyone
nice
to
meet
you
I,
was
before
good
lab.
I
was
at
square
and
then
paper
space
respectively,
used
to
live
in
San
Francisco,
but
recently.
Well,
it's
been
a
year
and
a
half
now
so
not
that
recently,
but
moved
back
to
Copenhagen
Denmark,
where
I
am
now
I
wanted
to
join
gitlab,
because
I
am
really
fond
of
automation
and
infrastructure
that
just
works
and
has
a
nice
focus
on
user
experience.
C
C
A
A
The
gender
one
item
is
also
mine,
so
I
wanted
to
bring
this
up
in
this
call.
So
the
question
is:
how
can
we
resolve
front-end
and
back-end
dependencies
if
we
have
issues
that
involve
both
front
and
and
back
and
rook
being
scheduled
for
the
say
milestone
so
in
the
past,
I
think
we
already
started
by
agreeing
on
an
API
spec,
which
is
a
good
starting
point
in
my
opinion,
and
that
works
out
pretty
well.
A
Obviously
it's
a
middle
of
the
night,
but
then
he
also
added
some
thoughts
to
this
one.
Maybe
we
could
start
kick
off
the
end
point
with
a
fixture
spec
or
integrating
an
endpoint
that
returns
dummy
or
Kent
data.
This
means
the
front-end
tests
can
be
written
earlier
for
the
components
that
consume
the
data,
so
this
I
think
being
able
to
start
working
on
the
backend
and
the
front-end
part
simultaneously
works
out
pretty
well.
So
we
can
also
think
about
Ezekiel's
proposal
here.
A
We
had
the
problem
that
the
feature
was
broken
up
into
I,
think
four,
three
or
four
mirage
requests
and
the
last
much
requests
got
merged
on
the
date
of
the
or
pretty
much
on
the
last
day
of
the
milestone
and
yeah.
Obviously,
we
didn't
have
a
lot
of
time
to
work
on
the
integration
on
the
front
end
side.
So
I'm
curious
to
hear
your
thoughts
how
we
can
improve
this.
Is
there
any
workaround
any
any
process,
change
that
you
can.
E
D
E
A
A
And
in
an
ideal
world,
everything
works
out
of
the
box,
but
we
all
know
that
the
integration
there's
always
something
that
you
have
to
fix
on
the
front
and
side
to
make
it
work
and
especially
in
the
last
milestone,
I
think
there,
the
last
day
of
the
milestone
was
a
Friday
so
making
this
making
as
possible.
It's
just
it's
just
painful
to
have
this
kind
of
integration
work
being
done
on
a
Friday
evening
or
Friday
night.
A
So
maybe
we
can
think
of
ways
how
we
can
improve
this,
because
I
think
we
already
did
a
great
job
on
on
the
on
the
starting
point
where
we
agree
on
API
spec
or
even
if
we
can
start
with
a
fixer
extra
spec
like
Ezekiel
proposed,
but
I
think
the
main
pain
point
now
is
the
integration
part.
So
I,
don't
think
that's
something
that
we
need
to
to
answer
now.
I'm
happy
to
open
an
issue
for
further
discussion
and
paying
everyone
on
the
issue,
but
just
something
to
think
about.
B
A
I
think
we
did
agree
on
I
referring
to
the
to
the
API
spec,
like
what
the
response
data
should
look
like
I
think
that's
what
we
already
did
for
some
reason.
Well,
agreeing
on
that
and
then
making
the
integration
gonna
like
work
and
and
and
integrate
back-end
and
front-end,
there's
always
something
that
that
doesn't
like
fit
together
as
design.
A
So
there's
always
something
that
where
you
need
to
tweak
it
a
little
bit
and
if
you
need
to
do
that
on
the
last
day
and
then
probably
or
possibly,
you
would
also
need
to
change
some
front-end
specs
to
work
accordingly
and
make
those
small
tweaks.
This
is
this
puts
developer
in
a
stressful
situation.
A
C
Sort
of
tools
do
we
have
to
to
work
with
this?
Do
we
have
something
that
we
can
continuously
update
as
we
start
implementing,
so
whatever
the
backend
is
implementing
the
front
end
will
have
readily
at
hand
when
it's
when
it's
done
so
like
a
slow-moving
integration
instead
of
like
now
it's
done,
and
then
everything
that
tried
to
integrate
everything
at
that
point.
I
guess.
A
Look
sometimes
what
we
would
do
is
just
rebase,
whatever
branch
that
Candy's
working
on.
But
then,
even
if
you
like,
split
up
front
end
in
multiple
in
Aris,
then
you
would
need
to
have.
They
have
a
lot
of
overheads
to
rebase
all
those
branches
and
keep
them
in
sync.
So
that'sthat's,
one
potential
solution
and
for
a
small
feature
like
this,
that's
probably
doable
but
for
bigger
features.
I
think
this
is
adding
up
too
much
overhead.
B
A
A
We
broke
the
issue
down
into
like
multiple
m
RS
which
got
merged
one
after
each
other,
so
I'm
not
sure
if
the
backend
work,
if
it
would
have
been
possible
to
like,
for
example,
I
think
what
we
did
was
we
with
the
labor
two
metrics,
so
I
don't
know
if
it
if
it
would
have
make
sense
to
start
delivering
one
metrics
and
then
get
this
out
and
then
work
on
the
second
metrics
as
opposed
to
integrating
both
metrics.
At
the
same
time,
the
truth
that
would
have
helped
a
lot
good
question.
B
B
A
D
D
Yeah
and
I
think
you
know
the
the
key
thing.
Is
we
don't
need
to
see
solve
problems
here?
You
know
we
need
to
do
just
enough
in
order
to
complete
this
kind
of
set
of
three
stories
that
we're
working
on
related
to
this
in
this
iteration.
So
you
know
narrowing
the
scope
of
the
proposal
to
being
just
enough
to
deliver
it
on
that,
and
then
you
know
moving
forward.
I
think
someone
did
comment
on
that
issue.
Over
the
weekend,
I
haven't
seen
the
latest
ones,
but
hopefully
we're
getting
close
I.
A
D
The
the
the
issues
that
we'll
be
working
on
primarily
next
are
all
of
those
bullet
points
under
the
the
epic
that
we
have
around
the
generic
report
page.
But
I
wanted
to
give
a
few
kind
of
looks
ahead
at
things
that
you
haven't
seen
in
this
meeting
here.
So
the
first
one
is
multiple
value
streams
per
group.
D
This
is
something
I'm
hoping
will
take
on
in
thirteen
two
and
the
main
idea
here
is
that,
with
the
story
that
we're
working
on
to
add
filters
to
value
stream
analytics
in
this
milestone,
we'll
be
able
to
start
seeing
our
group's
own
measures
by
filtering
on
the
group,
analytics
label
and,
and
so
will
start
to
be
able
to
get
a
much
better.
Look
at
what
value
stream
analytics
can
tell
us
about
our
own
process.
D
So
we
don't
want
this
to
be
really
intrusive,
so
the
way
that
Nick
proposed
to
handle
it
is
with
just
a
drop-down
in
the
upper
right
that
we
would
default
to
just
having
the
the
group
name
in
it.
But
then
you
could
select
the
option
to
create
a
new
value
stream
here,
give
it
a
name
and
have
multiple
value
streams.
So
so,
in
the
gate,
lab
or
group,
we
could
have
value
streams
for
each
of
the
various
analytics
teams
and
they
could
modify
the
configuration
settings
for
for
each.
D
A
D
A
D
D
All
right,
the
next
item
is
direct
navigation
to
report
pages.
This
is
not
something
I
expect
us
to
do
in
13-2,
but
I
wanted
to
show
a
picture
here
so
that
you
could
see
sort
of
the
direction
we're
headed
in
with
these
report
pages.
So
the
first
set
of
stories
around
the
report
pages
are
really
as
a
landing
place
for
embedded
experiences.
We've
got
the
recent
activity
on
the
group.
Page
we've
talked
about
having
drilling
from
the
inbox
analytics,
you
know,
from
the
to
Do's
area
and
throughout
the
product.
D
D
You
drill
into
the
chart-
and
you
land
in
the
report
page
two
to
actually
give
that
kind
of
drill
in
detail,
but
before
we
get
there,
sort
of
a
lower
bar
is
to
just
provide
direct
navigation
to
the
various
metrics
that
we
have
available
on
those
report
pages
and
just
to
move
between
them
quickly.
So
another
way
of
thinking
about
this
is
it's
a
an
improvement
over
the
drop-down
list
that
you
have
in
incites
right.
If
you
go
to
the
insights
page
today,
there's
all
these
different
pages
and
reports.
D
So
again,
not
intended
for
work
in
13-2,
but
I
wanted
to
give
a
picture
of
sort
of
where
we
were
headed
with
this,
so
that
we
could
be
thinking
about
this
nick
is
out
on
vacation
this
week
and
he
has
some
other
time
off
this
month
as
well.
So
I
don't
think
we're
gonna
be
in
the
right
place
to
execute
this
on
13-2,
not
just
from
the
standpoint
of
having
designs
finalized,
but
also
because
we
don't
have
enough
content
to
make
this
the
list
of
reports.
D
D
A
What
is
be
located
under
the
like
the
group
namespace,
or
would
this
be
on,
like
the
instance
namespace
so
reason,
I'm
asking
is
some
of
the
report.
Pages
I
feel
like
some
of
the
report
pages
would
be
tied
to
a
particular
group,
for
example
the
like
group
activity
or
group
recent
activity,
new
merge
requests
or
group
recent
activity
members.
Those
counts
would
be
depending
on
a
group
right.
A
D
D
In
the
discussion
about
the
generics
reports,
page
I
suggested
that
the
URL
that
those
should
live
in
would
be
sitting
above
the
group,
because
we're
gonna
have
some
reports
that
are
instance,
level
reports.
I
think
the
same
thing
is
true
here
that
some
of
this
sits
of
now
there
are
a
couple
of
ways
we
could
handle
group
selection.
One
of
them
is
that,
instead
of
a
flat
list
here,
we
have
more
of
a
tree
so
that
you
could
navigate
kind
of
groups
of
metrics
I.
D
Think
if
you
had
just
a
flat
list
here,
it
might
be
very
hard
to
find
the
kind
of
metric
that
you
want.
So
it
seems
very
likely
to
me
that
we
would
actually
implement
this
as
some
kind
of
tree.
Another
thing
that
we
could
do
is
also
move
group
selection
as
a
widget
into
the
report
pages.
If
we
wanted
to
do
that
and
make
that
simpler
as
well,
we
haven't
gotten
nearly
that
far
but
an
excellent
question.
E
D
We
we
added
the
table
to
issue
analytics
in
this
last
milestone.
The
idea
is
to
take
that
kind
of
work
and
make
it
available
in
the
generic
report
pages
as
well,
and
then
proceed
to
make
those
charts,
clickable
and
so
on.
So
I'll
be
working
on
that
this
week.
If
there
are
specific
ones
of
these,
that
you
have
questions
about
and
would
like
to
see
me
work
on
sooner
than
others.
You
know
please
ping
me
and
let
me
know,
but
that's
that's
what
I
expect
to
be
working
on
this
week.