►
From YouTube: Manage:Analytics 13.2 Pre-Planning Meeting
Description
Pre-planning team meeting to review the issues / epics listed in the planning issue below:
https://gitlab.com/gitlab-org/manage/-/issues/16681
See other videos in our playlist at:
https://www.youtube.com/playlist?list=PL05JrBw4t0KoBbJjwSPt1E7J_Ng6SRq-y
A
Seeing
none,
let's
just
dive
in
so
here's
our
planning
issue
and
I
thought
I'd
start
with
out
where
we
are
statement
just
so
we're.
On
the
same
page,
there
adding
filters
to
VSA
has
been
chugging
along
and
seems
like
that's
going
to
come
in
okay,
unless
one
of
you
know
differently
the
group
activity
in
Mars,
charts
and
issues
chart
that's
part
of
the
generic
metrics
API.
We
are
closing
in
at
this
point
on
our
plan
for
that.
A
So
it's
a
it's
a
light
start
may
not
be
all
the
way
in
you
know
by
the
end
of
the
milestone,
but
they
should
be
well
on
their
way
at
minimum.
I
would
think
by
the
time
we
would
start
so
the
idea
there
then,
is
to
build
on
that
work
on
report
pages
in
two
ways:
the
first,
by
working
with
new
sources
of
data
and
we've
already
had
conversations
about
doing
that
with
the
new
members
chart.
A
There's
been
a
fair
bit
of
conversation
already
about
how
what's
the
best
way
of
getting
that
data.
How
would
we
store
it
and
so
on
and
then
for
depth
doing
things
like
making
those
charts,
embeddable
and
starting
to
add
a
data
table
and
so
on
for
VSA?
The
idea
is
to
to
kind
of
wrap
up
the
work.
We
were
doing
to
try
to
unblock
internal
dogfooding
of
VSA
by
allowing
individual
teams
to
create
their
own
configurations.
B
A
A
A
Now
there
are
some
alternatives.
We
could
look
at
when
we
look
at
this
MVC.
If
we
wanted
to
we've
had
a
number
of
other
teams
expressed
interest
in
what
we're
doing
with
generics
metrics
API.
Recently
one
is
team
working
on
test
code
coverage
which
Dan
brought
to
my
attention
yeah
just
yesterday,
I
think
and
another
is
Gabe's
team.
That's
been
doing,
work
on
burn
up
and
burn
down,
charts
and
found
our
generic
API
and
said
hey
having
something
we're
gonna
have
to
do
some
refactoring
of
the
work
we
did
on
this
anyway.
A
If
we
had
something
like
this
generics,
API
metrics
API,
it
would
really
help
us.
So
you
know
I
think
we
should
make
our
choice
there,
based
upon
whatever
is
going
to
help
us
understand
how
to
take
our
first
step
for
that
MVC.
Having
a
few
examples
to
look
at
even
when
we
pick
one
which
would
be
new
members
by
default,
it
would
help
us
there
for
value
me
and
stream
analytics.
A
The
next
thing
I
was
inclined
to
do
is
walk
through
the
report
pages
story
and
show
some
of
the
restructuring
that
we've
done
there
based
upon
what
we've
learned
through
the
conversation
with
it,
insights
I
put
a
fair
bit
of
work
into
to
kind
of
cleaning
up
that
whole
tree
of
stories
yesterday,
so
I
can
take
you
through
the
updates
there,
and
then
we
can
walk
through
these
issues
in
order
that
sound
like
a
good
use
of
time,
where
there
are
things
you
want
to
discuss
before
we
go.
Go
to
that
level.
C
A
Well,
first
of
all,
one
thing
I
didn't
say
but
could
have
in
the
where
we
are
section
is
that
we've
made
really
good
progress
on
the
instrumentation
for
our
Northstar
metric
Magda
has
done
an
awesome
job
of
getting
that
kicked
off
and
both
Pavel
and
Adam
have
done
great
reviews
really
thorough
reviews
of
her
work
too.
So
we're
really
pleased
with
the
way
that's
coming
along
and
we
will
have
a
lot
better
insight
until
and
into
how
all
of
the
various
analytics
features
are
used.
A
I
think
we're
tracking,
like
14,
separate
features
and
then
also
tracking
a
total
number.
For
you
know
any
analytics
feature
touched
and
we're
looking
at.
You
know
how
how
many
unique
users
in
a
given
week
are
touching
those
various
features.
So
one
of
the
things
that
we'll
have
to
do,
which
I
haven't
spun
up
a
story
yet
around
in
13
2
is
you
know,
add
another
entry
for
report
pages
to
our
North
Star
metric
and
start
collecting
data
on
that
too.
But
we
will
now
have
a
really
grounded
way
of
seeing
how.
D
I,
take
a
pulse
check,
real,
quick
like
Dan
and
Martin
like.
How
are
you
feeling
about
this?
Like?
Are
you
more?
Are
the
biggest
questions
in
your
mind?
Still
around
13
or
around
13,
one,
like
you
know,
moving
to
report
pages
implies
that
we
should
spend
our
time
talking
about
13
1.
What?
Where
should
we
invest?
Yeah.
B
So
my
biggest
concern
like
concern
is
still
on.
How
far
do
we
get
with
the
embassies
that
we
plan
on
delivering
in
13.1
regarding
our
like
directional
shift
from
like
using
insights?
Now
so
there's
still
a
few
discussions
or
the
discussions
are
almost
being
resolved,
so
we're
gonna
start
implement
with
the
implementation
probably
next
week,
so
I
wonder
how
much
carryover
we
will
have
from
thirteen
point
one
into
thirteen
point:
two:
that's
that's
my
only
concern.
A
A
All
right
so
I
want
to
go
pop
back
up
the
stack
here.
Okay,
so
this
is
where
we
started
with
the
report
pages.
This
is
the
the
main
epic
there.
We
took
a
branch
off
of
this
epic
to
talk
about
using
insights
yeah
to
do
this,
and
that
conversation
is
just
about
wrapped
up
and
I
proposed
yesterday
evening
that
we
actually
closed
that
issue
in
the
next
24
hours.
You
know
unless
anybody
has
objections.
A
The
the
net
result
of
that
was
that
instead
of
the
new
members
chart
being
our
MVC,
which
is
the
way
we
had
laid
this
out
before
now.
The
mrs
chart
is
the
MVC
and
we
use
an
insights
for
that
and
we
follow
on
with
issues
again
leveraging
insights
for
that.
So
this
story
now
has
kind
of
the
details
about
you
know
what
is
the
MVC
look
like
that
were
brought
over
from
that
other
story
and
the
there's
a
link
to
the
thread
in
the
insights
issue,
where
we
were
kind
of
wrapping
things
up
and.
A
A
In
in
the
context
of
this,
mr
start
story,
so
I've
asked
Adam
and
Brandon
who
both
volunteered
update
this
issue
with
any
of
the
implementation
issues
that
spin
off
of
that.
Both
of
them
have
already
identified
lists
of
tasks.
That
would
be
those
implementation
stories,
so
I'm
hoping
in
the
next
24
hours,
to
see
those
show
up
here
and
we
ought
to
be
ready
to
start
and
then,
once
once
that
story
is
done,
the
issues
chart
there.
There
shouldn't
really
be
anything
left
to
do
there
because
we're
using
the
same
insights
engine.
A
A
Then
I've
moved
the
the
new
members
chart
down
and
out.
You
know
I'm
not
expecting
that
we
would
get
very
far
at
all
in
13:1.
With
with
that,
there's
been
some
good
discussion
about
how
we
actually
fetched
that
data
in
a
performant
way
and
some
initial
conversation
about
what
that
API
might
look
like
in
in
in
the
new
members
chart
story
itself.
A
What
does
the
API
look
like
for
the
MVC
of
the
generics
API
into
which
this
this
goes
and
then
how
do
we
change
the
report
pages
to
actually
grab
data
from
that
API
and
then
it's
just
a
matter
of
using
the
config
file
to
pull
it
out,
so
there's
there's
definitely
work
that
needs
to
be
done
still
to
figure
out.
You
know
what
is
this
and
they
see
going
to
look
like
and
then
how
does
the?
A
A
A
D
A
Well,
there's
just
to
clarify
Jeremy:
this
is
we've.
It
seems
obvious
to
me
anyway
that
this
is.
This
story
is
clearly
a
13-2
that
the
the
prior
to
that
are
building
on
insights
without
much
further.
The
I
think
are
gonna,
be
in
13
1
or
you
know
they
might
slip
a
bit,
but
the
scope
of
work
is
pretty
defined
and
pretty
narrow.
On
those.
This
one
is
a
hairier
one.
I
would
not
modesta
finish
until
32.
E
So
I
mean
I,
guess
Martin
I,
don't
but
I
don't
want
to
speak
for
you
here,
but
I
earlier
I
wanted
to
sort
of
second
what
you
were
talking
about.
So
in
my
mind
we
didn't
actually
even
schedule
these
charting
issues
for
13:1
like
if
you
look
at
the
thirteen
one
planning
issue,
they're
still
listed
as
candidate
issues.
So
I
think,
like
my
concern
that
you
know
I
think
I
share
Martin's
concern.
Here's
what
I'm
getting
at
but
like
if
I
had
to
describe
it
I
would
just
say
like
we
haven't
started
on
the
work.
C
E
E
B
Yeah
I,
agree,
I
think
it's
just
a
matter
of
what
are
the
expectations
posed
from
you
know
from
product
for
thirteen
point
one
and
what
are
the
expectations
from
engineering
or
what
do
we
feel
that
we
can
accomplish
and
I
think
that
the
biggest?
So
we
spend
a
lot
of
time
and
effort
into
discussing
how
we
can
like
set
up
this
generic
drill.
In
page
from
scratch,
we
had
different
proposals,
and
now
we
finally
come
to
an
agreement
and
I
think
those
discussions
are
obviously
necessary.
B
B
I'm
just
concerned
that
we
probably
won't
implement
an
MVC,
or
it's
very
likely
that
we
want
the
labor
and-
and
we
see
in
certain
point
one
mainly
because
we
already
spend
a
lot
of
time
in
certain
point
when
discussing
things
so
just
wanted
to
double
check
what
the
expectations
are
from
the
product
team
for
the
outcome
of
thirteen
point
one.
So.
A
A
B
A
B
For
me,
this
makes
perfect
sense.
I,
don't
think
that
we
I
think
that
the
chances
are
very
low,
that
we
will
pick
something
up
that
in
the
meantime
and
and
wait
to
get
to
get
started
for
until
until
13.1.
So
it's
it's
definitely
the
top
priority.
That's
that's!
That's
absolutely
clear.
I
was
just
checking
make
sure
we're
all
in
the
same
page,
and
since
we
are
already
half
through
the
milestone,
chances
are
obviously
lower
to
get
this
done,
but
now
that
we
are
almost
I
think
we
have
pretty
much
closed
most
of
the
discussions.
B
A
E
So
I
agree
with
everything.
Martin
said
there
I
think
it's
like
just
personally.
For
me,
the
thing
that
makes
me
a
little
uncomfortable
is
on
your
screen:
John
Mason.
What
it
shows
up
at
the
top
here
by
the
start
of
13.2.
We
will
have
delivered
or
be
close
to
delivering.
We
don't
know
you
know
we
haven't.
Even
we
haven't
even
gotten
to
a
point
where
execution
has
been
broken
down
and
estimated.
E
So
you
know
I'm
I'm
a
little
uncomfortable
with
that
statement,
but
yeah
I
agree
with
Martin
that
the
priorities
here
are
clear:
I,
don't
think
anybody's
talked
about
hitting
pause.
You
know.
We
know
that
this
is
our
top
priority
to
finish,
refinement
on
draft
the
execution
issues
for
estimate
them
and
get
moving
on
the
execution.
So
you
know
I
like
for
me.
It's
just
a
matter
of
like
I.
Don't
want
to
end
up
with
a
traffic
jam.
E
You
know
I
don't
want
to
end
up
with
us
saying:
oh,
we
got
a
bunch
more
done
in
13
1,
you
know
or
assuming
we're
gonna
get
a
bunch
of
stuff
done
in
13
1
and
then
scheduling
too
much
for
13,
and
this
is
just
the
pre-planning
meeting
right,
we're
gonna
know
more
by
next
week,
probably
much
much
more
by
next
week
at
the
proper
planning
session.
You
know
the
final
planning
session,
so
you
know
I
I
think
we're
all
on
the
same
page.
E
A
E
A
All
right,
let's
see:
where
do
we
want
to
go
next,
so
shall
we
talk
about
these
specific
ones
for
next.
E
Question
actually
yeah
yeah
yeah,
please
objectives
so
I,
I,
hadn't
tier,
so
like
I
added
the
the
members
chart
link
and
then
the
second
kind
of
sub
bullet
point
there
for
depth.
Embeddable
charts
so
I
added
a
link
for
that,
but
I
I'm,
not
sure
I'm,
aware
of
data
table
NVC.
Is
there
a
link
to
that
like?
Is
there
an
existing
issue
for
that.
A
E
A
Spun
it
up,
okay,
yep
and
so
I
think
embeddable.
My
view
is
embeddable
and
group
by
day
and
month
are
going
to
be
very
easy
to
understand.
What's
asked
for
you
know,
they'll
be
some
conversation.
How
do
we
achieve
it,
but
there
the
scope
of
them
is
fairly
small
and
straightforward
report
pages
included
data
tables
a
little
bit
more
interesting
in
that
we
need
to
figure
out
how
to
do
that
in
a
way
that
is.
A
A
D
Dan
yeah:
do
you?
What
do
you
think
about
this
issue?
Do
you
find
it
helpful
when
we,
when,
when
we
add
like
this
level
of
detail
to
the
proposal,
III
personally
I,
wonder
we're
adding
a
little
too
much
detail
here
that
kind
of
constraints,
the
space
for
your
engineering
team
to
make
calls
about
meeting
the
goals
of
this
issue?
What
do
you
think.
E
Yeah
I
mean
it
it's
funny,
because
when
it's
when
it
jives
perfectly
with
what
you
know
the
engineers
end
up
wanting
to
do,
then
it's
really
nice
other
times
it
can
be
confusing.
So
that's
that
can
be
a
little
bit
of
it
can
be
a
little
bit
of
a
tough
one
like
actually
over
in
compliance.
I
just
ran
into
this,
where
I
put
up
too
specific
a
little
snippet
of
code,
and
it
was
misleading
to
the
engineer.
E
So
you
know,
I
just
fell
into
that
trap,
so
it
I
mean
it
can
be
a
trap
so
on
this
one
like
actually,
the
first
thing
is
I
would
actually
like
an
example
from
the
parent
issue:
John
Mason,
just
because
I'm
not
exactly
sure,
I
had
a
dated
table.
Oh
okay,
okay,
so
like
when
you
click
the
chart,
the
data
table
appears
below
right.
A
B
E
So,
okay,
Jeremy
I,
think
to
get
back
to
your
question.
I.
Do
think
that
this
may
be
assumes
that
we're
using
graph,
QL
and
I
don't
I,
don't
know
that
we
are,
and
then
John
Mason.
Another
question
for
you
here
is:
is
this
going
to
show
all
of
the
data
in
the
table
above
because
this
doesn't
say
anything
about
clickability?
So
this
is
not.
This
might
not
like
a
click.
Ability
enabled
feature
right
right:
okay,.
B
E
Yeah
John,
Mason
I
think
maybe
to
Jeremy's
point
here.
You
know
you
wrote
the
this
example
is
to
illustrate
not
acceptance
criteria.
Maybe
acceptance
criteria
would
be
kind
of
the
more
straightforward
approach
of
like
I
want
a
table,
it
shows
50
records,
you
know
and
and
then
cuts
it
off
no
pagination,
and
you
know
it
basically
just
shows
data
from
the
chart.
You
know
the
first
50
records
in
a
table
below
and
maybe
kind
of
a
screenshot
of
what
the
columns
are
of
the
data
mm-hmm.
A
D
D
We
propose,
you
know
limiting
it
to
the
first
50
rows
and
then
you
know
considering
a
fall
on
issue
that
we
open
up
on
pagination
and
let
engineering
react
and
see
if
there's
more
room
for
to
scope
it
down.
If
not,
then
feels
pretty
shovel-ready
stay
sign-off
on
no
I'm
happy
to
add
the
screenshots
I
can
do
that
right
now.
My.
B
Only
concern
with
the
screenshot
is,
it
definitely
helps,
but
as
far
as
I
understand,
this
should
be
like
a
generic
implementation
right.
So
we
don't
really
care
about
the
columns
that
we're
gonna
represent
in
the
table.
It
should
be
we're.
Gonna
represent
whatever
we
receive
or
will
receive
from
the
back
end
right.
So
in
this
regard,
it
could
be
like
three
columns
like
username
some
other
details
and
in
a
different
scenario.
It
would
be
like
a
totally
different
set
of
attributes
that
we
would
show
in
the
table
so.
E
A
B
Yeah
I
guess
in
in
this
particular
case,
so
as
Cringer
definitely
helps
because
everyone
knows
what
the
tables
going
to
look
like.
I
just
wanted
to
point
out
that
the
the
attributes
or
the
columns
that
the
screen
shots
is
gonna
dip
or
the
screen
shot,
shows
or
depicts.
It's
not
necessarily
the
the
full
data
set
that
that
that
will
be
displayed,
or
it's
just
a
one
version,
because
in
a
different
scenario,
we
will
have
a
different
subset
of
data
being
displayed
since
its
generic
page.
That's
what
I
wanted
to
say.
A
A
B
A
A
So
we've
talked
about
the
data
table.
We've
talked
a
little
bit
about
and
charts
embeddable
and
handbook
pages.
This
issue
doesn't
have
a
lot
in
it
yet,
but
it
kind
of
describes
the
problem.
I'll
add
links
to
example,
handbook
pages
and
do
a
little
bit
of
investigation
as
to
you
know
how
science
works
and
so
on,
and
try
to
make
more
of
this
text
bullet
point,
but
but
I
think
the
scope
of
this
is
is
fairly
straightforward.
Any
of
any
questions
about
this
one.
E
B
I
think
it's
a
front-engine
take
integrating
stuff
in
like
an
environment
that
you
don't
really
well.
You
kind
of
control
the
handbook
right,
but
you
could
ideally
I
guess
the
broader
vision
would
be
like
you
can
take
that
snippet
and
integrate
it
in
whatever
environment
or
whatever
page
you
want
like
a
customers
page
or
a
customer's
dashboard
or
whatever.
B
So
I
think
that
the
biggest
challenge
in
this
regard
would
be
on
the
front
and
side
to
make
sure
that
ours
are
our
source
code
or
our
scripts
are
not
interfering
with
any
other
page
specific
JavaScript
that
the
client
has
or
that
we
are
running
on
our
handbook
page.
But
those
are
implementation.
Details
I
just
wanted
to
point
out
that
the
challenges
that
that
we
will
be
facing
in
this
regard.
A
And
I
want
to
also
be
clear
about
my
expectation
with
this
right
in
the
title.
It
says
in
handbook
pages
because
I
think
it's
fine
to
limit
scope
to
that
and
then
come
back
around
to
other
kinds
of
dashboards
later,
if
there
are
additional
complexities
to
embed
in
other
places.
That
wouldn't
it
all
surprise
me
and
we
don't
have
to
tackle
them
all
at
once,
it'll
be
a
win
if
it
works
in
the
handbooks
page,
the
next
one
group,
by
day
or
month.
A
A
All
right
oops
keep
going
back
to
the
wrong
place.
A
A
But
like
once
I
think
he's
you
know
kind
of
through
this
most
critical
deliveries
for
a
13
one.
You
know
I'd
rather
see
him
spend
time
on
trying
to
figure
this
stuff
out
as
early
as
possible.
That
long,
you
know
you
know
shipping
shipping
more
stuff,
because
because
there'll
be
a
lot
of
work
to
figure
this
bit
out.
A
A
Nick,
while
you
are
out
there
was
a
fair
bit
of
discussion
on
this
issue,
thanks
by
the
way
for
putting
together
this
really
quick
nick
said:
hey
I'm
bout
ready
to
head
out
for
vacation.
Is
there
anything
you
for
me
and
I
said:
hey
Nick,
I
promise?
We
won't
try
to
implement
this
without
giving
you
more
time
to
look
at
it.
But
could
you
please
throw
together
something
for
this
and
he
knocked
it
out
right
away.
A
C
B
A
You
know
maybe
more
than
that,
if
people
played
with
them
eventually
we'll
need
to
give
people
a
way
of
deleting
ones
that
they
were
just
playing
around
with
and
didn't
want,
but
that's
not
really
in
scope
for
this
story.
I'm
not
expecting
that,
given
our
audience
for
this
immediately
that
we're
talking
about
hundreds,
it's
tens.
A
C
A
A
B
D
So
so
can
I
ask
what
next
steps
are
here.
It
sounds
like
for
the
message
I'm
receiving
I'm
hearing
for
13:1
is
that
it's
the
critical
path
is
through
engineering
at
the
moment
that
we
have
DRI
define
for
back
in
in
front
end
on
the
reports
work,
and
the
next
step
is
on
engineering
to
provide
that
issue
breakdown
that
we
can
then
sequence
is
that
correct,
I
think.
C
E
A
B
E
And
I
think
in
terms
of
next
steps
beyond
that,
like
we
have
a
lot
to
refine
here
and
and
I
actually
just
took
a
look
at
how
many
on
deck
issues
we
have.
We
have
33
right
now,
so
it
might
actually
be
good
to
kind
of
cull
that
list
to
pull
the
on
label
off
a
bunch
of
those.
So
it's
really
clear
what
we
need
to
be
focusing
on
for
refinement,
I,
think
that
I
think
that
would
help
yeah.
A
E
D
A
E
A
D
Makes
sense
so
I
know
we're
at
time,
so
I
just
want
to
make
sure
that
we're
clear
on
next
steps,
so
it
sounds
like
product
is
gonna,
go
ahead
and
like
call
the
the
on-deck
label
from
there,
because
we
went
through
a
number
of
issues
in
this
meeting
regarding
13.
What
are
the
next
steps?
Are
we
gonna
at
that
point?
Are
we
gonna,
maybe
like
drop
a
note
into
the
analytics
channel
and
say
like
these,
are
on
deck?