►
From YouTube: 2023-06-12 Delivery team weekly EMEA/AMER
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).
B
Hello,
hello
people
have
returned.
This
is
exciting,
exciting
delivery,
weekly
skill
back
welcome
back
good
to
see
you.
B
And
Steve
welcome
back
good
to
see
you
thanks,
awesome
and
who
else
forgot
so
I'm,
also
just
going
to
say
I'm
going
to
play
like
battery
roulette
right
now,
I've
got
45,
but
my
laptop
is
running
rather
hot,
so
we'll
see
how
much
the
zoom
call
Burns
through,
but
hopefully
it's
not
more
than
45.
B
B
So
welcome
everyone.
This
may
be
all
of
us.
This
is
June
the
12th.
This
is
our
emea,
America's
delivery
weekly.
B
So
for
those
of
you
who
haven't
been
with
us
for
a
little
while
this
one
just
messed
up
my
view,
so
I
can
no
longer
see
it's
good,
because
my
laptop
is
running
just
a
little
hot.
B
We
have
a
section
at
the
top
where
we're
going
to
try
and
keep
rough
out
of
office
stuff
and
that's
just
because
it
is
proven
to
be
a
little
tricky
to
keep
track
of
things
via
the
app
in
slack.
So
if
you
have
stuff,
you
know
feel
free
to
drop
it
in,
and
hopefully
this
helps
us
cross
team
cool.
We
don't
have
any
announcements
at
this
stage,
but
I
wanted
to
just
run
a
little
discussion
and
have
a
quick
voting
session
on
the
blocks
deployments
label.
B
So
I
have
seen
a
few
incidents
and
I've
seen
a
few
questions
and
discussions
in
slack
that
made
me
wonder
whether
we
actually
all
think
of
this
label
in
the
same
way
so
quick
vote,
you
can
vote
under
as
many
of
these
options
as
you
want,
but
when
you
are
using
the
blocks
label
on
an
incident
or
when
you
see
it
on
an
incident,
please
add
your
name
about
whether
you
think
that
label
is
saying
I'm
unable
to
deploy.
B
B
Cool
okay,
great
so
from
this
it
looks
like
we
are
using
this
label
to
do
two
different
things.
So
majority
of
votes
are
against
this
label
being
the
the
thing
that
is
going
to
block
all
future
deployments,
but
we're
also
using
it
as
a
almost
a
reporting
tool
right.
Does
that
sound,
fair,
like
we
are
using
it
to
also
indicate
that
there
is
a
problem
and
I
try
and
include
your
comment
here
as
well.
Jenny,
which
is
the
releases
or
deployments,
are
also
like.
B
Do
you
want
to
verbalize
Jenny.
C
Yeah
I
was
just
busy
typing
yeah,
so
basically
I
use
it
for
anything.
That's
like
you
know.
We
need
to
release
a
security
release
today,
but
you
know
it's
completely
blocked
because
of
this
incident.
Right
stuff,
like
that
I
do
tend
to
use
on
block
deployments.
I
know
that
it
does
block
like
production
of
like
the
promotion
part
at
which
point
I
do
take
that
away,
but
sometimes
I
do
by
myself,
while
using
that
label.
B
C
Generally,
take
it
away
after
I
do
notice
that
it's
causing
a
actual
Auto
deploy
problems
so
I
think
I,
don't
know
if
the
incidents
actually
have
a
wait.
Now
we
have
the
delivery
severity
label,
so
I
I
think
I
tend
to
use
that.
But
I
do
remember
using
that
late,
like
the
blocks
deployment
label
for
something
that's
more
like
release
related
yeah.
B
B
D
Yeah,
so
for
metrics,
we
don't
need
to
know
what
kind
of
items
are
where
they
were
stopping
our
operations.
So
whenever
we
have
like
a
change
request
that
is
operating
the
database
or
is
doing
something
on
the
web
nodes
that
we
cannot
deploy
well,
I
normally
add
a
label
like
okay,
these
change
requests
or
this
incident.
B
Does
the
automation
that
pulls
together
the
deployment
blockers
report?
Is
it
using
this
label.
D
B
D
E
Yeah
and
if
the
label
gets
removed,
it
will
also
search
for
the
ones
that
have
the
deploys,
blocked
and
the
numbers
of
hours,
so
I
think
it
yeah
I
think
it
pulls
both
of
those
levels.
B
Because
the
reason
I
asked
about
this-
and
it's
certainly
interesting
to
hear
the
kind
of
different
requirements
we
have
I,
suspect
I,
don't
know
this
for
sure
so
feel
free
to
disregard
this,
but
I
suspect
we
sometimes
make
our
lives
more
difficult
with
deployments
because
of
adding
this
label,
for
example
like
if
you
have
tests
failing
on
stage
in
Canary-
and
you
add
this
blocked
deployments
label,
you
have
you've
given
yourself
another
step
in
that
you'll
have
to
remove
that
to
unblock
yourself
later
versus
the
tests
are
failing
and
when
the
fix
lands
through
in
that
environment,
they
will
just
be
passing
and
your
deployment
will
continue.
B
So
I
wonder
if
it
might
be
interesting
for
us
to
try
and
separate
out
these
two
intentions,
like
the
Box
deployments,
has
the
automation
coded
around
it
to
say,
if
you
add
this
label,
everything
is
going
to
grind
to
a
halt
and
not
get
going
again
until
this
is
removed
like
it's
the
kind
of
like.
What's
the
what's
the
chord
You
Yank
in
the
in
the
in
the
factories.
B
B
E
Yeah
I
think
actually
this
it
was
an
interesting
label
when
I
joined
the
team,
I
I
thought
it
was
the
first
one
and
then
kind
of
learned
that
it
was
more
for
the
second
one
like
I
thought
it
was
like.
Oh
this,
this
causes
deployments
to
be
blocked
and
it
does.
But
it's
it's
more
of
like
no.
We
we
want
to
stop
deployments.
It
seems
as
good
intent
about
label
so
I
wonder
if
I
mean
even
just
changing
it
from
blocks
deployments
to
like
block
deployments
like
kind
of
makes
a
different.
E
But
yeah
I
think
those
three
situations
that
you
kind
of
described
make
a
lot
of
sense.
B
G
Yeah,
but
if
you're
going
to
have
another
label
that
you
know
serves
the
purpose
of
the
Second
Use
case
that
we
spoke
about,
then
you
could
have
the
label
that
actually
blocks
deployments
like
the
label
itself
blocks
deployments.
You
could
have
that
be
called
something
like
stop
stop
deployments,
while
the
label
that
simply
informs
others
that
this
issue
is
blocking
deployments
could
use
the
word
or
some
form
of
the
word
block.
G
B
The
word
I
remember
like
that.
One
I
feel
like
that
one
gets
on
videos
super
quick.
So
actually
it's
interesting
on
the
reporting
thing,
because
we
do
for
the
case,
you
were
talking
about.
Jenny
I,
think
the
delivery
impact
labels
would
work
well
for
that,
one
where
it's
kind
of
like
we
have
the
ability
of
saying
this
is
high
impact
to
delivery,
but
it
doesn't
that
doesn't
solve
it
with
the
this
thing
held
us
up
and
I
want
to
get
it
into
the
deployment
blockers
report.
D
I
wanted
to
rectify
myself.
The
deployment
blocker
report
doesn't
use
this
label.
It
actually
uses
the
release,
blocker
label
and
it.
C
I
was
actually
about
to
say
almost
the
same
thing
where
I
I
think
there's
a
there's
a
bit
of
confusion,
because
I
also
look
at
the
deployment
blockers
table
right
and
I
see
something
like
you
know:
I'll
talk
about
it
when
we
go
to
that
section,
but
you
know
multiple
QA
failures
in
the
security
release,
so
that
takes
something
completely
securely
release
related
and
it's
tagged
with
release
blocker
right,
but
it
still
technically
goes
into
deployment
blockers
with
zero
hours
into
staging
and
prod
so
I
think,
even
within
our
teams
like
reporting
it
like
that
wording,
kind
of
gets
confusing
right.
C
F
Security
release
is
a
weird
one:
isn't
it
because
it's
the
only
one
where
the
thing
has
to
go
into
production
and
it's
not
already
been
in
production
and
gitlab.com
all
the
other
releases.
It's
already
been
there,
and
now
we
have
to
package
it,
whereas
the
security
release
it's
different,
because
it
has
to
still
go
to.com
to
be
validated
right.
That.
C
B
Probably
not
a
deploy
block
like
actually
I,
think
it's
relatively
rare,
that
any
of
us
would
need
to
use
the
deploy
blocker
label
the
blocks
deployment
label,
because
that
is
more
of
a
I.
Think
it's
more
commonly
used
by
someone
outside
the
team
to
say
hey!
This
is
an
emergency,
don't
promote
this
under
any
conditions
like
remain
stable,
but
it's
kind
of
like.
If
we
know
about
it,
we
tend
to
not
promote
it.
B
So
I
think
it's
relatively
rare
that
that
will
be
like
a
big
label
obvious
for
us.
The
reporting
is
a
little
bit
more
hazy
and
yeah.
It's
a
great
example.
You
give
that
Journey
about
the
different
in
different
names
and
different
intentions
behind
them.
E
B
E
E
As
you
can
say,
I'm
curious
Jenny
mentioned
the
delivery
impact
labels
and,
and
so
that
covers
a
lot
of
like
what's
mentioned
in
the
number
one
item,
I'm
unable
to
deploy
and
I.
Think
like
our
team-
and
maybe
our
section
knows
about
those
labels,
but
do
other
people
know
like
I,
guess
what
what
are
those
labels
used
for
outside
of,
like
our
team
kind
of
seeing
them
and
knowing
what
they
mean.
C
I
think
it's
more
for,
like
signaling
purposes
more
like
we
don't
do
any
like
metrics
based
off
of
them
right,
correct,
yeah
and
also
I've
personally,
never
seen
anything
outside
of
severity.
One
get
used
for
that
impact
label
and
if
you
know
anything's
blocking
us
is
severely
one,
then
maybe
that
should
just
turn
into
a
different
label,
I'm,
not
sure,
because
I'm
not
even
sure
how
many
severity
levels
there
are
for
that
label,
because
we
just
always
use
one.
B
For
example,
that's
really
high
impact
for
us,
so
that's
where
the
delivery
labor
the
impact
labels
and
arose
from
and
the
CH
we
don't.
We
certainly
I
haven't
seen
them
widely
used.
The
general
idea
behind
them
is
what
we
can
do
if
we
stick.
These
on
is
actually
then
go
and
say
shout
to
people
and
say
like
hey.
We
have
two
impact.
B
B
Yeah
thanks
I
was
expecting
to
be
on
the
delivery
page,
no
they're,
not
what
would
be
useful.
E
One
other
thing
to
note
on
that,
like
on
that
same
topic
is
like
I've
heard
from
some
other
team
members
that
it
would
be
very
useful
if
they
had
somewhere
to
check
our
deployments
blocked
right
now,
like
like
a
status
page
kind
of
so
whether
or
not
we
can
have
a
label
Feed
into
that.
Somehow
I
could
see
other
people
finding
that
useful
and
preventing
some
of
those
messages
we
see
in
in
our
Channel
and
in
the
releases
Channel.
B
What
about
is
there
any
action
we
can
take
so
that
we
don't
need
to
use
blocks
deployment
for
reporting
purposes
so
that
we
keep
blocked
deployments
as
they
when
this
label
is
on?
We
do
not
want
a
deployment
to
be
taking
place
and
when
this
label
is
not
on,
we
do
want
them
to
take
place
wherever
possible.
B
So
that
would
mean
if
you
have
a
pipeline
with
failing
tests,
you
wouldn't
need
to
use
the
label
because
you
do
want
to
deploy
it's
just
you
actually
can't,
because
your
tests
are
failing,
but
as
soon
as
your
tests
are
passing,
your
deployment
goes
on
versus.
This
is
an
incident,
and
potentially
we
have
a
problem
with
the
database
and
let's
not
make
any
more
changes,
in
which
case
we
definitely
don't
want
to
be
accidentally.
Deploying
on
top
of
that,
like
is
there
a
practical
action
we
could
take
to
help
with
that.
G
I
wonder
if
we
can
sort
of
differentiate
the
action
and
Reporting
labels
very
clearly
like
say
using
something
like
Scopes
scoped
labels.
So,
like
action,
block
deployments
or
report,
you
know
blocks
deployments.
So
it's
something
better
than
that,
but
so
like
you
can
just
look
at
it
and
you
know
that
this
label
is
going
to
take
an
action
or
this
label
is
used
for
reporting.
E
E
It
might
make
sense
to
update
labels
there,
like
we
mentioned,
the
release,
blocker
label
adds
things
to
the
report
and,
and
it
is
part
of
the
process,
to
add
that
anytime,
you
open
up
an
issue
on
the
release,
tracker
project
and
so
I
think
maybe
that
label
just
needs
to
be
changed
or
split
into
one
or
two
labels
to
make
more
sense.
So
it's
less
confusing
as
to
what
it's.
F
It's
almost
a
core
problem
with
labels,
isn't
it
that
labels
are
descriptive
of
state
or
meant
to
be,
and
that's
it's
kind
of
hard
to
describe
an
action
you
want
to
take
based
on
it
and
then
describe
the
state.
You
want
the
thing
to
be
in
after
having
taken
the
action.
So
if
you
had
a
label
that
said
deployment
stopped,
it
wouldn't
be
obvious
that
you
know
in
order
to
stop
deployments,
you
need
to
apply
this
deployment
stopped
label,
but
that
is
the
state
you
want
to
describe
on
the
Mr
and
end
up.
B
Steve
those
it
doesn't
have
to
be
like
today,
because
I
know
you've
just
returned,
but
would
you
mind
perhaps
just
making
a
proposal
and
just
dropping
it
into
slack
with
a
here's?
What
this
could
look
like
and
we
could
just
see
if
it
looks
like
it
might
be
better
or
worse
and
and
see
if
we
can
head
towards
like
we?
B
May
it
may
be
that,
like
you
know,
we
don't
need
to
massively
do
loads
and,
like
maybe
we're
fine,
but
it
also
feels
like
a
reasonable
enough
confusion
that
we
should
probably
assume
more
people
in
the
future
joining
the
team
will
have
the
same
confusions,
or
maybe
some
of
the
engineering
callers
also
have
this
confusion.
So
if
we
could
make
it
more
clear
that
probably
is
a
good
thing.
B
Yeah
cool
thanks,
Dave
great
go
back
over
to
you.
A
So
I
know:
we've
worked
at
the
delivery
or
the
release
Management
schedule
already
out
all
the
way
through
October
I
am
planning
on
taking
probably
the
entire
month
of
August
and
September
all
for
paternity
leave
and
I
know.
A
That's
probably
going
to
create
a
lot
of
stress
for
the
people
that
live
in
the
Americas
time
zone,
I'm
wondering
if
we
want
to
I'm
wondering
if
we
want
to
ship
the
schedule
at
all
for
anyone
just
so
that
I'm,
you
know
at
least
participating
in
release
management
at
all,
so
I'm
looking
to
see
if
Myra
you
would
like
for
me
to
do.
July
effectively
is
what
I'm
trying
to
ask
here.
D
A
Okay,
I'll
put
in
a
merge
request
to
make
that
change.
B
So,
release
managers,
everything.
C
Yeah
that'd,
be
me,
give
me
one
second
I'm
trying
to
go
over
the
deployment
blockers
there
isn't
that
much
from
the
start
of
my
day
to
actually
fill
out
that
sheet.
So,
let's
see.
C
Yeah,
let's
go
take
a
look
at
the
release
on
the
deployment
blockers
for
a
bit,
so
I
was
just
going
through
these
incidents
and
trying
to
fill
out
a
bunch
because
there
were
a
lot
last
week
and
so,
as
you
can
see
throughout
the
week,
there's
just
been
a
lot
of
small
to
moderate
sized
incidents
I'm
finding
out
more
under
the
additional
incidents
where
deploys
block
on.
C
What's
it
called
blocks,
deployment
label
was
used
and
then
kind
of
taken
off,
and
then
that
doesn't
get
taken
into
consideration
here,
mostly
because
the
blocks
like
prod
blog
label,
wasn't
used
at
the
time
but
yeah
so
a
bunch
of
those
incidents,
and
they
get
reflected
pretty
well
in
this
graph.
C
I
will
go
throughout
after
this
call
and
then
try
to
fill
those
out.
But,
as
you
can
see,
there
are,
you
know,
spurts
of
not
promoted,
spiking
up
and
kind
of
trying
to
catch
up
with
that
Spike
and
then
more
incidents
happening
around
this
time.
Yeah.
It
wasn't
too
pretty
of
a
week
last
week
and
then
yeah.
We
got
into
the
auto,
deploy
pause
for
production
and
I.
C
Believe
all
of
deploys
were
down
for
another
incident
this
morning,
yeah
over
here,
so
yeah
I
will
go
fill
those
out
but
yeah,
not
looking
too
good
for
last
week
kind
of
gets
reflected
here.
We've
been
having
some
pretty
rough
weeks,
so
yeah
deployment
frequency
the
highest
was
four.
At
least
there
wasn't
like
a
dip
like
the
other
weeks.
C
C
Nothing
two
out
of
the
ordinary
and
I'm,
pretty
sure
I
mean
yeah.
We're
going
on
deploy
today.
So
pretty
sure
we're
gonna
see
another
Spike
here.
I,
don't
really
know
how
to
read
the
lead
time
changes
that
well
when
it
doesn't
have
this
much
difference
but
yeah.
That's
basically
how
it
looks
like
any
questions,
comments.
B
B
That's,
usually
how
I
interpret
this
so
like
the
week
around,
the
May
16th
was
like
overall
a
healthy
week
because
it
mostly
stayed
below
the
red
line
and
then
the
only
thing
that
makes
me
question
a
little
bit
is
that's
the
medium.
It's
not
the
target,
so
it
will
presumably
that
red
line
moves
if
we
have
a
number
of
bad
weeks,
but
generally
that's
how
I
read
this.
C
Yeah
sounds
about
right,
yeah,
it's
pretty
much
about
it!.