►
From YouTube: Manage:Analytics Weekly Meeting 2020-04-28
Description
The Analytics group talks about blockers, "on deck" issues, and cool stuff from the past week.
A
B
B
The
demo
part
that
we
usually
had
on
our
agenda
is
that
we
wanted
to
give
the
opportunity
to
everyone
to
talk
about
interesting
problems
or
solutions
that
might
be
that
could
be
relevant
for
others
as
well,
doesn't
have
to
be
like
a
new
component
on
a
new
feature.
It
could
also
be
like
any
sort
of
technical
problem
that
you've
been
working
on,
and
you
wanted
to
talk
about,
or
some
design
that
you
wanted
to
share,
so
anything
that
you
can
think
of
it
doesn't
have
to
be
technical,
doesn't
have
to
be
a
technical
problem.
B
B
The
other
thing
that
that
we
thought
might
might
also
be
interesting
to
everyone,
since
we
already
have
the
new
on-deck
label
in
or
are
using
it
in,
our
team
would
be
to
have
a
dedicated
section
on
a
weekly
basis
in
our
agenda,
to
give
mainly
product
or
to
an
amazing
the
opportunity
to
maybe
share
some
interesting
on
the
little
issues
with
the
team,
so
doesn't
have
to
be
today,
but
maybe
that's
something
that
you
can
start
beginning
next
week
since
we
haven't
talked
about
this
yet.
B
But
I'm
just
wanted
to
introduce
this
idea
to
everyone
so
to
give
like
a
forecast
of
potentially
or
of
potential
issues
that
might
that
we
probably
have
to
expect
in
the
next
milestone,
and
we
have.
Obviously
we
already
had
a
bunch
of
issues
labeled
with
on
deck.
It
would
be
cool
to
have
like
a
brief
overview
of
some
of
those
issues
and
get
a
better
understanding
what
what
those
issues
are
about,
and
so
everyone
can
can
begin
to
those
issues
after
the
call,
if
they,
if
they
seem
interesting.
B
So
maybe
that's
something
that
would
be
and
on
your
agenda
in
the
future
jam
base,
and
if
that
makes
sense
to
you
then
and
I
just
talked
about
this
idea
last
weekend,
I'm
curious
how
everyone
else
on
the
team
thinks
about
this
agenda
item,
and
so
we
can
get
a
better
understanding
of
on
that
issues
and
they
don't
have
to
be
like
explained
in
too
much
detail.
But
to
get
like
a
brief
overview.
C
B
B
A
This
was
an
idea
that
John
Mason
had
so
right.
Now
the
number
is
27
that
are
open,
so
we
can
just
pop
that
in
there
27,
so
basically,
it's
just
a
way
and
maybe
John
Mason
can
elaborate
if
he
wants,
but
my
standing
was
that
this
is
way
for
us
to
just
kind
of
track
that
we
do
have
some
work.
That's
currently
the
attention
of
refinement
efforts.
D
Right
yeah,
part
of
what
I
really
want
to
do
is
help
kind
of
increase
the
strategic
density
of
what
we
deliver
every
every
month.
You
know
you
can
eat
calories,
but
they're
not
all
nutritious
same
thing.
We
we
can
produce
a
lot
of
work,
but
you
know
with
time
and
attention
the
work
that
we
produce
will
have
greater
and
greater
impact
in
the
marketplace
on
our
customers
and
we'll
start
to
see
that
as
you,
you
know,
usage
will
start
to
ramp
and
so
on.
D
And
you
know
part
of
increasing
the
kind
of
strategic
density
is
having
the
top.
You
know
good
stuff
prepared
that
we
have
a
lot
of
good
research
on
you
know.
Customers
have
already
expressed
an
interest
and
using
that
feature
as
soon
as
it
rolls
off
the
the
end
of
the
assembly
line
and
so
on,
and
so
that
all-
and
it
also
has
to
do
with
being
having
enough
stuff
that
we
can
make
good
decisions
and
say
well.
This
item
is.
E
D
B
Cool
yeah,
the
other
thing,
instead
of
instead
of
walking
the
board
we
figured,
it
might
might
be
a
good
idea
to
maybe
just
talk
a
little
bit
every
week
about
trend
blockers
that
anyone
is
experiencing.
So
it
seems
like
do
we.
Nobody
has
said
anything
to
the
agenda
under
this
item.
So
I
wonder
under
any
blockers
that
we
should
talk
about
this
week,
or
should
we
skip
it
for
this
week?.
F
B
F
F
However,
upon
reflecting
on
it
and
with
the
new
new
designs,
I
think
the
approach
of
keeping
them
both
both
there
is
not
a
viable
one
and
will
lead
to
a
lot
more
confusion
than
it's
worth.
So.
My
question
here
is:
is
it
worthwhile
hiding
this
behind
a
feature
flag
and
then
Brandon
basically
posed
this
question
to
to
John
Mason,
because
this
could
basically
impact
the
direction
that
would
that
we
talked
about
so
I'll
open
it
up
on
the
table.
F
B
F
B
D
B
The
good
thing
about
the
feature
flag
is
we
could
enable
it
for
a
particular,
so
we
would
have
it
like
enabled
for
the
kid
level
or
group,
while
other
groups
would
still
have
the
old
control
or
the
old
UI
in
place.
So
this
is
some
sort
of
a
be
test
with
like
within
different
groups,
but
still
it
enables
us
to
get
some
sort
of
user
feedback
without
rolling
out
the
future
to
everyone.
Yeah.
D
F
I,
like
that
and
bye-bye
dogfooding
and
using
the
feature
flag
just
to
share
it
with
get
lab
or
get
lab
team
members
I
think
that's
a
very
good
way
to
sort
of
start
testing
it
out
in
in
real
life,
rather
than
rather
than
just
showing
some
screenshots
and
reflecting
with
some
questions.
I
think
that's
a
good
idea.
F
B
E
B
Yeah
next
item
would
be
on
Dec
issues,
but
yeah.
This
is
a
fairly
new
item,
as
we
just
talked
about
so
John
Mason.
Do
you
have
anything
top
of
your
head
that
you
you
want
to
talk
about
on
like
about
current
on
that
issues,
or
should
we
just
skip
it
for
this
this
weekend
and
start
talking
about
on
Dec
issues?
Next
week,
I.
D
D
We've
been
working
on
some
adjustments
to
the
to
do
api's
and
the
next
step
in
that
is
actually
to
help
us
distinguish
which
action
resulted
in
the
closure
of
an
API.
This
one's
had
very
active
conversation
as
we're
trying
to
figure
out
what
the
what
new
fields
we
want
to
add
to
deduce
to
understand
what
action
actually
resulted
in
its
closure
who
closed
them
and
so
on,
and
that's
important,
because
it's
we're
trying
to
tease
out
what
the
user
was
really
trying
to
do.
D
D
D
D
One
of
the
things
that
Dan
asked
about
with
this
item
is:
if
we
couldn't
provide
some
more
use,
cases
and
Nick
has
provided
a
nice
image
here
of
one
example
use
case
of
how
this
API
would
be
used.
The
other
thing
that
I
have
been
doing
is
spending
some
time
with
our
insights
product
and
looking
at
how
would
if
we
were
to
migrate
all
of
insights
to
this
new
API
system?
How
would
it
work,
and
so
I
spin
up
a
new
epoch
to
sort
of
explore
that
question
here
called
my
great
insights.
D
Generic
to
the
generic
API
is
in
UI
to
explain
sort
of
what
would
it
look
like
if
we
used
this
generic
API
for
for
all
of
insights
and
I,
try
to
tease
out
here
sort
of
what
kinds
of
controls
in
insights
today
that
are
controlled
by
configuration
attributes
in
insights
yml
file,
how
they
get
reflected
in
either?
The
data
set
definition
API
or
a
background,
aggregator
or
wind
up
being
sort
of
a
front
in
control
and
like
in
order
to
help
us
explore
that
question.
I
produce
this
PDF.
D
That
goes
through
each
of
the
incites
charts
that
we
have
configured
today
in
the
at
the
group,
get
lab
group
level
and
then
showed
what
the
yml
to
configure
that
particular
chart
was
so
that
you
can
sort
of
see
some
very
specific
examples
of
how
that
aggregation
could
work.
So
all
of
the
attributes
in
these.
D
Yml
snippets,
then,
are
described
here
in
this
table
to
sort
of
explain
kind
of
how
that
how
that
would
work
so
I,
don't
think.
We've
completely
answered
the
question
that
Dane
has
about
examples,
but
we're
moving
towards
having
more
examples.
That
would
help
us
understand
our
approach
to
this
generic
metrics,
API
and
and
then
we'll
start
carving
it
into
little
pieces
where
we
can
actually
implement
a
whole
piece.
D
B
E
B
B
B
I'm
not
super
familiar
with
it's
all
the
data
that
we're
showing
in
the
chart
yet
but
yeah.
So
the
charge
is
here
we
get
and
a
bar
chart.
That
indicates
what
it
shows
us
the
tasks
by
type
and
based
on
our
current
selection
for
the
project
and
the
time
frame
and
yeah.
You
can
see
that
for
particular
dates.
B
E
B
I
think
front
end
is
already
one
of
the
selected
ones,
so
we
should
probably
add
a
different.
So,
for
example,
if
you
include
webpack
now
we
should
see
webpack
being
included
in
the
charts
but
I
think
yeah
there.
We
have
a
vector
issue
or
task
basically
and
I
think
we
can
also
switch
this
from
issues
to
merge
requests.
B
Instead
of
showing
the
charge
for
issues,
we
can
toggle
this
and
get
the
merge
requests
that
have
the
relevant
labels
assigned
to
so
overall
I
think
this
is
a
pretty
cool
feature
which
has
like,
or
at
least
allows
customers
to
use
it
in
many
different
ways,
by
switching
the
total
from
issues
to
merge,
requests
and
applying
different
filters.
Sorry
different
labels
to
it
yeah-
and
this
is
already
in
production
and
I-
think
it
should
be
enabled
by
default
in
in
this
milestone.
B
D
A
This
kind
of
ended
up
in
this
section,
I,
don't
know
if
it
really
belongs
here
which
is
about.
This
is
actually
sort
of
an
announcement
for
back
end,
which
is
self-assignment
of
p3
and
p4
issues,
so
P
ones
and
p2
s
are
still
getting
assigned
directly,
but
Adam
I
think
you're
the
only
back-end
or
on
the
call
at
the
moment.
So
just
you
know,
when
you
don't
have
p1
or
p2
work,
then
just
go
ahead
and
self
assign
your
stuff,
p3
and
p4,
which
I
think
you
were
already.
F
Wanted
to
say
big
thanks
to
Brandon
Brandon
I'm
working
on
the
the
path
component.
It's
looking
amazing
right
now,
it's
in
my
review
as
we
speak,
and
thank
you
for
tolerating
my
designer
nitpick
eNOS
and
helping
push
it
across
the
line
without
getting
too
angry
at
me.
So
it
looks
amazing
I
was
wondering
whether
you
could
give
it
a
quick
demo
to
show
everyone
else.
Oh.
C
No
problem,
I
was
gonna,
do
a
demo
next
week,
obviously,
because
if
you
can
change
a
lot
of
things
right
now
with
architecture
on
the
front
end,
but
that
shouldn't
change
anything
visually,
so
y'all
quickly
share
my
screen
and
see
what
we
got
so
here.
This
is
the
merge
request
itself,
but
I'll
just
actually
show
you
what
I've
got
in
the
story,
but
forget
lab
UI
here's
the
component
basically
will
just
receive
an
array
of
objects
for
what
needs
to
be
passed
through
to
it.
C
Yeah,
it's
mobile
responsibility
in
the
initial
version,
so
you
can
see
item
number
ten
just
popped
up
on
a
smaller
screen.
It
should
then
nicely
scroll
between
items.
She
make
that
even
smaller
yeah
and
it
should
scroll
quite
nicely
between
them
as
well
so
I
care.
But
the
fourth
item
I'll
become
the
first
item
in
because
it
was
partially
invisible.
C
B
Had
one
question
did
we
consider
because
these
also
effects
this
custom
stages
right,
so
we
would
also
have
custom
stages
to
appear
in
the
horizontal
navigations,
so
to
say
so.
What
would
happen
if,
like
a
customer,
has
like
a
really
long
name
with
like
400
characters?
For
some
reason,
are
we
going
to
truncate
that
at
some
point
or
what's
the
idea
behind
this?
Yes,.
C
That's
very
good
points:
I
haven't
yet
handled
anything
like
the
truncation
or
adding
metrics
to
it
or
custom
icons
or
anything
just
for
the
MVC
are
right
not
to
display
the
title,
but
it's
a
very
good
point
to
handle
truncation
on
long
names,
especially
because
you're
always
still
gonna.
Add
the
sorting
and
everything
like
that.
So
yeah
definitely
great
idea.
That
is
follow-up
item
cool.
B
F
And
it's
it's
great
that
we
also
make
the
time
to
work
on
components
for
pajamas
as
well,
because
from
a
lot
of
the
teams
that
I've
been
speaking
to
they're,
currently
just
constantly
accelerating
and
I'm,
not
taking
the
time
to
contribute
towards
the
design
system
which,
in
the
end
is
just
adding
two
more
UX
debt.
So
really
appreciate
that
our
team
is
prioritizing
this
sort
of
stuff.