►
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
A
All
right
so
nick
marcel
and
I
wanted
to
bring
you
up
on
board
because
we
actually
both
scheduled
separate
meetings
to
chat
with
you
when
we
realized
hey
we're
talking
to
him
about
the
same
thing
in
like
a
two-hour
span,
so
we
thought
we'd
join
it
all
into
one.
So
the
what
sparked
all
this
was
last
week,
sid
had
a
proposal
of
ex
you
know.
Testing
are
some
of
our
navigation
changes
about
taking
the
theory
of
us
embedding
settings
links
within
the
left,
nav
and
he's
like
you
know.
A
There
was
another
thing
that
was
going
on
with
analytics
last
year.
You
created
this
video
about,
like
you
know,
potentially
integrating
dashboards
within
within
the
product
itself,
so
under
project
issues,
merge
requests.
That
would
be
a
dashboard
link
and
he
he
took.
He
took
a
stab
of
creating
a
proposal,
and
then
we
took
a
look
at
some
of
that,
but
for
me
personally,
that
came
out
of
that
field
as
in
like
so
far,
I've
been
like
so
into
settings.
B
So
in
that
video
I
sort
of
referred
to
objects,
so
that
was
using
the
the
model
of.
If
we
create
these
two
types
of
objects,
one
being
a
report
and
one
being
the
dashboard,
can
we
somehow
standardize
and
white
label
these
these
types
of
pages
in
a
way
where
they're
just
reusable?
And
you
don't
need
to
build
a
new
page
every
time
you
want
to
get
some
data,
you
just
whack
it
in
there
configure
some
things
and
then
bada
bing
bada
boom.
You
have
a
page
with
some.
B
Some
data
sets
in
there
that
approach
of
having
this
sort
of
universal
way
of
collecting
data
from
an
api
and
then
a
universal
way
of
presenting
it
through
reports
and
dashboards
doesn't
really
fit
into
the
the
zeitgeist
of
gitlab.
Let's
say
so.
That
was
quite
difficult
to
implement
and-
and
I
think,
we've
sort
of
we've
pivoted
away
from
that
approach
and
we're
going
with
a
a
more.
B
We're
going
with
a
more
iterable
approach,
iterative
approach,
which
is
sort
of
based
on
using
value
stream
as
the
overarching
lens
of
of
how
we
or
order
and
and
and
frame
our
analytics
pages
and
with
the
general
idea
of
the
optimized
team.
We've
only
got
two
front
end
and
two
back
end
engineers,
and
we
don't
really
have
too
much
time
or
effort
to
contribute
to
anything
other
than
devops
adoption
and
and
devops
adoption
and
value
stream
analytics.
So
the
idea
is
we.
B
We
have
some
ideas
for
templates
and
ways
of
presenting
data
in
a
standardized
way
at
the
stage
level
and
at
the
object
level,
but
from
there
we
need
to
rely
on
basically
other
teams
to
to
create
those
pages.
So,
for
example,
like
ci
cd
analytics,
which
is
like
a
stage
level
analytics,
is
being
contributed
toward
towards
by
like
the
release
team
and
all
that
sort
of
stuff,
because
we
we
can't
cover
every
single
piece
of
analytics
in
the
product,
so
that
makes
it
a
little
bit
complicated,
I'm
going
on.
B
But
what
I'm
trying
to
get
at
is
it's
complicated,
because
the
analytics
pages
that
live
across
the
project
and
group
level
and
instance
level
are
not
consistent,
because
we
just
don't
have
the
resource
to
to
distribute,
to
enable
and
ensure
that
there's
sort
of
consistency
across
these
levels
that
diagram
that
marshall,
yeah
marcel's
based
is
is,
is
the
one
that
I'm
sort
of
referring
to.
But
that's
that's,
that's,
basically,
the
the
current
state
of
analytics
at
the
moment,
so
it
sits.
B
It
doesn't
really
fit
too
nicely
within
our
navigation
model,
because
our
navigation
model
is
sort
of
very
object-oriented,
whereas
vsa
inherently
is
a
meta-analytics,
something
that
overarches
lots
of
stuff.
So
we
have.
We
have
three
types
of
analytics.
We
have
the
analytics
at
the
object
level
analytics
at
stage
level
and
analytics
at
like
the
sort
of
meta
level
or
the
executive
level,
depending
on
whatever
you
want
to
call
it.
C
B
B
Let
me
think
so,
broadly
speaking,
you
can
have
two
types
of
analytics
categories
within
within
devops.
You
could
have
one
which
is
like
the
looking
at
analytics
data
retroactively,
so
like
looking
at
the
past
three
months
to
understand.
What's
going
on
and
from
looking
at
the
past
three
months,
you
can
start
to
see
different
patterns
and
trends
and
that
helps
you
to
develop
and
understand,
like
a
more
strategic
point
of
view.
B
B
So,
if
you
look
at
the
issues
analytics
and
the
mr
analytics
right,
there
they're
both
displaying
data
around
what
is
currently
in
flight.
With
regards
to
mr
analytics
or
what
is
currently
in
flight
with
regards
to
issues
and
from
there
providing
some
data
points
to
help
you
identify
outliers,
so
you
can
then
jump
on
top
of
it.
C
C
B
A
Yeah,
I
can
see
how
you
kind
of
frame
that
around
the
ic
kind
of
and
go
with
issues
and
merge
requests,
because
this
is
actually
the
first
time
I
actually
looked
at
analytics
on
myself
and
I
see
it
as
like.
Oh,
this
is
actually
kind
of
cool
from
a
you
know,
like
I'm
tracking,
my
performance
and
stuff
and
like
I
have
a
lot
of
issues
that
are
like
almost
a
year
old.
So
that's
like.
Oh.
B
A
You
know
what's
wrong
with
that,
and
you
could
be
using
that
in
a
coaching
perspective
or
like
optimizing,
my
own
workflow
kind
of
thing,
so
yeah
really
interesting
and
I
think
that's
kind
of
the
case
where
it
is
what
it
is
now
and
but
like
it
could
be
so
much
more
but
like
where,
where
that
path
is,
is
kind
of
like
to
be
determined.
You
know
like
yeah,.
B
A
B
And
I
and
just
yeah,
to
add
a
little
bit
more.
The
reason
I
said
sort
of
like
dev
leads
and
ics
is
because
all
these
analytics
pages
are
facilitating
team
collaboration
in
some
way
or
another.
So
even
if
an
engineering
manager
is
looking
at
a
bunch
of
issues
which
is
within
his
team
or
her
team,
then
they
still
want
to
collaborate
with
like
they
want
to
drill
into
the
individual
issues
from
those
individual
contributors
and
collaborate
with
them
around
that
in
some
way
or
another.
B
A
C
Because
I
thought
it
might
be
a
bit
helpful
to
also
give
you
nick
a
bit
of
an
introduction
into
why
we
have
made
certain
changes
and
our
long-term
philosophy
to
then
really
start
discussing.
How
could
this?
How
could
this
maybe
fit
into
some
of
the
long-term
proposals?
So
I'm
gonna
share
my
screen
and
up
to
14.0.
C
We
have
really
been
working
on
consolidating
making
things
easier
to
overview,
making
things
more
predictable
and
when
you
look
at
especially
this
great
comparison
that
michael
created,
this
was
our
current
version.
You
have
the
entire
left,
sidebar
and
so
much
stuff
is
hidden.
Even
when
you
have
just
a
small
portion
open
like
issues
where
there
are
just
six
menu
items
here.
Yeah
and
things
like
settings
are
constantly
hidden
behind
something
unless
you
have
a
really
large
screen.
C
C
Where
teams
work
around
this
problem
of
exposing
too
many
items
on
the
left
sidebar
by
hiding
them.
If
we
look
at
our
most
most
popular
most
popular
open
source
projects
like
you
can
see,
they
have
disabled
a
large
ton
of
menu
items.
Here
we
don't
know
for
sure
whether
this
is
just
for
external
users
or
whether
this
is
also
disabled
for
internal
team
members,
but
it's
a
problem
that
we
take
away
the
opportunity
for
each
team
member
to
explore
these
areas
just
because
one
person
decides
that
they
shouldn't
see
this.
C
C
A
second
proposal
that
we
are
currently
looking
at
is
a
very,
very
crazy
idea.
We
started
playing
around
with
this
a
couple
of
days
ago,
where
we
used
the
same
pattern:
that,
coincidentally,
also
firebase
users,
where
they
push
the
menu
items
we
would
have
in
the
sub
menu
on
the
left
sidebar
as
tabs
onto
the
page.
So
you
still
have
only
authentication
but
then
sign
in
method
templates
and
similar
to
analytics
usage.
C
If
we
combine
these
two,
these
two
long-term
ideas
we
already
have,
we
could
even
look
at
what
would
happen
if
we
go
to
these
life
cycle
buckets
and
then
also
work
with
the
tabs
on
pages.
That's
something
that
catherine
also
has
here
as
another
proposal
where
you
would
see
that
previously.
If
we
looked
at
like
the
build
lifecycle
bucket,
it
would
have
10
items,
which
is
a
large
number
and
we
could
go
down
to
something
like
5
with
repository.
Merge
requests
the
icd
registries
snippets.
C
B
So
I
can
definitely
sort
of
see
a
a
future
vision
for
navigation
alignment
with
this
quite
nicely
with
regards
to,
like
the
the
progress
that's
been
made
on
it.
So
far,
like
I'm
gonna
start,
we've
got
like
a
rough
storyboard
of
of
what
we
want
to
work
on
so
far,
just
like
the
general
beats
within
the
story
of
who's
gonna
be
doing
what
and
then
I
think
this
week,
I'm
gonna
start
to
visualize
some
stuff
out
and
make
some
details.
B
B
It
makes
sense
like
the
one
thing
that
I've
always
struggled
with
with
with
this
sort
of
stuff,
with
trying
to
organize
and
and
like
reconcile
the
the
the
different
features
within
gitlab
stages
is
like
this:
the
the
the
clusters
and
stuff
that
you've
you've
you've
outlined.
There
definitely
makes
sense,
but
then
there's
also
like
the
the
way
that
marketing
describes
the
different
devops
stages
and
stuff
as
well.
So
there's
always
the
potential
for
for
the
confusion
in
that
area,
where
you're
just
like.
B
We
don't
really
even
talk
about
the
default
stages,
all
that
much
within
the
product.
So
that's
that's.
That
was
the
first
thing
that
jumped
out
to
me
there.
What
you
show
it
makes
sense
with
regards
to
the
tab
vision
it
it
instantly
made
me
feel
like.
Oh,
I
don't
know
about
that,
because
I
use
tabs
quite
a
bit
within
within
analytics
pages,
so
having
tabs
within
tabs
nested,
and
all
this
sort
of
stuff
makes
me
a
little
bit
hesitant
to
to
sort
of
introduce
that
potential
complexity.
B
The
general
idea
of
the
story
is
going
to
be
starting
out
with
some
sort
of
high
level
initiative
or
idea
within
the
video
games
industry
and
showing
how
work
then
gets
done
throughout
the
entirety
of
of
gitlab
and
the
value
stream.
To
take
that
idea
and
initiative
from
an
okr
all
the
way
into
into
deployment
and
measuring
the
results
of
that.
C
Yeah
that
makes
complete
sense,
and
I
100
agree
with
you
on
the
potential
confusion
between
the
marketing
stages
and
our
own
stages,
because
I
don't
even
know
whether
it
would
be
a
good
idea
to
propose
something
like
create
and
plan
could
be
confusing
to
users
just
because
we
have
aligned
in
this
way
and
then,
if
we
don't
do
it
yeah.
I
can
absolutely
see
that
point.
C
C
B
Although
it
felt
to
me
a
little
bit
flawed,
based
on
the
fact
that
probably
asking
users
to
navigate
to
pages
that
they'd
never
navigate
to
anyway,
so
I
think
yeah
like
I
haven't,
conducted
any
research
around
the
ia
for
the
navigation.
But
some
of
the
stuff
that
katherine
did
may
have
touched
upon.
That.
C
Yeah,
it
did
on
the
settings
side.
So,
for
example,
where
would
you
go
to
change
the?
I
think
it
was
the
protected
branch
for
the
merge
request
area
and
my
what
I
would
now
love
to
have
is
understanding
is.
If
we
move
analytics
to
these
contextual
settings,
does
that
not
only
make
sense
for
users
from
a
pure
like
ia
perspective,
but
is
that
also
where
they
would
navigate
to
or
would
they
actually
continue
moving
to
analytics?
C
B
Like
yeah
understanding
the
user
mental
model
for
for
analytics
structure,
as
opposed
to
our
sort
of
just
general
ia
yeah,
it
makes
sense.
I
don't
know
whether
I'd
be
able
to
lead
that
at
all.
Basically,
I'm
going
to
be
doing
some
currently,
I'm
standing
in
furlers
who's
out.
So
I
haven't
got
much
time
for
design
at
the
moment,
but
yeah
like
I'd,
be
happy
to
help
shape
the
help,
shape
the
research
plan
and
and
provide
some
input.
But
I
don't
know
whether
I'd
be
able
to
like
leave
that
at
all.
C
A
That
sounds
like
a
great
plan
because
we're
probably
testing
this
structure
versus
some
other
structures
of
our
nav.
I
think
there's
a
difference
between
tree
testing
and
in
like
navigation
testing
with
the
ui.
So
I
think
if
we
can
set
up
a
few
scenarios
that
are
constant
across
the
three
like
from
the
tree
test
to
to
this
one,
to
this
idea
to
your
tabs,
then
we
can
probably
do
some
analysis
on
that
to
see
what
we
can
get
out
of
that
so
yeah.