►
From YouTube: 12.3 Monitor:Health Kick-off
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
Oh,
all
right
so
as
part
of
the
scaling
of
gitlab
and
the
growing
of
the
engineering
and
product
teams
we're
changing
a
little
bit
about
how
we
do
kickoff
for
each
milestone,
which
is
wonderful,
so
we're
gonna
be
just
recording
a
meeting
where
we
review
items
for
this
upcoming
milestones:
12
3.
This
is
not
me
doing
a
readout.
This
is
not
a
perfectly
choreographed
call.
This
is
more
here.
The
big-ticket
items
that
could
be
part
of
the
panel
discussion
for
the
main
kickoff
call.
Do
we
feel
like
there's
enough
information
in
there
I?
A
Do
we
agree
on
scope?
Do
we
agree
on
commitment
and
at
a
future
State
when
we
are
fully
staffed?
This
is
also
the
time
when
we
would
go
over
designs
for
those,
so
I'm
gonna
share
my
screen
and
we're
gonna
go
through
the
things
that
I
would
deem
the
release
post
items,
the
things
that
contribute
to
incident
management
direction
or
other
product
categories
that
the
Health
Group
might
be
working
on.
We
are
not
gonna
go
through
every
single
bug
or
every
single
small
improvement.
A
A
So
here's
our
planning
board
I
have
filtered
it
for
12:3,
which
I
realize
all
it
does
is
clear
out
the
other
columns,
because
it's
already
organized
by
milestone
at
the
top
of
the
milestone,
I've
put
our
larger
ticket
items.
Everything
else
is
underneath
it
and
we've
got
a
bunch
of
MVC's
as
well
as
continuation
on
our
zoom
integration.
If
you
guys
have
looked
at
our
vision
page,
these
will
populate
there
by
the
direction
label.
A
A
B
So
I
went
ahead
and
just
raised
my
tokens
and
for
the
new
spaces
we
we
are
anticipating,
it
should
work,
so
I,
don't
see
any
blockers
to
prefer
that
chases,
my
tokens
over
so
actually
ice
last
Friday
I
start
started
the
implementation
of
very
tiny
and
small
client
zoom
clients
in
order
to
support
some
actions
on
the
meetings
most
likely
creating
meetings
and
getting
information
for
a
specific
meeting
which
brings
us
a
little
bit
closer
to
the
slash
zoom
command
in
the
near
future.
I
guess
but
again,
that's
just
I.
A
A
B
Think
for
now,
like
just
showing
the
status
of
the
zoom
call,
would
be
easy
enough.
Other
stuff
like
showing
how
many
participant
has
been
on
the
call
involves
a
little
bit
more
API
calls
I
guess
so,
but
we
could
easily
again
destroy
if
the
latest
we
linked
into
a
issue.
Description
is
still
going
on
finished
or
is
the
waiting
stage
by.
C
We
want
to
include
a
front-end
engineer.
Hopefully
it
would
be
very,
very
light
for
an
end
work,
but
I
could
one
do
that.
The
only
other
thing
that
I'd
you
know
make
sure
I
want
to
raise
is,
is
the
possibility
of
sort
of
you
know,
expanding
the
scope
of
this
and
and
making
it
I
guess
slightly
riskier
to
finish
in
time
is.
A
A
D
A
Right,
I'd
also
like
to
add
that
this
is
an
excellent
example
of
someone.
Engineering
and
UX
can
continue
to
collaborate
on
during
the
milestone
and
that
we've
done
our
work
to
prepare
something
70%,
but
these
are
experienced
side
and
then
we'll
continue
to
shift
gears
as
we
learn
new
things.
So
I
love
that
thanks
guys
all
right.
A
So
I
changed
of
this
particular
issue
and
I'll
start
from
a
high
level
for
those
who
are
not
familiar
with
this
one.
It
used
to
say
slack
integration
for
incident
management
and
I
changed
it
to
say,
slack,
chat,
ops
for
incident
management,
and
we
see
verbal
reasons.
One
chat,
ups
via
slark
is
already
a
feature
that
exists
within
get
lab
that
it's
owned
by
the
configure
stage.
We
are
adding
to
it
augmenting
it
to
support
the
operations
personas
that
we're
serving
with
this,
and
we
are
adding
to
the
chat
ops
feature
using
less
slack
product.
A
So
in
the
future
I
know
we
have
a
matter
most
integration
or
we
could
potentially
choose
to
add
more
from
a
child's
perspective
using
other
products.
I
wanted
to
be
clear
that
this
way
is
existing.
This
is
the
known
chat,
UPS
feature
using
the
slack
product
and
we
are
changing
it
or
adding
to
it
for
incident
management.
So
we
found
both
in
my
prior
experience
and
through
a
ton
of
conversations
that
Emilia
and
I
have
had
with
our
customers.
That
majority
of
everybody
is
using
slack
as
a
chat
tool
to
collaborate
during
the
firefight.
A
So
we
want
to
close
the
gap
between
gitlab
and
slack,
develop
a
set
of
functionality
that
makes
it
really
easy
and
intuitive
for
people
to
do
things
such
as
create
update,
close
issues.
Add
comments,
share
knowledge
share
metrics
to
the
issue,
while
operating
in
slack,
which
is
where
they
do
most
of
their
work.
A
So
the
MVC
for
this
particular
feature
and
we're
going
to
iterate
on
this
in
future
milestones
is
going
to
be
essentially
enabling
the
workflow,
where
an
issue
has
automatically
been
created
in
gitlab
from
a
trigger
alert,
and
we
are
sending
this
issue
to
slack
so
that
configuration
already
exists
once
the
issue
is
in
slack
and
people
have
collaborated
on
it.
We
are
adding
a
slash
command
which
allows
you
to
close
the
issue
so
completing
that
collaboration
cycle.
We
allow
you
to
get
the
issue
into
slack
and
we're
gonna.
A
Allow
you
to
close
it
in
get
lab
to
minimize
that
context.
Switching.
So
it's
really
simple.
It's
the
boring
solution
to
this
particular
workflow.
At
the
end
of
that
we're
gonna,
be
posting
system
messages
to
the
issue
within
get
lab.
Saying
issue
was
resolved
and
then
within
slack
this
is
an
optional
part
of
the
scope,
depending
on
how
difficult
we
find
the
MDC
posting
a
system
message
to
the
threaded
discussion.
Within
slack
that
says,
this
issue
has
been
resolved
so
that
individuals
who
are
working
on
either
platform
have
the
same
context.
A
I'm
going
to
take
that,
as
this
is
pretty
straightforward
to
follow
on
that
errand,
Amelia
and
I
are
doing
a
little
bit
of
divergent
thinking
this
month,
where
we're
laying
now
what
the
integration
Changkat
lab,
slack
and
zoom
looks
like
and
kind
of
how
all
of
those
products
are
going
to
work
together,
as
they
are
frequently
used
together
during
a
firefight,
and
we
want
to
make
that
experience
really
streamlined.
So
we've
got
an
MVC
for
this,
we're
just
at
the
point,
more
authenticating,
zoom
and
starting
to
add
new
features
to
that
one.
A
We
recently
built
or
are
almost
done
with
the
ability
to
embed
Drex
charts
from
the
cute
lab,
metrics,
dashboard
and
issues,
and
we
want
a
mirror
that
same
functionality
for
Griffin
Griffin
is
currently
more
heavily
used
and
far
more
features
than
our
metrics
dashboard.
At
some
point
in
the
future,
in
support
of
our
single
application
view
for
the
DevOps
lifecycle,
our
dashboard
may
be
there,
but
for
the
time
being,
we
need
to
meet
people
where
they
are
working
and
support
them
in
products
that
they
are
actively
using
during
the
firefight.
A
A
C
A
A
A
There
may
be
situations
where
you
are
not
looking
to
include
Prometheus
and
you're
monitoring
portfolio,
and
we
want
to
enable
people
to
be
able
to
take
advantage
of
incident
management
and
not
be
prescriptive
and
the
tool
that
they
should
use.
So
we
need
to
consume
alert
some
other
sources
rest
on
point.
Someone
can
just
send
a
JSON
payload
to
it.
We
consume
it
and
we
generate
an
issue
with
that.
A
Payload
from
that
message,
I
am
proposing
that
we
have
a
block
at
the
top
of
those
issues,
similar
to
the
way
that
we
create
issues
for
Prometheus
alerts,
you're
about
to
get
a
bunch
of
sirens.
I
live
on
the
Main
Street,
sorry
about
that,
and
so
at
the
top
four
issues
for
Prometheus
alerts.
Sorry,
we
show
a
title
starts
at
description:
runbook
peter.
Am
I
missing
any
other
attributes
that
we
include
there.
B
I'm
not
sure
about
the
attributes.
I
think
these
are
fine.
I
was
just
thinking
about
authentication,
so
right
now
for
pro
meters
and
night
manager,
we
do
generate
and
para
talk
token
on
github
and
configure
the
manager
to
send
this
token,
while
sending
an
alert
and
I
think
this.
We
also
have
to
consider
for
for
this
generic
endpoint.
C
B
So
right
now
the
token
for
self-managed
parameters,
installations
lives
in
the
service
area,
so
project
services
and
it's
the
parameter
service
and
I'm,
not
sure
if
they
use
I,
would
be
confused
to
go
to
pro
meter
service
in
order
to
configure
that's
for
maybe
two
which
is
not
prodigious
so
maybe
creating
a
new
service
which
is
should
be
fairly
easy.
It's
good
enough,
but
I'm
not
sure
about
this.
Just
raising
the
authentication
issue,
because
I
don't
think
we
can
allow
folks
without
authentication
poking
some
endpoints.
C
A
Fact
that
we
also
had
a
call
scheduled
to
talk
about
this
but
I'm
looking
at
my
calendar
and
I
am
not
seeing
it.
So
the
goal
was
to
have
a
synchronous
conversation
about
this
at
the
end
of
the
week
and
I'll
make
sure
that
we
have
that
scheduled.
So
could
that
be
Peter
says
Aaron
and
I?
Would
anyone
else
like
to
be
a
part
of
that
for
the
initial
kickoff
to
make
sure
we're
ready
to
go
in
this
one.
A
D
So
for
the
rest
of
the
team,
the
milestone
dates
are
still
a
little
bit
confusing
because
there's
still
a
lot
of
conversation
about
what
it
should
be
since
we've
moved
to
CD.
So
for
the
sake
of
being
on
the
same
page
for
our
team,
we're
just
going
to
in
our
team
internally
determined
that
16th
is
the
day
when
the
new
milestone
will
start,
even
though
technically
you
may
have
until
the
18th
to
merge
for
that
release
and
technically
the
kickoff
kickoff
call
about
product.
It's
like
around
the
7.
A
Awesome
well,
that
is
it!
Thank
you
so
much
for
attending
this
impromptu
call,
especially
to
those
for
whom
this
is
outside
of
their
working
hours.
I
really
appreciate
it
for
milestones
in
the
future,
we'll
be
doing
a
recorded
kickoff
call
every
month,
I
think
it'll
be
nice
to
align
the
team,
have
a
wonderful,
Tuesday
or
Tuesday
evening.