►
From YouTube: 2023-01-11 - 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).
A
B
Yeah,
okay,
so
in
terms
of
how
do
we
ask
questions
about
a
what
a
term
and
a
description?
Is
that
what
you're
getting
at.
A
Well,
how
do
yeah
I
think
someone
or
many
can
just
start
writing
the
definitions,
but
we're
going
to
get
into
where
we
have
two
words
that
mean
the
same
thing
and
two
teams
may
be
having
a
different
take
on
how
that
the
filter
should
be
called
or
whatever
the
element
is
so
I.
Ideally,
this
list
should
be.
We
all
agree
like
for
every
single
one.
We
are
in
an
agreement
on
it
or
we
need
further
discussion
on
it.
A
Foreign
agrees
that
dashboard
is
the
right
term
and
the
like
I,
don't
know
if
we
just
put
little
checks
of
sign
off
per
person
or
something
or
we
like
I'm.
Okay
with
the
definition.
That's
there
right
now,
I'd
be
like
I'm,
okay
with
that,
but
if
somebody
else
doesn't
they
can
modify
it
and
make
it
better
and
at
some
point
we'll,
hopefully
have
like
consensus
on
most
of
them
and
then
we'll
the
diffs
are
where
it's
more
interesting
I
think
to
spend
our
time
discussing.
B
C
They're
all
some
people
like
in
the
working
group
that
have
more
are
more
involved
than
others,
so
we
could
in
very
one
agreement
from
everyone
in
the
working
group,
but
that
does
that
necessarily
would
that
necessarily
work?
Would
we
actually
be
able
to
get
some
of
the
people
who
aren't,
as
involved,
to
get
involved
to
do
that?
I?
Guess:
I'm,
not
words
English
only
just
about
to
work.
A
C
It's
just
a
case
of
of
having
just
come
to
me
having
that
agreement
thing.
If
anyone
wants
to
argue
debate
a
particular
point,
they
should
comment
and
put
a
suggestion
in
I
guess
and
then,
if
we
see
suggestions
in
the
next
meeting,
then
we
can
go
through
those
suggestions
and
we
resolve
them
at
each
meeting
as
they
come
up.
A
C
That's
my
product
on
the
team
I
mean
in
product
analytics
we're
currently
calling
a
widget,
but
I
don't
see
any
conflict
we'd
be
happy
to
change
it
to
panel.
C
D
A
On
our
last
call,
we
live
did
it
for
the
hour.
We
went
through
sourced
out
of
the
issue
and
then
on
the
grafana
and
looking
at
everything
that
we
could
think
of.
That
would
be
in
the
dashboard
based
on
what
we'd
seen.
So
it
was
like
a
first
pass
and
we
may
have
missed
some,
but
if
you
watch
last
week's
you'll
see
kind
of
us
just
having
the
spreadsheet
open.
That's
all.
We
did
basically
that
for
the
hour,
okay,
okay,.
B
Let's
take
a
derivative,
it
was
derivative
of
the
the
analysis
of
the
existing
dashboards
and
the
competitors.
A
D
A
The
the
column
A
like
the
categories
kind
of
came
out
of
that,
as
we
were
like.
Oh
all,
of
these
things
we're
saying
around
like
a
dashboards
definition
like
it
has
a
name,
a
description,
a
data
source
they
kind
of
get
replicated
onto
the
panel
config
too,
like
there's
just
some
common
elements
between
each
like
a
dashboard
would
have
a
name
and
a
panel
could
have
a
name
and.
A
E
D
Which
no
the
text
content?
That
would
be
the
11th
row.
A
So
having
done
I
was
in
plan
and
then
I
did
an
opportunity,
canvas
on
Save
queries
and
views
in
gitlab.
We
use
list
views
predominantly
so
anything
whenever
you
query
to
show
a
list
of
issues.
It's
only
a
list.
View
I
was
proposing
and
I
hope
at
some
point.
We
get
this.
You
could
also
view
it
as
a
table
list.
You
can
also
view
that
query
as
a
board,
so
those
get
lab
views
and
like
the
only
one
we
have
in
Flight
is
list
right
now,
but
that's
an
alternate
panel.
A
It
could
be
a
different
way
of
displaying
data
that
we
already
have
in
our
pocket
and
we
already
use
in
our
views
at
gitlab.
So
that's
something
that
was
an
add-on
in
addition
to
the
charts
and
the
all
the
other
ways
that
we
could
render.
We
could
also
just
render
like
a
boring
list
yeah
like
security
items
for
my
team,
just
a
list
yeah.
D
C
A
question
around
the
descriptions:
how
detailed
do
we
need
these
to
be?
Do
we
need
these
to
be
like
technical
writing
level
descriptions,
or
are
they
more
rougher
rough
outlines
of
what
it
is.
A
C
Sorry
I
meant
the
actual,
not
the
term,
but
the
US
describing
what
these
terms
are.
Sorry.
A
C
I
guess
I.
The
only
reason
I
ask
is
because
I'm
assuming
eventually
you
will
turn
this
into
a
a
page
on
the
handbook
in
some
form,
so
I
guess
we're
gonna
have
to
get
attention
we'll
someone
with
technical
writing
experience
to
make
it
same.
A
Yes,
good
point:
I
was
inspired
by
how
simple
grafana's
glossary
is
and
just
like
it's
hard
to
disagree
with
the
way
they
wrote
there.
So
if
we
could
kind
of
have
that
in
mind
and
then
I
don't
know,
if,
if
we
should
ask
for
technical
writing
to
come
in
once
we
kind
of
get
it
to
a
point,
this
will
go
in
our
docs
right.
It's
not
just
pajamas.
D
E
E
A
B
A
A
E
A
C
A
D
It's
good
that
you
mentioned
this
because
I
was
actually
thinking
about
this
and
I
wasn't
sure
if
I
should
ask
at
this
point,
because
it
looks
like
just
from
defining
these
terms,
we
are
already
kind
of
dictating
what
the
user
experience
could
be
should
be
because
we're
saying
you
could
probably
filter
the
whole
dashboard
and
you
could
possibly
filter
a
single
panel.
How
does
that
work
right?
D
So
we're
now
defining
a
user
experience,
even
though
we're
not
sure
yet
how
it
will
actually
work
out,
but
I
don't
know
if
it's
a
discussion
for
now
or
is
it
a
discussion
we
should
have
later
or
it's
all.
A
We
definitely
should
start
thinking
now,
I
think
because
highlighting
those
the
discussion
we
had
last
week,
the
term
variable
came
out
of
it
like
I've
done
a
lot
of
dashboarding
across
tons
of
products
setting
some
kind
of
high
level
variable,
such
as
my
team's
label,
or
the
core
time
frame.
Setting
those
at
the
dashboard
level
affects
the
the
ease
of
use
of
a
lot
of
dashboards
and
also
overrides
are
important,
though
like
sometimes,
you
also
might
want
to
just
copy
a
panel
and
make
it
your
own
in
some
other
way.
A
D
Yeah,
it's
my
opinion
without
looking
into
it
at
all.
I
would
say,
is
the
dashboard
filter,
whatever
it
is
set
to
should
probably
be
overwritten
by
the
panel
filter?
That's
how
I
Envision
users,
who
probably
want
to
use
this
right
so
on
the
dashboard
level.
Maybe
they
have
more
General
filters,
but
some
of
them
might
clash
with
a
filter
inside
a
panel
and
when
that
happens,
I
think
the
panel
should
link
this
argument
right
between
the
YouTube
filters.
A
Yeah,
the
specificity
that
got
added,
takes
precedence
and
there's
some
indicator
that
it
is
overriding
on
some
level.
It
would
be
interesting,
like
maybe
you
thought
you
were
looking
at
all
of
January
on
the
whole
board,
and
then
one
panel,
though,
is
showing
oh
actually,
this
one's
like
just
this
week
or
it's
out
of
sync
or
something
it's
a
different
variable
used,
but.
D
Yeah
exactly
we
could
actually
come
up
with
a
bunch
of
Concepts
on
how
to
show
that
in
the
UI
and
actually
do
some
testing
to
see
if
the
users
understand
you
know
how
data
is
filtered
and
presented,
and
just
that
example
that
you
just
gave
you
know
if
something
is
filtered
by
January
on
the
dashboard
level
and
then
in
one
of
panels,
it's
filtered
by
a
different
date.
Will
they
understand
that
it's
overriding
right
through
the
UI
I'm,
not
sure
if
this
is
something
we
want
to
do
as
part
of
this
working
group,
though?
A
I
think
that
indicating
that
some
way
to
indicate
a
change
from
the
main
query
is
something
we
could
just
add
as
a
list
or
add
on
to
the
list.
So
we
keep
it
in
mind.
Even
if
we
don't
action
on
it,.
D
A
I
think
I
just
realized.
We
don't
have
a
date
range
on
either
in
the
list.
So
maybe
we
should
add
that
because
I
was
just
trying
to.
Think,
though,
is
that
the
is
it
required
for
for
a
data
source
and
a
query
for
an?
Is
it
a
required
piece
defaulting
to
all
time?
Maybe,
but
like
is
a
date
range
always
there
yeah.
C
Only
because
there
are
many,
you
know
you
might
have
a
dashboard
which,
rather
than
having
a
universal
time
across
the
dashboard,
you
might
have
individual
panels,
which
are
last
14
days
last
30
days
last
three
months
or
whatever
it
might
be,
to
see
that
transition
over
time
I
mean
there
are
other
ways
of
doing
that.
But
I
have
seen
that
type
of
situation
before
so
that
doesn't
a
dashboard
doesn't
necessarily
need
to
have
a
way
of
changing
the
date.
A
D
C
C
In
the
UI
at
least
there,
wouldn't
there
could
be
no
way
for
them
to
change
that.
That's
what
I
mean
right.
A
It's
the
Ida
issue
title
or
the
Little
Dot
on
the
chart
is
the
property
assigning
properties
to
the
view
is
another
part
of
it
and
it
just
happens
automatically.
If
you
pick
like
a
chart
or
something,
let's
say
you
rendered
as
a
table,
you
might
want
to
only
have
three
columns
or
three
properties
visible,
but
that's
another
thing:
I
was
thinking
about
this
week
that
we
didn't
get
a
property
much.
E
A
D
Required
yeah
is
it,
does
it
need
to
be
there
and
then
another
thing
I
was
thinking
about,
is,
is
it
user
facing
and
does
it?
Is
it
important
for
us
to
to
know
who
it
is
or
if
it's
not
because,
for
example,
unique
ID
I,
imagine
that's
not
user
facing,
they
won't
know
a
unique
ID
of
the
dashboard
unless
some
really
technical
reason
or
requirement.
D
A
A
B
Think,
there's,
there's
sort
of
this
gray
area
that
will
have
to
balance
between
how
far
do
we
Define
what
people
can
do,
but
maybe
that's
maybe
what
we
should
think
about
is
what
is
our
as
we're
getting
into
this
as
we're
writing
these
things
out,
we
could
probably
write
a
consider
what
our
goals
are
in
terms
of
how
far
we
want
to
push
something,
but
we
won't
necessarily
know
that
until
we
start
writing
them,
I
think.
A
For
example,
in
notion,
I
use
them
all
the
time
because
you
can
build
out
any
kind
of
query
and
filter,
but
if
we
were
in
our
spec
to
write
the
way
they
do
their
filters,
they
basically
allowed
you
to
add
any
filter.
You
want
in
succession
all
together,
so
I've
got
all
these
rules.
I've
got
this
additional
filter,
which
I
just
added
I'm
going
to
delete
it
and
I've
got
two
sorts
running
on
this
I.
A
But
I
think
we
should
get
into
filtering
must
accept
many
different
filters
or
unlimited
filters,
or
something
like
that,
and
we
may.
We
also
should
be
able
to
sort
in
multiple
ways
that
stack
or
something
like
that
or
there
maybe
we'll
say
there
will
only
ever
be
one
sort
in
our
world
just
does
that
make
sense
that
we
would
capture
the
desire
for
feature,
filter
flexibility
and
the
creation
of
additional
queries
right
now.
We
don't
really
save
filters
in
any
way,
or
we
just
rely
on
the
URLs
and
the
the
URL
attributes
and.
A
All
of
the
modern
when
you're
setting
up
a
lot
of
these,
they
they
kind
of
you,
set
your
core
database
and
then
you've
got
additional
filters
that
help
you
make
it
better
for
your
team
or
whatever
so.
A
C
I
think
they're
less
necessary,
not
necessarily
the
less
technical
constraints
and
more
I
guess
how
the
user
experiences
or
interacts
with
the
dashboard.
So
that's
what
we
want.
Isn't
it
it's
not.
We
don't
necessarily
care
how
it
how
technically
it
functions.
What
we're
more
interested
in
is
making
sure
there's
a
consistent
user
experience
across
all
our
dashboards
at
GitHub.
C
Whether
the
engineer
does
things
in
one
way
or
another,
but
in
the
background
is
more
or
less
irrelevant.
As
long
as
the
output
is
the
same
I
guess
that's
what
I'm
trying
to
get
there?
C
Obviously,
we've
got
pajamas
UI
components.
So
that's
not
going
to
happen.
They
will
end
up
being
consistent
for
the
most
part
from
a
technical
point
of
view,
but
I
just
wanted
to
see
if
that
was
a
clearer
distinction.
C
I
we
kind
of
have
a
just
like
in
our
pajamas
guidelines.
We
describe
the
do's
and
don'ts
of
the
user
experience.
Don't
we
we
don't
necessarily
describe
exactly
what
should
sometimes
we
say
some
items
must
be
on
the
left
or
the
top
or
the
bottom
Etc,
but
we
don't
describe
how
they
should
look
from
a
UI
point
of
view
necessarily,
but
we
do
describe
the
behaviors
and
the
expectations
that
all
users
are
expecting
to
see.
C
So
I
do
feel
like
eventually,
once
we
get
our
descriptions
that
would
maybe
not
in
this
working
group
but
as
a
follow-on
that
may
be
necessarily
as
some
kind
of
pajamas
guidelines,
because
that
is
going
to
be
the
from
a
from
a
designer's
perspective.
That's
going
to
be
the
first
look
when
we're
looking
to
build
a
new
dashboard
is
what
how
do
we
do
things
currently?
What's
my
target
audience's
needs.
What
do
we
currently
suggest?
We
do
and
pajamas
is
the
first
go-to,
at
least
for
me
when
I'm
having
to
do
design
work.
C
I
first
look
at
pajamas
and
that
would
be
a
guard
I
guess
against
less
about
against
non-conformity,
I'm
trying
to
say
I,
don't
know.
A
There
could
be
that
follow-on
contribution,
for
example,
an
update
to
filter
bar
to
make
it
work
for
the
needs
that
we
find
here
like
supporting
multiple
sorts
or
multiple
filters
or
whatever
we
end
up
I,
seeing
how
many
different
ways
gitlab
has
done
dashboards
and
we've
tried
so
many
times
to
align.
It's
just.
It
looks
painful
for
the
user
to
have
so
many
different
experiences.
A
So
if
we're
able
to
upgrade
the
filter
bar
in
particular
comes
to
mind,
but
every
piece
so
that
it
it
follows
this
over
the
next
year
after
the
working
group
I,
think
that
would
be
awesome
and
like
deliver
that
to
pajamas.
Maybe
it
also
needs
research.
Maybe
it
needs
a
lot
more,
especially
on
some
of
the
complex
filter
or
complex
UI
components
like
filtering.
B
D
I
think
it
would
make
sense
to
have
some
guidelines
for
dashboards
come
out
of
this
work,
possibly
into
pajamas,
so
that,
as
as
we
said
because
that's
when
our
designer
starts
working
on
attachment,
they
already
have
some
guidelines
that
they
start
with.
So
it's
also
more
consistent
right.
So
that's
not
every
dashboard
initlab
looks
different
and
then
the
other
thing
and
I
think
filtering
is
actually
a
really
good
example.
D
I'm,
actually
working
on
improving,
filtering
and
documenting
the
filtering
Alternatives
in
terms
of
UI
to
the
current
filter
component,
because
the
current
filter
component
is
so
complex
already
and
if
we
keep
adding
stuff
to
it,
it
will
be
even
more
complex
and
it's
hard
to
maintain
it.
Basically
so
I'm
thinking.
D
Okay,
we
have
the
dashboard
guidelines
in
pajamas
and
then
those
dashboard
guidance
can
refer
to
the
filtering
guidelines
that
I'm
currently
working
on
and
that's
already
exists
basically,
so
that
we
keep
it
in
multiple
smaller
pieces
of
guidelines
that
you
can
refer
to
as
you
need
them.
Basically
right.
B
D
Yeah
yeah,
and
that's
also
why
I
started
working
on
this
on
documenting
this
filtering
Alternatives
and
we're
also
working
on
documenting
an
actual
filter
Builder,
which
is
very
similar
to
what
Kristen
showed
earlier
from
motion,
which
we
don't
have
documented
in
GitHub
at
the
moment,
because
we
rely
so
heavily
on
other
components
right
so
that
we
can
use
these
things
as
we'll
need
them
in
the
dashboards,
because,
as
I
started,
working
on
exploring
these
dashboard
Concepts
I
realized
we'll
need
other
filtering
methods.
D
That
is
not
a
Hilton
component,
because
that
filter
component
won't
be
able
to
split
into
a
panel,
for
example
right
or
if
it.
If
we,
if
you
do
push
it
into
a
panel
inside
of
a
dashboard
that
has
entity
panels
in
it,
it
will
be
really
hard
to
use
because
it
will
be
in
in
a
tight
space,
basically
right
so
yeah.
That's
why
I
started
working
on
that.
It
came
from
my
needs
to
use
filtering
in
dashboards,
so
I
think
it
will
align
quite
well
with
whom
names.
A
And
we
could
maybe
MVC
that
panels
inherit
or
something
like
that,
so
you'd
we'd
go
out
with
the
main
filter,
maybe
being
at
the
top
or
something
like
that,
and
then
we
could
augment
it
over
time,
but
that's
cool
that
you're
you've
already
gone
down
that
path.
I
think
the
two
will
come
together
nicely.
A
D
Is
there
like
I,
don't
have
access
to
grafana
I
think?
Is
there
like
an
example,
dashboard
or
an
example
account
that
we
could
take
a
look
at
or
should
I
just
sign
up
and
try
it
out.
A
B
A
I
think
it
was
just
the
docs
okay,
but
yeah
I'd
love
to
see
kind
of
how
they
expose
their
filters
and
how
that
works,
and
then
we
could
align
the
needs
of
that
the
requirements
of
the
already
existing
uis
to
the
other
ones
too.
B
Yeah
stuff,
like
that
I,
don't
think
we've
changed
in
knobs
Trace,
where
we're
we
had
to
Fork
it
because
of
Licensing,
mainly,
and
also
because
we
need
to
basically
hack
it
apart.
So
it
looks
like.
B
E
A
Yeah
so
like
we
might
have
some
of
that
for
free,
although
it's
not
in
our
design
system.
Yet
it's
not
in
pajamas
they're
trying
to
convert
it
to
look
like
pajamas,
so
we
can
still
set
the
Precedence
for
how
the
gitlab
filter
should
be,
and
they
can
modify
it
to
be
that.
But
there
may
be
parts
of
that
filter,
specifically
its
requirements,
that
we
should
just
ensure
that
we
have
the
granularity,
that's
necessary.
B
And
and
taking
a
step
back
looking
at
the
way
that
we've
defined
the
delivery
or
due
dates
and
the
labels
or
the
titles
that
we
gave
each
of
those
sections,
the
16th
was
actually
just
to
map
all
the
pieces
or
the
13th.
What
we
had
before
and
the
definitions,
which
is
really
what
we've
been
talking
about
today,
is
until
the
end
of
February.
A
B
A
E
A
Stuff
to
lock
the
definitions,
descriptions
and
then
what
the
final
requirements
are
nice
that
this
week,
leading
into
end
of
release,
plus
a
friends
and
family
day,
it's
nice
to
have
something
done:
early
laughs.
A
B
E
No
I
was
saying
if
you
just
want
to
check
out
what
grafana
looks
like
and
how
it
works.
E
My
the
previous
company
I
worked
at
actually
built
their
product
on
top
of
grafana
and
they
have
a
demo
that
you
can
access
and
click
around
to
see
what
the
profiler
looks
like
I'll
share
that
on
the
agenda.
Doc,
if
you
all
just
want
to
see
what
grafana
looks
like
without
having
to
download.
A
E
E
Well,
I
I,
don't
know
how
we're
gonna
skin
ours,
our
the
one
we've
worked.
B
A
D
E
A
B
A
A
D
E
B
B
And
I
I
noticed
that
there's
probably
some
Zoom
lag,
but
even
in
the
in
the
analytics
demo,
when
you're
dragging
something
size,
they
give
you
a
a
gray
background
of
where
it's
going
to
end
up.
If
you
drop
it
right
now
and
I
I've
done
that
before
when
I've
designed
silly
things
like
this,
without
using
someone
that
already
built
it
and
I
tried
to
stick
to
a
grid
tube
to,
let
users
know
that
there's
a
very
specific
way
that
you're
allowed
to
arrange
these
things
and
size.
D
I
think
I
actually
checked
in
on
this.
With
the
team
there
are
capabilities
to
limit
the
sizing,
so,
for
example,
for
a
certain
panel,
you
could
be
able
to
say
it
can
be
strong
field
below
this
point
or
it
could
can
be
extended
Beyond.
This
point,
which
I
think
is
really
good.
It
will
be
really
useful.
B
A
A
You
just
have
to
click
each
one,
but
it's
like
shrunk
it
down,
and
then
they
they're
basically
getting
the
entirety
of
the
whole
product
org
in
one
huge
view,
but
it's
useless
in
the
sense
that
you
can't
actually
visualize
each
one
should
open
as
a
modal
above
it
or
something
or
go
to
its
own
page.
Currently
it
goes
to
its
own
page,
so
the
maybe
the
some
of
them
could
have
a
detailed
View.
And
this,
like
the
small
view
like
maybe
it's
just
one
number
or
one
small
thing.
D
We
do
already
have
the
sparklines,
for
example,
in
optimize
the
work
we
do
in
optimize,
where
it's
just
like
a
trend
line
right.
So
you
show
a
metric,
you
describe
the
metric
with
the
label,
possibly
you
have
the
trend
icon,
so
you
can
say
it's
either
increasing
or
decreasing
and
then
below
it.
We
often
show
the
the
trend
line.
D
So
it's
like
a
small
chart
that
gives
you
some
information,
but
not
all
the
details
right
that
gives
you
a
nice
overview
and
you
can
hover
over
it
and
it
will
show
you
some
additional
information.
It
doesn't.
We
haven't
predicted
any
interactions
like
clicking
on
it
and
it
would
show
you
a
bigger
chart.
D
A
B
Yeah
I
mean
I
did
do
some
draft
draft
dates
so
end
of
the
month
for
the
draft
to
have
everything
written
in
get
feedback
by
the
10th
of
February
and
then
be
done
done
by
the
20th.