►
From YouTube: 2023-01-18 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
A
C
A
C
And
what
actually
that's
that's
interesting,
I
kind
of
just
like
in
the
dashboard
also
be
a
term
for
its
own
category,
like
I
kind
of
like
I,
don't
know
in
last
last
week's
discussion
that
I
think
it
was
last
week
I
kind
of
thought
of
dashboard
as
that
root
container,
but
I.
B
D
E
C
Yeah
never
mind
go
ahead.
I
was
thinking.
I.
Think
optimize
is
working
on
multiple
visualizations
per
panels,
but
I
think
that
is
explicitly.
You
know.
One-To-Many
panels
to
visualizations
I
think
we
can
all
agree.
These
are
all
containers,
you
know
containing
child
objects,
but
I
think
calling
the
specifically
root
panel
I
would
be
okay,
calling
this
root
container,
but
I
would
also
just
say
dashboard
as
well,
because
if
we
couldn't,
if
that's
or
if
that's
too
much
root
container
would
make
sense,
is.
A
C
I,
wouldn't
want
to
say
it's
not
I
mean
it's
certainly
possible.
I,
just
can't
imagine
a
case
where
that
would
be
like
absolutely
necessary
or
not
confusing
to
the
user.
I
think
I
I,
don't
know.
If
that's
the
goal
of
this
working
group
to
like
Define,
what's
sensible
limits
or
not
at
some
point
like
product
analytics,
wants
to
have
embeddable
panels
and
dashboards
and
theoretically
you
could
put
you
know
if
you
really
wanted
to
four
dashboards
in
a
single
page,
but
I
think
what
I
would
assume
for
the
average
user.
A
I'm
thinking
about
like
our
Pi
reviews
and
product
I,
don't
know
if
any
of
you
have
gone
to
those
it's
a
huge
long,
yaml
page
but
like
each
each
team's
graph
or
dashboard
gets
pulled
up
onto
that
big
roll
up.
So
it's
like
there
could
be
a
world
where
even
a
higher
level
thing
is
created,
and
maybe
it's
not
called
dashboard,
though
it
could
even
be
like
canvas
or
something
more
General,
something
where
you're
like
pulling
higher
level
things
together
for
an
executive
report
or
something
like
that.
But
yeah.
C
That's
something
where
I
would
imagine
we
would
use
views
for
where,
like
you
know,
we
have
like
pis
for
different
contexts
or
groups,
and
then
you
can
roll
it
up
to
an
overview
using
the
same
data
set,
which
would
be
that,
like
high
level
rolled
up
like
initial
View,
and
then
you
can
dive
deeper
into
it.
But
I
would
still
liken
that
to
like
One
dashboard,
given
that
it's
like
trying
to
deal
with
one
data
set
around
performance
indicators,
but
I
mean
I.
Guess
that's
a
conversation
for
a
later
time.
A
So
we
have
the
suggestion
of
instead
of
root
panel,
just
call
it
dashboard
or
call
it
root.
Container
I
I'm
not
really
sure
how
to
see
like
blame
on
this,
like
who
suggested
root
panel,
but
I
liked
it
from
from
the
idea
that
panels
and
dashboards
have
very
similar
characteristics
like
titles,
unique
IDs,
sometimes
having
filters
I
get
why
maybe
that
was
added,
but
I
think
it
does
get
kind
of
confusing.
You
need
the
container
around
the
panels
to
be
dashboards.
C
A
A
D
Yeah,
it
looks
to
be
one
of
your
group
sessions
where
you,
where
you
all
were
working
for
it.
While
I
was
on
holiday
from
the
version
history
I've
seen.
A
C
A
A
D
From
a
pragmatic
sense,
Au
dashboard
will
be
a
grid,
a
recitable
redragable.
You
know
editable
Grid
in
some
ins
in
MO
a
lot
of
instances,
so
we
wouldn't
you
wouldn't
be
able
to
have
just
a
static
floating
bit
of
text
content.
D
C
C
Text
content
would
have
to
be
at
a
panel,
because
panels
are
what
we
use
to
define
the
dimensions
of
you
know.
This
takes
50
of
the
entire
dashboard
width
and
is
excuse
me
x,
amount
of
rows
or
like
rows
high,
and
things
like
that.
So
even
if
you
wanted
to
have
a
text
heading
similar
to
size
sense
where
it's
like
I
want
this
to
be
like
large
or
stand
the
entire
width
of
the
dashboard,
we
would
be
treating
that
effectively
as
a
panel
at
least
programmatically
for
product
analytics,
Beyond
Rod.
Correct
me.
D
You're
not
wrong
mate
from
optimizer's
point
of
view.
Would
you
ever
have
a
content
text
content
outside
in
the
way
described
having
it
as
a
way
of
separating
a
dashboard,
so.
F
Outside
of
our,
whether
we
call
them
panels
right,
not
widgets,
a
text
outside.
F
I
mean
titles,
yes,
maybe
but
texts
like
paragraphs
I
can
can't
think
of
a
why
that
would
be
useful,
but
titles
I
can
see
yeah
where
you
would
be
able
to.
You
know,
put
a
title
somewhere
in
the
dashboard
and
all
the
widgets
below
that
are
some
are
related
to
that
title,
visually
speaking,
right
and
then
below
it.
Maybe
you
have
another
title
where
you
have
another
one
in
another
column
in
another
area
of
the
dashboard
I
think
that
could
be
useful.
Yeah.
A
C
They
are
resizable,
though,
like
I
use
them
as
kind
of
annotations
in
some
of
the
dashboards
I've
built
in
sizeense.
C
A
D
I've
also
seen
it
used
as
a
way
of
like
a
next
to
a
chart
or
visualization
to
describe
what
you
are
trying
to
visualize
or
what
you're
expecting
to
see
out
of
that
data.
What
maybe,
what
the
thresholds
are
stuff.
F
C
You
can,
we
are
programmatically.
Treating
panels
like
the
panels
are
what
you
can
put
in
the
grid
and
resize
so
I
believe
the
the
topic
is,
you
know
we
think
text
content
is
useful,
it's
just
how
do
we
treat
it
as
far
as
is
it
do
they
belong
in
panels
or
not,
and
and
programmatically
at
least
with
how
product
analytics
is
defining
it
is
that,
if
anything
is
you
know
resizable
within
the
grid,
then
it
is
technically
a
panel.
C
So
if
I
were
to,
you
know,
build
a
dashboard,
I
would
add
a
panel
and
then
add
text
content
in
that
panel
to
be
able
to
represent
like
format
it
such
that
it's
a
heading
or
an
annotation,
or
a
description
of
a
chart
or
sorry
visualization.
A
F
C
C
D
D
B
A
C
C
Agree
with
that
so
like
chart
spreadsheet
wise,
like
it,
belongs,
underneath
panel
text,
content
would
be
effectively
whether
you
really
believe
it
or
not,
visualization,
which
you
could
argue
some
answers
on
that,
but
at
the
end
of
the
day,
coming
out
to
how
the
user
interacts
with
it.
That
could
be.
You
know,
a
combination
thing
that
happens
where
they
don't
actually
have
to
manually,
add
the
panel
and
then
manually
add
the
text
content
so
I'm,
bringing
it
back
I
think
it
would
just
belong
under
a
panel.
Yes,.
D
C
B
F
So
yeah
but
then
I,
don't
I,
don't
know
why
I
thought
about
the
actual
panels,
like
you
have
a
chart
and
it's
a
it's
in
a
panel
and
then
you
have
a
name.
Is
that
actually
the
title?
C
I
think
we
would
want
the
option,
at
least
for
panelists
to
like
hide
their
title,
in
which
case,
if
we
create
this
like
text
content
shortcut,
then
you
know
panels
don't
actually
show
their
titles,
like
you,
wouldn't
actually
name
those
but
I.
Think
we're
getting
more
into
like
the
how
the
user
actually
adds
these
into
the
the
dashboard,
but
yeah.
D
I,
my
YouTube
census.
We
have
the
unique
ID
which
could
be
a
string.
We're
not
just
promote
we're,
not
saying
functionally
how
that
what
that
unique
ID
is,
and
then
the
name
I
would
say
the
title.
If
you
want
to
rename
that
term
to
title
I'm
happy
to
make
that
far
clearer.
B
F
I
mean
it
makes
it
a
bit
clearer
that
it's
something
that
the
user
will
see
because
the
name
could
be.
You
could
set
a
name
for
a
panel,
but
you
don't
actually
see
it
I
guess
in
the
same
way,
no
for
the
dashboard.
When
you
set
the
name
for
the
dashboard,
you
see
it
on
the
top.
You
will
see
it
in
a
and
on
a
page
where
you
will
choose
which
dashboard
you
want
to
open
and
things
like
that.
F
A
Awful
when
titles
make
URLs
like
in
size,
sense
too
right,
I
know
we're
getting
so
technical,
but
the
unique
ID
should
be
the
URL
or
the
render
so
that
you
could
make
the
title
anything
if
a
user
changes
a
title,
it's
just
it's
annoying
when
it
updates
all
of
the
URLs.
F
A
A
A
C
C
C
Multi-Parent,
well,
they
effectively
don't
have
parents
right
they're,
just
stand
alone,
not
objects
that
you
can
include
in
your
dashboard.
So
so.
C
So
we
refer
to
them
by
their
unique
ID,
and
then
you
know
you
could
have
three
dashboards
that
always
pull
up.
You
know
cycle
that'll
cycle
time
or
something
like
that,
and
then
that
wouldn't
change
and
if
you
updated
it
once
it
would
update
it
everywhere
that
kind
of
thing.
But
then,
of
course,
it's
subject
to
dashboard
level
filters
like
date
range
and
whatever
else
you
have
determining
the
subset
of
data.
A
That's
cool,
that's
exactly
how
I
think
it
should
be
built
and
then
yeah
at
some
point
rendering
for
transparency
where
this
chart
is
also
being
like,
who
are
its
parents,
having
some
kind
of
list
to
look
and
show
where
it's
like?
Oh
I'm,
on
the
CEO's
dashboard
with
this
one
yeah.
C
C
Maybe
you
don't
want
to
inadvertently
change
the
old
dashboard,
whereas
we're
doing
it
from
the
other
way
where
we
want
the
portability
and
we
want
the
reusability,
but
it
could
easily
be
done
that
you
change
something
on
a
dashboard
and
don't
realize
that
you're
changing
in
on
five
others
right
so
I,
don't
know
that
there's
necessarily
a
right
or
wrong
way.
It's
just
what
what
we
think
is
the
right
convention
for
for
our
product
so
but
I
agree.
It's
it.
A
A
Okay,
so
that's
what
I
was
just
driving
to
there
is
yeah
I,
think
uniques
are
important
and
then
exposing
if
you're
in
a
multi-parent
situation
and
you're,
you
realize.
Oh,
my
dashboard
is
included
on
said's,
dashboard
and
I.
Just
blew
it
all
away
or
messed
it
up
or
put
a
date
on
there.
That's
not
happening
or
something
I
think
that
transparency
at
some
point
is
good
to
have
on
them.
A
Okay,
so
we
kind
of
went
through
dashboards
has
a
high
level,
and
then
we
got
into
panels
and
the
text
content.
Does
it
make
sense
where
I
put
lines
34
and
35?
Should
those
just
be
nested
under
panel
as
a
content,
like
maybe
content,
type
or
visualization
starts
includes?
These
like
visualization
would
be
the
first
one
and
then
maybe,
like
text
is
a
type.
A
B
A
B
C
Yeah
you
could,
or
you
could
argue
it's
not
argue,
but
you
could
say
it's
it's
a
visualization.
It's
a
representation
of
a
a
list
of
rows
or
rows
of
data.
Just
as
a
list.
E
Yeah,
that's
why
I'm
purposefully
championing
that
name,
because
it's
so
broad
it
kind
of
captures
everything
and
I
really
like
rafana's
definition
of
that.
It's
a
graphical
representation
of
a
query,
so
it
could
be,
could
be
anything
could
be.
A
text
could
be
a
table,
it
could
be.
A
list
could
be
a
line.
A
C
I
think
that
would
depend
on
whether
we're
setting
the
standard
for
dashboards
and
filters
should
work
currently
in
Project
analytics.
It's
a
two-way
decision,
a
a
yeah
to
a
decision
where
we
have
dashboard
level
controls
overwriting,
that
of
panel
or
visualizations,
but
I'm,
not
sure.
If
we
can
speak
for
every
other
group,
that's
going
to
build
dashboard
if
that's
how
they
want
things
to
be
built.
Yeah.
F
F
C
C
E
I
correct
my
understandings
that
we
don't
know
yet
like
what
we're
trying.
First
is
just
setting
it
at
a
dashboard
level,
because
that's
the
most
useful
I
can
see
it
from
both
angles.
Why
it's
viable,
but
I,
do
think
in
gitlab.
We
should
probably
try
and
settle
on
one
like
method,
which
is
it's
either
it's
it's
either
overriding
from
the
dashboard
level
or
from
the
panel
level
having
it
go
like
different,
different
ways
on
different
dashboards.
It's
just
going
to
create
a
confusing
user
experience.
E
C
My
rash,
or
the
reason
why
I
was
supportive
of
dashboard
level
controls
is
that
it's
very
easy
for
someone
building
a
dashboard
to
set
up.
Let's
say:
you've
got
10
panels
and
each
one
has
their
own
date
range
and
then
you
have
and
it's
querying
one
of
them
is
querying
60
days,
but
your
dashboard
level
is
scoring
30
days.
Yeah
I
think
it's
very
confusing
to
set
all
these
different
limits
and
then
override
them
at
the
individual
panel
level.
C
Whereas
it's
a
lot
simpler
to
just
say:
okay,
you
can,
you
can
reduce
the
amount
of
confusion
you
have
on
your
dashboard
if
the
dashboard
level
filter
is
the
one
setting
like
the
limit
of
what
the
panels
can
use
and
then
ultimately,
having
like
the
like
for
project
analytics,
for
example
like
if
you
don't
like
that
convention
and
it's
again
a
two-way
decision.
C
But
you
know
you
could
export
that
data
and
and
do
something
else
with
it
if
you
really
wanted
to,
but
we
just
wanted
to
kind
of
reduce
the
amount
of
confusion
that
potentially
could
be
caused
by
creating
dashboards
that
every
panel
in
a
dashboard
could
just
have
its
own
limit,
and
so
you
might
be
looking
at
a
dashboard
and
it
says
last
30
days,
but
panels
are
displaying
whatever
they
feel
like
displaying.
C
So
it
could
be
a
Year's
worth
of
data
or
seven
days
worth
of
data,
and
so
I
personally
feel
like
it
gets
more
confusing.
Looking
at
a
science
dashboard,
for
example,
where
you
have
these
date
filters
that
say
seven
days,
but
then
you
have
charges
doing
whatever
they
want.
That
was
that
was
mine,
yeah
General,.
B
D
Behind
it,
I
should
say,
because
products
is
working
on
the
concept
that
a
panel
is
reusable.
D
Sorry,
correction
so
I've
that
it
means
that
we
can
Define
on
the
visualization
the
set
number
of
filters
that
get
applied
to
that
data
set
on
that
visualization,
because
that
visualization
is
then
reused
within
multiple
could
be
reused
across
different
dashboards
and
their
panels
having
the
PA
having
the
visualization
and
panels
Define
their
filters
and
not
get
overridden
by
the
Dashboard
can
cause
serious
problems
from
a
user's
point
of
view,
but
it
does
make
sense
if
you're
looking
at
it
say
if
you
want
a
dashboard
where
you've
got
the
last
7,
14
and
30
days
of
something
and
you
haven't
set
any
filters
on
your
dashboard.
D
D
A
E
E
I
was
about
to
see
exactly
also
it's
just
there.
I
think
this
is
something
that
we're
we
can,
as
an
action
item,
maybe
create
some
visuals
and
expand
on
what
is
possible.
What
is
not
possible
going
in
both
directions
like
if
we
do
it
this
way,
we
can
do
this,
but
we
can't
do
this
and
it's
vice
versa,
because
yeah
just
talking
about
it
is
especially
while
all
of
our
terminology
is
also
in
Flex
is
a
kind
of
difficult.
C
C
C
B
A
C
Just
be
blankets
are
asking
because,
like
theoretically,
you
could
query
all
the
data
but
product
analytics
is
not
allowing
you
to
do
that,
because
that
would
be
like
we're
having
shared
data
clusters,
and
so
that
would
be
a
very
expensive
and
long-running
query
to
do
so.
C
We
have
we're
trying
to
add
what
we
think
are
sensible
defaults
so
that,
if
you
don't
have
a
date
range
to
find
we'll
start
you
off
with
seven
days
and
then,
if
you
want
to
change
that,
you
can
go
beyond
that
or
or
limit
that,
okay
and-
and
that
would
be
a
convention
that
we
may
want
to.
We
should
eventually
discuss,
though,
that
will
change
depending
on
what
data
source
you're
using
because
our
data
source
is
not
going
to
be
the
same
as
other
groups,
for
example,
date.
A
C
It's
not
I
guess
we
are
requiring
it
like
yeah
and
I
just
had
this
discussion
like
we're,
limiting
it
to
30
days
from
now,
but
ideally
we
would
want
you
to
be
able
to
query
all
of
it,
but
that
would
really
depend
like
we're
still
doing
like
cost
and
scalability
assessment
for
like
how
product
analytics
is
doing
it.
So
we
don't
know
if
we
can
but
theoretic
like
as
it's
currently
defined
we're
just
placing
limits.
Even
though
they're
you
could
query
all
of
it.
Sorry
mate.
F
If
we
keep
that
we'll
need
to
reflect
that
in
the
UI
somehow,
because
in
that
example,
that
Kristen
gave
where,
if
she
wants
to
have
a
list
of
security
issues
right,
it's
it
it's,
it
doesn't
need
to
be
filtered
by
a
periods
to
be
useful
right.
Maybe
she
wants
a
list
of
all
of
them
right.
C
Or
product
analytics
clickhouse
like
they're,
all
going
to
have
different
limits
in
place,
so
I
I,
guess
I'm.
Maybe
I'm
misunderstanding
like
the
question,
but
like
I,
don't
think
we
need
to
decide
whether
it's
required
right
now
because,
like
that,
that's
very
context
dependent
and
data
source
dependent
but
I.
Guess
if
your
question
is,
can
you
just
pull
up
a
list
of
all
security
issues
of
all
time?
C
Yes,
you
could
but
whether
that
you
could
do
that
in
product
analytics
or
in
optimize
or-
and
you
know-
verifies
dashboard
like
I
I,
don't
think
any
one
of
us
can
answer
that
because
it
depends
on
the
data
source.
Does
that
make
sense
so
I
guess
it
doesn't
make
sense
to
like
require
it
because
it
can
vary,
is
what
I'm
trying.
A
To
say
so,
our
gitlab
API,
technically,
we
could
connect
and
pull
all
the
issues
like
we
do
on
any
list
page,
but
that
would
be
a
data
source
itself.
We
would
just
configure
that
if
I
pull
issues
into
notion,
they
they
cap
it
at
20
000
to
any
API
connection,
and
we
have
40
000
issues,
so
I
can't
use
it.
A
It
for
internal
objects
like
Mrs
or
issues
like
I,
see
us
building
cool
queries
where
you
could
like
have
issues
and
Mrs
in
the
same
view
with
like
filtered
on
the
same
list
or
the
same
labels
and
like
get
some
really
cool
stuff
going
I,
don't
know
that
we
would
have
to
limit
it
the
same
way.
We
would
on
some
of
the
click
house
stuff,
because
we're
already
doing
a
lot
of
those
more
expensive
queries
throughout
the
whole
app.
C
Yes,
and
no,
because
when
you
look
at
issue
boards,
for
example,
it
doesn't
load
all
the
issues
in
that
label,
it
keeps
infinite
loading
or
yeah,
infinite
loading
them,
and
so
our
API
will
already
page
it.
So
true.
B
C
Just
really
depends
on
where,
like
a
general
rule
of
thumb,
is
you
shouldn't
query
all
the
data,
even
if
the,
if
it's
like,
perform
it
or
I
mean
even
like
I,
don't
even
think
like
nothing's
perfect,
like
clickhouse,
is
going
to
have
querying
issues
as
well.
We're
going
to
have
to
have
limits
in
place,
so
I
don't
disagree
that
the
utility
of
having
all
the
issues
merge.
C
Requests
of
all
time
makes
sense,
acquiring
that
and
also
rendering
all
of
that
on
the
same
page
is
is
difficult,
I,
but
I
don't
know
going
back
to
like
the
date
range
thing
like
yeah.
A
D
D
That
limitation
is
a
pragmatic
one
from
a
database
point
of
view.
There
are
ways
we
can
pre-aggregate
data,
so
we're
not
having
to
run
that
query
every
single
time.
We
can
instead
run
it
in
the
background,
in
our
regular
intervals,
to
get
close
to
near
current
data
for
those
kind
of
long-running
queries.
That's
a
that's
a
programmer's
problem,
rather
than
a.
B
A
Saying
it
only
from
the
planning
side
of
gitlab's
objects,
the
things
that
we
already
see
on
lists
and
Views
I,
don't
with
click
house
and
the
things
that
all
of
you
are
dealing
with.
That's
like
way
more
data
hungry
and
complex,
so
I'm
not
talking
about
that
I'm
talking
about
just
the
data
source,
which
is
the
internal
app
and
the
views
we
already
have
in
gitlab.
That
sometimes
are
paginated.
C
There
there
are,
they
should
all
be
paginated,
so
it
would
be
similar
to
how
you
view
issues
in
the
repo
you
get
the
counts
for
all
of
them,
but
notice
how
you
never
have
like
page
like
specific
page
of
Nation
on
the
issue,
let's
install,
but
it's
always
previewed
next
right
so
like
you
can
theoretically
thumb
through
all
the
issues,
but
you
can
never
list
all
of
them
on
one
page.
D
C
But
in
terms
of
like
making
it
required
that
you
had
to
find
a
date
range,
that's
that's
I,
don't
think
that's
going
to
change
depending
on
which
group
you
ask,
because
you're
going
to
have
different
data
sources
to
work
with,
but
you're
always
working
with
the
full
data
set
it
just.
A
C
C
You're,
like,
like
Rob,
said
you're,
always
working
with
the
full
data
set.
It's
just
how
you
choose
to
aggregate
it
and
represent
that.
So,
even
when
we
say
like
you
know,
I
get
I
guess
you
could
say
like
give
me,
like
all
the
users
of
all
time,
like
over
over
month
by
month,
you're
still
querying
the
full
data
set
to
generate
that
monthly
roll
up.
A
D
It's
also
worth
noting
that
visualization
is
going
to
have
far
less
content.
Data
I
should
say
than
an
issues
list
if
it
will
have
a
singular
data
point
and
maybe
a
label,
and
that
is
pretty
much
all
you're
going
to
get
out
of
it.
You
might
get
a
link
or
some
other
things,
but
other
than
that
in
terms
of
passing
and
outputting
their
data
on
the
pragmatic
level,
it's
much
more
reduced,
which
is
why
you
can
visualize
the
ad
and
rolling
it
up
helps.
D
This
sounds
like
a
per
group
or
per
dashboard
issue
and
I
I've
rather
than
a
default.
It
sounds
like
we
should
just
leave
it
up
to
the
individual
group
that
are
making
a
new
dashboard,
because
there's
going
to
be
performance,
concerns,
ux
concerns
security
concerns
and
all
of
these
things
are
best
handled
by
the
domain.
Experts
nothing's
going
to
get
through
gitlab's
review
process
without
people
noticing
that
something's
going
to
be
drastically
wrong.
D
If
we
try
and
do
something
that
you
shouldn't,
we
should
give,
we
should
just
make
sure
that
they
have
the
power
to
set
those
controls
and
maybe
have
in
our
documentation
and
recommendation
that
they
should
have
pre-filtering
of
some
kind.
A
C
C
C
A
I'm
thinking
from
the
perspective
of
customizing
dashboards
as
we
move
forward
I'm
taking
that
role
where,
as
a
PM
I
could
go,
build
some
views
for
myself.
My
issues
that
I
care
about
things
like
that.
However,
I
think
that
what
we
currently
have
for
customers
that
should
be
configured
the
date
ranges
should
be
set.
It
should
be
thought
through,
but
at
some
point,
I
want,
like
Open
Season,
to
be
able
to
create
a
view
of
like
my
team's
security
issues
or
things
like
that.
C
A
Yeah
I
think
if
we
give
tools
such
as
our
scoped
filters
and
things
like
that
as
ways
to
cut
down
data
at
the
beginning
like
for
me,
I
always
spoke
to
group
foundations.
Some
of
the
high
level
scoped
labels
can
get
people
to
a
place
where
they're
already
looking
at
a
subset
of
the
data
and
it's
less
than
the
whole.
D
A
A
C
I
think
we're
currently
exploring
panels
and
having
multiple
data
sources,
so
you
can
theoretically
have
a
dashboard
with
panels
with
different
data
sources.
B
A
Dashboard
variable
is
one
that
I
added
I
don't
know.
If
that's
that's
what
I
was
trying
to
get
with
like
some
of
the
key
like
for
me:
I
always
filter
to
one
thing
like
group
foundations
or
a
specific
date,
that's
set
at
the
highest
level
in
the
dashboard,
and
then
every
panel
can
render
off
of
that
Main
selection.
But
I
don't
know
if
variable
is
the
right
word.
If
we
need
that
or
if
it
should
be
something
else,
such
as
like
a
filter
variable,
that's
set
at
the
dashboard
level
or
a
filter
setting.
C
C
It's
reusable
across
a
dashboard
or
panel
level,
so
say,
for
example,
you're
trying
to
write
a
pi
dashboard
for
the
product
analytics
group.
You
can
Define
that
as
a
dashboard
variable
use
that
in
the
filter
at
the
dashboard
level,
but
then
have
panels,
use
that
same
variable
for
I
guess
what
you're
saying
is
like.
Would
you
have
to
reuse
it
in
the
lower
level?
But
I
don't
know
if
you
end
up
querying
yeah.
B
C
A
E
C
Yeah
I
mean
I.
Think
titles
may
be
useful,
but
I've
only
ever
used
that
in
the
sense
of
like
manual
querying
and
science
for
example,
which
I
don't
believe
product
explains
it
to
at
least
anytime
soon.
C
E
I
know
I
want
to
say:
I
can
like
I
understand
the
need
to
have
a
variable
if
it's
like
editing
stuff
that
isn't
related
to
the
query
like
editing
the
title
or
something
like
having
this
variable,
and
then
it
applies
to
the
stuff
in
like
a
visual
way
that
doesn't
edit
the
query.
C
Yeah
I
think
that's
the
use
case
that
Kristen
just
described
in
terms
of
like
setting
a
variable
and
using
that
for
multiple
titles
or
something
like
that.
I,
don't
see
that
as
a
product
use
case,
but
I
can
see
that
you
can.
That
can
be
useful
for
other
dashboards.
A
And
definitely
we
wouldn't
like
build
that
out
yet.
But
it's
just
something
to
think
about
filter
variables
is
something
you
said:
Eon
too
and
I
just
I.
Don't
know
that
concept
of
whether
I
searched
a
string
like
the
word
assessed
across
titles
or
something
or
it
was
like
wait
are
dates
or
labels
or
whatever
else
those
have
to
be
kind
of
staved
in
some
object
and
then
available
to
the
other
panels.
A
B
C
A
I
know
we're
at
time
here
too
I
just
realized,
so
how
about
for
next
steps?
We
all
review
these
and
put
our
names
on
if
there's
ones
that
we
feel
are
correct
and
by
our
next
meeting,
we'll
have
more
to
go
through
and
let's
look
at
the
visualization
too.
Is
that
something
that
someone
wants
to
take
on
just
the
inheritance
or
showing
like
the
filter
and
the
dashboard
and
the
panels,
so
that
we
have
like
a
working
image
of
what
those
things
are
and
how
they
relate.
E
Some
basic
stuff
yeah,
but
I'll
I'll,
just
extend
like
basically
what
I've
already
created.
That's
good.