►
From YouTube: Manage:Analytics Weekly Meeting 2020-05-19
Description
The Analytics group talks about blockers, "on deck" issues, and cool stuff from the past week.
A
So
it
looks
like
we
have
some
FY
eyes
to
go
through
or
for
people
to
read
through
the
first
vocalized
item
on
the
agenda
is
walking
through
blockers
and
at
risk
items
and
I
think
there
was
at
least
one
based
on
comments
on
the
planning
issue,
but
I'll.
Let
anybody
you
know
bring
up
whatever
they
want
here.
A
B
B
We've
got
a
set
of
three
issues
that
we'd
like
to
take
in
as
part
of
the
13:1
release,
and
there's
already
been
some
very
good
discussion
on
these.
The
first
is
the
group
activity
new
members
chart.
We
I
think
reviewed
this
some
last
week,
but
we've
made
a
lot
of
progress
on
kind
of
clarifying
what
this
is
the
basic
idea
being
that
in
the
group
recent
activity
we
can
drill
down
on
the
members
added
and.
B
And
then
link
over
to
a
chart
that
shows
members
added
over
time.
Of
course,
the
whole
reason
we're
doing
this
is
to
create
that
kind
of
generic
capability
where
we
can
use
the
same
page
for
other
kinds
of
metrics
and
in
the
three
that
follow.
We
do
the
we'll
do
the
issues
opened
and
merge
requests
opened
and
so
on.
B
If
we've
done
the
first
one
correctly,
so
these
three
things
we're
hoping
to
bring
into
thirteen
one,
and
then
there
are
some
other
things
that
if
we
had
time,
we
could
tackle
things
like
grouping
by
day
and
month
supporting
a
second
series
and
so
on.
But
these
are
all
follow-on
type
items
that
are
not
in
scope.
For
for
these
three
things
that
we
split
off
an
issue
that
could
possibly
be
worked
in
parallel
on
the
front
end
after
some
design
work,
is
this
PJ's
issue
around
adding
a
second?
B
B
So
we've
got
a
PJs
issue
open
about
that.
So
one
question
I
have
for
you
all
about.
You
know
when,
when
we've
got
new
chart
components
like
this
is:
do
we
open
two
issues,
one
PJ's
issue
and
none
one
issue
on
the
front
end
in
get
lab
org,
or
does
the
work
happen
in
the
PJs
issue?
How
does
that
ordinarily
work.
C
C
The
PGA's
issue,
I'm
not
sure,
do
like
from
frontin
perspective.
We
would
technically
just
open
an
issue
in
github
UI
to
make
the
proper
updates
to
the
existing
chart.
So
we
would
have
like
a
separate
github
UI
issue
to
make
sure
that
we
can
keep
track
of
the
required
changes
that
we
need
to
do
on
the
on
the
charts.
C
My
question
is:
does
this
need
to
be
a
PG
issue
at
all,
since
we're
just
it's
more
or
less
like
adding
a
configuration
option
to
an
existing
chart
right
we're
not
really
changing
existing
behavior?
We're
not
really
changing
the
styles,
so
I
wonder
if
you
really
need
a
PJs
issue
for
it,
but
that's
probably
something
that
Nick
can
answer.
D
So
there
are
a
couple
of
key
stages
within
pajamas,
which
is
trying
to
align,
get
love,
UI
and
and
and
PJ's
together,
and
the
like.
The
breakdown
of
those
stages
are
create,
build
style
and
integrate
and
create
is
essentially
where
you
design
it
or
you
update
the
designs,
build
and
style.
You
know
is
where
you
actually
implement,
created
and
UI
and
and
then
integrate
is
where
you
actually
implement
it.
D
So
the
way
the
way
it
should
work
is
basically
the
need
arises
where
a
new
component
yeah
a
new
component,
the
need
arises
for
an
update
to
a
component.
We
start
by
doing
the
create
PJ's
issue
that
once
that's
created
and
designed.
We
then
feed
that
over
to
the
build
and
style
phase,
that's
when
something
gets
created
within
gitlab
UI
and
that's
where
it
actually
gets
built
and
the
PJs
issue
is
closed
down.
D
C
No,
that
makes
sense.
I
was
just
wondering
if
we
need
a
dedicated
pgz
true
for
such
a
I'm,
calling
it
a
small
minor
change
since
it's
basically,
we
already
have
styles
and
everything
defined
for
one
y-axis
and
it's
pretty
much
copying
the
existing
designs
back
for
the
second
y-axis,
if
I
understand
correctly
so,
but
I
understand
that
we
need
to
go
through
the
process.
C
So
in
that,
in
that
case
we
probably
need
two
issues,
one
for
PJs
and
then,
ideally,
if
that's
signed
off
and
reviewed,
then
we
can
start
working
on
the
github
UI
issue,
even
though
I
believe
for
such
a
small
change.
I,
don't
really
expect
too
much
pushback
from
the
design
review,
so
I
I
suppose
we
can
already
start
if
we
have
capacity.
C
Obviously
this
is
a
lower
priority
issue
in
the
milestone,
but
if
we
had
already
capacity
for
this,
we
could
already
start
working
on
that
in
parallel.
But
to
answer
Tom
Mason's
question:
yes,
I
I
guess
we
should
create
two
issues,
one
for
PJs,
which
we
already
have
that's
the
linked
one,
and
then
we
should
create
a
dedicated
or
a
separate
issue
within
get
web.
Ui
that
we
can
link
to
the
PJs
issue.
B
D
B
C
D
D
I'd
expect
Joe
Mason
is
in.
If
you
would
create
a
feature
issue
and
you'd
say:
oh
I
think
we
need
to
update
this
component.
I
would
probably
most
likely
create
the
components
for
the
for
the
PJs
issue
and
then
I'd.
Imagine
Martin
would
be
the
person
or
another
front-end
engineer
would
be
the
person
who
created
the
UI
get
lab
UI
issue.
Ok,.
B
C
I
think
that's
fine,
I,
don't
think
you
need
to
create
three
issues.
I
think
we
can
start
with
which
one
and
then
we
can
like
developers
whenever
we
feel
like
we
want
to
have
the
y-axis
and
being
used
in
a
chart
like
developers
would
say:
okay,
I
realize
we
don't
have
this
feature
yet
I
would
just
go
over
to
get
lucky.
I
created
the
issue
for
that,
and
then
we
can
update
our
components
accordingly.
All.
B
B
B
C
Just
one
question
regarding
the
MVC:
so
the
idea
is
to
pretty
much
start
with
the
member.
Then
you
knew
new
members
chart
and
have
like
this.
This
generic
set
up
or
the
generic
brilliant
page
being
implemented.
So
the
only
thing
that
would
be
missing
in
order
to
deliver
the
other
remaining
items,
which
is
a
Mars
chart
and
issues
chart,
would
be
the
link
on
the
recent
activity
page
and
clicking
on
that
shoot
out
of
the
box.
Show
the
charts
for
the
other
two
metrics
is
that
correct,
Jason,
yeah.
B
So
that's
right:
there
would
just
be
the
front
end
issue
and
there
might
be
some
configuration
change
like
you
might
have
to
have
another
yml
file
or
you
might
have
to
say
if
you
decided
to
take
a
pre
computed
approach,
which
I
think
we're
kind
of
steering
away
from.
As
I
understand
the
state
of
the
conversation,
but
if
we
were
to
do
that,
then,
if
you
were
to
write,
you
know
some
aggregation
or
to
have
a
an
api
call
on
the
safe
side
where
you
push
the
data
in.
B
C
A
I
was
gonna
ask
if
maybe
from
the
front-end
side
in
the
backend
side,
we
could
kind
of
explain
where
we
feel
like
we're
at
on
that
issue.
So
I
think
on
the
back
inside.
The
big
question
right
now
is
how
to
handle
the
data
set
definitions,
and
it's
still
it's
still
a
little
bit
of
an
open
question
like
we're.
Making
progress
but
still
a
little
bit
of
an
open
question
and
I
was
just
curious
like
where
things
stand
on
the
front
end.
Are
there
any
blockers,
I.
C
I
think
it
would
make
sense
to-
or
at
least
it
would
help
fronting
a
lot
to
agree
on
a
on
a
proposal
like
an
API
spec
or
a
llamó
spec
or,
however,
the
data
structure
is
going
to
be
delivered
that
we
can
implement
or
that
we
can
work
with
mock's
on
the
front
front
hand
side.
So
we
can.
We
can
start
implementation
as
soon
as
possible
and
other
than
that.
I.
A
C
I,
guess
that's
that's
one
approach
we
can
do.
We
can
just
make
sure
or
we
can.
We
can
double
check
well,
but
what
data
format
not
not
format?
What
data
structure
the
column
chart
expects
I
said,
as
I
already
mentioned,
I
think
different
charts
have
different
requirements
in
terms
of
how
the
data
needs
to
look
like,
but
then
for
the
NBC.
We
will
focus
on
the
on
the
column
chart.
So
that's
that's
just
it's
a
good
starting
point
and
we
can.
B
A
B
In
when
I've
used
graph
QL
for
stuff
in
the
past,
what
I
found
that
it's
really
good
at?
Is
you
know
picking
which
columns
of
data
or
you
know
which
data
attributes
you
want
to
display
and
sort
of
how
you
want
to
traverse
the
object?
Graphed
across
related
objects,
I've
not
used
it
for
aggregation
and
I'm,
not
sure
kind
of
with
the
capabilities
that
are
helpful.
It
would
be
there.
B
It's
it's
a
lot
easier
for
me
to
imagine
how
a
graph
QL
query
would
be
useful
for
rendering
the
table
below
the
chart
where
you
would
want
that
that
data
table
to
be
configurable.
You
know
to
have
certain
columns
which
are
turned
on
off
and
on
and
graph
QL
could
help
drive
that
than
it
is
for
me
to
to
picture
how
it
would
be
is
for
the
aggregation,
but.
C
B
B
One
of
the
items
we
had
on
the
planning
issue
is
a
to
do
section
and
we
had
a
number
of
items
here:
a
resolution
mechanism
capturing
the
timestamp
and
then
also
introducing
a
closed
state
and
so
on.
We
just
had
the
feature
kick
off
and
we
actually
had
a
lot
of
feedback
on
this
particular
issue:
roll
in
as
part
of
that
cake
as
part
of
the
kickoff
and
I.
B
Until
we
get
some
further
discussion
on
the
closed
state
and
primarily
the
button
at
the
top
I
think
we
should
consider
these
one.
These
two
on
hold
these
things
up
at
the
top.
Three
are
ready
to
go,
no
problem,
and
these
we
may
reduce.
We
may
you
know,
release
the
hold
on
it,
but
I
I
don't
want
to
do
anything
there.
Just
just
yet.
B
It
is,
you
should
actually
see
a
comment
from
Eric
Brinkman
on
the
to
do
issue
itself
on
the
close
State
issue,
and
there
was
some
conversation
about
it
on
the
kickoff
call,
which
is
on
get
lab
unfiltered.
So
there's
a
there's,
a
managed
staged
kickoff
video,
and
this
is
one
of
the
items
that
was
discussed
there.
F
D
F
D
F
B
A
A
B
B
A
Not
not
the
resolution
mechanism
that
seems
fine
to
me,
but
the
time
resolution
seems
kind
of
predicated
on
us
having
you
know
kind
of
a
more
robust
set
of
options
for
reaching
a
resolution
state.
You
know
if
it's
just
if
it
is
what
it
is
now
where
it's
done.
You
know
it's
either
pending
or
done,
and
it's
it's
very
simple
I'm
not
sure
like.
Basically,
if
we're
not,
if
we're
not
sure
we're
going
further
down
the
road,
do
we
need
to
be
differentiating
the
timestamp
for
resolution.
B
B
Yep,
they
know
off
the
last
update
right,
yeah.
The
last
update
and
I
think
with
the
fix
that
we
made
to
that
in
the
last
release,
where
all
of
those
dates
are
set
to
the
same
date
when
I
hit
the
bulk
button.
The
I
think
that
gives
me
what
I
need.
Okay,
so
yeah
this
this
timestamp
I
think
was
just
to
help
us
future
proof.
B
B
A
B
All
right,
that's
that's!
All
I've
got
on
my
side,
I
guess
the
other.
The
other
one
we
had
talked
about
before
was
tracked
the
amount
of
time.
The
issue
is
spent
with
a
particular
label.
I've
already
marked
that
as
not
selected
in
this
iteration
and
we'll
have
follow-up
conversations
on
that,
but
we
won't
expect
that
it
would
work.
It's
find
its
way
into
this
release.
A
C
C
So,
basically,
from
a
UI
perspective,
there's
not
much
new
to
expect.
We
have
code
review.
This
is
the
previous
filter
bar
that
or
the
leg
the
legacy
filter
bar
that
we
have
and
the
issue
I'm
talking
about
is
the
legacy.
Filter
bar
has
some
limitations,
especially
when
it
comes
to
adding
additional
filter
tokens
that
we
want
to
use
in
the
future.
C
So
at
the
moment,
it's
possible
to
your
smile,
stone
labels,
assignees
and
those
kind
of
things,
but,
for
example,
one
of
the
main
limitations
is
that
you
cannot
use
projects
or
groups
and
stuff
like
that.
So
the
reason
I'd
like
to
demo.
This
is
because
I
use
code
review
to
build
an
embassy
for
the
new
filter
bar
which
is
behind
a
feature
flag,
so
I
just
need
to
enable
the
feature
flick.
C
Only
thing
that's
missing,
for
the
new
version
is
the
recent
searches
lockdown,
so
this
is
not
implemented
yet,
but
other
than
that,
we
have
the
same
possibility
to
filter
by
token,
for
example,
to
filter
by
milestone.
So
that's
something
that
already
works
for
the
existing
version
and
also
works
in
a
new
version.
C
We
also
have
the
possibility
to
add
additional
tokens
easily,
so
we
could
easily
add
a
project
drop
down
at
a
project
token
or
a
group
token,
and
there's
also
something
that's
interesting
for
us,
especially
since
one
of
the
newer
features
that
we
will
be
working
on
is
adding
a
filter
bar
to
value
stream
analytics
we're,
ideally
in
the
in
a
follow
up
iteration
that
will
be
migrating.
The
project's
drop
down
to
basically
show
up
as
a
filter
option
in
the
filter
bar.
C
So
that's
something
that
the
new
filter
bar
should
allow
us
and
another
cool
thing.
That's
also
that
we
can
also
benefit
in
the
analytics
space.
Is
that
once
you
have
defined
those
filter
tokens
how
they
look
and
behave?
For
example?
In
the
milestone
token,
we
only
have
milestones
showing
up
as
plain
text,
whereas
on
the
label
token,
we
have
labels
with
the
corresponding
colored
rectangle
in
front
of
them.
C
So
once
you
have
defined
such
a
token,
it
can
easily
be
reused
across
the
entire
analytic
space
and
we
can
make
we
can
implement
the
filter
bar
from
scratch
for
particular
features.
But
the
tokens
is
something
that
we
can
reuse
easily
and
I.
Think
that's
something
that
we
can
benefit
in
in
other
in
other
features
as
well.
So
again
from
a
first
glance,
it's
nothing
and
the
look
and
feel
hasn't
changed
compared
to
the
existing
or
the
legacy
version,
but
the
technical
capability
is
way
better.
C
Now
in
terms
of
reusability
and
extended
behavior,
yeah
I
think
the
only
thing
that's
still
missing
and
that's
something
I'd
like
to
work
on
in
this
milestone.
Is
the
recent
searches
drop
down
to
to
the
existing
version
to
the
new
version?
So
yeah?
That's
that's
pretty
much.
It
yeah
one
question.
Actually,
maybe
for
you
John,
Mason
or
Nick,
do
you
think
it's
worth
enabling
this
for
the
gitlab
project
in
the
or
the
giblet
group
on
production?
C
B
I'd
be
interested
in
others,
points
of
view
on
this,
but
in
my
view
that,
having
that
reason,
searches,
dropdowns,
pretty
valuable
capability
and
I
think
people
might
miss
it
if
at
least
I
you,
you
know
when
I,
when
I'm
doing
searches,
I
use
it
all
the
time.
So
my
inclination
would
be
to
to
add
that
before
migrating,
okay.
C
D
C
This
milestone,
if
I
find
some
time
so
yeah,
but
I
understand
that
this
is
something
that
the
actual
the
current
implementation
of
code
review,
so
that
the
feature
is
part
of
the
current
code
review
page
so
taking
it
away,
might
upset
some
users
because
they
might
miss
it,
and
they
probably
feel
that
this
is
a
bug
or
they
don't
understand
the
reasoning
behind
why
this
drop
down
was
removed.
So
I
guess
it
makes
sense
to
it
longer
to
enable
this
feature.
C
C
A
I
mean
we're
kind
of
running
out
of
time,
so
let's
treat
them
mostly
as
FYI
I
guess
on
this
first
one
I
think
most
of
us
here,
possibly
all
of
us
here,
I'm
not
sure,
actually
have
not
been
through
an
annual
360
feedback
cycle
before
so
just
so
everybody
knows
it
stretches
over
a
few
weeks
and
I
asked
him
if
he
had
any
advice
because
he's
been
through
it
a
couple
of
times
and
he
said
be
sure
to
spread
that
work.
You
know
the
the
feedback
work
across
all
of
those
weeks.
A
C
A
D
So
I
have
I'm
more
I'm,
yeah
I'm,
more
confident
on
on
the
research
plan
now
so
what
I
want
to
do
is
just
quickly
show
you,
the
high
level
sort
of
thinking
for
the
agenda
of
what
we
test
and
then
the
the
actual
content
of
the
research
stimuli
just
to
quickly
validate
with
that
with
you.
So
the
stuff
I'm
building
is
sort
of
not
wasted
time.
D
D
I
have
removed
all
these
jobs
to
be
done
here
and
focused
specifically
on
this,
responding
to
notifications,
one
and
the
key
yeah.
So
this
one.
This
is
the
this.
The
primary
job
to
be
done
when
checking
in
on
my
team's
need
one
more
woman
team
needs
for
me:
I
want
to
quickly
identify
and
respond
to
the
most
important
notifications,
so
I'm
not
blocking
their
flow.
D
Validate
these
three
buckets
and
then
get
user
feedback
on
the
solution.
Ideas
related
to
this
and
then
also
understand
how
users
feel
about
certain
metrics,
real
art
ever
got
related
into
this.
The
specific
job
to
be
done.
These
are
the
four
ones
I'm
much
happier
now.
These
are
very
focused
and
I.
Think
I
think
it
it's
sort
of
very
clear
and
how
we
can
actually
address
that
so
based
on
that,
the
way
that
I
think
would
be
a
good
way
of
testing
this
is
we
go
into
a
discussion.
D
What
those
steps
are,
and
then
we
could
use
this
to
deep
dive
into
the
particular
steps
and
figure
out
what
the
current
pains
and
stuff
are.
So
that's
a
nice
visual
way
to
to
discuss
task
management
in
general
and
then
from
there.
We
can
use
that
as
a
way
to
actually
dive
into
specific
areas
such
as
to
do's
and
get
that
get
them
to
walk
us
through
to
deduce
and
then
get
them
to
walk
us
through
how
they
use
notifications
and
if
they
use
activity
as
well.
D
D
So
it's
easier,
you'll
live,
but
basically
get
them
to
organise
this
themselves,
get
them
to
like
organize
it
in
a
few
different
ways:
nope
and
then,
and
then
after
that,
we
go
into
a
closed
card
sort
where
we
take
the
same
cards
and
get
then
get
them
to
to
sort
them
into
our
predefined
called
buckets.
So
we
we
get
their
perspective
on
on
how
they
do
it,
and
then
we
test
out
our
perspective
as
well,
and
then
the
the
gap
between
that
and
the
difference
would
would
yield
some
quite
interesting
stuff
from
there.
D
We
then
go
into
testing
out
the
different
prototypes
and
different
research
stimuli
and
grouping
those
into
like
basically
a
story
and
a
flow
and
then
getting
them
to
sort
of
react
and
go
through
the
flow
and
comment
on
that.
So
the
first
flow
I
wanted
to
test
out
is
effectively
the
inbox
structure
and
like
the
the
concept
of
using
this
as
an
inbox
and
then
some
some
of
the
new
functionality
we
add
in
in
order
to
do
that
and
I've
started
prototyping
that
one
already
and
then
the
second
one
would
be
around
taking
action.
D
Based
looking
at
some
of
the
metrics
that
we
include
within
the
inbox
and
then
taking
action
on
those
in
some
way
and
then
understanding
we
can
bet.
We
can
include
some
like
potentially
risky
ones
like
comparing
your
productivity
to
your
team's
productivity
and
stuff,
and
that
could
spark
some
interesting
insights
and
discussion
and
then
finally,
and
then
finally
yeah.
D
B
A
good
there's,
a
lot
more
focused.
It
makes
a
lot
of
sense
to
me.
The
approach
that
you're
taking
I
think
it's
a
good
mix
of
open-ended
and
directed
kinds
of
it
exercises
that
are
going
to
give
us
the
breadth
of
information
we're
looking
for
so
this.
This
looks
great
I
think
the
magic
is
going
to
be
in
the
prompts.
You
know
what
are
those
particular
cards
that
we
have
them:
sort
I'll
go
into
the
mural
and
take
a
look
there.