►
From YouTube: 2020-11-23 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
So
hello,
everyone
happy
monday,
so
I've
realized
the
the
problem
at
this
time
of
year.
I
sit
in
like
a
kind
of
gloomy
cave,
so
I
do
own
other
lights,
but
I'm
gonna
opt
not
to
use
them.
So
we've
got
lots
on
the
agenda
today.
So
let's
get
going
of
course
on
the
announcement.
Well
done.
Jeff
skelbeck
awesome,
release
management,
lots
of
things
going
on
last
week
and
a
sunday
release
as
well,
but
yeah,
usually
we're
done.
B
Oh
sorry,
I
should
have
put
not
to
read
here
just
that
I'm
taking
an
extended
holiday
this
weekend.
I
thought
maybe
others
would
as
well,
if
I
put
it
here
so
but
yeah
I'm
taking
off
starting
friends
and
family
I'll
be
out
wednesday,
thursday
friday.
A
Awesome
cool
and
then
I
just
added
here
I
put
it
in
slightly
just
in
case:
you
missed
it.
So
we
have
a
scheduled
meeting
tomorrow,
go
ahead
and
add
questions
the
agenda,
doc
ahead
of
that,
if
there
aren't
any,
we
can
cancel
so
we'll
see
how
that
goes
cool
so.
B
Yeah,
I
just
wanted
to
highlight
this
because
I
didn't
know
this
was
released
until
I
read
the
release
post
is
that
there
have
been
some
improvements
to
milestones.
B
I
know
a
couple
of
the
complaints
have
been
that
when
you
move
issues
from
one
milestone
to
the
next
milestone,
you
kind
of
lose
a
record
of
what
was
done
and
it
sounds
like
that's
been
addressed.
I
haven't
actually
tried
it
myself,
but
if
I
believe
the
release
post
it
looks
like
that
is
no
longer
the
case,
and
also
you
have
this
cool
little
burn
up
truck,
which
is
really
nice
for
tracking,
unplanned
work.
I
don't
know
if
we
would
ever
adopt
milestones.
A
Yeah
thanks,
I
had
a
quick
look.
I
think
I'm
still
in
the
like,
I'm
not
like
sure
what
problem
they
solve
for
us,
but
I
mean
if
anyone
wants
to
put
together
a
proposal
of
what
they
could
solve,
then
very
happy
to
to
read
that
so
yeah
go
ahead
and
do
that.
If
you
want
to.
A
Cool
man.
C
Hey
everyone.
I
wanted
to
chat
a
bit
and
give
some
reminders
to
the
team
that
you
probably
remember,
but
it
doesn't
hurt
to
actually
repeat
related
to
iteration
and
dog
footing,
specifically
for
this
team.
So
you've
probably
heard
it
like
a
million
times
so
far
from
all
sides.
That
dog
footing
is
really
important
for
us,
and
some
of
you
know
iteration
very,
very
well
or
think
that
you
know
iteration
very
well,
but
I
want
to
frame
it
within
the
team
and
explain
why
and
how.
C
We've
not
always
done
dog
fooding
first
and
we've
not
always
done
just
iterate
to
a
solution
right,
but
a
lot
of
our
things
in
the
team
have
been
done
that
way
and
when
we
do
a
large
dog,
fooding
effort,
which
specifically
puts
some
new
product
features
in
and
removes
some
of
our
own
maintained
code.
C
We
actually
create
a
bit
of
a
cover
for
us
to
actually
go
with
the
next
set
of
things
that
are
not
necessarily
directly
in
the
product,
but
we
can
implement
them,
run
them
run
them
at
the
process
we
have,
and
then
we
stop
go
back
and
start
porting
that
back
into
the
product
and
while
that
doesn't
seem
like
a
big
deal,
it
is
what
allowed
us
to
run
for
the
past
two
years,
largely
unobstructed,
so
creating
features
within
gitlab
that
are
not
only
for
us,
but
for
everyone
else
and
then
changing
our
own
processes.
C
When
I
say
our
own,
I
mean
in
gitlab
internal
processes
to
actually
match
the
new
feature,
actually
moved
us
or
moved
focus
away
from
us,
so
that
we
can
actually
focus
on
the
work
within
the
team.
C
I
also
want
to
address
address
the
iteration
part,
which
is
something
that
I
got
confronted
with
last
week.
C
It
is
also
okay
for
us
to
replace
as
small
as
possible
parts
and
then
over
time
build
those
features
out.
That
gives
us
first
of
all
again
dog
fooding.
It
gives
us
the
the
insight
in
how
we
can
do
it
differently
within
the
product.
What
kind
of
changes
we
can
make
in
in
our
processes
to
actually
accommodate
that,
but
also
it
exposes
as
well.
You
know,
like
the
next
steps
that
we
can
take.
C
I
know
that
for
a
lot
of
you,
this
is
like
very
much
known,
but
it
doesn't
really
hurt
to
remind
remind
everyone,
mostly
because
now
that
I'm
not
leading
the
team
like
I'm,
not
keeping
a
strict
eye
on
everything
there
and
you
all
need
to
help
amy
and
so
that
amy
can
help
you
all
as
well
with
this
direction.
So.
C
Try
to
think
and
if
you're
not
really
certain,
try
to
think
about
the
next
step
we
could
take
for
any
given
feature
like
I
can.
I
am
going
to
use
the
example
of
production
change,
lock
here,
not
calling
out
anyone
just
using
an
example.
Here
we
have
a
whole
project.
That
is
very
useful
for
us
of
course,
but
we
have
a
new
feature
that
is
in
gitlab,
and
we
can
start
that
discussion
by
thinking
about.
Well,
let's
try
to
use
the
new
feature,
and
then
we
have
backend
engineers
inside
of
the
team.
C
Let's
see
how
we
can
improve
it,
let's
see
what
kind
of
processes
we
can
change
to
actually
accommodate
the
usage
of
this
new
feature,
so
we
can
remove
yet
another
thing
from
our
queue
and
ideally
I
wouldn't
need
to
participate
there
like.
I
noticed
it
by
accident
and
I
wouldn't
need
to
participate
there
as
well.
Amy
shouldn't
participate
there
as
well,
like
you
all,
are
very
senior
here
and
you
know,
or
you
should
know
how
much
of
an
impact
that
actually
has
on
on
the
team
as
a
whole.
C
C
Excellent
question,
so
what
jarv
just
did
now
where
he
gave
us
a
highlight
like
hey?
This
is
something
that
we
are.
We
can
possibly
consider
using.
That
needs
to
come
with
the
follow-up
issue
in
our
issue
tracker,
so
we
can
track
it,
and
then
you
use
the
process
the
theme
process
on
putting
it
in
in
a
certain
queue
and
then
it's
up
to
amy
to
actually
work
on
prioritizing
this.
So
my
direction
to
amy
is
the
dog
fooding
issues
always
like.
C
We
have
to
strike
the
right
balance
between
the
okrs
and
and
dog
fooding
and,
as
you
can
see,
for
example,
we
now
kind
of
shifted
this
quarter
more
on
like
generating
like
a
large
feature,
but
if
we
were
to
do
some
of
these
things
more
frequently,
it
wouldn't
have
to
be
like
a
big
bang
type
of
event
where
we
actually
have
to
write
like
a
large
feature
to
actually
satisfy
this.
C
So
by
following
what
is
being
released
right,
like
I
think,
all
of
us
should
be
reading
the
the
monthly
release
right
and
by
then
creating
an
issue
putting
it
in
the
board.
You
can
think
of
it
as
yeah.
It
might
end
up
just
in
the
back
of
the
queue
somewhere
unknown,
but
we
have
a
process
for
dog
fooding,
which
is
in
the
handbook
the
right
labels
with
the
right
labels
applied.
C
We
can
track
it
more
easily
and
we
can
raise
priority
because
this
is
top
of
mind
for
a
lot
of
leaders
come
coming
from
the
top
right
like
there
is
always
this
discussion
of.
C
How
are
we
balancing
these
things
and
like
if,
if
I
can,
if
I
and
amy
can
explain
what
kind
of
balance
we
made
and
why
we
made
it
it's
easier
than
saying
we
didn't
even
look
into
it
right,
like
example,
here
is
one
of
the
features
that
came
out
last
month
was
kubernetes
cost
management
panel.
Right,
like
I
knew
about
it,
and
I
made
a
mistake.
C
I
didn't
create
an
issue
for
it,
so
then
it
came
as
a
directive
from
sid
like
how
are
you
using
this
feature,
and
I
was
like
I
didn't
even
raise
an
issue
for
it,
so
we
don't
need
sid
to
be
here
and
remind
us.
How
are
you
using
this
feature?
We
can
do
that
on
our
own,
and
if
we,
if
you
say
it's,
not
the
top
priority
at
the
moment,
that
is
also
okay.
We
can
explain
why
it's
not
a
top
priority,
as
long
as
it
doesn't
come
as
a
surprise
to
everyone.
A
There
nice-
I
it's
definitely
interesting.
For
me,
this
is
something
which
I
have
not
seen.
Work
super
well
in
previous
places
like
it's
a
it's
a
really
great
thing
that
we
have
this
kind
of
iterative
approach
and
also
the
dog
fooding,
so
yeah
like
definitely
help
me
out
on
on
cases
where
you
can
see
opportunities
for
for
us
to
do
both
of
those
or
to
do
more
of
both
of
those
things
so.
C
And
this
is
a
two-way
street
by
the
way
right
like,
if
you
see
me
doing
something
silly
like
not
creating
an
issue,
you
can
call
me
out
like
we
know
each
other,
all
of
us
long
enough
for
you
to
be
able
to
feel
comfortable
about
calling
me
out
and
saying
like
marvin.
Where
is
that
issue,
and
then
I
can
say:
well,
I
didn't
create
it.
C
I
can
delegate
it
to
amy
then
right,
but
at
least
you'll
call
me
out
on
that
and
I
can
take
the
action
or
have
someone
else
take
the
action
for
it.
A
Also
highlighting
in
there
that,
like
we
do
kind
of
have
our
kind
of
north
star
is
that
the
dream
is
everything
we
do
exists
inside
the
gitlab
product.
Maybe
that's
a
long
way
away.
Maybe
maybe
we
have
a
shortcut
that
we
find,
but
that's
the
ultimate
goal
is
to
everything
we
use
to
do
our
deployments
and
our
releases.
Everybody
else
can
also
benefit
from.
C
Yeah
and
you'll
see
like
the
next
quarter.
Okrs
are
going
to
be
more
and
more
in
that
direction.
Right
like
as
we
reached
our
targets
with
mttp,
we
are
going
to
now
do
this.
Technical
data
will
address
the
technical
debt
with
release
tools
by
moving
it
into
a
one
coordinated
pipeline
right,
but
the
next
steps
are
going
to
be.
C
How
are
we
going
to
dismantle
this
whole
thing
right,
like
not
immediate,
next
step,
obviously,
but
we
always
have
to
balance
like
what
makes
our
mttp
and
our
metrics
that
we
want
to
track
achievable,
but
then,
at
the
same
time,
what
makes
like
we
want
to
automate
ourselves
out
of
work,
so
we
want
to
make
sure
that
we
move
as
many
of
these
features
back
into
the
product
and
over
time
things
are
going
to
like
get
smaller
in
what
we
have
to
maintain,
but
other
things
are
going
to
increase
right,
the
number
of
releases,
the
number
of
things
that
we
need
to
deploy
and
so
on
and
so
on.
C
So
there
is
always
going
to
be
a
need
for
this
team.
It's
just
that
the
structure
is
going
to
change
and
over
time
you
might
not
be
interested
about
that
work,
so
you
might
be
more
interested
in
joining
the
stage
group
teams
that
are
going
to
be
working
on
the
features
that
you
built
right.
So
there
is
this
like
natural
revolution
that
is
going
to
come
in
the
next
five
years
into
this
team.
But,
as
you
all
know,
it's
not
gonna
happen
next
year,
like
it's
really
really
hard
to
do
that.
C
But
it's
definitely
not
gonna
happen
next
year.
If
we
don't
start
moving
things
slowly.
So
it's
it's
really
important
to
know
that
now
that
we
achieve
certain
goals
of
ours,
especially
like
with
kubernetes
being
relatively
close-ish
to
completion,
we
have
to
shift
gears
into
what
are
we
going
to
do
to
now?
C
Remove
the
actual
toil
we
have
with
our
own
maintenance
and
move
it
back
into
the
product
and
with
the
exception
of
jarvan's
car
back
all
of
you
worked
in
the
stage
group
teams,
and
you
know
how
to
build
a
feature.
You
know
how
to
address
that
and
then
jars
and
starbucks
role
changes
a
bit
as
well
they're
not
going
to
be
writing
code,
but
there
is
still
a
lot
of
maintenance
to
be
done
related
to
how
this
actually
works.
How
releases
were
how
deployments
work
and
so
on
so
yeah?
A
Thank
you
thanks
for
sharing
that
as
well.
So,
yes,
I
just
wanted
to
share
out
that
on
wednesday,
it's
friends
and
family
date,
that's
going
to
be
that's
a
hard
production
change,
lock,
so
nothing
on
staging
and
then
thursday
and
friday
for
us
holidays.
A
We
have
a
soft
production
change,
look
so
nothing
beyond
canary,
so
just
to
kind
of
heads
up,
skelbeck
I'll
coordinate
with
you
on
on
all
of
that
stuff,
as
release
manager,
but
yeah
just
wanted
to
make
sure
everybody
was
aware
like
if
you,
if
you
are
working,
say
thursday,
don't
be
surprised
if
no
release
is
going
out.
E
A
E
Yeah
just
another
question,
so
what
would
happen
if
we
tried
to
deploy
it
to
production
like?
Is
it
completely
restricted
or
we
can
actually
override
that.
A
It's
discouraged
strongly
discouraged
because
there
won't
be
very
many
people
around,
so
we
should
avoid
doing
it
unless
in
a
soft
changelock
like
if
we
absolutely
have
to.
If
we
need
to
fix
a
problem,
then
we
can
do
that
with
with
we'll
work
with
the
sre
on
call,
but
sorry
engineering
cool,
but
we
won't
be.
We
won't
be
deploying
just
for
the
sake
of
deploying
it
will
only
be
in
response
to
something
which
will
make
monday
interesting
so
yeah.
I
could
shout
on
the
security
release,
cool
and
eric.
F
It's
broken
up
into
two
epics
there's
one
for
the
actual
changelog
part,
and
then
this
one
for
making
it
more
easier
to
or
say
making
possible
to
edit
commit
messages
within
gitlab,
partially
or
mostly
because
the
feedback
we
got
there
is
quite
a
bunch
of
people
were
worried
that
the
process
of
editing
them
through
get
rebase
and
basically
doing
it
locally,
is
too
too
painful.
F
It
is
when
we
want
to
roll
this
out
that
that's
when
we're
going
to
need
the
commit
message,
editing
capabilities,
so
yeah
doesn't
necessarily
have
to
be
now.
So
take
a
look
at
it
and
let
me
know
if
there's
anything
worth
highlighting.
F
And
I
think
I
am
the
last
one
so
that
brings
us
to
the
discussion
what
we
did
last
week.
C
I
guess
I'll
I'll
ask:
did
we
engage
with
product
on
the
features
eric.
F
Yeah
so
andrew
thomas
is
involved
in
it,
okay,
and
actually
now
that
I
started
planning
these
issues
for
the
editing
part,
I
found
that
there
have
been
epics
for
this
in
the
past.
They
hadn't
really
gone
anywhere
for
various
reasons,
so
I
tried
to
loop
in
james
ramsey
because
he
was
part
of
that,
and
I
found
that
actually
five
days
ago,
gideon
or
at
least
cj
created
an
epic
to
add
rebasing
support
to
getaly.
F
So
I
also
mentioned
him
like
hey,
you
know
some
of
the
work
we're
doing
here
will
be
overlapping.
F
C
Cool,
given
that
this
is
a
feature
like
we
need
to
stay
on
top
with
products
here
like
they
need
to
give
us
general
direction
of
what
they
want
to
see.