►
From YouTube: 2020-11-30 Delivery team weekly
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
A
Awesome,
let's
get
started
so
first
up.
Thank
you
so
much
euric
for
helping
out
we've
got
an
interesting
one
going
on
at
the
moment.
I'm
hoping
this
is
going
to
be
the
only
one,
but
we
may
not
be
in
that
we're
generating
for
a
to
help
out
with
a
specific
customer
problem,
and
so
we
don't
it's
not
one
of
our
documented
processes.
A
So
it's
it's
been
a
little
bit
interesting
in
the
last
few
days,
so
yeah
thanks
so
much
eric
for
help
unblocking
us
on
that
one
earlier.
A
Cool
next
announcement
engagement
survey,
so
just
in
case
you
haven't
seen
it,
you
should
have
an
email
somewhere,
it's
coming
from
culture
amp.
A
So
if
you
haven't
been
through
that
already,
please
do
take
some
time
to
to
complete
that
I've
spoken
to
a
few
of
you
about
this
already,
like
coach
amp,
holds
the
raw
data.
A
There's
there's
no,
like
the
raw
data,
doesn't
come
back
to
gitlab
in
any
way
it
gets
cut
into
like
specific
reports
that
feed
the
data
back.
So
it
is
anonymous.
In
that
sense,
comments
are
super
useful
in
terms
of
giving
a
bit
of
context
on
why
you
have
certain
opinions
on
things,
but
comments
also
the
bit
that
usually
make
it
a
lot
less
anonymous.
A
So
if
you
are
adding
comments
like
try
and
make
them
as
generic
as
you
can
to
help,
people
remain
that
sort
of
anonymous
data,
but
but
yeah,
please,
to
be
honest,
like
I
know,
there's
probably
some
opinions
on
how
things
have
been
in
the
past
or
what's
happened
after
these
surveys
in
the
past,
but,
like
you
know,
it
is
useful
to
share
those
things
as
well
so
cool,
I
know.
So
what
when
is
the
deadline?
A
A
15Th
thanks
so
much
super
important
bit
of
information
and
I've
linked
in
the
the
select
thread
that
has
links
off
to
the
issue
and
things
like
that.
So
if
you
have
feedback
on
the
general
thing,
then
it's
being
gathered
as
well.
A
I
don't
actually
know
either
what
happens
next,
I
should
find
out,
but
assume
they'll
be
results
will
be
shared,
and
what
I
also
like
to
do
is
we'll
talk
through
this
together
as
a
team.
At
some
point,
once
we
have
results
and
see.
If
there's
anything,
we
can
do
within
our
team
to
kind
of
improve
on
areas
that
haven't
performed
so
well.
A
Awesome
so
discussion
so
unscheduled
work,
so
I
was
chatting
to
maren
earlier
and
we
were
talking
about
the
fact
that
there's
always
going
to
be
kind
of
unexpected
things
that
come
in.
But
what
is
probably
useful
for
me
to
keep
track
of
is
what's
the
unexpected
stuff
that
came
in
that.
Actually,
we
should
have
been
able
to
predict
in
some
way,
so
it's
not
just
always
unexpected.
A
So
I
was
thinking
just
as
a
super
lightweight
way
of
doing
this.
Initially
I'll.
Just
stick
the
unscheduled
label
which
have
to
have
found
but
I'll,
find
an
unscheduled
label
which
I
could
put
on
things
that
we
didn't
consider
we
were
going
to
be
working
on,
but
which
are
important
enough
that
we
need
to
do
them.
A
So
currently,
those
sort
of
things
are
some
of
the
recent
discussions
we've
been
having
about
getting
and
how
we
can
get
more
visibility
to
pipeline
failures
there,
and
also
things
like
renaming
of
the
master
branch
and
stuff
like
that.
That's
going
to
generate
work
for
us
that
we
perhaps
like
the
beginning
of
quarter
didn't
realize.
A
B
I
have
a
question,
so
are
we
talking
about
this
kind
of
some
kind
of
interrupt
driven
work,
so
we
are
doing
something
else,
and
then
we
have
some
kind
of
an
emergency,
and
then
we
want
to
track
that
this
happened
or
is
more
about
something
slammed
in
our
face,
but
is
not
so
urgent
to
be
done
right
here
right
now,
so
we
just
label
and
scheduled,
and
then
we
know
that.
B
A
It's
a
great
question
in
terms
of
the
interrupt
driven
stuff
are
you
I
mean?
I
know
we
have
like
corrective
actions
like?
Are
there
other
interrupt
driven
things
that
you're
thinking
of.
B
Well,
it
may
also
be
some
maybe
an
incident
or
or
an
security
issues.
I
mean
it's,
I
don't
know
right,
so
maybe
we
we
in
during
regular
development,
we
break
something
and
then
someone
has
to
stop
and
yeah
fix
some
pipeline
error
or
things
like
that,
yeah
or
maybe
we
have
an
api
change
in.
It
happened
in
the
past
that
we
had
api
changes
in
the
products
and
then
some
of
our
integration
no
longer
works
and
someone
had
to
stop
and
fix
those
things.
A
Yeah,
so
I
think
the
api
change
would
be
one
of
these
because
I
think
that's
a
great
one
where,
with
some
kind
of
processing
change,
we
could
have
like
been
aware
that
that
was
coming
up.
Probably
the
pipeline
breaking
or
incidents,
perhaps
a
little
bit
less.
So
I
I
don't
think
it's.
I
don't
think
it's
like.
We
definitely
shouldn't
label
them,
but
I
think
they're,
probably
they
will
always
exist
to
some
degree.
So
I
think,
there's
probably
a
little
bit
less
learning
that
we
can
do
from
those
things.
A
I
think
if
it
feels
useful
like
feel
free
to
either
add
it
or
let
me
know
so,
we
can
add
it,
but
I,
I
think,
probably
the
ones,
I'm
thinking
more
of
are
types
of
work
that
would
have
been
possible
for
us
to
have
known
about
in
some
form
so
that
we
could
have
got
a
little
bit
further
ahead
of
so
like
I'm
thinking
kind
of,
like
somebody
did
a
project
that
impacted
us,
or
we
had
a
thing
for
some
reason
that
had
a
time
limit
on
it
that
we
forgot
about
and
didn't
prioritize
or
something
along
those
lines.
A
Cool
job:
do
you
want
to
verbalize
that,
before
I
jump
into
a
little
bit.
C
Yeah,
I'm
also
having
a
little
difficulty
kind
of
wrapping.
My
head
around.
What
type
of
issues
would
you
know
would
require
this
label
because
I'm
used
to
scheduled
work
in
the
context
of
sprint
planning,
maybe
maybe
work-
that's
not
tied
to
an
okr
interrupt
driven
work
that
comes
from
outside
the
team.
C
Those
are
two
things
I
can
think
of
that
we
could
use
it
for,
but
there's
also
the
category
of
work
where
we
schedule
and
when
we
plan
and
schedule
like
an
epic
and
then
we
have
a
bunch
of
tasks
and
then
there
are
things
that
we
didn't
think
about
that
we
need
to
add
later
and
in
the
context
of
sprint
planning.
This
can
be
unscheduled
work
because
it's
like
something
that
you
didn't
plan
for
the
sprint,
but
you
know
you
had
to
do
it,
but
I
don't
think
that
applies
here
right.
That's.
A
Right
yeah,
no
I'm
thinking
like
I
I'm
gonna
keep
it
kind
of
loose,
so
we
can
kind
of
see
how
it
goes,
but
I
am
thinking
along
the
lines
like,
I
think
anything
that's
to
do
with
an
okr.
I
think
that's
the
problem
is
scheduled.
I
think
it's
more
like
a
a
problem
that
could
have
been
scheduled
hasn't
been
scheduled.
A
It's
probably
more
how
I'm
thinking
about
it
so,
like
I'd
say
like
this
renaming
of
the
master
branch
like
we
could
have
scheduled
that
like
if
we'd
have
known
that
was
coming
up
this
quarter,
we
could
have
scheduled
that
work
as
it
is.
We
haven't
and
now
we're
kind
of
we're
at
danger
of
becoming
a
bit
behind
on
that
task.
A
So
I'm
not
going
to
ask
you
to
do
anything
with
this
labeling.
I
will
add
these
in
and
I'm
going
to
say
initially,
I'm
going
to
use
them
really
so
that
I
can
review
how
I've
been
thinking
about
prioritizing
things
and
see
if
we
can
change
that
or
how
we
can
increase
visibility
from
other
teams.
A
But
the
question
I
did
have
for
you
is
in
terms
of
our
current
scheduled
things.
I'm
thinking
we
obviously
have
okrs
and
all
our
work
related
to
okrs.
Is
there
anything
else
that
you
considering
to
be
scheduled
work
at
the
moment
that
we
that
we
should
like
treat
as
scheduled?
Is
there
anything
else.
C
Maybe
maybe
release
related
work
and
release
work
that
you
do
as
a
release
manager
to
both
like
work
on
the
release
and
also
improve
the
release
process,
because
that's
sort
of
I
feel
like
that's
sort
of
scheduled,
it's
kind
of
baked
into
being
a
release
manager.
Is
that
you're
you're
working
on
that
sort
of
thing
as
well.
A
B
There
is
also
the
architecture
workflow
stuff
that
it
may
happen
from
time
to
time.
So,
for
instance,
right
now,
I'm
working
on
the
uploads
and
object
storage
blueprints.
So
it's
something
that
wasn't
really
in
the
planning
when
we
started
the
quarter
but
yeah,
it's
still
something
that
we're
doing.
A
Yes,
okay,
that's
a
great
example
as
well,
actually
yeah
of
something
that
almost
becomes
scheduled.
We
don't
just
fall
into
that
so
much
it's
like
a
choice,
so
yeah,
that's
another
great
example
myra.
How
do
you
want
to
consider
the
rest
of
the
security
process?
D
That
is
a
good
question.
I
was
seeing
some
updates
about
removing
the
build
label
because
it
is
not
currently
prioritized
so
up.
I'm
not
sure.
If
I
mean
if
it
is
not
scheduled,
I
guess
it
will
be
to
non-scheduled.
A
D
A
Is
it
something
which
so
I
am
assuming
that
so
we
have
a
security
release
scheduled
for
next
week
for
monday,
so
we
won't
have
it
for
that.
The
next
one
will
be
in
january.
I
assume
because
of
the
production
change
lock
over
over
the
holiday
period.
A
Cool
okay:
let's
consider
it
unscheduled
in
that
case
like
there
may
be
cases
where
we
need
to
react
and
do
some
process
changes,
but
I
think
it
it
does
feel
like.
We
have
a
lot
of
stuff
in
progress
right
now,
so
be
good
to
limit
that
where
we
can.
A
Cool,
okay,
great,
okay,
well
I'll
start
work
on
this
I
say
I
expect
to
see
a
few
extra
labels,
but
don't
feel
you
have
to
do
anything
and
what
I
will
do
is
try
and
work
out
some
patterns
that
we
can
discuss
and
and
come
up
with
a
plan
around.
A
So
one
of
them,
the
simple
one,
is
the
first
one,
which
is
the
proposal
for
a
deployment
slo
we're
at
the
state
of
discussing
what
deployment
really
means
and
then
once
we
work
out,
we
can
work
out
what
a
sensible
number
is
now
the
background
for
this
one
is
the
mttp
has
in
it.
A
So
this
would
be
to
try
and
separate
those
a
little
bit,
and
so
we
would
have
mttp
as
our
overall
kpi
and
within
that
we'd
have
a
split
between
kind
of
things
that
we
can
directly
control
and
things
that
we
can't
directly
control,
which
we
can
help
work
with
others
to
change,
and
then
the
second
one
is
around
mean
time
between
deployment
failure,
which
is
a
sort
of
breakout
of
mean
time
between
failure,
which
scalability
are
working
on
at
the
moment,
and
the
idea
behind
this
would
be
to
try
and
get
us
something
which
we
could
use
as
a
kind
of
counterbalance
to
mttp,
so
that
we'd
know
like
if
we
start
deploying
too
fast.
A
We
would
see
this
measure
increase
and
we
could
sort
of
use
that
to
say:
okay,
we're
taking
too
much
risk
here.
However,
both
of
them
are
in
very,
very
early
stages,
so
actually
stepping
back
a
little
bit.
What
I
thought
might
be
more
interesting
is
to
think
about
what's
a
useful
thing
for
us
to
be
tracking
in
terms
of
like
an
mttp
style
thing.
What's
what
information
would
be
useful
for
us
to.
E
A
Cool
so
like
the
actual
kind
of
like
each
of
the,
the
phases
is
kind
of
the
the
goal
yeah.
E
Yeah,
I'm
curious,
I
don't
know
if
we
should
touch
on
this
now
but
like
maybe
we
want
to
track
how
long
it
takes
for
us
to
get
a
feature
out,
not
a
feature,
a
release
out
along
with
our
tracking
auto
deployments.
B
So
if
we
could
track
mean
time
between
migration
and
mean
time
between
background
migration,
so
that
we
know
how
long
it
takes.
Oh,
so
every
ex
deployment
we
have
one
migration-
or
maybe
we
just
have
one
background
migration
a
month.
Something
like
that,
so
that
we
can
understand
the
the
frequency
of
migration
and
background
migration.
B
E
Similar
to
that
point,
I
made
a
comment
on
that
issue
already,
where
it'd
be
interesting
to
have
tracking
for
every
component
of
our
deploy,
because
things
like
italy
is
the
perfect
example
of
where
there's
no
change
in
the
ghillie
version.
We
don't
deploy
to
those
nodes.
We
just
skip
right
over
that.
E
So
if
we
take
an
entire
mttp
and
it
includes
giddily
one
day-
it's
gonna
be
like
hey.
It
took
us
five
minutes
to
deploy
where,
if
we
add
the
giveaway,
because
there
is
a
version
change,
it
will
be
like.
Oh,
it
took
three
hours
to
deploy,
so
our
mtp
is
going
to
do
a
big
sawtooth
over
the
course
of
time,
and
that's
going
to
be
kind
of
awkward
to
figure
out
how
to
balance
and
measure.
But.
B
Yes,
but
again
it's
we,
you
can
still
have
italy
as
things
into
trucks,
apparently,
but
then
web
front
and
all
the
other
things
that
right
now
can
be
tracked
as
an
individual
thing,
then
we'll
be
just
part
of
it.
A
B
What
the
way
I
see,
the
those
this
guy,
this
type
of
metrics,
is
more
where
we
can
socialize
with
development
teams
when
there
is
a
kind
of
struggle
in
the
way
that
software,
so
that
component
of
git
lab
interacts
with
the
deployment.
So
it's
not
because
it
really
depends
right.
So
some
maybe
there's
some
optimization
that
we
can
do
in
our
deployment
pipeline,
but
oftentimes
could
be.
That
is
actually
the
way
the
software
is
designed
that
doesn't
allow
for
a
faster,
faster
deployment.
So
both
cases.
A
Cool
okay,
great,
I
think
I
will
open
up
an
issue
which
has
the
kind
of
general
overarching
concept,
so
it's
kind
of
aware
that
both
the
deployment,
slo
and
the
mean
time
between
deployment
failure
are
two
specific
related
things
that
kind
of
tie
into
something
much
bigger,
which
is
also
tied
into
mttp.
So
I'll
open
up
a
discussion
issue
just
to
gather,
try
and
link
those
together
and
also,
if
you
want
to
kind
of
debate,
ideas
or
share
thoughts,
and
things
like
that,
then
go
ahead
on
that
as
well.