►
From YouTube: GitLab 15.1 Kickoff - Monitor:Respond
Description
GitLab 15.1 Kickoff for the Monitor Respond Group
https://gitlab.com/gitlab-org/monitor/respond/-/issues/104
A
A
Awesome
so
what
we
have
planned,
I'm
going
to
switch
it
up
a
little
bit
and
talk
about
some
plan.
Maintenance
first
get
the
boring
stuff
out
of
the
way
in
this
coming
upcoming
milestone.
We
have
a
few
usability
improvements,
including
a
way
to
toggle,
monitor
deployment
and
infrastructure
on
the
left-hand
side,
toggle
the
visibility
of
those
navigation
items,
and
then
we're
gonna
make
some
slight
improvement
to
the
incident
issue
by
hiding
the
edit
button
in
tabs.
A
That's
not
the
the
main
description
tab
and
we'll
also
be
going
to
be
working
on
a
security
issue
so
jumping
into
the
more
interesting
stuff
after
shipping.
The
incident
timeline
mvc
we're
going
to
be
adding
a
few
first
features.
First
of
all,
we're
going
to
allow
the
users
to
edit
a
timeline
at
items.
Currently
you
can
add
new
timeline
items
in
the
nbc,
but
there's
no
way
to
edit
it.
A
A
A
So
the
way
it's
going
to
work
is
I'm
showing
the
one
thing
that
this
was
surprised:
you'll
notice
that
there's
going
to
be
a
new
clock
icon
here
in
a
comment,
and
once
you
click
it,
he
actually
adds
it
directly
into
the
timeline
which
I
don't
have
a
screen
pulled
up.
Apologies,
but
it's
it's
just
a
quick
way
to
facilitate
adding
additional
information
into
instant
timelines.
A
A
So
you'll
see
that
this
new
area
on
the
page
is
introduced,
resource
links
and
the
way
you
add
links
is
you
provide
a
text
and
a
url,
and
once
it's
added
you'll
see
it
here.
So
in
this
example,
the
user
is
adding
a
new
zoom
link,
so
this
can
also
have
application
beyond
the
incident.
So,
given
that
the
incident
is
built
off
of
issue,
we
can
eventually
make
it
available
to
regular
issue
types
as
well,
which
is
pretty
cool
and
I'll
turn
it
over
to
amelia
to
talk
about
before
looking
stuff,
we're
working
on.
C
So
right
now
we
are
capturing
when
an
incident
is
open
and
closed,
but
we've
heard
from
our
own
teams
and
from
other
people
that
that
isn't
necessarily
all
of
the
information
we
need
to
be
capturing
and
incidents
are
likely
to
have
started
prior
to
the
incident
issue
actually
being
opened.
So
in
order
to
accurately
track
incident,
metrics
and
terms
of
how
long
incidents
take
to
resolve
and
such
and
stuff
like
that,
we
need
to
be
capturing
additional
time
stamps
in
the
ui.
C
So
right
now,
we've
been
working
on
that
the
timeline
form
that
kevin
was
just
sharing,
adding
an
additional
field
to
that
form
to
to
capture
an
incident
timestamp.
So
that's
the
design
we've
been
working
on,
but
we
want
to
validate
that
design
to
make
sure
that
it
actually
works
for
for
our
sre
team
and
for
our
other
end
users.
So
that's
one
of
the
things
ux
will
be
working
on
in
this
next
milestone,
and
the
next
thing
is
to
clean
up
the
presentation
of
items
in
the
incident
highlight
bar
and
sidebar.
C
You
can
see
a
current
incident
right
here.
We
have
this
highlight
bar,
but
because
a
lot
of
people
aren't
associating
alerts
with
incidents
a
lot
of
times
this
highlight
bar
is
mostly
empty,
so
we
want
to
use
that
space
better
and
what
we
are
planning
to
do
is
use
these
timestamps
that
we're
capturing
over
here
and
introducing
them
into
this
incident
highlight
bar,
so
that
important
information
is
surfaced
right
up
in
front
and
another
thing
that
we
are
hoping
to
look
at
is
capturing
and
displaying
instant
duration.
C
When
we
have
an
accurate
start
time
and
end
time
for
incident,
we
can
show
how
long
the
incident
lasted
and
again
we're
thinking
about
using
that
highlight
bar
to
display
that
information.
So
we
think
that
all
of
these
improvements
will
help
better
surface
the
most
important
information
for
people
who
are
actively
involved
in
resolving
incidents.