►
From YouTube: 2022-12-14 - Dashboards working group
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).
B
A
I
would
but
my
internet's
very
bad
right
now
and
I'm
only
just
looking
at
the
issue
now
yeah.
B
We've
got
a
link
to
her
issue
where
she's
got
a
summary
comment
and
there
has
been
some
responses
on
that
comment.
B
The
takeaways
I
see
here
are,
regarding
the
regions,
says,
there's
often
a
way
to
control
The
View
on
the
page,
but
there's
a
lot
of
variation
across
the
products
in
terms
of
which
controls
are
used.
Sometimes
it's
a
path
component,
sometimes
tabs,
sometimes
drop
down,
sometimes
a
button
group.
So
that's
an
interesting
insight.
B
Many
dashboards
contain
tables
of
data,
meaning
they're,
not
just
charts
or
or
visualizations
some
dashboards,
but
not
all
have
filters
most
use
our
standard
filter
component
with
the
addition
of
most
recent
drop
down
option,
a
small
subset
also
uses
a
date
range
filter,
some
dashboards,
but
not
all
have
data
visualizations
most
of
the
data
visualizations
are
charts
with
area
charts
being
the
primary
chart,
type
used,
some
column
or
line
charts
are
also
used.
In
addition,
okay,
some
dashboards
include
additional
data,
visualizations
ones
that
serve
more
as
a
page
overview
summary
call
out
visualization.
B
Also,
if
anyone
has
anything
to
say
on
these
jump
in
as
I'm
going
through
and
then
all
the
dashboards
are
in
the
Box,
all
the
dashboards
reviewed
are
out
of
the
box
dashboards
with
no
ability
to
customize
Beyond
filtering.
Although
the
now
deprecated
metrics
dashboard
did
allow
for
the
creation
of
a
custom
dashboard.
So
there
is
a
precedent
for
that
in
the
product.
C
I
think
the
observability
team's
grafanovork
will
allow
for
custom
dashboards
and
that's
kind
of
why
I
think
that
other
metrics
dashboard
that
she
talks
about
will
be
deprecated,
because
this
will
such
a
be
replacing
that
okay.
D
B
E
B
B
We
haven't
executed
it
yet
at
gitlab
in
a
consistent
amazing
way,
but
that
does
sound
like
a
really
big
theme
and
then
there's
been
a
lot
of
tries
to
like
I've,
been
here
three
years,
but
there's
been
a
few
times
where
people
try
to
get
dashboards
out
and
it
just
doesn't
really
take
so
I
hope
we
could
align.
If
we
all
jump
on
the
same
solution
or
similar,
we
could
probably
move
but
move
us
down
the
line,
a
lot
faster.
We
can
get
aligned
and
how
we
customize
okay.
B
So
there's
a
lot
of
opportunity
to
standardize
customization.
For
instance,
we
have
page
controls,
we
Define
a
standard
page
control
to
use.
If
we
want
to
have
a
summary
or
call
out
information
on
the
page
we
could
Define,
which
component
to
use
by
default.
These
kinds
of
decisions
would
help
improve
consistency
of
the
dashboard
experience
across
the
product
question.
D
Yeah
so
I
I
was
leaning
towards
what
well
is
answering
right
now,
but
I
wanted
him
to
say
because
he
knows
statistics
better
than
me.
C
C
I'm
sure
that
we've
probably
gotten
like
the
bigger
you
know
themes.
You
know
through
Amelia's
analysis,
but
we
might
Identify
some
other
things
along
the
way
that
are
they're.
C
B
A
A
E
B
C
If
I
weren't
going
on
vacation
the
next
couple
days,
I
would
definitely
take
you
up
on
that.
I
mean.
Is
this
something
that
could
be
done
like
next
week,
potentially
because
I
might
have
a
little
bit
of
time.
A
B
G
B
G
Initially
posts
this
this,
these.
G
She
wrapped
up
here,
she's
reviewing
what
we
currently
have
in
gitlab
right,
the
dashboards
and
I
was
suggesting.
Should
we
also
consider
and
I
think
that
makes
sense
that
recommendation
here
in
general
makes
sense,
but
should
we
also
consider
what
we
want
to
do
with
the
dashboards
in
the
future,
because
we're
quite
Limited
at
the
moment
what
we
do
with
the
dashboards?
We
have
a
lack
of
consistency.
We
use
these
regions,
which
are
mostly
100
in
width
right,
so
there's
a
lack
of
flexibility
there
as
well.
G
So
we
need
to
improve
how
we
do
our
dashboards
and
we
are
we're
and
when
I
say
we
plan
optimize
we're
exploring
what
these
dashboards
could
look
like
in
the
future
and
I
know.
Product
analytics
have
been
experimenting
with
the
with
a
fully
customizable
dashboard.
So
should
we
consider
those
things
as
well
so
that
we
don't
limit
ourselves
too
much
to
what
we
already
have
and
what
we
already
do?
G
B
Side,
I
think
we
should
consider
it
so
that
we
have
flexibility
moving
forward
and
that
might
be
the
next
phase.
B
B
A
No
I
think
that'll
be
the
next
step
for
sure.
I
was
just
checking
the
goals
of
the
working
group
to
make
sure
that
still
fell
in
line,
but
I
think
part
of
it
is
defining
what
a
dashboard
isn't
isn't.
I
think
that's
part
of
the
conversation,
so
at
the
same
time,
dafana
offers
a
full
Suite
of
visualizations.
A
We
also
use
e-charge
as
well,
which
has
plenty
of
visualizations
to
work
with
as
well
that
we've
already
been
using
in
various
dashboards,
so
it'll
be
good
too
yeah
definitely
chart
where
we're
at
currently,
but
then,
with
the
different
groups,
experimenting
kind
of
reconcile
all
of
that
to
to
Define
what
we
can
and
can't
do
with
dashboards,
at
least.
B
All
right
from
the
the
last
comment
here,
she's
got
an
issue
comment
that
she's
linked
to
this
thing
is
the
same
one
The
Next
Step
should
be
our
first
output
here,
as
a
group
could
be
descriptive.
We
could
spell
out
that
in
gitlab
these
elements,
these
are
the
elements
that
dashboards
contain.
B
We
could
also
start
potentially
defining
which
components
people
can
consider
using
for
different
sections
of
the
dashboards,
for
example,
for
page
navigation,
we
could
recommend
using
X
component
for
summary
call
out
information.
We
could
recommend
using
Y
component.
We
could
document
all
this
information
in
pajamas.
This
feels
like
it
would
be
a
reasonable
next
step
and
potentially
the
outcome
of
this
working
group.
B
E
E
We
also
still
haven't
just
find
what
we're
going
to
call
all
these
things,
which
is
another
thing
we
kind
of
need
to
do
before
we
start
documenting
it
on
pajamas
I
feel
like
this
is
that
the
output
would
be
a
great
output
to
have
and
something
we
should
definitely
do,
but
if
it
was
like
the
step
after
what
we
need
to
do
right
now,.
E
B
E
A
Yeah
I
was
just
gonna.
Ask
like
I
agree
that
these
are
important
next
steps,
I
just
wonder
if
it
makes
sense
to
put
in
pajamas
yet
or
whole
until
we
have,
because
we
want
a
inventory
everything
we
have
inventory,
what
we
want
to
do
in
the
future
and
so
I
think
there's
a
lot
of
changes
that
are
going
to
be
happening.
A
A
lot
of
editing
happening,
I,
wonder
if
it
makes
sense
to
hold
off
on
putting
it
into
pajamas
until
we
have
have
kind
of
like
a
final
list
of
or
or
more
complete
list
of,
here's
what
we
have
and
here's
what
we
want
and
the
naming
of
all
that
and
the
description
of
what
they're
supposed
to
do
in
terms
of
functionality
before
we
throw
it
into
Atlanta
pajamas,
just
in
the
interest
of
like
iterating
quickly
on
it.
B
A
A
B
A
F
B
B
B
F
It
kind
of
depends
on
how
they're
going
to
be
used
in
design
right
now.
Anything
we
have
is
has
pretty
low
usage
so
and-
and
these
are
generally
pretty
time
consuming
to
build
and
maintain
so
it's
it
might
be
one
of
those
things
where
if
we
need
to
we
need
to
otherwise,
if
it's
in
gitlab
UI-
and
we
can-
you
know
a
designer-
could
take
put
in
their
data
with
with
properties
and
take
a
screenshot
and
use
it,
then
that
could
be
helpful
too.
So.
B
B
F
Yeah
and
and
for
something
like
this
well,
it
kind
of
depends
on
on
the
approach.
I
would
leverage
figma
more
for
maybe
design
specs
that
get
rolled
up
into
gitlab
UI
and
then
are
pulled
into
pajamas
rather
than
trying
to
reflect
a
final
design
state,
so
it
it
might
be
more
on
the
exploration
side
and
it
might
get.
F
You
know,
be
stuff,
that's
just
artifacts
that
we
just
throw
away
later,
but
that's
the
other
approaches
it
might
be
better
to
just
use
figma
for
that
design,
spec
initially,
and
then
rely
on
the
code
that.
B
H
Sure
yeah
I'll
quickly
talk
through
my
points.
I
just
wanted.
This
is
more
like
an
FYI.
That's
on
that
issue,
I've
added
another
design
for
the
dashboards
that
product
analytics
is
busy
building
and
the
concept
for
it
so
yeah.
This
is
specifically
for
reusable
dashboards.
So,
as
was
previously
mentioned,
plan
optimize
is
also
thinking
of
using
this
because
we're
creating
it
as
a
shared
component
first
and
then
implementing
it
specifically
for
product
Analytics
and
yeah
I've
I've
mapped
out
the
regions
there.
H
The
good
things
is
that
there
isn't
much
like
differences
between,
like
all
the
other
dashboards,
we're
trying
to
stick
to
what's
being
done
as
much
as
possible
and
I
think
we're
at
a
stage
where
one
of
the
biggest
things
that
we
just
need
to
pin
down
right
now
is
like
the
nomenclature
and
just
make
sure
that
we're
consistent
across,
like
all
reusable
dashboards
on
what
we
call
things
but
yeah.
Please
have
a
look
on
that
design
and
feel
free
to
leave
comments.
B
I,
don't
know
if
Amelia
called
it
out,
I
might
have
missed
it,
but
it's
breadcrumbs
a
normal
I
noticed
that
on
a
few
of
them,
it's
talking
about
a
breadcrumb
in
the
dashboard,
not
the
gitlab
breadcrumbs.
Is
that
correct,
because
we
do
have
that
as
a
part
of
our
main
navigation
in
git
lab
there's
a
breadcrumb
at
the
top.
A
lot
of
pages.
H
Yeah
my
my
understanding
here
is
that
this
is
like
elapsed.
Bridge
crumbs,
that's
one
of
these
two
jars,
just
showing
basically
all
the
page
elements,
but
it
could
be
different
for
other
cases.
F
E
A
E
Think
in
the
gitlab
UI
it's
a
steps
component
I
believe
that
element.
We
don't
have
that
breadcrumbs
element
that
is
on
all
pages
is
specific
for
page
navigation,
it
shouldn't
be
used
for
internal
in
a
component
navigation.
B
A
I
ordered
did
matter,
but
I
don't
know.
If
that's
it's
supposed
to
be
like
your
entire
workflow
technically
so.
E
G
A
lot
of
people
actually
find
us
confusing
and
we
want
to
redesign
that
part
completely,
but
we
just
haven't
had
time
to
pick
that
up,
but
we
do
know
that
it
is
a
bit
confusing
and
we
need
to
change
that.
So
it's
more
clear
that
these
are
actually
steps
that
one
follows
the
other
we'll
get
there.
B
E
A
That's
part
of
the
work
we'll
have
to
figure
out
with
customizability
is
there's
going
to
have
to
be
some
training
wheels
or
guard
rails
to
let
people
know
that
they
might
be
confusing
themselves
or
going
out
of
the
bounds
of
what
we
can
provide
yeah,
but
yeah.
G
G
D
G
B
B
B
A
B
Yeah
so
I
don't
think
the
sales
in
CS
should
be
a
blocker,
although
I
do
have
those
issues
open
with
them.
I
think
that
the
investigation
of
our
internal
product
has
been
done
just
thinking
out
loud.
We
just
defined
today,
though,
that
we
wanted
to
look
at
the
libraries
that
we
have
in
git.
Labs
such
as
grafona
and
e-charts
was
mentioned,
so
maybe
we
need
to
do
some
investigation
on
those
two
and
that's
still
a
part
of
Investigation.
B
G
G
B
D
D
B
D
D
B
Oh
yeah
I
wanted
to
mention
on
the
sales
and
CS
issues.
Sales
hasn't
been
responsive,
I've
got
one
thing
back
from
CS,
but
I
was
going
to
today
go
through
chorus
and
see
if
I
can
find
these
words
in
conversations.
B
So
looking
down
the
list
that
we
already
have
words
like
dashboards
panels,
I
was
just
going
to
get
a
count
of
how
many
times
customer
calls
have
those
words
in
them
in
the
last
like
90
days,
and
that
might
be
a
way
we
could
vet
in
the
future.
Let's
say
we're
not
sure
on
what
to
call
something
if
we
can
find
them
in
customer
calls.
We
could
maybe
also
see
how
our
customers
think
about
them,
but
I
won't
put
all
my
faith
in
chorus,
but
it's
just
something
I'm
thinking
of
trying.
B
It
just
these
can
kind
of
overlap
but
mapping
the
pieces
and
then
getting
into
actually
writing
the
definitions.
I
feel
like
if
we're
already
starting
a
spreadsheet
or
like
writing
down
what
these
things
are.
We're
kind
of
building
the
definitions
as
we
go,
which
is
good.
E
We
should
with
investigation,
we
should
have
Matt
pretty
much
mapped,
almost
everything
we
just
need
to
categorize
what
we've
found
more
or
less.
Don't
we,
so
it
shouldn't
take
too
long
to
do
the
map.
But,
as
you
said,
the
definitions
is
going
to
take
a
while.
B
D
B
So,
let's
see
who
can
join
on
that
call,
but
I'm
sure
many
of
us
will
be
off
and
I
won't
be
joining
December
end
of
December,
sir
I
guess
we
can
do
this
async,
but
in
the
absence
of
me
whoever's
on,
we
should
just
make
sure
that
someone
records
and
does
all
the
things
so
I'll
before
I
leave
I'll
kind
of
make
a
slack
ask
to
see
who
could
run
them
if
anyone
is
planning
on
going,
maybe
update
your
attendance
on
the
calendar
events
and
if
you
aren't
going
to
join
due
to
holidays,
just
do
a
no
on
that
and
then
I'll
just
help
me
see
too.