►
From YouTube: Pods FY24 Target
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
A
Discussion
between
Camille
Berry
and
myself
about
making
pause
part
of
the
Year
leaves
for
FY
24
and
what
that
could
look
like.
A
So
as
a
as
I
understand
here
is.
They
are
actually.
A
An
MR
that
added
them
so
yearlys
are
informed
by
the
three-year
strategies
and
like
objectives
and
key
results.
Each
yearly
is
aligned
to
one
of
the
three
pillars
of
the
three-year
strategy.
There
should
be
at
least
one
yearly
for
each
strategic
pillar.
I.
Think
pods
aligns
well
with
gitlab
hosted
first,
you
know
that
is
I,
think
how
that
comes
in
and
they
really
sort
of
contain
the
priorities
for
the
fiscal
year
and
the
annual
plan
contains
more
of
a
budget
Focus.
A
A
One
idea
that
I
had
is
we
know
that
we
have
to
migrate
ourselves
onto
a
pod,
and
if
we
want
to
dog
food
pods
is
an
ambitious
yearly
goal
to
migrate.
At
least
some
parts
or
all
of
git
Labs
stuff
onto
part
2..
A
C
C
A
A
I
also
think
that
we
have
to
think
about
actually
deploying
a
pod
in
production,
which
I
think
depends
a
lot
on
scalability
and
reliability,
which
I
think
may
be
the
second
half
of
the
of
the
year,
because
I
think
that
is
a
big
boulder
to
move
and
I.
Think
then
the
question
becomes:
is
there
a?
A
Is
there
sort
of
a
state
where
we
can
already
create
new
customers
or
new
organizations
on
part
two,
while
we
haven't
figured
out
all
of
the
migration
pieces
for
existing
github.com
organizations,
and
then
the
question
is
to
me:
should
we
say
well
in
order
to
slow
down
the
growth
of
gitlab.com
having
the
ability
to
create
new
customers
or
new
organizations
on
part,
two
is
sort
of
the
first
year
and
then
the
ability
to
migrate
people
from
or
between
pods
or
from
pod.
One
two
part
two
is
the
year
after.
A
B
B
Maybe
we
just
have
like
roughly
working
application
with
some
major
things
being
broken
to
you,
so
like
it's
still
like
having
something
that
is
internal
and
basically
is
very
likely
that
only
quite
closer
to
the
end
of
the
year.
We're
gonna
be
focusing
on
getting
this
somehow
deployed,
but
the
tricky
part
is
like
all
of
the
production,
Readiness
reviews
and
like
our
interactions
in
the
databases
and
I'm
like
our.
B
B
We
have
mostly
working
basic
workflows
in
airports.
We
do
not
yet
have
figure
out
like
the
the
current
deployment
procedure,
like
the
migration
procedure
like
are
we
gonna
interact
with
others,
so
so
I'm
kind
of
thinking
like
that?
Maybe
the
way
how
to
describe
that
is
like
figure
out
like
what
is
like
the
most
important
workflows
that
we
want
to
deliver.
B
B
B
Maybe
you
can
go
to
project
issues,
create,
match,
requests
and
things
like
that,
but
I
I
would
not
say
that
it's
gonna
be
a
Productions
table
in
that
sense
that
you
could
like
locate,
data
and
assume
that
nothing
terrible
gonna
happen
with
that.
B
C
I
mean
if
we're
gonna
game
and
fire
what's
actually
written
here
right,
it
just
says
application
changes.
You
could
argue
that
that
doesn't
necessarily
mean
it's
out
there
in
production.
It's
it's,
maybe
ready
to
be
out
there
in
production,
but
it
doesn't
I,
don't
read
this
as
it
has
to
be
out
there
and
production
by
the
end
of
fy24.
B
I
mean
to
be
honest,
it
would
make
a
lot
of
sense
that
this
is
part
of
the
production,
but,
like
you
know,
found
that
we
are
sure
that
this
is
like
not
causing
a
harm
to
the
record
one
because
then,
like
we
kind
of
make
other
things
and
other
people
to
build
against
posts
and
like
I
I,
think
it's
pretty
essential,
like
that.
This
is
really
like
being
done
early,
given
how
many
things
are
gonna
be
broken,
so
I
mean
saving
is
still.
B
A
We
say
something
like
delivered
part
two
in
into
staging
and
ensure
the
application
is
POD
ready
for
the
top
five
workflows
or
something
like
this,
because
I
think
that
they're
two
they're
two
things
here
right.
It's
like
one
is
the
deployment
mechanisms
of
all
of
this
and
the
management
which
I
think
is
hard
and
that's
also
a
little
bit.
That
at
least
is
I.
A
Think
out
of
the
control
of
the
group
pods,
that's
maybe
more
on
infrastructure,
which
doesn't
mean
we
shouldn't
address
it,
and
the
other
thing
is
what
the
application
actually
can
do
and
I
think
I.
Think
that's
you.
Could
you
could
slice
it
like
this
or
you
could
actually
focus
on
some
kind
of
customer
facing
deliverable
which
I'd
prefer?
But
if
that
is
unrealistic
for
a
year,
then
it's
maybe
that's
not
the
way
to
go.
Yes,
but
I
I
mean
like
the
problem
with
the
customer
facing.
B
Stuff
is
like
how
much
of
application
broken
is
fine,
second
like
if
we
like,
like
give
it
to
the
customer,
we
kind
of
lose
flexibility
to
to
fix
any
major
problems
that
we
can
like
have
at
like
at
other
development,
because,
like
one
year
for
this
product
is
really
like
pretty
early
in
the
development
of
the
solution
and,
like
you
know,
I'm
gonna
cover
like
a
lot
of
workflows
in
this
time
period,
so
we
still
gonna
have
to
probably
need
to
make
a
very
structural
changes
after
that
time.
B
C
A
What
we,
what
about
and
then
just
throwing
things
out
here,
what
about
we
say
in
a
year?
We
are
ready
for
internal
dog
fooding,
as
in
we
can
start
to
think
about.
Like
have
git
lab
people
use
this
in
certain
contexts
when
we
need
to,
because
then
that
it
may
be
acceptable
to
still
have
a
few
things
broken,
but
at
least
we
we
have
it
ready
for
experimentation
in
a
way.
Yeah.
C
I
mean
like,
like
I've,
got
a
personal
account
on
it
on
gitlab
as
well
as
my
gitlab.
You
know
account
foreign.
We
could
be
ready
to
have
people,
you
know
willing.
Participants
move
over
to
well.
I
could
just
create
a
new
account
and
I.
Don't
have
a
lot
on
there
at
the
moment,
but
willing
participants
move
over
to
the
new
pod
understanding
that
stuff
could
go
wrong,
but
it's
just
personal
accounts.
So
it's
not
necessarily.
B
I
I
I,
don't
know
I
I,
don't
know
how
many
major
failures
we're
gonna
have
when
we
start
doing
user
workflow,
because
it's
probably
gonna
be
like
some
indicator.
How
heart
is
gonna
like
to
say
because,
like
I
mean
like
one
thing
is
like
having
future
broken,
that
it
gives
you
like
500
error,
but
another
thing
is
like
having
feature
broken
that
breaks
all
their
features,
that
you're
using
and
GitHub
is
like
very
interconnected
organism.
B
So
it's
basically
I'm
worried
that,
like
we
start
fixing
these
major
workflows,
but
someone
taught
us
a
very
specific
toggle
that
breaks
their
experience
because,
like
we
cannot
isolate
these
broken
features
enough
or
like
it's
really
hard
after
they
find
that
it's
just
better
to
fix
them.
So
I
am
I'm.
Basing
like
all
my
suggestions
right
now
that,
like
everything,
gonna,
be
broken,
it's
very
unknown.
We
are
right
now
it's
really
hard
like
to
to
isolate
things
that
are
broken
and
very
likely.
B
We
can
only
provide,
let's
say
a
list
of
the
specific
workflows
that
we
cannot
actually
validate
and
run
QA
to
ensure
that
they
are
stable.
But
but
then
you
see
like
how
much
kids
are
being
broken
is
fine
and
like
how
we
identify
that
things
being
broken.
Do
not
create
a
cascading
failure
in
the
system,
because
this
is
actually
something
bigger
of
the
of
the
issue.
B
It's
less
of
the
issue.
The
staging
is
big,
is
the
actual
application
on
github.com.
B
So
sorry,
I
I,
don't
have
completely
fine
I,
just
I,
just
yeah
well
really
hard
like,
because
we
didn't
actually
get
implement
something
in.
A
B
Maybe
so
maybe
like
going
through
for
another
dimensional
like
we
have
this
risk
identified.
Maybe
we
should
really
devise
our
plan
through
those
risks
that
like
like,
if
there
is
this
like
organizational
isolation,
it's
done.
If
the
risk
is
like
router,
it
must
be
working.
If
there
is
this,
like
some,
some
other
one,
because
this
is
what
is
working,
and
this
is
really
like.
Our
Target,
like
that.
B
We
focus
on
fading
fast
in
this
year
by
mitigating,
in
this
risk
to
to
not
be
a
risk
anymore
because,
like
I
think
like
the
the
challenge
is
like
if
at
some
point
we
find
this
I
know
this
risk
to
be
like
simply
impossible
to
move
over
like
then,
we
are
pretty
screwed
if
we
find
that,
like
two
years
from
now
so
I
I,
know,
there's
really
nice
to
like
to
focus
on
workflows.
Workers
are
useful
to
discover,
but
I,
think
for
me
I've.
B
The
most
important
are
the
risks
like
how
we
gonna
actually
like
another
reason,
is
like
how
we
gonna
deploy
and
interact
with
the
old
one
database.
B
If
we
have
the
answer
for
like
these
risks
in
this
year
and
something
working-
and
this
will
kind
of
give
us
a
confidence
in
English,
this
is
like
a
right
direction
and
it
actually
like
gives
you
like
a
very
values.
Let's
say
Solutions
right,
because
if
the
router
is
a
risk,
we're
gonna
have
router
working
if
database
decomposition
of
the
cluster
by
data
is
a
risk.
We're
gonna
work
towards
we're,
also
going
to
work
towards
that,
and.
C
We
can
get
ourselves
an
issue,
that's
a
risk
register,
get
everything
in
there
and
prioritize
it,
and
then
that
feeds
into
the
quarterly
and
Milestone
planning
and
then
and
then
we
start
talking
about
what
we
can
do,
which
is
kind
of
where
I
was
going
to
go
next.
We,
instead
of
talking
about
what
we
can't
do,
let's
talk
about
what
we
can
do
and
what
what
can
be
achieved
as
as
we
go
throughout
the
year,
then
we
can
I
mean
when,
when
these
things
appear
in
in
yearlys,
do
we
end
up
reporting?
C
C
As
it's
worded,
we
know
we
can't
do
this
right,
that's
that's
the
given!
So
if
we,
if
we
start
talking
about
them,
what
we
can
do
and
put
something
like
this
risk
registered
together,
which,
like
say,
feeds
into
the
planning
which
then
starts
us
talking
about
what
we
can
do
and
then
you
know,
if
anybody
wants
to
Define
this
against
this
this
yearly,
then
we
can
say
well
we're
we
look
like
we're
kind
of
X
percent.
C
You
know
here's
what
here's
all
the
risks,
here's
the
ones
that
have
completed
so
we're
X
percent
away
from
from
achieving
that
yearly
goal.
B
A
We
all
this
year
to
go,
but
I
think
the
question
is
what
is
a
an
ambitious
goal
in
the
end?
And
yes,
if
we
can
figure
out
what
we
can
do
in
the
end,
then
maybe
we
can
determine
from
this.
What
what
is
the
the
possible
end
state
but
I
think,
given
that
this
is
a
very
short
statement,
I
think
we
need
to
be
like
I'm
thinking
if
it's
like
you
know,
ship
a
prototype
of
pods
or
create
a
an
MVC
or
use
some
language.
C
C
If
that's
where
we
get
to,
then
then
great,
that's,
you
know,
that's
where
we
get
to
and
if
we
need
to
have
conversations
as
to
why
we're
not
accommodating
x
million
unique
monthly
users
active
users
yet
well,
we
can
start
saying
well,
like
I
say
we
got
70
of
the
way
there
right
or
whatever
it
actually
ends
up
being
backed
by
the
evidence
of
the
risks
and
how
many
of
them
were
completed
and
how
we
planned
them
through
the
year
and
then
we
can,
and
we
can
show
all
that
to
say
you
know
this
is
this
is
where
we
got
to.
A
I
I,
like
the
succinctness
of
it,
we
could
say,
deliver
part
two
into
staging
using
the
same
domain
and
I.
Think
then
you
know
that
is
what
that
will
take
so
much
individual
work,
but
I
think
it
Shields
also
gets.
We
have
to
roll
that
out
into
production
because
maybe
too
risky
for
the
first
year,
but
it
has
a
clear
sort
of
here-
is
the
thing
that
we
were
able
to
to
get
to
get
done.
B
B
So
a
lot
of
these
like
decisions,
we
can
still-
let's
say
sorry,
not
decisions,
I-
think
that's
like
the
idea
we
should
have
before,
but
like
a
lot
of
implementations
of
these
decisions,
we
can
actually
delay
to
the
later
moment,
but
this
is
also
I
think
why
we
are
focusing
on
the
workflow
to
quickly
identify
various
problems
and
the
way
to
uploads
them
and
basically
very
fast
either.
B
So
we
don't
have
to
fix
everything
on
that
moment,
but
I
think
we
need
to
have
like
a
practical
sense
of
what
cannot
be
broken
and
how.
A
A
B
A
Right
here,
no
I
think
that
may
also
then
trigger
a
discussion
with
infrastructure
and
reliability
and
scalability,
because
getting
something
onto
staging
is
not
easy.
A
A
Next,
look
thanks
for
the
quick
sync
yeah,
thanks
for
your
time,
it's
scary,
but
also
exciting,
bye-bye.