►
From YouTube: 2020-10-15 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
Cool
so
see,
we've
got
on
this
week,
oh
so
I
am
out
tomorrow
and
monday.
If
you
I'd,
recommend,
go
ahead,
delivery
weekly
on
monday.
If
you
have
topics
you
should
all
be
able
to
host
the
meeting,
and
things
like
that.
So
I'll
double
check
those
settings
before
I
head
off
today,
but
if
you
have
things
you
want
to
cover,
then
go
ahead
and
run
that
one
cool
and
I
was
going
to
discuss
our
discussion.
A
But
actually
the
issue
is
going
on
quite
nicely,
so
I've
just
been
a
little
nudged
up.
Please
go
ahead
and
add
your
thoughts
onto
the
okr
issue,
thanks
for
the
suggestions
and
things
so
far,
particularly
uric.
Thanks
for
multiple
suggestions,
I
think
we
will
like
we
can
still
just
bounce
around
ideas
this
week.
So
go
ahead
and
do
that
and
then
next
week
we'll
actually
tie
them
down
to
some
some
things
that
we
want
to
focus
on
in
q4.
A
I
think
what
I've
seen
so
far
on
this
one
is
it's
less
about
what
to
do
and
it'll
be
more
about
what
order
makes
sense
to
do
things,
so
it
might
be
that
we
line
up
some
stuff
and
be
like
this
is
q4,
and
then
this
stuff
comes
after
in
q1
or
something
along
those
lines.
A
Cool
so
discussion,
so
as
part
of
we
building
in
familiarity
with
our
boards.
Let's
take
a
look,
so,
let's
start
with
what
we've
got
on
the
billboard
right
now,
so
I
think
pretty
much
everything
hopefully
that
we
have
in
progress
is
in
progress.
A
What
I'm
going
to
start
doing
from
next
week
is
actually
putting
together
a
little
summary
and
we
can
start
looking
at
all
the
stuff
we've
completed
in
x
period,
so
we
actually
get
a
little
bit
more
of
a
sense,
so
I
think
we
always
will
have
a
lot
of
stuff
going
on
in
delivery.
I
think
it's
easy
to
kind
of
just
overlook
the
the
things
we've
already
achieved,
so
I'll,
try
and
wrap
up
some
stuff
next
week
on
on
a
report
there.
So
in
progress.
We've
got
all
this
stuff
which
looking
good.
A
Yes,
great
thanks
even
more
stuff
on
the
board,
so
that's
going
on,
we've
got
pretty
ready
column
as
well,
which
is
good
so
say
if
you
need
to
pick
stuff
up,
please
grab
from
the
ready
column.
These
are
the
things
I
think
pretty
much.
Everything
in
here
will
move
us
closer
towards
our
q3
okrs.
A
So
all
of
that
stuff
is
is
good
value.
We've
got
the
priorities
so
yeah.
You
can
use
that
as
well
to
help
you
help
you
pick
on
stuff.
A
Is
there
anything
else
that
people
feel
we
should
bring
into
the
billboard
in
the
next
x
period
like
for
now,
like
I'm,
not
going
to
set
a
like
a
sprint
period
of
time,
because
we
don't
know
how
long
this
stuff
will
take
us,
but
is
the
stuff
that
people
actually
want
to
have
available
as
a
ready?
We
could
pick
it
up
as
the
next
task
if
we
need.
C
C
A
Didn't
get
that,
I
did
think
that
as
well
like
at
the
moment,
I'm
using
the
highly
manual
thing,
which
also
filts
and
with
us
not
having
too
many
things
in
this
column,
so
that
we
can
actually
sort
because
yeah
you're
right
like
this
should
definitely
be
sorted
by
priority,
so
that
it's
much
easier.
C
A
B
B
D
D
Scarbrick,
I
think
it's
because
you
have
the
performance
bar
up
and
it
hides
the
x.
It
doesn't
account.
A
For
that,
this
is
going
to
be
a
lot
of
fun
using
these
boards.
I
can
see
awesome,
okay.
Well,
if
you
come
across
things,
particularly
if
you're
working
on
an
epic
and
you
can
see
stuff
coming
up,
then
go
ahead
and
drop
that
stuff
in
we
also
have
our
planning
board.
So
this
is
the
stuff
which
is
we're
not
necessarily
going
to
start
building
on
this
right
away.
A
But
these
are
things
where
we
have
things
that
we
need
to
kind
of
come
to
some
sort
of
idea
of
how
we
would
solve
the
problem
before
we
build
it.
One
thing
so:
last
week
we
took
out
the
additional
column,
which
was
the
proposal
column.
A
I
have
to
say,
I've
struggled
a
little
bit
so
I'd
love
to
hear
people's
thoughts
on
this.
What
I
wanted
to
be
able
to
do
is
say
this
century.
One,
for
example,
we've
got
some
really
good
discussion
on.
Do
people
feel
like
that
is
like
do
you?
How
are
your
notifications
enough
for
you
to
actually
be
able
to
see
that,
or
is
it
actually
useful
to
have
some
different
thing
between
the
this?
C
So
I
think
that
at
least
for
me,
so
the
notification
is
useful
for
let's
say
as
a
conversation
starter.
But
then
maybe
when
people
start
commenting,
you
don't
always
get
you
don't
always
get
notified
again.
So
you
don't
get
a
two-dose
and
maybe
if
something
is
still
not
really
actionable,
but
still
in
the
discussion
phase.
A
If,
for
example,
this
board
looked
like
this,
I
pulled
those
two
just
because
I
know
they
are
in
my
mind.
I
think
they
are
very
close
towards
actually
being
able
to
just
say
great,
that's
the
answer.
Let's
move
them
on
when
you
landed
on
that
board.
Does
that
feel
like
it
would
be
more
clear
between
his
stuff?
I
need
to
start
having
ideas
about
and
here's
stuff
I
could
just
have
a
quick
scan
of,
and
maybe
thumb
up
or
comment
if
needed,.
A
A
So
I
think
it
is
a
proposal,
is
it
has
a
there's?
A
proposed
solution
on
this
that
people
might
want
to
input
into
triage
is
we
need
to?
We
need
to
come
up
with
an
idea,
so.
C
A
Let's
see
how
we
go
with
that
for
for
the
next
iteration
like
again,
I'm
very
happy
to
modify
if
needed,
but
certainly
for
me,
I
kind
of
wanted
to
be
able
to
say
to
people
like
hey.
Let's
have
a
look
at
the
sentry
one
like.
I
want
us
to
make
a
cool
on
that,
and
so
it
feels
different
to
me
to
some
of
the
other
triage
ones.
A
Cool.
Okay.
Is
that
if
there's
anything
else,
we've
got
quite
a
lot
of
stuff
on
this
board.
One
thing
we
haven't
covered,
which
I
think
we
should
have
a
think
about-
is
there's
two
ways.
We
can
do
this.
Really
it's
how
we
actually
deal
with
the
triage,
so
we
could
either
have
it
where
everybody
just
spends
a
bit
of
time
each
week
and
we
gradually
move
things
over
that
could
work.
A
We've
got
plenty
of
stuff
that
is
ready
to
be
built,
so
we're
not
like
blocked
waiting
for
this
stuff
or
the
way
that
some
of
the
other
teams
do
it
is
they
have
a
rotor
and
there's
somebody
who
is
like
the
primary
person
responsible
for
moving
these
things
over
and
everybody
else
contributes.
E
I
I
would
suggest
that
whoever
creates
the
issue
is
sort
of
in
charge
of
triaging
their
own
issues,
because
in
theory
they
they
know
the
most
about
whatever
they
are
reporting,
whether
that
will
work,
I'm
not
sure,
I
think
the
issue.
If
you
have
somebody
dedicated
on
a
rotation,
they
might
not
be
able
to
try
out
everything
properly
and
it
it
might
not
be
the
case
in
our
team,
but
it
can
lead
to
people
not
bothering
to
try
our
work
because
whoever
is
on
the
rotor
will
do
that.
E
A
Yeah,
okay,
I'm
happy
with
that.
So,
let's
see
how
we
go
and
say
we're
right:
we're
not
blocked
at
all
right
now.
The
ones
I
particularly
want
people
to
have
a
look
at
are
the
ones
that
are
going
to
be
sort
of
the
broad
reaching
across
the
team,
so
say,
for
example,
like
sentry,
we
all
use
sentry.
We
all
have
to
go
through
the
release
process,
so
those
are
the
ones
which
in
particular,
I
think
we
should
have
more
than
just
one
or
two
people's
views
on
but
yeah.
A
Let's
see
how
we
go
on
this
one
and
say
if
you
want
to
bring
in
new
stuff
for
planning,
please
go
ahead
and
do
stuff.
And
similarly,
if
you
want
to
drop
anything
off
these
boards,
just
go
ahead
and
do
that
as
well.
That's
totally
fine.
F
Cool
for
those
of
for
those
of
us
who
occasionally
bypass
the
board,
are
we
okay
with
those
four
rules?
Are
you,
okay,
with
those
amy.
F
Yeah,
it's
the
item,
the
sub
four
four
rules
for
the
bot
to
help
with,
like
you
know,
moving
the
labels
around
for
those
of
us
who
sometimes
bypass
the
board
and
just
like
snag
issues.
Are
we
okay
with
those
four
rules?
Does
that
make
sense
to
you.
A
F
A
Nice
one
other
thing
as
well
on
labeling.
One
thing
I
don't
know:
if
other
people
do,
I
think
I've
only
seen
scarbeck
is
on
issues
and
particular
epics
having
a
little
example
or
not
a
little.
Like
summary,
at
the
bottom
of
the
labels
reviews.
That
is,
super
really
really
helpful.
So
I
think
we
should
also
like
consider
standardizing
that
on
our
epics
as
well.
So
if
you've
got
an
example
to
hans
quebec,
but.
B
F
F
A
Yeah,
I
think
that's
possibly
true
as
well
cool
but
yeah.
I
agree
with
those
rules.
They
look
good
nice
and
I
say
we're
still
iterating
on
this
stuff.
I
haven't
written
up
that
work
flow
stuff
into
the
handbook
yet,
but
I
will
do
I'll,
try
and
do
next
week.
I
think,
maybe
towards
the
end
of
next
week,
so
we
can
like
we
can
still
change
it,
but
just
so
it
settles
in
a
little
bit
so
feel
free
to
keep
suggesting
ways.
We
can
change
this
stuff.
A
Awesome
so
next
point
is
mtbf,
so
rachel
and
I've
been
working
on
this.
It's
a
proposal
at
the
moment,
but
I
want
to
give
you
a
heads
up,
so
I
have
been
thinking
about
this.
We
think
about
this.
I
guess
slightly
different
ways.
I'm
thinking
about
it
as
it
will
be
a
useful
in
the
future
it'll
be
a
useful
counterpart
to
mttp.
A
A
Whilst
we
can
keep
mtbf
stable
and
from
rachel's
side
on
scalability
she's,
looking
at
it
as
a
way
to
measure
are
we
are
we
improving
things
so
that
we
don't
keep
interrupting
people
on
things.
A
So
those
are
the
issues
and
mrs
and
things
that
we're
working
on
at
the
moment.
I
think
in
terms
of
what
I'm
expecting
on
our
day-to-day
work.
It
won't
change
things
too
much
for
us.
It
might
be
useful
as
a
feed
into
okrs
that
we'll
sort
of
adjust,
but
scalability
will
probably
switch
focus
a
little
bit
more
frequently
on
these
things.
F
Yeah,
just
thinking
like
how
can
we
tell
if
we're
going
too
fast,
and
maybe
one
way
is
just
to
see
how
often
we're
roll
backing
or
issuing
rollbacks?
If
that's
something
that
we
start
doing.
C
C
F
F
A
Yeah
yeah
and
you're
right-
and
this
is
the
thing
I
don't
it
won't
be
so
much
like.
We
change
change
our
work
so
much,
but
I
think
it
will
be
an
interesting
one
of
do.
We
need
to
spend
more
time,
for
example,
working
with
development,
so
they
understand
the
implications
of
changes
of
these
types
or
do
we
need
to
spend
more
time
working
with
quality,
to
change
the
way
qa
things
work
like,
I
think,
having
just
a
focus
of
fast,
fast,
fast,
there's,
a
risk
that
we
could
be
like
great.
A
We
could
just
cut
10
checks
out
of
the
pipeline
and
therefore
we
won't
you
know
it.
We
can
go
faster,
but
we
could
be
having
some
impact.
So
rollbacks,
I
think,
will
be
an
interesting
one,
because
if
we,
I
think
at
some
point
we'll
need
to
be
able
to
separate
out
an
issue.
That's
detected
on
staging
versus
one.
That's
detected
in
production
and
rollbacks
be
a
really
good
way
for
us
to
actually
limit
the
impact
on
production,
but
we're
not
quite
there
yet
like
in
terms
of
like
needing
to
measure
that
stuff.
A
So
I
think
what
we'll
do
is
reasonably
manual,
we'll
have
a
chart
that
will
track
through
periscope,
and
we
can
have
that
alongside
mttp
in
terms
of
actually
drilling
into
the
data
and
making
a
decision
of
like
do,
we
need
to
be
doing
something
differently,
we'll
do
that
in
a
bit
more
of
a
human
thing,
we'll
have
a
spreadsheet.
We
can
take
a
look
through
the
issues
and
actually
use
it.
As
a
are
we
seeing
patterns.
Is
this
something
we
want
to
be
doing
differently
to
actually
change
this
number
or
not?
C
So
still
talking
about
mean
time
to
something.
If
we
have
to
pick
another
one
that
is
important
to
us,
I
would
suggest
that
we
go
for.
We
go
for
main
time
to
recovery
because
there
we
may
have
control
over
it.
So
it's
about
it's
all
about
making
sure
that
the
rollback
strategies
really
works
and
it's
performing,
and
that
could
be
a
second
yes,
this
is
a
kpi
or
whatever
performance
indicator,
to
keep
track
of.
A
It's
a
really
great
point:
yeah
mtt
art
really
also
does
tie
into
this
stuff,
so
yeah.
I
think
we'll
certainly
take
a
look
at
that
in
the
future
as
well.
A
Cool,
so
so
it's
not
really
finalized
yet
so,
but
just
for
visibility
that
stuff,
hopefully,
is
coming
in
as
well
cool,
so
yeah.
So
yesterday
in
the
ama
marin
made
a
great
sort
of
bigger
blue
sky
thinking
that
I
was
going
for,
but
it
was
like
if
qa
tests
around
in
five
minutes,
it's
a
really
great
way
to.
I
guess
help
us
think
about.
Where
do
we
want
to
get
to
in
the
future
so
yeah?
A
B
Well,
firstly,
if
I
think
if
qa
tests
ran
as
quickly
as
they
needed
to
to
accomplish
everything
they
test
in
five
minutes,
we
would
probably
bring
down
our
environments
because
we'd
hammer
that
environment
but
yeah
if
builds,
happened
in
less
than
an
hour.
That
would
certainly
help
us
out
a
little
bit.
B
C
C
We
also
had
a
couple
of
discussion
when
we
were
talking
about
the
next
gen
also
deploy
and
the
two
main
direction
that
we
identified,
where
one
is
eventually
do
parallel
building,
so
that
we
can
start
deploying
white
substitute
running,
and
we
have
some
kind
of
a
break
point
at
at
the
end
of
staging,
so
that
we
will
never
promote
past
staging
unless
all
the
other
tests
are
okay,
the
other
one
was
about
the
tagging
from
master,
but
in
but
yeah.
C
I
I
agree
also
with
roberts
that
the
pipeline
for
building
our
packages
was
designed
a
long
time
ago
with
different
expectation
and
different
requirements,
and
even
just
thinking
that
we
have
to
repeat
the
whole
world
just
for
creating
an
omnibus
package
when
maybe
we
just
want
to
upgrade
the
assets,
and
this
is
something
that
you
can
do
patching
and
existing
packages.
Or
maybe
you
want
to
ship
just
a
new
getaway
binary
and
you
have
to
repackage
everything.
So
there
are
there's
a
lot
of
room
for
improvement
there,
but
it's
yeah.
It's
a
very
big
effort.
A
Okay,
awesome
great,
I
think,
all
of
the
stuff
ties
in
nicely.
I
think
we've
talked
a
little
bit.
I
think
I've
talked
to
each
of
you
a
little
bit
about
there's.
Definitely
we
have
a
long
road
map
ahead
of
us
and
it's
really
great
to
hear
this
stuff
because,
like
this
stuff
is
big
and
we
don't
have
an
obvious
answer
to
it,
so
yeah
that's
really
exciting.
I
think
we'll
see
lots
of
exciting
things
coming
in
and
completing
the
migration
yeah.
F
F
F
Think
it's
worth
pursuing
one
thing
that
would
help
I
put
it
down
here
is
like
just
removing
the
omnibus
after
wearing
kubernetes
all
together.
B
Running
we
still
have
certain
things
that
we
use
the
deployer
node
for
so
like
database,
migrations
and
stuff.
We'd
have
to
say.
A
We
have
kind
of
a
whole
load
of
other
tools
to
play
with
right,
like
we
could
deploy
to
a
cluster
and
hold
that
one
and
switch
traffic
and
do
some
stuff
there
as
well
awesome.
So
this
was
really
just.
I
was
curious
on
just
random
ideas
that
we
had
so
we
can
start.
We
could
start
thinking
kind
of
much
longer.
A
I
think
the
next
six
months
are
pretty
easy
to
predict
with
the
work
that
we
already
have
kind
of
in
progress,
but
beyond
that
six
months,
the
next
couple
of
years,
I
think
it'll
be
really
interesting
to
see
where
we
can
take
this
stuff.
A
Cool
jav.
F
Yeah,
I'm
just
curious
what
the
next
steps
or
what
do
we
think
the
next
steps
are
for
alessio's
proposal
to
start
deploying
off
the
master
branch.
Do
we
think
this
is
something
we
may
also
know,
and
I
were
talking
about
it
earlier
and
we're
thinking
like
you
know,
maybe
we
could
just
keep
everything
the
same
except
we
tag
from
the
master
branch
and
create
an
auto
deploy
branch
but
never
use
it
and
try
that
for
a
month
see
if
that
causes
problems,
if
not
like.
Maybe
we
go
forward
with
just
using
the
master
branch.
A
Yeah,
I'd
love
to
understand,
say
this
one's
kind
of
on
still
on
planning.
I
think
it
would
be
good
to
hear.
C
C
In
that
case,
we
when
we
say
create
the
branch;
instead
we
are
tagging
master
and
creating
a
branch
out
of
it,
and
you
and
you
don't
tack,
so
you
you,
don't
you
remove
the
the
the
the
scheduled
pipeline
to
just
do
the
tagging
so
that
you
can
test
this,
so
the
the
conversation
we
had
so
we
in
german
I
had
about
this
is-
is
more
about
the
safety
of
it.
So
what
what
I
described
in
the
issue
had
this?
C
I
it's
based
on
this
idea
that
building
a
package
is
a
commitment
to
deploying
it.
So
you
do
you
stick
with
it
right.
So
until
you
you,
you
need
a
good
reason
for
tagging.
Another
thing
on
another
place
of
mastering
start
starting
again,
so
you
should
reach
production
with
that
thing
and
if
we
just
re,
remove
the
current
schedule
and
tweak
the
the
branch
creation
to
also
tagging,
we,
we
kind
of
lose
this
idea
right,
because,
basically,
every
six
hour
or
whatever
you
tag
and
yeah,
I
don't
know.
C
I
want
to
make
sure
that
if
we
go
down
this
route,
which
can
be
easy,
maybe
you
can
do
this
easily
with
a
feature
flag.
We
still
have
the
ability
to
cherry
pick
something
and
create
a
package
out
of
something
that
we
know
works
or
doesn't
work,
because
I
I
don't
want
to
enter
the
situation
where
we
have
a
p1
issues
that
was
spotted
too
late,
so
he's
already
in
production,
it's
a
cannery
or
production,
and
then
we
want
to
tag
something
else
from
master
which
maybe
it's
just
a
reverse,
because
we
identified
problem.
C
A
Yeah,
I
I
think
that
sounds
slightly
sensible,
though
yeah.
I
think
we
just
need
to
work
out.
Those
last
little
bits
come
up
with
a
good
plan
and
then
truthfully,
it's
really
just
going
to
be
a
case
of
scheduling
it
in
right,
prioritizing
it.
A
I
think
well,
my
view
but
open
for
others
is
that
it
doesn't
go
towards
our
okrs
and
we've
got
two
weeks
left
of
this
quarter.
It
doesn't
feel
like
it
should
be
hyper
higher
priority
than
the
things
that
were
already
on
the
billboard,
but
I'm
very
much
like
keen
for
us
to
do
it
so
yeah
we
can.
We
can
schedule
this
in.
A
Awesome
we
are
at
time
on
this
meeting,
but
well
it
makes
me
think
what
I
will
do
I'll
leave
it
for
monday,
because
let's
see
how
you
see
how
you'll
go
on
that
one
like,
but
we
should
probably
consider
whether
we
want
to
make
this
meeting
45
minutes
or
find
a
way
to
take
some
of
this
stuff
async.
It
feels
like
we
we
regularly
overrun
but
open
for
ideas
there
as
well,
but
if
anyone
needs
to
drop
off,
please
go
ahead.
A
If
not,
and
you
want
to
stick
about,
then
let
me
stop
the
recording.