►
From YouTube: 2021-03-01 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
all
right,
let's
get
started,
we've
got
lots
on
the
agenda
today,
but
some
of
these
may
work
async
as
well,
but
just
to
give
you
a
heads
up,
so
I'm
going
to
start
dropping
in
the
current
mttp
each
week,
just
because
it
doesn't
unfurl
on
slack
anymore,
which
is
less
than
helpful.
A
I
shared
in
that
that
or
I
updated
on
the
handbook
on
that
current
mttp
link
ahead
of
that.
Just
the
reasons
why
it
spiked
up
in
february-
and
that
was
really
because
we
got
a
little
bit
unlucky
on
on
dates
really
and
we
had
the
pcl
at
the
end
of
january
because
of
the
incidents
and
then
almost
immediately
after
that
we
had
the
two
incidents
back
to
back,
which
were
both
from
the
post
deployment,
migrations
timing
out
and
the
locks
to
just
having
those
all
together
looks
pretty
unhappy
on
mttp.
A
But
no,
there
were
no
concerns
raised.
One
of
the
things
we
will
be
doing
in
the
next
month,
or
so
is
davis,
is
going
to
have
a
look
for
us
whether
we
can
actually
start
tracking
mttp
over
working
days.
So
at
the
moment
it's
a
view
over
the
whole
month,
which
we've
talked
about
a
little
bit
before,
like
we
have
no
intention
to
deploy
at
weekends,
so
davis
is
going
to
see
if
he
can
actually
update
this
chart
to
just
track
against
workdays.
A
Cool
and
then
on
the
announcements,
so
these
are
just
mostly
so
you
have
a
little
okay.
These
are
the
announcements
getting
currently
better,
so
I'll
start
doing
a
dull
one,
which
is
just
I'm
off
friday
and
then
two
fyis
just
again
related
to
the
incidents
particular
database
stuff.
That
is
a
a
group,
now
has
sprung
up
to
try
and
investigate
these
and
also
broken
master,
so
particularly
relevant
for
robert
eurek
right
now.
A
A
A
Okay,
okay,
okay
cool,
so
robert.
C
Yes,
so
I
noticed
last
week
that
we
are
currently
building
google
to
20.04
packages
for
auto
deploy
tags
and
then
they're
never
downloaded
by
anything.
So
I'm
wondering
if
we
actually
need
those.
I
was
just
looking
into
it.
It
looks
like
distribution
added
it
to
the
configuration
specifically
so
I'll
check
with
them
and
see
if
we
actually
need
it.
B
I
just
posted
some
information
that
we
yeah.
I
know.
C
A
Perfect
thanks
for
bringing
that
robert
nice
cool,
so
yeah
security
release
timeline
thanks
for
opening
up
the
issue
robert,
it's
just.
I
think
my
main
question
was
really:
when
are
we
going
to
start
the
or
when
are
we
going
to
disable
the
nightly
package?
I.
A
Okay,
so,
okay,
the
reason
I
mentioned,
that
is
just
one
thing
that
was
interesting
in
the
run
up
to
13.9
was
one
of
the
late
sort
of
finding
bugs
that
we
had
was
the
the
gitly
performance
issue
that
we
saw.
A
One
of
the
reasons
that
was
late
was
because
we
did
the
security
release
the
week
before
and
whilst
we
have
the
nightly
packages
disabled,
we
lose
some
test
visibility,
so
that
was
actually
that
was
an
interesting
one
like
no
problem
there,
but
we
should
just
keep
that
in
mind,
maybe
a
future,
a
future
iteration
improvement.
A
D
A
Exactly
yeah,
no
no
problem
at
all
here,
yeah,
it's
more
just
a
nightly
package
stuff
might
be
more
interesting
than
certainly
I
was
thinking
it
was
yeah,
but
yeah
no
problems
this
week
at
all,
so
nice
cool,
so
culture
amp
stuff.
So
we
did
the
engagement
survey
some
months
ago.
There
are
still
kind
of
conversations
going
on
to
get
actions
from
these
so
trying
to
mostly
give
you
a
little
bit
of
visibility
for
this
stuff.
A
So
I
dropped
the
team
stuff
in
there
just
in
case
you
haven't
seen
that
recently
and
also
for
you
henry
and
then
we
have
a
department
issue
and
then
we
have
a
sub
department
issue.
So
those
two
are
both
in
progress.
You're
welcome
to
just
like
follow
along
or
if
you
want
to
suggest
things,
but
I
suppose
from
a
team
point
of
view,
is
there
anything
that
people
specifically
want
to
focus
on
as
an
area
that
we
should
be
pulling
actions
from
like?
A
I
know,
we've
got
kind
of
there's
been
kind
of
conversations
around
reasons
why
some
of
the
areas
might
have
scored
low,
but
would
it
like?
Do
you
actually
want
as
a
team
to
actually
as
we
could,
I
mean
we
could
certainly
do
async,
but
like
do
you
want
to
try
and
set
some
actions
within
the
team
for
this,
or
do
you
want
to
stick
with
the
sub
department
and
departments.
A
Okay,
because
I
think
what
we're
seeing
is
that
there's
quite
a
lot
of
similarities
in
the
results
at
suburb
department
level
and
also
at
department
level,
so
there
will
be
some
actions
that
come
out
of
these
things.
A
There's
already
a
discussion
going
on
about
career
conversations
and
making
sure
that
those
are
happening
more
consistently
across
all
of
engineering
and
as
part
of
those
we'll
also
be
looking
at
like
how
do
we
get
more
opportunities
so
like
to
your
point,
henry
and
now
are
sort
of
dark
about,
like
you
know,
how
do
we
create
opportunities
for
mentoring
and-
and
things
like
that,
when
we
don't
have
any
juniors
like
you
know,
there
are
things
we
can
do,
but
you
know
we
will
make
sure
that
we
actually
do
those
cool,
okay,
well
I'll.
A
Keep
you
posted
on
these
things,
so
you've
got
the
issues
there.
If
you
want
to
add
any
comments,
or
I
will
keep
you
posted
when
things
get
decided.
A
Cool,
so
I'd
like
to
get
your
thoughts
on
this,
so
something
I
do
each
week
is
update
our
epics
with
just
a
sort
of
short
summary
of
of
what
we've
been
up
to.
A
But
it
would
be
really
helpful
for
me
if
actually,
this
came
from
you'll
like
the
dris,
just
to
kind
of
streamline
this
a
little
bit
for
me.
So
would,
if
I
add,
in
the
sa
status
section
on
the
on
the
actual
working
epics
that
I'm
like
an
update
for.
Would
you
as
a
dri,
be
okay
with
just
adding
a
sentence
or
two
each
week,
which
basically
is
like
what
we've
done?
What
we've
kind
of
worked
on
recently?
Why
we
did
those
things
and
what
the
next
steps
are
for
that.
B
I
epic
for
the
kubernetes
work
like
epic
112
is
the
overall
one,
but
we're
not
going
to
see
status
updates
now
we're
going
to
see
the
status
on
the
ones
that
we
are
actively
working
on,
which
in
this
case
is
epic
271.?
Would
a
status
be
more
useful
on
that
epic,
or
do
we
still
want
that
stuff?
At
the
header
of
the
migration
of
all
things.
A
Yeah,
it
will
be
I'll,
have
a
look
through
the
epics
and
work
out
where
at
best
land,
it's
probably
the
at
the
moment.
It's
probably
like
the
api
service
level,
just
to
kind
of
pull
wrap
that
stuff
up.
What
I
do,
ideally,
is
automate
pulling
this
up
into
a
kind
of
more
of
our
top
level
epics.
A
What
we're
seeing
more
of
is
that
people
outside
of
delivery
and
even
outside
of
infrastructure
are
landing
more
on
these
parent
epics
and
actually
using
them
to
like
help
prioritize
projects
and
using
right
decisions.
So
the
dates
and
those
sorts
of
things
are
going
to
become
more
important,
so
I'll
I'll
start
doing
this
a
lot
more
consistently.
A
Cool
okay
I'll
stick
in
the
like
a
summary,
a
status
section
on
each
of
the
working
epics
I'd
like
an
update
on
upping
you,
so
that
if
you
have
something
and
then
happy
to
bounce
around,
what
that
looks
like
for
the
first
few
weeks
until
we
get
into
a
rhythm
of
that
stuff
as
well.
E
A
Yeah,
we
can
add
something
into
like
a
new
slack
reminder
or
something
like
that.
Yeah.
It's
a
great
point:
cool.
A
Nice
myra.
F
Yep
thanks,
so
the
depth
department
has
a
nokia
about
improving
the
knowledge
around
developments
and
the
infrastructure,
and
currently
they
want
to
encourage
team
members
to
join
the
delivery
ama,
which
I
think
is
nice.
So
I
wonder
if
any
of
you
have
any
other
ideas
about
how
to
improve
the
deployment
knowledge.
I
think
we
have
some
dark
pages
that
we
can
link,
but
not
sure,
if,
like
any
of
you
have
a
better
idea
than
that.
G
I
think
we
tried
this
in
the
past,
where
we
wanted
developers
to
what
we
tried.
The
best
was
to
have
developers
do,
release
management,
which
I
think
at
the
time
we
concluded,
was
basically
a
disaster,
but
not
so
much.
I
can
they
mess
things
up,
but
you
know
people
didn't
want
to
do
it
or
didn't
have
to
die.
I
mean
yeah,
it
was
difficult,
but
I
do
think
some
sort
of
buddy
program,
whatever
you'd
like
to
call
it
there
where
they
attend.
G
That
to
some
degree
will
be
helpful
because
I
think
if,
if
you
have
people
just
join
an
ama,
it's
going
to
be
just
the
people
who
are,
I
would
say
already
interested
but
you're
going
to
have
a
lot
of
people
like
yeah
yeah.
You
know
I
I
don't
really
care
me,
whereas
I
think
if
you
say
you
know
hey,
you
know
for
the
next
two
weeks,
you're
gonna
read
up
on
these
institutions
or
whatever
something
like
that.
A
Yeah,
it's
a
good,
it's
a
really
good
point,
certainly
something
in
the
past.
I
have
chat
to
the
other
engineering
managers
about
because
I
think
I
would
hope
that
they're
the
people
closest
to
knowing
who
wants
to
develop
like
these
skills
and
like
what
sort
of
time
pressures
we
have
here
so
yeah.
Maybe
it's
a
case
of
identifying
a
couple
of
people
who
we
could
do
this
stuff
with.
A
So
I
think
it
certainly
seems
like
a
good
first
step
to
get
engagement
there
with
people
like
you
have
to
have
done
a
little
bit
of
reading.
I
think
to
turn
up
there
and
ask
a
question.
So
that's
a
great
start
right
and
then
we
can
see
if
we
get
some
people
who
are
regularly
engaged
there
and
that's
not
enough,
then
you
know
we
can.
We
can
maybe
expand
it
actually,
as
I
say
that
the
other
big
ones
we
have.
Of
course,
every
week
we
do
a
rollbacks
demo
and
a
kate's
demo
right.
A
They
could
both
be
they're.
Both
public
people
could
definitely
come
along
and
maybe
fits
in
with
our
production
rollback
plans
to
try
and
get
people
engaged
there.
B
I'm
curious
as
to
what
we
would
do
outside
of
our
documentation,
like
we've
got
plenty
of
docs
that
discuss
the
need
in
this.
It
looks
like
this
is
focused
on
multiversion
compatibility,
at
least
that's
the
documentation
we
link
to
inside
of
this
issue.
What
else
are
we
trying
to
convey
or
teach
to
members
of
engineering.
D
I
was
thinking
about
this
last
week.
Actually
I
had
a
coffee
chat
with
brent
and
we
were
discussing
exactly
this
topic
and
I
was
thinking
that
a
nice
idea
could
be
it
requires
times
for
preparation,
but
having
some
kind
of
short
videos
no
longer
than
five
minutes
explaining
just
one
topic
very
actionable.
Very
kind
of
a
conversation
started
right
because
the
problem
with
extensive
documentation
is
that
people
don't
want
to
read.
Don't
read
it,
that's
the
problem
right.
So
we
have
this
expanded
contract
pattern,
which
is
a
very
big
and
explained
with
example.
D
We
have
a
lot
of
example
about
the
way,
is
migrations
and
how
to
handle
all
this
type
of
situation.
But
what
happens
is
that
either
you
screwed
up
and
create
a
big
mess
in
production,
and
you
got
involved
in
the
incident
and
in
corrective
actions,
and
then
you
read
that
page
and
then
the
next
time
you
know
how
to
handle
it
or
is
really
really
hard
that
someone
just
go
there
and
read
it.
D
So
if
we
have
some
kind
of
video
collection
of
yeah,
maybe
I
would
say
5
to
ten
minutes
about
five.
I
think
it's
already
enough
to
just
explain
one
topic
and
then
linking
to
some
real
documentation
where
you
can
go
deeper
and
deeper
and
understanding.
B
E
Yeah
I
mean
we
could
try
to
see
if
the
dev
onboarding
already
contains
some
links
to
documentation
of
how
deployments
are
working,
what
they
should
look
for
for
you
know,
reading,
mrs
and
so
on.
So
maybe
that
would
also
be
an
idea
to
spread
the
knowledge,
but
that
would
not
affect
the
people
who
already
onboard
it,
of
course,
so
for
them
we
maybe
can
have
an
extra
issue
too.
I
don't
know,
go
and
check
that
again.
D
Also,
the
drinking
from
the
fire
hose
phase,
which
is
quite
common
at
the
beginning,
at
gitlab
and
well.
I
don't
think
that
this
is
your
first
concern
where
you
try
to
just
get
your
first
murdericus
merch
and
with
hiring
freeze
as
well
is
kind
of
yeah.
It's
an
onboarding,
but
nobody
will
read
it.
But
yes,
I
think
if
there's
no
links
there,
maybe
maybe
also
just
something
if
you
want
to
know
about
deployment
and
then
there's
kind
of
an
index
so
that
you
can
just
bookmark
it
and
go
back
later
to
it,
but
yeah.
A
Yeah,
it
makes
sense.
What
do
we
want
to
do
as
next
steps
like?
Is
this
something
worth
opening
an
issue
to
gather
like
video
ideas
and
like
doc
or
topic
ideas
and
see
what
documentation
and
videos
we
could
like
we
might
have
already
or
we
could
create
or.