►
From YouTube: 2020-07-06 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
I
just
wanted
to.
Let
you
all
know
remind
you
that
this
Wednesday
we
have
a
AMA
about
releases
and
deployments
so
come
along
if
you're
interested
in
what
we'll
be
doing
this
one,
it's
going
to
be
the
last
one
that
meirin
leads
and
then
it
will
be
down
to
us
so
certainly
from
ex
month.
I'll
appreciate
your
your
support
in
helping
to
answer
questions
about
releases
Alessio.
B
A
Yeah
I
just
want
to
make
again
a
reminder:
the
backstage
label
is
going
away.
Fish
up
to
Robert.
You've
got
both
those
issues,
but
also
just
heads-up,
since
it
is
a
label
that
we've
been
using
in
the
past
that
there's
a
couple
of
new
options
we
should
use
instead,
so
that
it's
more
clear
that
we're
changing
like
workflows
or
pipelines,
or
something
like
that.
So.
A
A
D
D
C
B
I
think
that
also
happens,
and
we
just
because
it's
the
default
when
we
say
we
should
work
on
something
and
then
we
never
go
back
to
it.
It's
really
discussing
it.
So
this
is
kind
of
the
default
state
and
when
priority
was
increased,
then
we
move
to
it,
but
so
far
we
basically
work
on
priorities
mostly,
so,
if
something
is
important
enough,
then
it
will
move
through
the
stages
to
being
the
boss.
Okay,.
F
I
think
it
is
also
kind
of
confusing
that
we
are
working
on
the
delivery,
Charter
and
they're
released
to
start
pairing,
one
of
them,
so
good
luck
or
and
another
one.
Is
it
last
comments
and
I
think
one
revolution
doesn't
have
all
the
labels
are
available,
so
we
need
to
use
another
set
of
labels.
G
Looking
for
the
issue
tracker
now
and
I,
don't
see
many
issues
that
are
being
opened
by
people
outside
the
team,
so
I
kind
of
wonder
whether
I
mean
what
does
triage
mean
in
that
in
that
sense
like.
If
we,
if
we
open
the
issue
normally
like,
we
should
be
assigning
priority
and
severity
ourselves,
because
we
probably
have
a
pretty
good
idea
about
it.
Is
that
all
we
mean
by
triage
or
do
we
need
something
more
I.
E
Would
hedge
a
bet
that
we
also
include
the
fact
that
we
created
the
issue,
but
we
haven't
looked
into
potential
use
cases
for
how
to
solve
the
problem
at
hand,
and
it's
also
a
way
to
advertise
to
the
external
people
outside
of
our
team
that
we
are
not
currently
looking
at
this
issue
at
this
moment
in
time.
I.
C
A
I
have
to
say
in
my
head:
it
yeah
it's
kind
of
the
discussion
time,
because
I
would
think
that
I,
though
we
can
set
a
priority
in
terms
of
the
idea,
maybe
the
discussion
changes
that
I
don't
know,
but
I
do
think.
The
discussion
is
quite
valuable,
not
just
from
like
sharing
knowledge
but
just
generally
I
think
a
lot
of
what
everybody's
working
on
like
touches
up
on
other
stuff,
but
might
not.
G
We
could,
instead
of
like
I,
think
they
bought
automatically
puts
a
delivery
P
for
a
label
and
issues.
We
could
maybe
have
the
default
being
to
put
the
triage
label
and
then
once
you
assign
a
priority,
then
the
triage
label
would
automatically
get
removed,
but
then
again
I
think
there
was
some
mention
said
like
okay,
sometimes
it's
a
discussion,
sometimes
you
flush
it
out,
but
maybe
at
that
time
you
still
have
a
priority
on
it.
I.
B
B
Basically,
I
think
that
the
idea
is
that
you
have
an
idea,
so
you
put
this
workflow
in
triage
and
this
idea,
maybe
it's
something
easy
like
fixing
simple
behavior
on
release
whatever,
and
then
it
moves
basically
from
try
ash
to
ready
and
then
we
move
on
or
the
discussion
may
lead
to
a
bigger
issue
that
deserves
to
be
promoted
to
an
epoch.
In
that
case,
we
apply
the
discussion
label
and
we
start
streamlining
the
conversation
around
it,
but
not
sure
if
we
are
really
doing
this.
B
Think
that,
because
we
are
basically,
we
are
the
authors
of
all
of
our
issues,
kind
of
so
it's
it's
quite
obvious
that
the
author
is
the
one
that
cares
about
the
specific
topics
and
is
the
one
that
kind
of
keep
track
of
when
something
will
happen.
So
this
is
very
specific
to
to
our
workflow,
because
very
few
people
outside
of
our
team,
open
issues
on
our
tracker,
so
I'm
yeah
I'm
not
really
sure
about
this.
A
Okay,
I
will
come.
My
main
focus
at
the
moment
is
I'm
generally
trying
to
sort
of
like
tidy
up
a
little
bit
and
organize
things,
I'm,
hoping
that
we'll
end
up
with
something
where
we
have
it's
a
bit
of
our
you
can
sort
of
drop
in
and
see
a
view
of
what
we
working
on,
but
so
I
keep
tweeting
away
and
that
stuff,
please
give
me
a
feedback
if
it's
not
correct
or
helpful,
but
we
won't
make
any
radical
workflow
changes
I'm
just
generally
trying
to
make
it
a
bit
easier
to
show
off.
A
F
Yes,
I
normally
join
incidents,
call
cons
to
learn
like
a
thing
or
two
and
to
see
where
I
can
pick
there,
but
there
are
times
on
those
calls,
mostly
when
sre
starts
talking,
which
I
feel
that
I
am
in
a
meeting
with
a
bunch
of
aliens
because
I
don't
really
understand
what
are
they
talking
about?
So
I
found
this
issue
about
moving
or
trying
to
separate
the
line
between
engineers
and
SR,
East
and
I.
Don't
know,
I
find
it
interested
and
I
don't
know
if
anyone
else
also
finds
this
interesting.
A
Yeah
so
I
mean
I
was
sort
of
wondering
like
if,
if
there's
some
interest
in
this,
then
I
could
create
a
version
of
this
issue
for
delivery,
and
we
could
play
around
with
ideas
of
basically
how
we
can
knowledge.
I
know
like
a
few
people
have
mentioned
that,
like
you,
may
have
interests
in
some
of
these
things,
you
can
see
how
that
works
out.
I.
B
Think
this
is
a
nice
idea,
and
especially
it
would
also
in
shaping
what
we
want
to
do
with
delivering
our
own
software,
because
having
this
better
understanding
of
what
is
what
we
are
running
and
how
we
are
running
things
in
production
may
help
lot
so
yeah
I
definitely
agree
that
this
is
a
good
idea.
Probably
I
will
also
try
to
understand
from
Jarvan
scarback
what
they
are
doing
because
yeah,
because
what
I'm
thinking
here
is
that,
if
most
of
their
work
is
about
migrating
to
kubernetes,
so
I
don't
know.
B
If
there
is
something
easy
enough
to
pick
up
for
someone,
it
is
not
necessary
to
get
familiar
with
chaff
or
other
tools
if
we
are
not
using
as
a
back-end
engineers
on
the
other
side
is
easier,
at
least
from
my
perspective,
because
I
know
that
skarbek,
but
also
a
job,
are
already
contributing
to
release
tools.
So
then
the
opposite
flow
is
it's
already
in
place.
Let's
say
we
can
improve
it,
but
it's
already
in
place.
A
Yeah
thanks
Silesia,
like
I,
think
it's
really
like
any
even
like
super
tiny
things
right.
If
it's
like
we,
we
have
I,
know
even
like
we
don't
we
going
through
the
RCA
after
an
incident
or
just
something
like
that.
We've
got
a
corrective
action.
I
think
like
even
just
a
little
bit
of
knowledge
sharing
around
the
the
overall
lifecycle
could
be
could
be
helpful.
I.
A
Draft
something
up
for
delivery
and
we
can
have
a
little
bit
of
play
around
about
you
know
it
doesn't
have
to
be
an
exact
copy
of
how
scalability
of
doing
it
and
it
doesn't
have
to
be
anything
formal
either
right.
It
can
be
an
informal
thing,
but
perhaps
we
have
a
little
look
at
the
sorts
of
things
we
could
knowledge
share
on
or
pair
up
on
or
even
just
tickets.
That
could
be
like
issues
that
could
be
kind
of
marked
as
like.
Oh
this
one's,
actually
you
know
reasonably
straightforward
and
you
could
learn
about.