►
From YouTube: 2022-06-27 Delivery team weekly EMEA/AMER
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
B
Okay,
welcome
to
deliver
group
weekly.
This
is
27th
of
june
2022.,
so
we
have
some
announcements
about
friendly
family
days
upcoming,
the
one
in
july,
11th,
august,
29th
and
upcoming
time
of
of
some
people.
Actually,
so
it
looks
like
that
july
is
going
to
be
a
day
where
some
of
us
are
going
to
take
some
time
off.
B
We
also
have
the
announcement
that
karbic
made
last
week
about
the
fastboot
proposal,
so
please
go
there
and
add
your
availability
in
the
case
you
didn't,
and
it
will
be
very
helpful
also
if
you
want.
You
have
any
comments
to
add
that
to
that
paper.
A
C
I'm
going
to
say
I'm
afraid
I
don't
think
we'll
be
able
to
manage
that
as
tempting
as
it
is.
I
mean
we
certainly
can
consider
it,
but
I
think
probably
vlad
if
we
are
wrapping
up
your
internship
in
the
next
few
weeks
that
this
might
be
a
bit
of
a
a
tough
one.
So,
unfortunately
I
don't
think
we'll
be
able
to
manage
that.
C
D
A
The
second
question
was,
I
was
wondering
if
we
should
work
or
fine-tune
any
of
our
goals
or
deliverables
prior
to
trying
to
work
on
our
dates.
A
I'm
when
I
was
writing
this,
I
was
hesitant
to
try
to
figure
out
what
the
goals
and
our
deliverables
should
be,
because
I
don't
know
when,
if
assuming
it
gets
accepted,
I
don't
know
when
we'll
be
able
to
get
together,
and
my
one
of
my
fears
is
that
we'll
work
on
some
of
these
goals
or
deliverables
prior
to
fastboot,
which
kind
of
renders
this
useless
and
I'm
afraid,
if
that
happens,
you
know
it
wouldn't
get
accepted.
So
I
didn't
know
how
to
approach
that
when
I
was
writing
this
up.
B
I
guess
we
will
apply
to
something
to
prepare
in
advance,
because
it's
something
of
fast
boot
is
also
to
my
understanding.
Until
now
that
we
need
to
work
on
on
something
that
we
need
to
fastboot
some
activities,
so
I'm
not
sure
which
level
of
details
we
need
to
have
there
or
if
this
is
something
that
we
can
discuss
in
any
future
meeting
or
maybe,
if
amy
do
you
have
any
more
details,
so
you
participate.
C
No,
I
haven't
no,
no,
I
I'm
assuming,
yes,
is
probably
the
answer,
but
I'm
not
sure
to
be
honest,
so
I
think
for
for
now,
if
we
can
figure
out
everybody's
availability,
that
might
at
least
give
us
a
time,
a
rough
timeline
for
when
we're
aiming
for,
and
then
that
might
help
with
the
goals.
B
C
Yes,
so
a
big
milestone
here
is
the
changelog
has
now
officially
been
handed
over
to
the
release
stage
group.
So
I
just
merged
this
into
the
features
owned
by
group
earlier
today.
C
So
this
means
that
all
like
we
have,
I
think
we
just
have
two
two
or
three,
perhaps
change
log
issues
that
are
open
on
our
tracker,
which
I
will
move
to
theirs,
but
it
means
any
kind
of
future.
Requests
on
the
changelog
feature
would
go
to
release
stage
group
and
they
may
come
to
us
for
help,
but
we
wouldn't
be
the
primary
owners.
C
So
the
reason
I
put
it
in
discussion,
I
just
wanted
to
share
a
little
bit
of
context
around
this,
because
that,
in
itself
is,
is
not
really
a
huge
discussion
worthy
thing
but
building
the
changelog.
We
did
that
as
a
dog
fooding
item,
but
delivery
built
the
feature
we
designed
the
feature.
We
worked
with
product
managers
to
sort
of
agree
the
direction,
and
then
we
fully
implemented
it.
C
So
we
did
manage
to
build
something
it
is
in
use,
and
you
know
all
the
teams
have
adopted
it.
However,
it's
been
really
really
difficult
to
actually
hand.
This
over
and
get
ownership
and
and
move
this
forward.
So
I
wanted
to
share
this
as
a
kind
of
this
probably
isn't
the
best
way
to
dog
food
things
in
the
future,
and
I
think
we
have
a
couple
of
other
approaches
for
dog
fooding
that
have
shown
to
work
better.
So
one
is
the
opening
issue.
C
So
when
it's
a
feature
similar
to
changelog,
where
it's
sort
of
we
are
the
primary
driver
of
a
feature
opening
an
issue
in
the
team
backlog,
which
I
have
a
link
here
to
an
example
of
a
bunch
of
things
that
ruben
actually
opened,
which
have
so
far
been
they
take
a
little
while
to
schedule
but
have
been
very
uncontroversial
or
the
other
way
is.
If
we
want
to
move
things
a
bit
faster
is
actually
we
pair
up
with
a
stage
group.
C
So
we
get
an
issue
in
their
backlog
when
they
choose
to
prioritize
it,
we
can
ask
them
to
prioritize
it.
We
then
pair
with
them,
but
either
way
sort
of
working
directly
out
of
a
stage
groups
issue
tracker
versus
change
log,
where
we
took
full
ownership
of
everything
and
then
later
they
had
to
hand
it
over
to
a
team.
C
I
think
we
just
need
to
be
a
clear
up
front
on
what
we
want
to
do
so
for
this
one,
for
example,
for
the
changelog
we,
this
was
always
our
plan,
so
we
always
intended
to
build
inside
the
product
and
then
hand
it
over.
But
what
we
didn't
do
was
get
a
team
lined
up
to
be
the
owners
of
the
code
before
we
wrote
it.
So
we
were
like
they
roughly
agree
on
the
idea.
We
will
do
all
of
the
coding
and
then
later
hand
it
to
you
and
that's
been
really
tough.
C
So
I
think
what
we'd
do
in
this
case
would
be
to
go.
Here's
an
idea
we
want.
We
would
find
the
team
from
the
very
very
beginning,
and
we
could
then
just
collaborate
directly
with
that
team,
because,
even
even
in
terms
of
the
product
managers
we
worked
with,
we
didn't
necessarily
have
the
product
manager.
In
fact,
we
definitely
didn't,
but
I
don't
know
if
we
would
have
done.
Even
if
teams
had
changed,
we
didn't
have
the
product
manager
at
the
beginning
who
ultimately
became
the
owner.
C
So
later
it
was
kind
of
like
a
whole
team
got
ambushed
a
bit
with
us
saying,
hey
great
news:
here's
a
feature
we've
built
for
you.
It
works.
We
have
a
way
it's
a
kind
of
community
contribution
model,
but
it's
just
meant
that
it's
been
a
lot
slower.
So,
like
we've,
been
holding
ownership
of
changelog
since
say
last
march,
as
the
maintainers.
Until
today,
but
yeah
we
haven't
really
had
capacity
to
do
maintenance
if
we'd
have
needed
to
so
it's
not
a
great
a
great
model.
C
So
I
think
in
the
future,
if
we're
building
things
into
the
product,
with
the
intention
that
they
are
going
to
be
owned
by
a
stage
group,
we
should
do
one
of
the
other
two
approaches.
Instead.
C
In
the
product,
well
I
mean
it
depends
one
of
the
ideas
that
is
kicking
off.
Hopefully
quite
soon
came
out.
We
talked
about
a
little
bit
in
our
last
ama,
so
we're
hoping
to
start
working
with
release
stage
group
quite
soon
on
figuring
out
what
some
kind
of
dashboard
or
entry
point
into
the
whole
thing
could
be.
So
that's
a
really
good.
I
think
it's
kind
of
change
log
like
where
it's
quite
a
big
thing
I
could
see.
C
I
was
ending
up
doing
a
lot
of
the
implementation,
but
the
actual
discovery
work
will
be
fully
owned
by
release
stage
group.
So
that's
certainly
one
that's
going
on,
but
I
think
there
are
quite
a
lot
of
little
things
in
in
flight
around
like
cluster
configuration
and
that's
probably
the
other
real
big
possibility
or
environment
locking.
I
know
graham's
got
ideas
there,
so
there
are
quite
a
lot
of
pieces,
but
there's
not
that
many
where
we
go.
Here's
an
entire
new
feature
that
we
would
like
to
see
in
existence.
C
C
C
C
I
see
so
okay
great,
so
what
this
is
great
content
for
all
of
you
actually,
so
what
we're
hoping
for
is
to
get
to
a
place
where
everybody
in
the
team
is
able
to
walk
through
these
dashboards
in
the
way
alessia
has
been
doing
for
the
last
few
months.
So
what
we
should
do
next
monday
myra
is,
would
you
mind
scheduling
some
time
with
alessio
and
ahmad
next
monday
before
delivery
weekly?
C
So
the
three
of
you
can
go
through
the
dashboards,
because
one
thing
alessia-
and
I
were
talking
about-
is
kind
of-
why
I'm
glad
you
asked
the
question
is:
how
much
has
the
knowledge
shared
across
the
team,
and
I
think
you've
answered
the
question
which
is
it
hasn't?
So
this
will
be
a
good
one,
maybe
before
next
monday's
meeting.
If
you
sit
down
with
alessio
and
ahmad,
then
three
of
you
have
the
knowledge
and
then
you
can
be
handing
it
on
to
the
future
release
managers:
okay,
great.