►
From YouTube: Scalability Team Demo - 2022-02-03
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
All
right,
I
have
the
first
and
currently
only
item,
so
I
didn't
prepare
a
whole
lot
for
this,
and
this,
I
guess,
is
more
of
a
talking
through
a
change
than
a
demo
per
se,
but
I
figured
it
would
be
worth
at
least
kind
of
showing
and
talking
through
the
motivations.
B
So
woodhouse
is
our
internal
tool
for
declaring
incidents,
and
it's
a
slack
bot
that
brings
up
a
form
that,
when
filled
out,
will
then
generate
incident
issues.
Zoom
channel
incident
issues,
slack
channel
and
cross
link
stuff
as
we've
expanded.
Our
incident
manager,
rotation
and
we've
got
a
lot
of
engineering
managers
and
senior
engineers
on
board.
B
B
The
constraints
around
how
we
engage
incident
managers
has
changed
so
previously
it
was
a
very
small
pool
that
was
pretty
busy,
and
so
we
would
kind
of
avoid
paging
the
incident
managers
unless
needed,
but
now
we
have
a
big
pool,
and
so
I've
been
thinking
about
ways
of
improving
that
process
and
making
sure
that
they
actually
know
what
is
going
on,
and
so
here's
kind
of
the
proposed
change
that
is
trying
to
make
it
easier
to
do
the
right
thing
when
you
declare
an
incident.
B
So
actually
let
me
show
you
a
demo
of
what
that
looks
like
at
the
moment
and
then
we
can
compare
just
to
sort
of
see
the
the
before
and
after
a
little
more
clearly.
So
let
me
check
if
there's
anything
confidential
on
the
screen
doesn't
look
like
it.
B
B
This
is
a
pretty
difficult
decision
to
make
like
which
one
do
I
page.
Do
I
need
to
page
this
person?
Do
I
need
to
page
this
person?
It's
it's
kind
of
difficult
and
anecdotally.
I'd,
say
folks
within
infra
when
they
declare
incidents,
they
usually
don't
take
any
of
these
folks
external
to
infra,
either
don't
take
any
of
them
or
take
all
of
them
and
it's
kind
of
there's
no
clear
logic
to
it,
because
we
don't
have
a
clear
policy
for
it
and
so.
B
Going
back
to
the
change,
the
new
idea
is
to
basically
tie
this
to
severity,
so
for
s1s
and
s2s,
we
page
all
of
them
by
default,
and
then
we
make
it
opt
out.
So
if
we
declare
an
incident-
and
we
know
for
sure
that
this
doesn't
require
the
attention
of
say
cmoc,
because,
for
example,
it's
a
security
incident
and
we
don't
want
to
make
any
public
disclosure
yet
then
we
can
sort
of
opt
out
and
untick
the
box,
and
so
the
the
new
ui,
for
that
is
I
mean
the
the
ui
changes
aren't
huge.
B
It
looks
pretty
similar
but
yeah,
basically
they're
ticked
by
default,
and
they
will
only
we
will
only
page
for
s1s
and
s2s,
so
s3
and
s4
won't
page
anyone,
because
those
usually
don't
require
immediate
attention
and
one
of
the
other
nice
things
about
this
change.
Is
it
kind
of
removes
the
the
implicit
expectation
that
incident
managers
need
to
be
checking
slack
at
all
times?
B
B
If
it's
important
page
me,
that's
that's
kind
of
always
been
my
philosophy
and
I
I
would
like
to
extend
that
to
our
incident
managers
as
well,
so
that
they
can
go
off
and
do
something
else
and
know
that
if
they
are
needed,
they
they
will
be
brought
in
so
yeah.
That's
that's
the
the
basic
idea
and
I
just
wanted
to
kind
of
share
it
and
maybe
gather
some
thoughts.
C
I'm
just
wondering,
because
it
says
you
you
can
you
were
saying
that
we
would
not
pay
for
serenity.
Three.
B
Yeah,
that's
right.
It's
a
bit!
It's
a
bit
of
a
tricky
one
to
do
with
the
ui,
because
the
the
slack
building
blocks
don't
allow
you
to
do
dynamic
right
stuff,
I
mean.
Ideally,
if
you
select
severity,
three
it'll
hide
these
right
yeah
I
mean
I,
I
kind
of
tried
my
best
by
saying
page
only
for
these
severities,
but
if
you
have
any
ideas
on
how
to
make
this
a
little
bit
clearer,
yeah
I'd
love
to
hear
it.
D
What
about
if
the
the
paging
for
severity
is
closer
to
the
severity
box,
because
at
the
moment
it's
severity
service
severity
again.
B
Yeah
I
mean
I,
I
think
the
the
default
behavior
would
be
to
fill
out
this
this.
Maybe
this
and
not
touch
this
most
of
the
time,
so
I
kind
of
want
to
keep
the
the
boxes
that
are
more
likely
to
actually
get
interaction
at
the
top,
but
yeah
there's
I
mean
it's
with
these
ux
things.
There's
always
difficult
trade-offs.
B
Yeah
I
mean
if,
if
you
come
up
with
some
ideas,
let
me
know
I'd
I'd
be
happy
to
make
this
a
bit
clearer,
because
I
I
agree.
I
think
that
is
the
currently
the
most
confusing
part
about
this
change.
So
if
we,
if
we
can
address
that,
that
would
be
great
yeah.
C
I'm
also
trying
to
think
if
there's
a
situation
in
which
there's
a
s3
that
you
will
want
to
bring.
Maybe
something
like
we
found
out
this-
that
it's
going
to
blow
up
in
two
weeks.
Something
like
that.
So
I
don't
want
to
do
it
in
a
nice,
do
or
a
nice
one.
But
I
don't
know
if.
C
A
I
can
like,
I
think,
that
somebody
not
an
infrastructure
or
me,
for
example,
could
declare
an
incident
s3
and
want
the
all
column
involved,
because
I
want
to
change
something
or
do
something
and
I
want
their
feedback
kind
of,
and
now
I
just
mentioned
them,.
A
B
Yeah,
that
sounds
like
something.
For
slack
I
mean
I.
I
can
certainly
see
that
there
might
be
some
cases
where
someone
underestimates
the
severity,
and
so
we
then
don't
page
on
that,
so
there
might
be
some
edge
cases
that
aren't
covered
very
well,
but.
A
B
A
B
D
B
D
Thanks
for
taking
us
through
that
eagle
yeah,
I
hope
you
have
a
good
rest
of
your
day.