►
From YouTube: 2022-11-29 - Dashboard Working Group Kickoff
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
We've
got
four
of
us
on
the
call
today.
This
is
a
kickoff
meeting
today
to
essentially
go
through
some
housekeeping
questions
and
start
to
draft
some
of
our
intent
and
action
items.
A
So
there
is
agenda
which
will
be
linked.
We
also
kicked
off
the
working
group
slack
Channel
this
week.
The
Mr
is
yet
to
close.
I've
had
a
few
more
people
make
suggestions
for
their
names
that
I'm
going
through
after
coming
back
off
off
of
taking
some
time
off,
so
there
could
be
a
few
more
additional
people
added
to
the
working
group
just
in
the
next
day
or
two
foreign.
A
So
this
is
my
first
time
participating
or
leading
I
guess.
I've
sat
in
on
a
few,
but
I
wanted
to
ask.
Has
anyone
else
been
on
working
groups
before
on
the
call
Jeremy's
nodding?
I
have
not
okay,
so
we've
got.
This
is
a
new
experience,
so
I'm
going
to
be
referencing
the
handbook
a
lot
for
this
in
terms
of
how
we
run
it
but
Jeremy.
If
you
have
advice
on
on
best
practices
for
this,
how
we
could
get
from
zero
to
done
in
12
weeks,
that
would
be
my
goal.
B
First
I
I
was
in
the
working
group
for
the
merge,
request,
widgets
and
that
one
lasted
about
a
year,
and
there
was
just
we
had
a
few
definitions
of
done
and
what
it
would
take
for
the
working
group
to
be
closed,
and
once
we
satisfied
those
we
would
do
that
and
we
had
a
kind
of
a
I
should
I'll
try
to
pull
up
the
agenda
of
that
and
share
that
with
you
for
those
meetings
and
and
in
that
way
you
would
be
able
to
see
how
we
attract
I
think
globally.
B
Some
things
at
the
top
of
the
the
the
document
and
then
how
we
addressed
each
week.
So
I'll
share
that
with
you.
We
also
I
think
we
publicly
streamed
the
recordings
too,
so
not
only
recorded
it,
but
it
was
like
a
live
stream
deal,
but.
B
A
A
A
A
D
A
C
A
But
this
is
around
our
exit
criteria
to
end
the
working
group
and
Jeremy.
You
brought
up
a
good
point.
How
do
we
know
we're
done?
What
are
we
actually
doing
in
the
Mr
itself
and
I'll
link?
It
here,
I
proposed
that
our
exit
criteria
is
one
or
more
Mrs.
Two
pajamas
defining
these
terms
in
the
list
of
terms
is
2bd
TBD.
A
I
can
paste
the
suggestion
in
from
the
direct
just
the
Mrs
description
of
memes
that
have
been
tossed
around,
but
there's
probably
more
to
this
and
some
of
these
we
may
not
want
to
do
as
well
there.
It
could
say
I
think
a
lot
of
these
we
do
have
use
for,
but
for
some
of
them,
such
as
landing
page
and
home
page,
we
may
decide.
We
only
need
one
of
those
terms
in
our
in
our
documentation
or
dashboard
might
suffice
for
everything
and
we
could
drop
different
terms.
B
C
B
B
Then
what
we're
talking
about
here
so
so
even
setting
some
initially
when
I
I
don't
want
to
get
us
too
off
track.
But
initially,
when
I
was
doing,
the
testing
I
was
thinking.
Okay,
you
know
the
question
was
like:
where
would
you
put
like
a
dashboard
layout?
I
was
thinking
of
more
of
a
template,
a
page
and
very
quickly,
I
learned
that
that's
not
what
people
thought
of
they
thought
of
content.
B
They
thought
of
of
data
visualization,
so
it
was
a
page
was
like
one,
the
last
thing
they
thought
of,
and
so
we
can
get
more
into
the
weeds
with
that.
I
don't
want
to
derail
this
now,
but
just
something
that,
as
I
was
going
through,
that
trying
to
figure
out
exactly
what
we
were
talking
about.
That
was
something
that
came
to
mind
for
me.
A
A
B
It
is
yeah,
you
I
mean
you
would
have
I
mean
you
could
have
editorial
content,
you
can
have
threads
wikis
I
mean
there's
all
different
sorts
where
dashboard
was
just
seen
more
related
to
data
Vis
as
it's
feeding
you
just
data
points
and
overview
content.
Like
summary,
meta
content
that
provides
you
a
peek
into
something.
So
it's
it
was.
It
was
more
granular
than
a
a
page
level
experience,
which
is
how
I
had
been
thinking
about
it
before
it
was
very
much
focused
on
the
type
of
content
that
we're
presenting.
B
A
It's
something
to
keep
in
keep
it
the
Genesis
of
this
working
group
too,
and
the
name
dashboard
I'll
link
it
here.
This
is
the
user
personal
dashboard
opportunity.
Canvas
was
completed
six
months
ago.
A
It's
an
opportunity
for
us
to
formalize
our
use
of
that
term
and
get
some
features
out
that
our
customers
really
want,
in
particular
in
this
one.
It
was
around
an
engineering
perspective
dashboard
that
would
give
you
a
high
level
View
into
what
you're
doing
or
what
your
team
is
working
on
and
so
part
of
from
the
product
side.
We
want
to
align
ourselves
in
the
market
with
a
like.
Do
you
have
dashboards?
A
Jira
has
dashboards
like
that
kind
of
a
conversation
aligning
our
feature
set
to
words
that
our
customers
understand
as
well
when
they're
making
purchases.
So
that's
something
else
to
consider
if
it's
a
content
type
or
if
it's
a
feature
and
how
we
think
about
this
thing,.
B
Yeah
yeah
and
from
a
pajama
standpoint
it
it
it's
we're
thinking
in
terms
of
page
layout
and
construct
and
content
and
so
not
marketing.
So
it's
a
bit
different
too.
It
might
be
one
of
those
things
where
we
have
to
weigh
the
differences
between
templating
and
versus
content
and
and
stuff
like
that,
and
that's
kind
of
what
I've
uncovered
in
some
of
that
research.
Is
that
yeah
there's
just
a
different
and
there's
a
few
different
modes
to
come
at
it,
but
most
often
it
was
just
content.
So.
C
Yeah
same
thing,
they're
facets
of
those
that
I
could
think
of
like
being
able
to
dig
into
a
graph
but
I
think
that
could
be
as
part
of
the
graph
in
itself.
C
Yeah
filtering
or
even
if
you
see
a
spike
you're
going
to
want
to
troubleshoot
it
by
digging
into
it,
to
get
to
the
heart
of
that
data
point
in
and
of
itself,
so
you
can
figure
out
why
it
happened.
You
know
what
are
they
calling
that
I
can't
think
of
what
it
is,
but
basically
troubleshooting?
You
know
trying
to
solve
problems.
A
C
A
C
C
C
I
think
they
have
something,
but
it's
it's
very
much
oriented
around
logs
and
apparently
the
logs
are
garbage
when
it
comes
okay,
finding
anything,
they
don't
tell
you
anything,
it's
just
here's
the
data
you
figured
out,
whereas
we
want
to
help
people
interpret
those
laws
logs,
so
they
can
actually
solve
the
problem.
Instead
of
just
saying
you
figure
it
out.
A
So
we
need
some
kind
of
method
to
alert
or
present
a
delta
or
a
change
that
someone
wouldn't
have
found
if
they're
just
waiting
like
I'm
just
always
every
month,
I
check
in
on
my
size
sense.
But
it
should
tell
me
if
my
users
dropped
or
something
like
that
so
I,
because
there's
usually
when
you
have
that
many
graphs,
you
can't
keep
up
on
them
like
that,
it's
just
so
hard
yeah
and.
C
That
and
that
brings
to
the
foreground,
Valerie's
biggest
concern
about
the
word
dashboard.
You
know
it's
not
really
a
dashboard.
It's
it's
alerting!
That's
really
what
you
want!
You
want
to
look
at
a
chart
and
say
when
it
reaches
this
threshold.
Tell
me
or
when
it's
about
to
reach
it
tell
me
so
I
can
deal
with
it.
I'm
not
going
to
look
at
my
dashboard
every
five
seconds
to
monitor
it
myself.
You
know
and
that's
what
came
out
of
the
research
that
will
and
Ollie
did
too.
A
C
A
D
A
B
A
C
C
D
B
A
C
In
our
past
monitoring
capabilities,
we
allowed
users
to
take
a
URL
of
a
chart
and
then
put
it
into
a
comment
so
that
it
would
be
a
pretty
Standalone.
Just
an
instance
of
that
chart.
Observability
is
doing
the
same
thing
with
their
profile
charts.
So
in
a
way
I
could
I
could
see
that.
But
it's
still
a
raptor
I
mean
that
chart
none
of
itself
is
is
a
widget.
You
know
it's
a
panel
of
some
sort,
otherwise
it
needs
that
to
contain
the.
A
C
B
B
No
widget
would
have
function
and
I
think
what
we're
talking
about
here
is
like,
like
maybe
just
a
container,
because
a
container,
it's
not
descriptive
of
of
the
UI
representation
of
it.
Necessarily
it
can
be
a
semantic
container.
It
can
be
a
visual
container,
but
it's
a
container
and
I.
Think
that
explains
what
it
is
panel
is
a
bit
it's
a
bit
too
loose.
Like
you
know,
a
drawer
is
a
panel.
The
drop
down
that
opens
opens
a
panel
like
those
are
panels.
B
A
B
But
then
that's
where,
like
I,
think
about
a
card,
for
example,
I
mean
a
card
could
be
a
container
of
this.
You
know
a
card
might
have
like
specific
functionality
tied
to
it
a
container,
maybe
not
so
much,
and
so
I
think
it.
It
might
depend
on
the
object
on
what
it
is
and
what
the
interactions
are.
Are
you
doing
something
at
a
container
level,
or
are
you
doing
something
at
a
at
a
graph
level
right?
B
Can
that
container
contain
multiple
graphs
or
multiple
elements?
You
know,
probably
so.
I
I
think
that
we'll
have
to
to
kind
of
figure
that
out
and
what
that
other
hierarchy
would
would
be,
and
maybe
there's
variance.
Maybe
you
have
a
static
container,
and
maybe
you
have
a
shareable
container
or
whatever
a
container
with
actions.
A
And
single
Source
versus
multiple
two
right,
like
maybe
you
have
one
good
place,
but
it
gets
used
in
a
comment
somewhere
in
gitlab
as
a
reference
or
in
somewhere
else
in
markdown.
Like
do,
we
know
that,
like
that
is
the
single
source
of
Truth
or
did
I
just
make
a
copy
and
now
mine's
out
of
sync,
because
ideally
you'd
want
to
have
it
like
one
place
right
and
then,
if
it's
referenced
on
10
different
dashboards,
we
know
that
that's
still
the
ssot.
C
A
C
A
C
A
Should
be
wrapping
up
in
the
next
minute,
there's
a
few
more
questions
down
below
that,
maybe
we
can
do
async,
and
this
one
can
we
list
every
current
dashboard
at
gitlab?
That's
a
question
I
have
and
how
it
would
be
best
to
go
about
that,
or
is
that
valuable.
D
B
I
was
just
going
to
say,
I.
Think
multiple
people
should
probably
have
some
perspective
on
that,
because
you
might
have
one
person
that
goes
and
says
tries
to
just
find
every
chart
that
they
can.
But
another
person
is
looking
at
pages,
and
so
this
might
even
be
something
you
just
post
to
the
ux
channel
and
kind
of
source
or
ux
research
like
hey.
B
Can
you
share
a
link
of
what
you
think
is
a
dashboard
in
gitlab,
and
then
we
can
collect
and
and
then
start
to
work
through
what
patterns
might
exist
for
for
what
we
think
it
is
today,
but
and
even
from
a
marketing
perspective
like
what?
What
do
they
think
is
a
dashboard
and
a
product
that
they
would
be
selling
as
a
feature
might
be
very
different
than
what
we're
thinking
of
as
documenting
in
pajamas.
B
C
Yeah
I
could
I
could
pick
Jeremy's
suggestion
and
pop
a
question
on
your
external.
B
I
could
try
to
signal
boost
it
if,
if
that
helps,
maybe
even
in
the
what's
happening
at
gitlab,
you
know
so
I
can
do
that
I'll
be
out
next
week.
So
I
don't
want
to
get
too
deep
in
anything.
That
I
would
leave
hanging
for
everybody.
So.
A
A
And
we
can
take
the
last
one
async,
which
is:
how
do
we
address
required
reading
as
a
group
there's
a
cool
post
from
Tim
Zalman
on
dashboards
into
the
channel
I
think
as
a
team.
We
should
all
stay
up
with
that.
Do
we
want
to
catalog
that
in
some
place,
or
just
rely
on
the
slack
channel
for
for
reading
to
be
put
in.
C
A
A
The
current
Integrations
group
is
doing
a
really
they're
also
doing
one
right
now,
and
they
have
a
good
structure
where
they
have
like
a
whole
epic
up,
and
then
they
create
issues
as
needed,
but
they're
building
features
we're
not
building,
but
we
could
still
create
issues
to
track
things
like
use
of
dashboards
as
a
list.
Things
like
that.
C
A
A
C
A
So,
let's
wrap
up
for
today!
Thank
you.
Everybody
we're
going
to
be
going
into
the
holidays,
so
we'll
probably
have
a
little
bit
sparser
attendance
throughout
December,
but
we'll
keep
it
async
and
let's
get
for
the
next
week's
meeting
to
think
about
some
deadlines
as
a
team
that
we
can
start
to
map
out
the
next
12
weeks
and
just
put
some
goals
down.
A
How
do
we
structure
getting
to
alignment
on
these
things?
What
would
be
some
good
Milestones
to
have
as
a
team.