►
From YouTube: 2021-12-06 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).
A
A
Well,
you
mean
you,
don't
have
back-to-back
meetings
all
morning,
robert,
like
the
only
reason
why
calendar
works
is
because
it's
virtual
and
like
you
just,
can
click
on
new
links,
whereas
there's
a
real
problem
in
an
office
where
you
have
to
kind
of
like
sprint
to
the
other
side
of
the
building.
In
like
three
seconds.
A
A
Chaos
awesome
welcome
everyone,
happy
monday
and
so
awesome
mttp.
Looking
very
nice.
Is
there
anything
in
particular,
anyone
wants
to
highlight.
D
Why
we
didn't
have
such
nice
mttp
there,
but
we
just
started
this
week,
so
we
need
to
see
what's
going
on,
but
overall
we
were
mostly
busy
with
backports
right
and
security.
D
So
I
think
that
was
the
main
topic.
According
to
release
management.
A
Awesome,
okay
well
say:
give
us
a
shout:
if
there's
anything,
you
need
to
need
help
with
otherwise,
like
it's,
it's
looking
pretty
good.
I
highlighted
in
slack
as
well.
If
you
look
at
the
weekly
mttp,
which
is
useful,
gives
a
kind
of
slightly
different
view.
That's
counting
hourly,
so
weekends,
look,
pretty
scary
and
pcl's
look
pretty
terrible,
but
because
of
the
monthly
one
the
way
it
counts
is
it
doesn't
count
on
pcl's.
So
it
looks
a
little
bit
different
cool,
so
I've
added.
A
E
D
A
Incident
review
meeting
discussion
around
that
s1
instant.
That
would
be
a
great
one
to
maybe
bring
up
some
of
the
thoughts
we
had
around
the
challenge
of
getting
deployments
restarted,
because
that
would
be
a
good
one
for
us
to
actually
be
able
to
make
a
bit
easier.
F
We'll
probably
want
to
make
sure
that
if
we
don't
have
this
down
already
put
something
inside
of
the
issue,
maybe
as
a
corrective
action.
If
we
have
any,
because
that
what
I
would
imagine
what's
going
to
dominate
that
conversation
is
the
actual
incident
itself,
because
it's
a
very
unique
situation.
It's.
A
Yeah,
that
makes
sense
cool
great
to
say
a
couple
of
announcements
there.
I
will
let
you
have
a
read
through
discussion,
so
something
I
was
thinking
about
is
other
ways
we
could
be
more
iterative
and
I
don't
want
to
name
these
two
things.
Specifically.
A
They
were
just
two
issues
that
I
was
looking
through,
but
my
impression
at
the
moment
is
we
have
quite
a
lot
of
things
in
progress
and
that
we
have
a
lot
of
feedback
on
reviews
and
it
seems
that
maybe
we
have
re-reviews
going
on
and
perhaps
they're
like
holding
us
back
a
little
bit
more.
So
I
was
wondering
about
it's
kind
of
in
the
general
sense
of
like
what
can
we
do
as
a
team
to
be
more
effective?
A
You
know
two
bits
I
was
looking
at
specifically
just
to
say
that
sort
of
got
me
thinking
along
this
line,
but
then
they're,
not
the
only
two
examples
we
have
is
on
for
a
I,
like.
That's
a
blocking
issue,
which
I
know
mary's
working
on,
so
that
one
would
be
a
good
one
like
is
there
an
iteration?
We
could
take
on
that
to
unblock
it
and
then,
similarly,
on
4a
2
with
something
like
that,
where
it's
a
we
get
big
gains
by
having
something
automated.
A
Is
there
a
messy
sort
of
first
situation?
We
could
go
through
to
actually
get
this
out
and
start
using
it
or
testing
it,
and
then
we
can
come
back
and
and
tidy
up
on
the
code.
So
generally,
I'm
just
thinking
like
other
ideas
we
have
like.
How
can
we
reduce
the
back
and
forth
and
how
can
we
become
more
effective.
F
C
Was
actually
thinking
the
same
scarborough
that
yeah,
some
of
the
challenges
we
face
require
may
be
more
challenging
in
terms
of
communicating
why
we
want
to
do
something
than
the
action
change
itself,
and
this
may
bring
to
a
lot
of
feedbacks
and
having
to
address
this
type
of
concern.
C
So
I
mean
it
really
depends
on
what
we're
working
on
and
the
more
people
we
affect
with
a
single
change,
which
is
something
quite
unique
to
this
team.
The
more
we
may
have,
I
would
say,
pushback,
but
pushback
is
not
derived
even
just
genuine
question
right.
Someone
you're
just
asking
why
or
just
providing
his
input.
A
For
something
where
we
are
for,
like
the
one
that
ruben's
working
on
on
the
automated
blog
release
posts,
do
we
have
a
process
already
where
we
we
do
like
a
follow-up
for
so
like
we've,
never
chat
a
little
bit
this
morning
like
do
we
have
any
precedence
for
this
thing
is
working.
We
can
merge
it
and
test
it
and
here's
the
follow-up
issues
or
the
follow-up,
mrs,
that
do
the
tidy
up
of
the
code.
E
I
don't
know
we
have
a
process
for
it,
but
we've
I've
done
it
in
the
past.
With
previous
teams,
you
can
open
follow-up
issues
for
refactoring
things
like
that.
E
I
think
one
thing
I
can
do
is
maybe
I
think
I
rely
too
much
on
robert
and
maira
for
reviews.
So
it's
like
a
24
hour
review
cycle.
Maybe
I
can
start
giving
more
reviews
to
alessio
henry,
maybe
achmed
yeah.
B
A
A
Yeah,
it
doesn't
have
to
be
like
we've
rushed
through.
I'm
just
curious
on
that,
particularly
some
of
those
comments
on
looks
like
things
that
maybe
are
like
style
or
things
we
definitely
want
to.
You
know
we
definitely
want
to
have
good
code,
but
I
wonder
in
this
one
in
particular,
it
falls
into
our
like,
I
guess
almost
like
poc
right,
like
we've,
never
had
an
automated
blog
post
before
and
it
might
be
interesting
to
actually
have
something
that
we
can.
A
B
B
B
Where,
like
we
can
move
it,
but
then
you
have
to
move
it
and
there's
a
stupid
issue
and
it's
a
little
extra
work.
So
I
don't
know
if
it's
happened
before,
but
I
don't
think
we've
maybe
prioritized
going
back
and
actually
doing
the
cleanup.
It's
just
one
of
those
things
like
if
you
have
time
to
fix
this,
that's
one
of
the
things
you
can
pick
up.
C
Yeah
I
like
to
think
of
this,
like
the
analogy
of
tidying
up
your
room
when
you're
a
kid
for
me,
it's
even
tiding
up
my
apartment
now
that
I'm
grown
up,
but
the
thing
is
that
it's
kind
of
this
promise
when
you
say
yeah,
I
will
fix
this
later.
Yeah
sure
I
do,
and
so
this
happens
globally
on
development
side
right
so
and
when
you
are
reviewing
something
as
a
maintainer
you
always
you
have
to
make
your
point
in.
C
But
then
you
have
also
this
nice
thing
when
someone
actually
works
on
some
follow-up
issue
that
you
open
as
the
next
item
immediately
after,
which
is
obviously
a
joyful
moment
when
it
happens
right.
So
that's,
okay,
so
my
point
is
that
especially
in
release
tools
or
the
thing
that
we
work
by
ourselves,
we
are
kind
of
in
charge
of
the
schedule
and
everything
I
would
say
that
I
mean
we
are
within
one
team
right,
so
we
should
trust
each
other.
A
Yeah-
and
I
think
I
think
to
be
clear-
yeah,
like
I
guess,
I'm
thinking
of
of
that
example
right
where
it's
maybe
less
about
even
splitting
issues
and
maybe
just
more
about
splitting
mls
right
like
if
we
have
this
version
and
it's
functional
and
gives
us
some
benefit.
It
is
dangerous,
as
far
as
we
can
tell
I
I
can.
There
are
definitely
times
depends
on
the
feature,
but
I
think
there
are
particularly
things
around
our
tooling.
A
Where
we're
the
users,
I
think
we
should
consider
if
we
can
merge
those
and
then
follow
up
that
person
can
keep
working
on
it
and
do
the
follow-up
mr,
which
is
like,
and
now
here
is
the
cleanup
and
here's
actually
making
it
complete
solution.
F
Are
there
any
other?
I
was
gonna
suggest
that
I
think
part
of
the
problem
might
be
that
we've
expanded
our
team
quite
greatly
and
the
amount
of
stuff
that
we
both
touch,
use
and
utilize
each
and
every
day.
So
I
feel
like
that's
also
contributing
to
the
amount
of
workload
that
we
see
on
ourselves.
You
know
we
used
to
just
run
release
tools,
but
you
know
now
we.
F
More
with
chat,
ops,
we've
got
this
new
staging
environment.
Kubernetes
has
gotten
to
a
point
where
we're
a
little
bit
more
mature
with
it
like
we
do
a
lot
more
these
days,
our
team
has
also
grown
so,
like
I
questioned.
E
F
A
Was
gonna
say
like
absolutely
like?
I
guess
is
the
and
a
more
general
thing
yeah
I
was
going
to
say
like?
Are
there
other
things
we
could
do
to
be
more
efficient
like
do?
People
generally
feel
that
that
your
workflow
and
your
work
you're
able
to
be
efficient
or
other
areas,
we
can
improve.
D
I
think
what
room
mentioned
at
the
beginning,
maybe
to
ask
for
people
in
the
same
time
zone
to
work
together
or
maybe
I
think
that
can
help
in
some
cases
to
just
be
a
little
bit
faster
right,
because
it's
really
the
case.
If
you
want
to
get
input
and
don't
have
the
people
available,
then
it
slows
you
down
right
because
you
feel
like
you
are
blocked
and
maybe
turn
to
something
else,
and
this
is
distracting
a
little
bit
and
turns
away
your
focus.
D
A
Great
and
one
thing
I've
added
on
today
on
the
kind
of
priorities,
delivery
priorities
message
is
because
I
know
everyone
is
doing
lots
of
other
stuff,
and
I
know
you
will
get
pinged
on
general
things
as
well.
A
Is
this
week
I've
done
a
slightly
different
one,
see
how
it
helps
I'd
love
to
get
some
feedback
on.
A
This
is
just
to
try
and
give
like
the
top
priorities,
and
then
I
know
you
all
have
kind
of
various
other
things,
but
hopefully
this
is
a
kind
of
like
if
I
get
two,
mrs
coming
in
my
way,
if
one
of
them
is
for
those
three
projects,
please
prioritize
that
otherwise
it's
kind
of
like
p2,
like
you
know
you
can
kind
of
come
to
it
afterwards,
but
I
know
there
are
other
things
that
probably
don't
fall
into
those
priorities.
A
Obviously
it
depends
on
the
context,
but
I
do
I
am
kind
of
keen
that
we
find
a
way
to
maybe
reduce
the
amount
of
stuff
we
have
in
in
flight
and
then
have
a
few
extra
people
working
on
the
same
thing.
So
we
can
sort
of
like
try
and
push
those
forwards
and
try
and
unblock
things.
C
Yeah,
this
is
something
so
if
we
have
less
things
in
flight
and
more
people
are
assigned
to
the
same
say,
let's
call
it
project
and
it's
kind
of
easier
to
say
be
on
the
same
page
and
having
more
context
so
there's
less
context
which,
in
into
just
getting
those
reviews
of
what
is
he
doing,
right,
yeah
but
yeah.
Obviously,
then
yeah.
We
have
to
see
the
the
the
output
out
of
this
right.
So
if
we
end
up
doing
less
or
more
really
depends
on
it,
yeah.
A
E
So
do
we
want
to
distinguish
between
like
large
issues,
that
people
are
working
on
and
small
ones,
because
sometimes
having
like
extra
small
ones,
that
you
can
like
just
pick
up
and
work
on
for
half
a
day
or
something
can
be
useful,
say
if
you're
stuck
on
the
larger
main
issue
that
you're
working
on
you
just
pick
up
something
small
work
on
it.
A
little
bit
make
some
progress
and
then,
when
you're
unblocked,
you
come
back
to
the
main
issue.
You're
working
on.
A
We
can
do
if
it's
helpful
for
sure
like
if
I
think,
if,
if
you
you
feel
like
you
have
things
like
like
gaps,
you
want
to
pick
up
some
smaller
stuff,
then
sure
like
we
can
get
that
set
up.
Definitely
I've
definitely
prioritized
beyond
reviews.
So,
like
you
know,
if
there's
a
way
you
can
unblock
someone
else
then
go
for
that,
but
yeah
we
can
we
can.
A
We
can
try
and
do
that
I'll,
try
and
put
some
stuff
on
the
board.
The
board
always
has
a
load
of
p4
stuff,
but
I'll,
try
and
put
some
stuff
on
there
that
there
are
definitely
some
things
on
there
at
the
moment
there
are
small.
So
if
you
do
feel
like
you
have
a
few
hours,
then
there
are
some
right
now,
but
I'll,
try
and
see
if
we
can
always
have
a
few
extra.
A
Right
so
yeah,
that's
yeah,
so
henry-
and
I
chat
a
little
this
morning
about
this,
and
I
think
one
thing
that
be
helpful
in
release
management
is,
I
think,
in
the
last
six
months
or
so.
We've
done
a
lot
of
side
projects
whilst
release
managing,
and
perhaps
what
that
means
is
what
we
squeeze
out
is
small
tool,
improvements
or
docs
updates,
and
it
also
adds
a
load
of
pressure
so
happy
to
kick
us
off
for
next
year.
A
A
Awesome
all
right,
thank
you
for
the
discussion.
Everyone
is
there
anything
else.
Anyone
wants
to
bring
up
on
the
recording.