►
From YouTube: 2023-01-09 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
B
A
C
I
I
just
realized
like
nine
days
ago.
A
A
A
D
Yeah
I
think
we
are
ready
to
begin
so
welcome
everyone.
First
delivery
weekly
of
the
year
and
there's
a
bunch
of
announcements
up
there
that
you
can
all
read
as
async
things
so
discussion
items
I,
don't
know
who
put
the
first
one
on
to
someone
you
want
to
claim
it.
D
All
I
will
add
to
that
then.
So
question
is
around
fastboot
and
delivery
fastboot
and
the
sort
of
proposed
dates
rapidly
approaching
I,
don't
have
an
update
for
you.
I
I'm,
hoping
McKelly
may
know
more
when
he
comes
back
tomorrow,
so
I
I
well,
I
will
catch
on
my
Kelly
tomorrow
and
we'll
come
back
to
you
with
an
update
on
that.
But
at
the
moment
no
no
new,
like
updates
on
there.
So
we
are
still
waiting.
D
Cool
cool,
so
oh,
it's
such
a
great
that
you're
here
Fabian,
because
I
was
going
to
talk
a
little
bit
about
the
project
management
update,
so
hopefully
you've
all
seen
the
discussion
that
marriage
had
on
Friday.
If
you
haven't,
please
do
make
30
minutes
so
that
you
can
watch
through
that
really
interesting
to
see
what
sort
of
things
we
can
expect
to
kind
of
be
asked
about
in
the
future,
not
a
huge
number
of
changes
that
came
up
from
delivery.
D
I
wanted
to
say
thank
you
for
all
of
you
who
have
been
keeping
up
on
epics
and
labels
and
statuses.
You
know,
I
Know
It
is
a
bit
of
admir
work,
but
it
is
really
valuable
and
it
really
helps,
particularly
as
we
now
have.
Two
teams
like
super
valuable
to
be
able
to
just
have
a
single
view
of
what
what
everyone's
working
on
and
where
we're
up
to,
if
you
ever
are
wondering.
D
So
now
we
have
the
delivery
board
where
you
can
see
kind
of
issues
up
to
date
like
in
progress
and
what's
coming
up
but
I
know
sometimes
I
get
questions
from
people
about
projects
or
statuses
or
projects.
Actually,
our
release
velocity
epic
is
the
place
you
should
be
able
to
get
that
answer
from.
So,
if
there's
a
project
in
place
or
it's
coming
up-
and
you
don't
have
the
answers
available
to
you-
there,
that's
a
good
one
to
go
and
ask
the
dri
and
and
help
them
share
that
with
us.
D
One
thing
I
did
want
to
just
mention
outside
we're.
Actually
so
usually
was
like.
Thank
you
for
updating
those
things.
The
one
bit
that
did
stand
out.
I've
massively
probably
brought
this
forward
by
the
fact
that
Fabian
is
on
this
call,
but
one
thing
that
was
mentioned
on
there
that
I
do
know
that
we're
not
super
great
at
is
on
issues.
So
when
we
close
issues,
we
don't
tend
to
do
a
two
lot.
Much
admin
on
this.
D
Actually
one
thing
that
really
contributes
to
this
is
the
fact
that
it's
possible
to
close
issues
with
Mrs,
so
merging
of
an
MR,
does
tend
to
leave
a
lot
of
our
issues
in
a
not
super
updated
State
when
we
close
them.
So
please
just
have
a
little
think
about
this.
As
you
are
closing
issues,
we
should
be
updating
issue
descriptions
that
should
reflect
basically
what
you
decided
to
do.
D
We
don't
always
complete
everything
we
originally
stated,
or
sometimes
we
make
decisions
and
end
up
building
something
totally
different,
which
is
absolutely
fine,
get
the
issue
updated.
So
it's
clear
what
we
actually
did
decide
to
do.
We
very
very
rarely
update
labels,
so
please
do
also
set
the
workflow
in
for
a
label
to
be
done
if
it
is
done.
D
That
certainly
helps
with
us
keeping
track
of
where
we're
up
to
on
things
and
then,
hopefully
just
a
double
check,
because
this
should
have
happened
earlier,
but
just
a
good
time
also
to
just
check
that
the
issue
was
originally
assigned
to
you,
and
it
also
belongs
to
an
epic.
So
all
of
our
issues
should
live
in
an
epic
if
they
don't
release.
D
Velocity
is
usually
the
right
epic,
if
you,
if
it's
not
tied
to
a
project
but
keeping
those
things
linked
together,
also
makes
it
much
easier
for
us
to
find
them
again
in
the
future.
C
This
is
a
kind
of
minor
question,
but
when
you
add
a
note
after
closing
an
issue,
what
heading
do
you
give
it.
D
And
like
what?
What
sort
of
note
are
you
thinking
of
like?
Is
that
kind
of
the
updating,
the
description
yeah.
D
D
If
it's
a
case
that
we
didn't
do
all
of
it,
you
can
just
maybe
have
a
section
with
like
these
three
points
have
moved
off
or
will
be
done
on
a
future
issue
or
if
there
was
a
proposal-
and
you
can
then
add
another
section
which
is
sort
of
like
oh,
we
actually
implemented,
but
it
doesn't
matter
too
much.
I
think
the
the
main
guidance
I'd
give
and
I'm
happy.
D
If
anyone
has
specifics,
they
want
to
sync
on,
or
we
can
talk
through
like
for
that
specific
issue
like
just
let
me
know
where
I'd
say
generally
try
and
get
your
issues
so
that,
if
you
just
open
them
fresh
in
a
browser,
it's
really
clear
from
just
reading
that
description.
What
actually
happened
so
sometimes
that
might
mean
we
need
to
just
reorder
information
a
little
bit
so
that
that
relevant
stuff
is
at
the
top
of
the
description.
D
E
Yeah
I
I
had
actually
a
little
proposal
I
as
far
as
I
understood,
currently
like
the
way
we
manage
backlog
is,
is
completely
on
the
shoulders
of
managers
like
sort
of
or
or
dris
and
I,
see
that
we
have
a
lot
of
stuff
in
the
backlog
and
and
the
the
a
lot
of
like
very
old
tickets
there,
and
they
are
not.
E
There
may
be
some
leftovers
from
the
epics
that
we
already
closed,
but
the
sometimes
tickets
are
still
popping
up
from
two
years
ago
or
one
years
ago,
and
they
are
kind
of
that's
what
I
understood,
but
maybe
I'm
wrong,
but
they
are
popping
up
because
someone
actually
go
in
like
scanning
through
them
and
Define,
and
if
it's,
if
it's
a
good
approach,
if
it's
still
valid
or
not
but
I,
think
that
might
be
a
bit
overwhelming
for
dri.
E
So
project
managers
to
do
that
manually
and
we
made
maybe
add
some
sort
of
automation
for
review
old
tickets
and
they
are
just
like
if,
if
they
are
like
I,
don't
know
three
months
old
and
they're
in
the
the
Epic
is
closed
or
epic
is
not
closed.
They
may
be
kind
of
popping
out
popping
up
automatically
to
the
to
the
to
the
head
of
the
backlog.
E
Somehow,
and
we
we
know
that
okay,
we
need
to
figure
out
what
to
do
with
those
tickets.
If
not,
if
it's
not,
if
it's
not
needed
to
do
like
it,
if
it
doesn't
require
any
action,
we
can
just
maybe
automatically
close
them
because
I'm
honestly,
it's
it's
very
hard
to
look
at
the
backlog.
It's
super
huge.
A
A
We
have
some
Automation
and
reports
for
other
issues,
some
of
them
just
stay
open
for
for
a
long
time,
I
I
think,
if
I'm
perfectly
transparent,
I've
given
up
in
some
areas
on
our
sort
of
long-running
backlog,
because
I
think
it's
too
hard
to
make
decisions
on
it.
So
at
some
point
we
may
as
well
just
close
all
of
it
right
and
be
done
with
it.
But
what
I
do
think
is
that
we
have
the
opportunity
to
sort
of
create
parts
of
our
backlog
that
are
a
little
bit
like
our
garden.
A
You,
you
know
within
these
epics
things
that
sit
in
it.
You
know
people
tend
to
them
and
understand
that
they
have
some
priority
and
that
then
allows
us
sort
of
a
small
part
of
this
entire
thing
that
is
easier
to
to
control
and
be
being
very
mindful
of
what
we
put
into
it.
And
then,
when
you
have
a
product
manager
Sam,
what
I
found
being
successful
is
building.
A
Level
backlog
of
epics,
larger
initiatives
or
opportunities
or
ideas
without
going
too
much
into
all
of
the
implementation
pieces
first,
because
then
we
can
decide.
Is
this
even
worth
doing
and
when
we
say
yes
that
looks
generally
good,
something
that
Engineers
have
done,
for
example,
in
Geo,
is
sort
of
go
through
our
big
backlog
and
say
like
okay.
Are
there
actually
issues
that
are
relevant
to
this
specific
thing
that
we
want
to
touch
and
pull
them
out?
Those
are
some
some
things,
but
I
agree
with
you.
B
D
Are
quite
interesting
in
that
so
many
of
them
are
like
oh
yeah,
okay,
I'd
love
to
close
that,
but
actually
it's
really
really
valid.
Still
so
I
do
know,
there
are
there's.
Definitely
some
improvements
like
I
think
having
a
smaller
subset
super
valuable
I
would
definitely
I.
I
would
suggest,
like
the
epics
were
a
much
easier
way
in
almost
everything
does
belong
to
an
epic,
and
we
do
have
quite
a
few
epics
which
are
sort
of
our
I.
D
Guess,
rough
ideas,
ready
on
the
release,
velocity
triage
list
or
proposal
lists
which
have
a
label
they're
under
so
those
are
usually
an
easier
way
to
drop
in
in
terms
of
like
here
are
the
the
concepts
we've
been
playing
around
with
and
that
usually
then
drives
into
issues
but
yeah
yeah.
Certainly
we
should.
We
should
figure,
certainly
I,
think
within
the
individual
team.
So
I'd
say
one
thing
not
to
be
daunted.
E
That's
exactly
what
I
said
right,
so
you
said
you
said
you
and
Michaela
went
through
all
of
these
tickets
a
few
weeks
ago
a
month
ago
and
I
cannot
imagine
how
much
effort
it
takes
it's.
It
should
be
like
a
couple
of
days
like
non-stop
working
on
on
reviewing
those
tickets,
so
I
think,
like
it's
better
to
add
the
Automation
and
do
that
regularly
little
by
little,
rather
than
just
like
spend
a
week
of
digging
into
this.
From
my
point
of
view,.
C
C
Productivity
has
some
automation
for
the
main
gitlab
project.
I,
don't
know
if
we
can
use
some
of
that
here,
but
maybe
you
can.
A
I
do
get
reports
for
parts
of
the
backlogs
for
teams
from
engineering
productivity,
but
mostly
focused
on
bugs,
because
we
have
slas
associated
with
them
and
Mrs
as
in
you
know.
This
S2
bug
here
has
not
been
actively
been
worked
on
and
is
you
know,
sort
of
an
overview
of
activity.
A
D
But
you're
already
talking
quite
fast,
which
was
it
was
great.
Yes,.
A
I
was
talking
bullet
points
from
now
on,
no
I
think
the
the
one
thing
that
I'd
like
to
emphasize
again
because
I,
it's
really
important
to
me,
I'm,
really
genuinely
interested
in
in
your
earnest
and
honest
assessment
of
what
is
going
on,
but
I
think
this
is.
This
is
something
that
I've
seen
in
the
past
right.
Sometimes
things
don't
go
just
as
well,
and
this
is
maybe
some
personal
preference
I'm
not
going
to
speak
for
Marin,
but
I'm,
maybe
a
little
bit
more
realistic,
I
mean
I'm
generally
optimistic,
but
I'd
rather
notice.
A
Like
you
know,
I
have
a
feeling.
This
is
maybe
going
to
go
and
take
longer
earlier
rather
than
later
and
I.
Think
that's
just
something
to
to
remember.
So.
If.
A
A
B
D
Great
so
deployment
blockers.
So
is
this
still
a
super
rough
I'm
hoping
to
get
this
wrapped
up
and
added
back
into
the
Epic,
but
I
thought
it
was
still
interesting
enough
to
share.
So
we
could
have
a
look
at
it
today.
So
thanks
go
back
fixing
errors.
If
anyone
else
sees
arrows,
please
click
some.
What
I
will
do
is
I
will.
B
D
As
a
kind
of
summary
so
I
know
this
isn't
a
full
set
of
our
data,
because
manual
data
Gathering
is
hard,
but
I
did
also
want
to
show
you
like.
This
is
what
we
can
do
with
this
sort
of
data
at
the
end,
so
we
can
start
to
build
out
some
patterns.
Hopefully
you
can
share
this.
D
Okay,
so
hopefully
you
can
see
that
so
when
we
break
down
our
epic,
our
deployment
blockers
by
week
by
type
what
I
think
is
quite
interesting
and
I,
think
it's
a
shame
that
colors,
you
can't
manage
the
colors
super
closely,
but
I
think
one
thing
I've
mentioned
to
a
few
of
you
before
is
like:
do
you
think
we'll
start
to
see
different
Trends
appearing
in
the
data
one
that
I've
been
kind
of
watching
on
that
I
think
is
going
to
be
interesting?
Is
I'm
actually
find
it
is
change
requests.
D
So,
for
example,
earlier
on
in
beginning
of
last
year,
we
had
four
oh-
and
this
was
on
week.
Four
we
had
three
of
them
are
week
14,
but
what
we
start
to
see
is
that
they
start
to
increase
and
I
I
think
we
are
going
to
see
that
Trend
up
right.
So
a
couple
of
things
are
going
to
contribute
to
that
one
is
infra
scaling,
particularly
reliability
teams
scaling.
The
other
is
as
reliability,
teams
switch
into
more
of
a
project
Focus.
They
are
likely
to
be
contributing
more
changes.
D
So
I
think
that's
a
really
interesting
one
that
we
can
probably
assume
will
increase
the
amount
of
delays
to
our
deployments,
but
also
being
very
manual
and
the
way
we
actually
coordinate
like
is
now
a
good
time
to
run
this
change
request
or
not.
Do
we
pause
things
or
lock
environments?
We
can
probably
expect
we're
going
to
have
a
little
bit
more
work
coming
our
way
as
a
result
of
those.
D
But
even
though
this
is
interesting,
what
is
actually
was
perhaps
for
me
the
surprising
ones
was
when
I
broke
it
down
into
individual
charts
here.
So
we
talk
a
lot
about
flaky
tests
actually
from
the
data
we've
gathered.
Flaky
tests
are
way
down
compared
to
earlier
in
last
year,
which
was
surprising,
but
then
take
a
look
at
database
migrations.
So
those
are
the
sort
of
interesting
Trends
where
we
can
now
go
back
to
the
teams
and
actually
share
this
data
with
them.
It's
not
like
there's
any
individual.
D
D
So
I
didn't
add
all
of
them
in
here
there's
a
couple
of
other
categories
from
the
root
cause
which
I
didn't
bother,
calling
out.
They
weren't
they
didn't
appear
frequently
enough
to
be
interesting,
but
I
say
they
are
things
that
we
can
now
start
to
share
with
other
teams
and
start
to
make
some
plans
around.
What
might
this
look
like
over
the
next
the
next
year?
D
D
One
thing
I'm,
hoping
we
can
do
this
year-
is
find
a
better
way
of
tracking
this
data
because
it's
super
manual
even
to
pull
it
back
into
this
sheet
with
all
the
numbers
was
horribly
painful,
so
lots
of
room
for
improvement
on
How
We
Gather
this
data
and
how
we
can
analyze
it,
but
at
the
same
time
I
think
if
we
do
it
and
we
you
know,
make
use
of
the
root
cause
groupings
and
things
like
that.
We
actually
start
to
see
some
quite
interesting
patterns.
F
Hey
everyone
Happy
New
Year,
you
can
share
my
screen,
hope
you
can
see
it
and
we
start
with
deployment
packages.
As
you
can
see
here,
the
hard
PCL
we
promoted
two
packages
and
last
week
we
had
two
incidents,
a
hundred
us
a
bit,
but
then
I
think
starting
of
today
we
are
normal
again.
F
So
nothing
much
Happening
Here.
D
F
D
Comment
on
those
packages
so
for
future
ones
for
those
sorts
of
holiday
pcls,
we
may
want
to
consider
just
turning
it
off
completely
and
saving
ourselves
the
the
resources.
So
we
don't
have
to
build
too
many
packages
so
just
as
a
sort
of
future
reference.
That's
also
a
an
option.
F
And
for
the
lead
time
as
well
as
you
can
see
here,
nothing
happened
until
last
week
and
then
starting
of
today
for
the
deployment
frequency
we
were
too
low
because
of
the
hard
PCL
and
then
starting
again
last
week.
So
nothing
much
also
to
show
here
deployment
blockers.
However,
we
had
I
think
11
hours
or
we
brought
locking
mostly
like
UA
failures.