►
From YouTube: 2021-12-15 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).
A
B
A
And
just
wait
a
few
seconds
in
case
reuben
and
graham,
are
on
their
way.
A
Okay,
I'll
get
started
so
welcome
everyone.
This
will
be
our
final
apac
emea,
timed
delivery
weekly
for
this
year,
there's
quite
a
few
announcements
in
here.
Some
of
them
you
three
will
have
already
seen,
but
just
a
couple.
I've
added
in
on
one
c
and
d,
I
think,
are
the
two
new
ones.
A
So,
on
the
discussion
point
I
wanted
to
do
a
little
update
on
hiring,
so
we
are
still
looking
for
a
new
sre
to
join
us.
We
ideally
will
find
someone
who's
an
intermediate
level
and
based
in
the
americas
time
zone.
So
if
you
do
know
anyone
at
all
or
if
you
know
of
anyone
who
maybe
is
like
a
possible
future
hire,
please
do
refer
them,
so
we
can
consider
them
also
we're
actually
hiring
a
lot
of
people
across
platforms.
A
So
scalability
have
a
lot
of
back
end
engineer
positions
plus
sre
positions,
open
and
marion
is
also
hiring,
I
believe,
sre
and
back
end
as
well.
So
if
you
know
of
anyone
who
you
think
would
be
a
good
fit
at
delivery,
sorry
in
gitlab
please
go
ahead
and
refer
them
and
then
to
help
us
across
interviewing.
A
For
this
role,
but
also
kind
of
in
future
roles,
I'm
looking
to
have
everyone
trained
up
to
interview,
so
I
think
all
of
you,
except
for
ahmad,
are
currently
trained.
Already.
I
quite
like
I
haven't,
opened
up
your
issues
just
yet
we'll
wait
until
you've
gone
through
your
release,
management
training
following
that
we'll
do
this
so
you're,
not
learning,
absolutely
everything
all
in
one
go,
but
it
does
mean
that,
for
those
of
you
who
are
interviewing,
you
will
have
some
shadows.
So
skybeck
is
in
training.
A
Myra
is
about
to
start
her
training
and
graham,
is
also
about
to
start
training
as
well,
so
over
the
next
few
months,
as
we
do
run
interviews
we'll
we'll
probably
try
and
always
have
a
shadow.
So
we
can
actually
like
get
everyone
comfortable
with
this
and
then
actually
before
I
go
on,
are
there
any
questions
around
this
current
role
and
hiring
or
anything
I've
said
so
far.
C
I
have
a
question
about
an
announcement.
Oh
yeah,
please
go
ahead,
so
the
currency
conversion
rates-
I
never
understood
those.
So
I
I
have
a
specific
question.
So
maybe
this
is
not
the
right
place,
but
maybe
someone
knows
so.
Those
currency
conversion
are
only
for
the
salary
or
also
for
let's
say
the
holiday
budget
for
today
is
all
day
budget
is
in
dollars.
So
when
I
was
contractor,
I
used
to
refer
to
that
thing
to
to
expense
them
in
in
euro.
C
I
do
remember
having
some
argue
last
year.
I
think
when
I
was
expensing
something
and
they
were
just
complaining
about
the
the
conversion
rate-
and
I
say
this
is
what
is
in
the
end
book.
They
say
no,
you
should
look
at
the
daily
conversion
rate,
but
at
that
point
in
time
the
conversion
rate
was
frozen
for
a
long
time.
So
is
this
something
that
we
should
use
when
we
expense,
let's
say
today
holiday
budget,
or
we
do
with
the
daily
conversion
rate
for
usd
to
the
euro.
A
So,
as
far
as
I
understand
it,
this
with
this
announcement
was
specifically
around
salaries
and
it
was
specifically
around
so
some
people
get
paid
in
usd
and
then
there's
a
current
version
to
to
switch
it
into
their
local
currency.
So
this
announcement
was
specifically
about
that
in
terms
of
expenses,
I'm
actually
not
sure
like.
A
As
far
as
I
am
aware,
most
of
that
is
handled
automatically,
certainly
when
I've
had
different
currencies,
I've
just
thrown
them
in
and
they've
kind
of
figured
themselves
out,
but
I
would
say
if
there
was
something
in
the
handbook
use
that,
like,
I
think
in
your
case,
alessio
like
in
the
end,
the
handbook
was
honored
right.
A
So
I
would
say
always
if
there
is
a
policy,
a
process
in
there
with
an
amount,
then
use
that
one
and
if
ever
you
know
if
anyone's
challenges
you
on
that
one,
we
can
refer
back
to
the
handbook
and
people
can
update
that
so
follow
whatever
is
in
the
handbook.
A
Awesome
and
ruby
nice
for
your
comment,
hang
on
so
ruben.
Let's
get
you
starting
your
training
in
that
case,
because
there's
a
little
bit
of
like
pre-work
that
you
can
do
and
like
training
courses
that
can
take
a
little
bit
of
time.
But
then
the
bit
that
really
takes
the
longest
is
shadowing
because
it
relies
on
us
kind
of
having
the
right
interviews
scheduled
in
at
a
time
that
works
for
you
and
some
people
choose
to
go
through.
It's
like
recommended.
You
shadow,
two
interviews.
A
Some
people
like
to
do
a
few
more
than
that,
so
that
they
can
actually
see
different
interview
styles
and
get
comfortable,
so
there's
no
harm
in
starting
to
getting
to
the
shadowing
point
as
soon
as
you
can
so
that
you
can
maximize
that
time.
A
For
those
of
you,
I
hope
you
all
know,
but
for
those
who
don't
know,
alessia
is
going
off
on
parental
leave
next
year
in
february,
and
if
we
are
interviewing
during
that
time,
which
we
may
be,
then
we
are
a
down
one
person.
So,
that's
why
I'm
also
quite
keen
that
we
have
everyone
comfortable
and
ready
to
be
able
to
lead
interviews
from
february
if
we
need
to.
A
So
I'll
open
you
an
issue
for
that
ruben,
so
an
assignment
you,
so
you
can
go
through
the
first
few
steps.
B
C
A
Yeah
yeah,
so
we
are,
we
do
now
sometimes
get
checked
on
whether
we
have
completed
our
training,
so
it's
good
to
get
it
completed.
Get
it
to
the
point
where
you
can
just
close
it
out,
be
not
worry
about
that
and
get
get
into
actual
interviewing.
A
Awesome
and
then
the
other
thing
around
hiring
I
wanted
to
just
mention
is
that
we
are
following
this
new
sre
hire.
We
are
pretty
much
at
maximum
team
size
that
will
take
us
to
nine
and
I
think,
there's
a
couple
of
sort
of
significant
problems
that
come
about
at
nine.
One
of
them
is
just
the
the
the
sort
of
breadth
of
the
domain
that
we're
working
across
a
number
of
different
projects.
A
We
have
in
progress
a
number
of
different,
like
you
know,
it's
already
getting
a
little
bit
painful
when
we
ping
like
delivery
on
an
issue.
You
perhaps
don't
necessarily
need
input
from
the
entire
team,
you're,
probably
asking
for
a
smaller
subset
of
people
at
that
stage.
So
we'll
start
to
figure
out
how
we
can
split
around
that.
A
It
also
is
quite
hard
work
to
manage
nine
people,
so
we'll
be
looking
to
split
the
team,
hopefully
hire
another
manager
and
actually
see
if
we
can
actually
focus
most
likely.
We
haven't
figured
out
the
details,
but
most
likely
we'll
split
down
the
dot-com
and
self-managed
domain,
but
we
haven't
quite
figured
out.
It
depends
if
we
get
a
headcount,
we
can
figure
out
details
on
how
to
go
ahead
and
split,
but
just
so
you
know
that
that
that
is
likely
to
happen
next
year.
B
I
just
wanted
to
ask
about
this
issue:
is
the
proposal
for
moving
generation
of
the
qa
issue
to
its
own
job,
but
in
deployer
itself?
A
Maybe
I
think
for
this
one,
it
probably
is
whatever's
easiest
like.
Ideally,
it
would
be
in
release
tools,
but
it's
not
the
end
of
the
world
if
it
is
in
deployer,
because
it
still
moves
us
closer
to
where
we
want
to
get
to.
So
I
think
if
there
is
a.
B
B
Because
from
what
I
understood,
even
now,
that
myra
has
moved
the
qa
jobs
to
release
tools.
The
original
qa
jobs
in
deployers
still
exist,
because
if
you
start
a
deployment
via
chat,
ops
commands
it
triggers
it
in
deployer.
B
C
C
Now
the
probably
the
triggers
can
be
can
be
removed
already
has
been
removed.
I
don't
know
right
right
right
now,
but
the
thing
is,
then
the
problem
is
the
how
we
move
the
the
qa
thing.
So
I
think
this
is
what
she's
talking
about.
Maybe
she
wants
to
get
the
qa
generation
out
of
it
and
then
figure
out
if
we
can
move
the
the
artifacts
that
gives
the
the
url
or
if
there
is
a
better
way
to
get
that
url,
not
relying
on
artifacts.
B
B
A
So
I
think
to
to
move
further
with
that.
One
then
ruben
that
it's
probably
a
what's
the
minimum
you
need
to
have
done
in
order
to
be
able
to
do
that
so
having
those
blocking
jobs
is,
is
the
the
concerning
bit
because
it
gives
us
a
point
of
failure.
So
if
there's
something
which
we
can
do
that
helps
us
get
to
that,
then
that's
that's
a
good
thing
to
do.
B
B
C
C
To
do
to
get
the
list
of
deployments,
so
if
we're
going
down
this
route,
I
suggest
that
we
either
split
the
job
in
two
so
that
we
have
one
set
of
tracking
information
that
goes
to
gitlab.com,
so
that
are
useful
for
engineers
that
can
fail
and
another
one
that
is
targeting
hopes
with
the
things
that
we
rely
on.
That
can't
fail.
So
if
it
fails
you
just
it
stopped
reruns
I
mean
we
have
to
figure
out.
B
C
Yeah
I
mean
we
can
discuss
this,
so,
let's
we,
I
think
we
just
need
to
list
what
this
thing
is
doing
and
say
what
can
fail
and
what
can't
fail
and
when
we
have
all
the
interaction
that
this
tracking
job
is
doing.
We
can
say
it
makes
sense
to
split
here,
or
it
makes
sense
to
move
those
things
elsewhere,
and
then
we
made
a
decision.