►
From YouTube: 2022-10-19 Delivery team weekly APAC/EMEA
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
B
B
This
is
19th
of
October.
Welcome,
got
a
few
announcements
on
there
around
people
being
unavailable
over
the
next
next
few
days
or
weeks.
So
yeah
enjoy
good
good
to
see
some
conferences
and
training
coming
up.
B
B
We
have
a
few
sort
of
like
adminy,
a
gendered
sort
of
things
that
will
be
coming
up
so
okrs
we'll
be
wrapping
up.
Q3
okrs,
we'll
be
deciding
and
setting
up
the
Q4
okrs
and
we'll
have
our
usual
kind
of
retro
issues
opening
up
around
those,
but
is
there
for
the
Q4?
Okay
else?
There's
lots
of
ideas
on
the
on
the
issue.
Is
there
anything
anyone
wants
to
actually
use
any
of
this
time
to
discuss?
Since
we
have
anything
cross-team
or
people
happy
happy
to
continue
async.
B
Oh
okay,
yeah
I
mean
like
I
would
I.
Actually,
so
that's
that's
the
super
Point.
Let's,
let's
make
that
the
point
there
right
so
over
the
next
few
days
and
sort
of
early
through
next
week,
there'll
be
I'm,
hoping
anticipate,
let's
anticipate
lots
of
updates
on
sort
of
update
and
discussion
on
the
issue
and
as
well
as
Plus
lots
of
updates
on
the
independent
deployment
blueprint
right.
So
these
are
two
things
which
I'm
expecting
will
have
quite
a
lot
of
change
over
the
next
next
week.
B
So
please
figure
out
how
to
sort
of
work
that
best
into
your
workflow,
so
that
you
could
kind
of
join
in
those
conversations
push
things
forwards
it.
Maybe
it's
like
a
little
bit
of
time,
scheduled
into
each
day
or
something
like
that,
just
so
that
we're
all
sort
of
moving
along
online
of
those
things
they
will
both
be
concluded
in
the
next
week
right.
So
we
are
super
close
on
the
blueprint
and
I
think
yeah
we
can
get.
We
will
definitely
get
that
merged
in
the
week.
B
We
can
follow
up
with
new
iterations
if
we
need
to,
but
also
you
know,
don't
don't
let
that
one
pass
you
by
and
oh
Q4
okrs.
There
are
various
discussions.
I
know
you're
all
kind
of
having
discussions
between
yourselves
and
in
our
one-to-ones
as
well,
but
by
this
time
next
week
we
will
certainly
have
okrs
confirmed
we'll
be
setting
those
up
in
Ali
ready
for
Q4.
That
starts
on
the
31st
of
October.
B
Oh
Alessio,
let's
jump
to
the
next
discussion
item.
C
Yeah
I'm
just
jinxing
it
right
yeah,
so
yeah
the
thing
is
other
than
just
being
offline,
not
I
mean
yeah,
not
having
slack,
for
the
maintenance
window
is
about
five
six
hours.
It's
kind
of
a
it's.
C
C
B
B
So
that's
good
yes,
but
it
does
mean
that
the
Monday
we
come
in
I
think
I
I'm
working
across
all
of
infrastructure,
but
certainly
what
we
know
within
delivery
is
I.
Think
we
will
want
to
have
a
plan
of
like
here
are
the
three
four
critical
things
that
we
will
test
before.
Moving
into
regular
like
deployments
and
day-to-day
business.
C
Yeah
I
was
also
thinking
that
Amanda
do
we
already
have
a
plan
for
the
security
release.
I
guess
it's
gonna
be
just
the
week
after
the
regular
release,
so
it
will
not
be
affected
by
because
it
happened
in
the
past
that
we
were
moving
the
security
release
closer
to
the
beginning
of
of
the
next
month,
so
I
mean
just.
We
should
take
this
into
consideration
as
well,
but
yeah.
The
thing
that
mostly
concerns
me
is
the
the
re-implementation
of
slack
wrapper.
A
C
A
B
B
B
B
However,
worst
case
is
we'll
just
have
to
let
everybody
know
that
you
know
we
don't
get
it
completed
in
time.
They'll
have
to
look
up
release
managers
by
name.
B
I
think:
okay,
okay,
my
understanding
was,
it
was
literally
just
the
release
manager
at
handle.
B
See
so
if
it
fails,
it
will
affect
us:
okay,
fine,
fine,
okay,
yeah,
so
we
should
certainly
do
that
so
yeah.
Let's
come
back
to
some
of
those
questions
so
Reuben.
Do
you
already
have
a
plan
for
the
security
release.
A
Not
yet
I
was
just
looking
at
the
dates.
28Th
is
a
Friday,
so
we
probably
don't
want
to
release
on
28th
I
forget
who's,
the
who's,
the
other
release
manager,
yeah
I,
can
discuss
with
covert
today
and
see
either
27th
or
31st
or
first
okay,.
B
So
so,
in
that
case,
here's
what
I'm
thinking
right
so
from
next
week
orchestration
has
a
little
bit
more
capacity
from
the
week
after
we
have
a
lot
more
capacity,
so
I
think
we
can
fit
this
into
orchestrations
kind
of
workflow
like
we'll.
You
know
prioritize
this
work
and
I
mean,
at
the
very
least
like
try
and
get
it
so
that
the
job
won't
fail.
The
slacker
up
a
bit
doesn't.
B
C
It
should
be
trivial
because
the
the
the
API
is
the
same,
just
changing
the
end
point
and
adding
a
couple
of
parameters
I.
The
thing
that
I
don't
know
very
well
is
the
access
requests
workflow
and
how
this,
because
we
are
going
to
change
the
the
results
like
application
in
the
slack
back
office
side
that
Reuben
created
that
I
have
access
to
it
or
I
think
also
other
in
the
team.
We
I
think
we
should
add
the
new
Scopes
there
so
that
the
application
is
allowed
to
interact
with
user
groups.
C
But
then
we
need
to
ask
someone
from
I.T
I
think
to
reinstall
it
in.
A
C
A
So
sorry,
so
unless
you
I
saw
your
question
on
the
issue,
I
was
just
gonna
reply.
I
think
when
you
change
the
scopes
on
the
UI
slack
UI,
it
won't
affect
the
installed
app
I've,
not
confirmed
this,
but,
for
example,
I've
changed
Scopes
in
the
past.
You
know
to
test
stuff
and
all
and
and
nothing's
happened,
nothing's
broken
so
I
think
that
should
continue
working.
But
when
you
reinstall
the
app
will
we
need
to
create
new
tokens
that
I
don't
know
that
we'll
need
to
test
somehow.
C
Well,
in
any
case,
it
will
be
when
we
reinstall
the
app.
We
would
need
to
do
something
in
any
case
right.
So
that's
part
of
the
we
need
to
merge
into
new
changes,
and
so
yeah
and.
C
This
would
be
great
to
test,
but
then
that's
the
other
unknown
part
of
this.
We
don't
know
if
they
had
to
reinstall
it
again
as
part
of
the
migration
or,
if
not
because
they
say
that,
if
you
use,
if
the
thing
is
using
admin
Powers,
it
has
to
be
reinstalled.
Okay,
but
the
new
API
design
that
we're
going
to
implement
seems
to
rely
on
specific
scopes
for
those
things
and
not
admin
information.
So
in
theory,
you
should
just
keep
working
right.
B
Okay,
so
am
I
correct
in
thinking
I'm.
It
sounds
like
that
we
would
do
the
work
to
change
away
from
using
slack
wrapper
following
that,
we
would
need
to
reinstall
the
slack
app
and
that
would
complete
that
piece
of
work
and.
C
Powerful
application
and
then
we
implement
the
thing
and
oh.
B
Then,
after
the
migration,
we
will
have
a
testing
sort
of
window
open
in
the
morning
which
everyone
on
this
call
can
look
forward
to
joining
in
since
it'll
be
hour
day
who
picked
this
stuff
up
and
we
can
test
that
all
of
that
stuff
is
working
as
expected.
Plus
we
can
test
any
of
the
other
things
we've
identified
and
what
I'm
expecting
is
that
it
will
be
ready
and
kind
of
on
hand
following
the
migration.
B
If
there's
any
kind
of
like
rapid
resolutions
like
reinstalling
or
things
like
that,
they
will
be
ready.
So
we
we
should
get
a
plan
kind
of
documented
out,
so
that
they're,
aware
of
like
the
steps
but
I'm
expecting
with
the
team
doing
the
migration
that
they'll
be
expecting
to
be
around
to
help
with
these
things.
A
Do
they
provide
us
a
Sandbox
environment?
Well,
we
would
try
this
kind
of
things
like
you
know,
creating
an
app
installing
it
on
the
previous
one
having
a
Enterprise
grid
account
and
see.
If
we
switch
that
one.
Nothing
like
that
right,
so
testing,
apps
itself,
you
can
do
by
just
creating
a
workspace
in
your
slack.
Anyone
can
create
a
workspace
and
you
can
test
apps
in
that,
but
Enterprise
stuff.
You
won't
be
able
to
do
because
this
is
like
your
personal
workspace
yeah.
A
The
the
reason
was
asking
if
there
was
like
an
Enterprise
ticket
account
where
you
know
we
kind
of
at
the
app
migrate
to
that
and
see.
If
something
happens,
that
would
have
been
great
but
I
understand
that
it's
probably
next
level
sandbox
thingy
that
we
probably
didn't
probably
have
not
even
a
slack.
C
Yeah
I
mean
looking
at
the
documentation.
It
seems
that
basically,
all
the
API
have
an
optional
parameter,
which
is
the
kind
of
workspace
ID
that
we
never
set
in
our
API
call,
because
when
you
just
work
on
a
single
workspace,
it
just
get
the
wrong
by
default,
and
when
you
do
slack
grid,
it's
gonna
be
better
to
put
the
information
in.
So
when
you
refer
to
IDs,
they
are
matched
on
the
on
the
workspace
that
we
always
work
with
and
that.
A
C
Be
the
the
only
change
right,
so
we
change
the
end
point.
We
make
sure
we
are
providing
the
right
workspace.
Id
that
will
not
change.
This
has
been
confirmed,
will
not
change
over
the
migration
and
we
we
change
the
the
authorization
scheme.
How
we
pass
parameter
the
tokens,
because
the
the
old
one
is
the
slack
wrapper
and
the
new
one
is
going
to
be
the
one
for
from
zlap,
and
that
should
be
the
thing
right.
So
if
there's
no
need
to
reinstall
the
the
Monday
morning,
it
will
just
work
if
it's.
C
If
it
has
to
be
reinstalled,
it
will
be
reinstalled
and
we
see
if
we
have.
But
if
we
do
the
work
up
front
just
just
doing
before
the
switch,
we
will
already
know
if,
for
instance,
reinstalling
change
token
or
not,
because
maybe
it
doesn't
change
the
tokens,
and
that
would
be
great
right
because
they
will
do
the
upgrade
and
will
just
work.
If
not
yeah.
We
have
to
change
the
variables
I.
A
Would
kind
of
expect
that
the
token
system
is
kind
of
separated
from
the
rest,
so
they
could
actually
keep
it
across
different
things,
but
it's
just
wishful
thinking
and
a
speculation
on
somewhere
else
software
stock,
so
the
tokens
are
generated
in
the
slack.
App
and
I
have
a
feeling.
It's
not.
But
again,
this
is
just
unconfirmed.
I
have
a
feeling.
The
token
itself
will
not
be
affected
when
you
reinstall
the
app,
because
nothing
else
changes
on
the
UI
when
you,
when
you
like
change
the
scope
or
anything,
the
tokens,
don't
change
or
you.
C
Okay,
I
was
going
to
ask
once
they
installed
the
app
we
are
autonomous
in
creating
tokens.
That's
correct.
C
A
B
So
I
haven't
I
apologize,
haven't
had
any
time
to
read
the
issue
or
sort
of
think
about
this
project
so
far
this
week.
But
do
we
have
a
plan
of
all
these
pieces
on
that
on
the
issue
already.
B
B
Would
you
mind
taking
an
action
just
to
get
those
updated
so
that
we
can
actually
start
picking
away
at
this
like
next
week?
I'm
expecting
we
probably
won't
be
able
to
actually
work
on
this
like
Ruben
I
know,
you're
becoming
a
release
manager.
We've
got
Myra
at
a
conference,
so
certainly
next
week
is
kind
of
limited,
but
we
could.
It
sounds
like
we
could
go
ahead
with
the
access
request
and
get
get
the
the
Scopes
increased
at
least,
and
that
sets
us
up
a
little
bit
better.
A
Are
we
ready
to
do
that,
because
I
think
I
can
do
that
in
like
the
next
half
an
hour?
Even
if,
if
we
are
ready
to
just
update
the
scope
and
open
an
access
request
to
reinstall
the.
C
App
that
was
I
was
saying
right.
I
think
that
someone
like
Reuben,
that
already
did
this
in
the
past,
could
could
has
enough
information
from
there
to
do
it.
If
we
are
gonna,
take
someone
else,
anyone
else
that
also
had
to
read
the
documentation
of
slack
apps
and
things
like
that.
It's
going
to
take
more
time,
but
as
Reuben
state
is
probably
five
minutes
to
altitude
scopes
with
our
documented.
C
A
B
Thanks
very
much
appreciate
that
an
excellent
SEO
like
so
we've
got
a
I
I
promise.
I'll
have
more
time
for
this
just
as
soon
as
the
release
management
sells
done.
So
what
I
want
to
add
on
is
we
will
have.
We
will
set
up
a
plan
for
the
first
day
that
we're
using
the
new
migrated
slack
alongside
reliability,
to
make
sure
all
of
the
like
incident
creation
jobs
are
working
and
that
we
can
roll
back
and
I
think
we're
a
little
nervous
about
we'll.
Do
a
test
run
on
cool,
okay,
ghost
off?
B
Nope,
okay,
I
wasn't
on
the
call
and
I'm
afraid
I
haven't
had
time
to
watch
the
recording,
but
I
hope
you
had
release
manager
metrics
on
Monday.
It's
cool!
Is
that
the
case
perfect,
okay,
great
stuff,
so
we
can
all
for
for
me
and
anyone
else
who
missed
it.
Go
and
watch
last
week's
recording
once
I
upload
it.
Oh
sorry,
Monday's
recording!
What's
the
upload
it
to
check
these
things,
is
there
anything
else
that
we
should
talk
about
on
this
recording.