►
From YouTube: 2020-09-14 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).
B
A
A
So
hello,
everyone
happy
monday,
so
we
have
no
announcements
this
week.
Unless
anyone
wants
to
dive
in
then
the
thing.
C
I'm
taking
wednesday
off
bye,
I'm
done
with
announcements.
Thank
you.
A
Short
and
sweet
awesome
so
onto
discussion
points.
So
first
point
is
mine,
we're
halfway
through
the
quarter,
which
it's
kind
of
exciting
and
maybe
terrifying
it's
like
mid-september,
so
I
thought
it
would
be
I'll
put
some
updates
on
the
actual,
particularly
the
key
result.
Issues
as
well,
but
just
we
thought
it'd
be
nice
to
check
in
on
how
we're
getting
on
with
these
things.
So
our
first
key
result
is
automate
manual
deployment
approval
and
one
of
the
sort
of
measures
in
there,
of
course
is.
A
I
was
gonna,
put
a
screenshot
in
my
to
get
it
in
time,
but
it's
looking
super
healthy
right
now,
like
we
are
comfortably
below
24
hours
on
that
one
so,
but
on
to
everyone,
who's,
supported
and
kind
of
help
with
that
stuff,
and
then
the
second
piece
of
that
is
around
replacing
the
manual
deployment
approval
alessio.
Do
you
want
to
give
us
kind
of
a
brief
view
of
that
stuff.
D
A
A
And
then
our
next
key
result,
we
have
allstate
services
on
unmodified
helm,
chart
scarbeck,
trying
to
give
us
a
bit
of
a
view
of
that.
One.
C
Yeah
very
quickly,
we
just
migrated
the
get
websockets
or
excuse
me.
The
websockets
has
been
moved
over
to
production.
However,
it's
caused
an
incident.
We're
now
missing
some
of
our
metrics
coming
from
hp
proxy
that
I
guess
that's
why
java
is
not
currently
in
the
meeting
batch
two
for
the
sidekick
migration
is
on
its
way
into
kubernetes
as
we
speak,
I
started
that
change
request
like
two
minutes
before
this
meeting
started.
C
I
don't
recall
what's
next
on
the
list,
I
think
we're
going
to
kind
of
maybe
pause
a
little
bit
on
the
migration
start,
focusing
efforts
on
multi-cluster
configurations
because
the
if
we're
going
to
start
taking
client
traffic,
we're
going
to
greatly
increase
the
cost
of
our
network
being
spread
across
multiple
zones
instead
of
gcp.
C
A
Yeah
making
good
progress
there.
Thank
you
and
then
there's
another
key
result
affects
you
a
lot
a
little
bit
less
or
or
indirectly
affects
you.
I
suppose
I
should
probably
say
so
across
all
of
engineering
managers
are
doing
dib
training,
so
there's
a
target.
I
think
engineering
on
I've
almost
completed
earth
development.
All
the
managers
have
nearly
completed.
I
think
it's
just
a
couple
of
outstanding
and
infrastructure,
we're
tracking
here.
A
So
the
goal
our
we
have
a
key
result
all
managers
to
complete
dip
training
this
quarter,
so
you
can
keep
keep
track
of
that
stuff
and
also,
if
you,
if
you
want
to
watch
any
of
the
videos,
they're
online
and
freely
available
as
well
so
cool
so
as
well
as
all
of
those
things,
we
also
have
kind
of
ongoing
release,
velocity
work,
which
isn't
super
well
tracked
in
our
key
results,
actually,
which
is
a
little
bit
of
a
shame
because
it's
it's
super
important
stuff,
but
I've
just
called
it
out
separately
here.
A
So
we
have
three
things
going
on
here:
focusing
on
the
removing
the
blocking
nature
of
security
releases
so
myra.
Maybe
you
want
to
give
us
a
brief
view
of
that.
One.
E
Yeah
sure
so
we
are
working
on
changing
how
the
security
merge
requests
are
processed,
the
one
targeting
master
is
going
to
be
merged
early
than
the
security
release
and
the
backboards
are
going
to
be
merged
during
the
security
release,
and
that
allows
us
basically
to
combine
security
fixes
with
the
autodeploy
and
deploying
security
fixes
at
the
same
speeds.
Space
pace
at
any
other
regular
fix.
A
Awesome
sounds
good
and
then
also
we've
got
the
work
that
euric
is
doing
around
rebuilding
the
release
code
stuff.
So
that's
in
progress
and
then
finally,
we
have
a
new
one
which
I've
just
literally
added
onto
the
release.
Velocity
page,
which
is
your
one's,
got
back.
Self-Serve
registry
deployments.
C
D
C
Goal
behind
that,
just
so
that
team
can
kind
of
roll
out
changes
faster
and
independently
yep
yep
they're,
going
to
be
doing
a
lot
of
integrations
with
various
components
outside
of
get
lab
and
they're
going
to
have
their
own
database
at
some
point.
So
they
really
want
the
ability
to
deploy
outside
of
git
lab
itself
just
to
iterate
faster
than
where
we
currently
do
today.
I
guess.
A
Awesome
so
lots
going
on,
which
leads
me
neatly
into
my
next
point:
we've
got
lots
going
on,
so
we
do
so
there's
a
few
things
that
I
want
to
kind
of
tackle
around
our
workflow.
One
is
the
fact
that
we
don't
really
have
a
workflow
that
works
for
everybody,
or
certainly
not
one,
that
everybody
like
follows,
or
maybe
find
wants
to
follow
or
find
easy
to
follow.
A
So
I
want
to
definitely
address
that,
but
rather
than
just
saying
straight
off
like
we
should
just
do
this
thing,
that's
in
the
handbook,
it
seems
like
it'd,
be
a
good
idea
to
like
iterate
on
this
a
little
bit
and
see
if
we
can
actually
find
one
that
maybe
fits
better
with
the
way
we
do
work.
A
So
there's
going
to
probably
be
a
few
pieces
like
more
than
a
couple
of
pieces
to
this
because
there's
various
parts
to
our
workflow,
but
I
just
put
up
an
issue
on
on
piece
one
around
priority
of
work.
A
So
I've
put
out
the
goals
in
that
and
no
expectation
we'll
make
a
decision
on
this
today,
like
maybe
towards
the
end
of
the
week,
or
maybe
even
monday,
when
your
ex
back,
but
my
rough
goals
on
this
are
around
my
kind
of
I
guess
my
biggest
goal
is
around
us
not
trying
to
do
everything
at
once
all
the
same
time,
so
I
think
it
get
up.
We
do
have
more
things
in
progress
than
like
other
places.
A
So
I
think
that's
fine,
but
I
do
want
us
to
be
able
to
easily
recognize
that,
like
oh,
I
have
three
things
in
progress
and
I'm
desperately
trying
to
do
all
of
them,
and
actually
I
could
just
be
really
really
focusing
on
one
thing
and
have
the
others
more
kind
of
like
secondary
tasks,
and
I
think
the
other
pieces
around
that
are
knowing
how
urgently
you
need
to
unblock
somebody.
A
So
if
you're
sort
of
working
on
your-
I
don't
know
theoretically
like
priority
three
tasks,
and
you
get
a
request
from
someone
else
and
there's
it's
their
priority.
One
task,
you
know-
maybe
you
have
a
bit
more
urgency
on
that,
but
then
I
think
the
other
bits
that
we
don't
do
well.
Maybe
we
do,
but
not
very
explicitly
if
I'm
picking
up
this
new
piece
of
work,
what
does
that
mean
for
other
things?
A
So
I
think
we've
talked
about
it
a
little
bit
more
recently
in
kubernetes,
I'm
sure
we
all
have
to
do
it
all
the
time
which
is
like.
Oh,
I
was
working
on
this
thing,
but
actually
this
other
task
has
come
up.
Should
I
intentionally
switch
my
focus
or
not,
so
those
were
the
kind
of
things
that
I
would
like
us
to
be
able
to
be
a
like
remind
ourselves.
I
think,
to
do
because
I
think
we're
doing
them.
We
do
switch
tasks.
We
do
help
each
other.
A
We
do
have
multiple
things
going
on
at
any
one
time
and
we
manage
those,
but
I
would
like
our
workflow
to
actually
be
able
to
make
that
easier
for
us
to
remember.
Like
oh
hang
on
I,
it
looks
like
I
have
two
things
going
on
at
the
same
time
and
that's
going
to
be
pressure
on
you
right.
So
I
think
that's
the
main
thing
I'd
like
to
tackle
here
so
put
some
ideas.
A
There
feel
free
to
take
some
time
to
read
through
and
add
comments,
but
alessia
do
you
want
to
just
mention
the
comment
that
you've
already
popped
on
yeah.
D
Thank
you
because
maybe
I
I
didn't
get
your
point.
So
this
is
the
thing
that
is
not
clear
to
me
in
the
in
the
current
proposal,
because
we,
you
mentioned
the
fact
that,
basically,
when
you
pick
the
new
thing
when
you,
when
you
finish
your
task,
there's
something
becomes
your
next
p1,
so
we
have
some
kind
of
priority,
switching
which
reflects
the
the
order
of
priority
of
the
things
that
I'm
currently
working
on,
which
is
relative
to
the
to
the
given
set
of
time.
D
So
right
now
I
have
a
p1,
not
a
p2,
maybe
so
what?
What?
What
is
not
clear
to
me
with
this
is:
how
can
I
understand
the
original
priority
of
some
kind
of
work,
because
maybe
scarborough
is
working
on
a
something
that
was
p1
since
the
beginning,
and
I
should
help
him
because
maybe
my
p1
item
was
just
a
p4.
I
just
work
it
through
all
my
lists
and
it's
no
longer
it's
not
more
important
than
the
thing
that
karma
is
doing.
A
Yeah,
okay,
that's
a
really
great
point
yeah,
so
I
think
probably
the
way
I
was
thinking
about
it,
which
isn't
super
clear
in
the
way
I've
written
it
is.
I
atta
like
whilst
we're
actively
I'm
trying
to
get
it's
right.
A
So
the
way
I
was
thinking
about
it
is,
I
have
a
task
and
it's
a
p1
for
as
long
as
that
task
is
in
progress
that
would
most
likely
be
my
p1
right,
like
that's
my
number
one
priority
and
I
might
be
working
on
p2s,
but
they
are
still
p2s
because
as
much
as
I
can
be
I'll
be
doing
my
p1
when
I
close
my
p1,
something
else
promotes
up
to
my
p1,
so
it
might
be
one
of
my
p2s
moves
up,
or
it
might
be
that
at
that
point
I
see.
D
One
p
two
three
four
for
this
in
what
we
are
doing
with
priority
items
in
at
company
level
and
what
we
used
to
do
at
a
team
level
was
actually
reflecting
the
the
actual
priority
of
that
kind
of
work,
so
that,
if
I'm
working
on
something
that
originally
was
p2
or
p3,
even
if
it's
my
top
priority,
because
it's
the
thing
that
I
should
do
by
the
end
of
the
week
month,
whatever
if
something's
p1
pops
up,
I
would
drop
my
work
and
start
working
on
that,
because
we
have
this
relative
priority
between
tasks
and
this
gets
lost
in
this
kind
of
translation.
D
Because
my
thing
now
is
p1
because
it's
my
main
work
item,
but
maybe
yeah,
but
it's
not-
and
this
is
not
the
type
of
p1
that
we
do
when
we
create
a
new
p1
means
that,
for
instance,
release
tools
is
broken
and
so
release
managers
cannot
deploy.
So,
no
matter
what
I
was
doing,
how
important
it
was
I
have
to
if
I'm
available,
and
I
know
how
to
fix
it.
I
should
fix
this.
C
A
That's
probably
incorrect
that
right
and
I
think
that's
my
point
right
because
at
the
moment
I
think
the
vast
majority
of
things
we
work
on.
We
just
leave
as
a
p4,
but
actually
I
think
that's
the
gap
which
we
have,
which
is
we?
Don't
we
don't
prioritize
work
as
we
go
so
that's
kind
of
another.
I
think
a
piece
that
we
should
so
the
pieces
I'm
kind
of
thinking
around
in
this
workflow
one
is
around.
A
How
do
we
prioritize
work
and
at
the
moment
I
think
we're
doing
a
pretty
decent
job
of
actually
individually
prioritizing
and
I
think
you're
good
at
going
I'll
pick
up
this
thing-
and
I
know
I
have
that
thing
next,
but
what
we
don't
really
have
is
any
way
for
you
to
influence
what
somebody
else
picks
up
and
I
think
that
might
be
a
bit
of
a
gap.
So
one
of
the
pieces,
I
think,
will
be
to
work
out
how
to
as
a
team
we
agree
on.
These
are
our
top
priority
pieces
of
work.
A
Then
I
think
there
is
a
bit
around
the
actual
workflow
of
a
ticket
and
like
the
state
it's
in,
but
that
was
the
hardest
bit.
So
I've
I'll
come
back
to
that
bit
in
a
bit,
but
I
ideally
will
have
will
actually
it'll
be
super
obvious,
like
this
ticket
is
we're
deciding
on
a
solution
or
this
ticket
is
ready
to
be
picked
up
for
coding,
or
this
one
is
actually
in
progress.
So
there's
kind
of
a
visual
view
for
that.
But
yeah
it's
a
really
good
point.
Alessio
around.
A
Do
you
think
so
I
think
the
p1
stuff,
like
a
corrective
action.
I
think
we
know
how
to
handle.
We
handle
those
really
well
like,
which
is
it's
a
p1
and
something
else
gets
dropped
and
I
guess
we
we
kind
of
we
do
de-prioritize
something
else
to
pick
up
that
thing,
but
yeah
you're
right
about
the
thing
being
lost.
D
Yeah
kind
of
yeah:
the
point
is
that
maybe
it
starts
p4
like
we
are
doing,
but
then
they
have
product
manager
that
maybe
helps
prioritizing,
because
something
may
change
around
this
thing.
So
it
may
became
a
more
important
task
to
work
on,
which
is
something
that
we
are
also
doing.
But
we
do
we
realize
more
on
individual
speaking
derived
things.
We
don't
have
a
pm
that
just
prepared
the
kickoff
for
the
month.
That's
probably
this
is
the
big
change,
the
big
difference
that
we
have.
D
So
if,
as
a
theme
or
the
engineering
manager,
we
realize
that
something
is
now
it's
more
important
than
when
you
used
to
be.
When
we
wrote
it,
then
we
just
bumped
the
priority
to
because
now
it's
more
important,
but
I
think
that
skype
exploit
is
a
good
one.
So
maybe
we
need
another
set
of
scoped
labels
that
are
just
kind
of
personal
priorities
so
that
we
can
say
this.
C
I
would
argue
that
we
could
probably
reuse
the
existing
delivery
labels
and
we
could
use
the
company
provided
label,
so
the
scoped
priority
labels
that
already
exist
in
the
gitlab
org.
We
could
use
those
as
prior
labels
so
that
all
the
stuff
that
I'm
using
me
as
an
example,
all
the
stuff
that's
assigned
to
me-
would
exist
as
a
p4,
but
as
a
delivery
label,
it'd
be
a
p1
or
p2,
because
I'm
actively
working
on
that
does
that
make
sense.
A
Yeah,
that's
pretty
great.
I
do
okay.
Then
let
me
see
if
I
can
add
a
bit
more
detail
to
this
and
let's
keep
going,
but
that
sounds
like
it
might
be
a
good,
a
good
shape,
so
jeff
we're
just
chatting
about
the
delivery
team,
workflow
stuff.
So
I'll
add
on
some
details
on
the
issue
but
say
this
is
part
one
version
one
of
of
some
iterative
stuff
so
feel
free
to
look
through
this,
like
maybe
over
the
week
and
we'll
gather
some
stuff
on
this.
D
Well,
I
should
have
done
this
in
the
announcement
but
yeah.
I
posted
the
link
in
our
channel
about
the
ic
gearing
working
group,
so
I
just
prepared
them
an
epics
where
I'm
tracking
the
what
we
are
doing
in
the
working
group
and
I'm
collecting
feedback
from
the
whole
department.