►
From YouTube: 2022-09-14 Pods Group Sync - AMER/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
There
we
go
okay,
so,
just
briefly
again,
I
just
yeah.
I
want
to
make
sure
that
we
are
doing
the
right
things
at
the
earliest
opportunity
to
make
sure
you
know
we're
not
stepping
over
people
as
I've
put
in
there,
and
people
are
not
stepping
over
us
and
the
the
epic
that
I've
sorry.
The
issue
that
I've
put
in
there
is
is
one
example
of
two
or
three
things.
B
I've
heard
in
in
conversation
in
other
mediums
where
it's
I
don't
have
enough
context,
but
where
I
see
that
actually
we
may
be
starting
to
trip
over
people,
so
just
wanted
to
have
a
discussion
about
that.
C
Yeah,
thank
you.
I
think
that
it's
a
great
call
out
my
from
my
perspective
is
I'm
not
super
worried
at
the
moment,
given
where
we
are
right.
I
think
we
are
we're
still
learning
a
lot.
At
least
I
am.
I
think
that
the
the
time
when
this
becomes
maybe
a
little
bit
more
pressing
is
when
we
sort
of
have
an
our
own
sort
of
opinionated
proposal
and
maybe
a
poc
and
say
like
this
is
what
we
think.
C
Pods
look
like
for
those
reasons,
and
I
think
at
that
point
we
will
need
to
make
some
choices
right,
because
there
will
be
certain
things
that
we
say
like
are
going
to
like
actually
work
and
some
that
are
not.
I
think
at
that
point
it
will
take
sort
of
product
and
leadership
by
in
on
multiple
levels,
and
I
think
that
alignment
would
probably
take
some
time
right
to
be
able
to
say
like
yes,
this
is
something
that
we
want
to
do.
You
know
just
putting
it
out
there.
C
My
preference
would
be
to
start
with
the
proposal
when
we
go
out
and
say
like
this
is
this
is
our
thinking
right,
because
I
think
that
will
save
us
a
lot
of
confusion,
but
maybe
these
these
conversations
that
you're
seeing
are
also
triggered
by
people
just
not
really
like
trying
to
figure
it
out.
Essentially
right-
and
I
think
that's
that's
okay,
I
don't
feel
like
we
have
to
step
onto
people's
toes,
but
I
think
it's
a
concern.
A
B
Okay,
I
I
do
have
a
manager's
call
after
this
as
well.
I
might
just
start
trickling
the
feed
into
people's
ears
and
let
them
know
that
we're
that
we're
starting
to
get
there
so
it's
it
starts
to
be
consideration
for
people,
and
they
know
that
something's
coming.
C
C
Is
key
right?
I
I
don't
think
we
need
to
hide
anything,
but
I'm
I'm
kind
of
telling
people
like
look.
This
is
what
we
are
starting
to
think
about,
and
then
some
of
them
get
more
nervous
than
others.
D
Definitely
agree
the
one.
The
main
thing
I
think
is
important
is
to
always
be
highlighting
generally
that
we're
a
long
way
out.
Even
when
we
have
a
plan
like
this
is
a
fairly
long
running
project
and
in
particular
for
teams
that
are
focused
on
being
able
to
execute
things
in
the
near
term.
We
we
do
not
want
them
to
feel
like
they
should
wait
for
pods
to
to
do
something.
D
We
at
a
certain
point.
We
will
come
up
with
specific
tooling
that
tells
people
when
they're
doing
something
they're
not
allowed
to
do
so.
Omar
has
kind
of
already
been
thinking
about
that
and
good
examples
of
what
that'll
look
like,
but
you
know
much
like
cid
composition
at
a
certain
point,
we'll
add
things
to
the
code
base
that
tells
somebody
they
physically
cannot
do
things,
and
the
communication
will
be
very
clear
at
a
point
in
time.
A
No,
but
I
imagine
that
if
we
are
not
changing
any
if
you
are
not
adding
or
removing
features
like
organizations
or
anything,
that's
just
an
example
like
and
that's
the
ideal
case
that
I
refer
to.
So
whatever
teams
are
building,
we
are
just
taking
it
and
replicating
it
to
pods.
C
Probably
not,
I
think
I
think
I
mean
this
is
probably
the
the
biggest
thing
that
I
I'm
seeing
with.
You
know
like
in
some
of
those
discussions
that
people
have
ideas.
A
C
How
some
certain
things
are
going
to
work
and
I
think
we
we're
starting,
I
think
at
some
point
with
pods.
We
may
you
know,
make
a
make.
A
statement
say
like
these
are
the
the
features
that
can
work
within
a
certain
boundary
and
if
you
pass
that
we're
going
to
complete
that,
for
example,
at
least
in
the
first
iteration,
so
it
needs
to
work
differently
and
we
have
ideas
and
how
that
works.
And
I
think
when
we
reach
that
point
and
we
have
confidence
that
that
is
a
good
idea.
D
C
Leadership
and
product
buy-in
to
say
like
yes,
this
is
actually
the
direction
that
we
want
to
take
and
there's
more
to
it
than
you
know
us
making
making
that
decision,
and
I
think
that's
something
where
I'm
still
a
little
bit
unsure,
sometimes
just
reading
about,
for
example,
workspaces
and
how
they're
going
to
be
represented
to
users
and
what
they
are
and
all
of
that
right.
Then
that
becomes
a
lot
more
relevant
at
that
point,
but
we're
not
quite
there
yet
we'll
get
there.
A
A
B
Yeah,
you
know,
that's
fine.
If
it's,
I
think,
just
my
guiding
principle
will
be
say
the
right
things
at
the
right
time,
but
as
early
as
possible.
C
Can't
argue
with
that,
I
think
cool
the
next
one
is
for
me:
I've
done
that
today,
it's
not
quite
ready
to
review,
because
I
have
to
spend
a
little
bit
more
time,
but
I've
started
to
update
some
of
the
language
for
our
sort
of
first
iteration,
based
on
some
of
the
discussion
that
we
had
in
other
merge
requests
and
yeah.
Just
for
you
to
read.
You
can
of
course
always
comment,
but
I
still
have
to
think
a
little
bit
about
it.
I
I
think,
there's
something.
C
That's
quite
interesting
that
was
discussed
by
dylan.
You
know
with
sort
of
the
notion
of
a
default
pod
for
users,
and
maybe
we
can
make
our
life
a
little
bit
easier
by
at
least
initially
sort
of
assuming
that
when
users
create
workspaces,
they
default
to
the
same
pod
right
and
use
this
to
have
a
strong
affinity
to
a
specific
part
of
the
over
others,
and
that
may
help
us
out
initially.
C
Yeah
we'd
have
to
see
I'm
also
starting
to
come
to
the,
and
this
is
maybe
a
little
bit
rough,
yet
maybe
that
for
the
first
iteration
we
should
definitely
aim
to
aggregate
with
users
centric
data,
so
things
that
are
like
belong
to
users
and
they
care
about
like
merge
requests
and
to
do's
and
these
kinds
of
things,
but
we
may
not
actually-
or
we
may
restrict
features
that
cross
workspace
boundaries
in
other
ways
like
sharing
groups
or
associating
runners
or
these
kinds
of
things.
So
a
dashboard.
C
You
know
that
rolls
up
some
of
the
information
for
user,
maybe
something
that
we
want
to
aggregate
and
other
things,
maybe
not,
but
I
don't.
I
don't
know
if
that's
sensible
yet-
and
I've
also
moved
away
from
this
notion
that
an
organization
or
user
can
only
create
a
single
workspace
that
just
doesn't
seem
to
align
with
reality.
C
Yeah
end
users
should
be
global.
I
think
that's
something
I
think
we're
settling
in
on
as
well
right,
so
we're
not
going
to
have
separate
users
for
separate
pods
in
different
regions.
I
think
that's
an
assumption
that
I
think
I'm
comfortable
making
at
the
moment
saying
like
we'll.
Have
global
users.
A
But
if
that's
question
that
should
be
there
like
default,
but
for
user
or
not-
maybe
that's
like-
maybe
that's
a
technical
solution,
something
that
might
make
our
job
easier.
But
I
I
think
that
if
we
expose
the
word
put
to
the
user
in
the
interface
one
way
or
another,
it's
gonna
be
like
super
confusing
for
them,
because
we
are,
I
think
the
ui
is
already
confusing
and
we
might
be
adding
workspaces
which
might
confuse
them
or
it
might
simplify
the
ui
for
them.
I,
like
the
video
that
you
posted
it
was.
A
It
was
done
earlier
in
february.
I
think,
with
the
navigation
for
workspaces,
yes,
but
still
like.
If
we
expose
that
for
the
users,
then
it
might
be
no.
C
C
This
is
what
the
workspace
is
and
how
it
behaves,
and
those
are
things
that
are
allowed
between
workspaces
or
not,
and-
and
this
is
I
think
that
is
already
difficult
enough,
but
I
think
that
maybe
for
us
to
move
forward-
and
I
think
this
is
a
technical
detail
right-
we
have
to
maybe
work
with
the
default
part
initially
or
something,
but
that's
a
technical
detail,
like
maybe
I'll,
make
it
clear
as
like.
I
don't
want
users
to
ever
know
what
part
they're
on
by
having
to
care.
D
The
concept
I
added
to
the
technical
proposal
is
a
default
workspace
presented
to
the
user
and
effectively
translated
in
the
back
end
as
a
default
pod,
so
the
user
can
only
set
a
default
workspace
and,
in
the
back
end,
we'll
treat
that
as
a
default
pod,
which
is
the
place
that
they
land
when
we
have
no
other
clues
as
to
which
hard
to
present
them
with
that
present
their
data
from,
and
on
top
of
that,
it
would
imply
we
we
show
them
in
the
user
interface
for
certain
features.
D
We
show
them,
we
are
own.
You
know
a
notification,
we're
only
presenting
you
data
from
your
default
workspace,
so
you
know
when
they
go
to
slash
an
index
page
or
something
we
just
have
a
banner
up.
There
saying
we
are
only
presenting
you
with
data
from
your
default
workspace
so
that
they
understand
why
that
data
changed
when
they
navigated
somewhere
else
to
look
at
something
else,
or
why
there's
you
know
a
to-do
missing
on
that
page
or
a
merge
request
missing
on
that
page
or
something
that's
the
conceptual
idea.
D
Our
proposal
has
no
no
concrete
idea
about
how
we
would
implement
aggregation
yet
either.
So
you
know
we
talk
about
that
being
maybe
necessary
in
a
first
iteration
or
a
later
iteration,
but
so
far
in
my
discussions
and
just
even
thinking
about
it,
I
have
no
idea
about
how
we
would
implement
aggregation.
That's
why?
If
we
have
no
idea
how
to
implement
aggregation,
why
would
we
need
to
come
up
with
a
solution?
We
could
ship
that
that
required,
no
aggregation.
C
I
think
I
think
if
we
wanted
to
ship
an
initial
iteration
without
any
aggregation,
then
you're.
Sorry,
my
daughter
is
having
a
sit.
C
C
My
slight
worry
at
the
moment
is
that
you
know
people
will
want
to
add
something
on
top
of
multiple
workspaces,
eventually
right,
like
your
dashboard
and
activity
across
all
workspaces,
similar
to
how
it
is
right
now,
and
then
we
will
sooner
or
later
have
to
figure
that
out,
but
I
think
at
least
for
user
data
and
user
dashboards.
I
think
that
initially
makes
sense,
because
they
would
be
most
impacted
by
that,
but
that's.
C
Question
when
I'm
trying
to
like
figure
out
how
they
actually
want
to
present
these
workspaces
to
users,
because
if
you
imagine
in
a
future
where
a
workspace
is
very
prominent,
you
know
to
a
user
as
something
that
they
understand
is
sort
of
the
universe
that
they
care
about.
And
you
make
the
switch
to
a
workspace
very
explicit
right.
D
Yeah
I
had
that
discussion
a
little
bit
with,
I
think
tom,
maybe
camille,
but
there's
like
lots
of
these
features
in
the
gcp
ui
and
whenever
you're
navigating
google
cloud
in
the
google
cloud
console
you're
just
always
quite
clearly
aware
of
the
fact
that
you're
in
the
context
of
a
project
and
sometimes
you're
in
the
context
of
a
of
a
region,
and
just
you
know
that
that's
just
something
you
kind
of
get
used
to
in
that
interface,
and
it
is
annoying
and
quirky
at
times,
because,
like
I'm,
not
seeing
something
that
I
know
I
have
access
to,
but
you
do
just
go
okay.
D
Well,
I
need
to
actually
change
my
project
scope
to
actually
see
something
else.
So
I
could
imagine
the
same
thing
eventually
being
true
for
for
gitlab,
and
I
could
imagine
that
that
that
the
way
the
decisions
they've
made
in
their
ui
to
never
really
aggregate
things
for
the
user
or
have
very
limited,
aggregated
views
for
the
user
and
mostly
scope
views
probably
allows
them
to
implement
sharding
on
the
back
end
in
it
gives
them
a
lot
of
options
for
implementing
sharing.
C
Like
that's
my
at
least
my
personal
opinion
right
now,
I
I
feel
that,
given
how
complex
gitlab
is
sort
of
giving
clearer
boundaries
to
users
so
that
they
understand
their
own
world
and
context
is
maybe
even
something
that's
advantageous,
and
it
would
allow
us
nicely
to
keep
things
quite
separate.
C
That
should
also
be
separate
right
like
I
would,
for
example,
imagine
if
you
have
a
region's
use
case
and
the
the
reason
why
people
want
a
second
reason
is
because
they
don't
want
data
to
leave
that
region
for
data
residency,
and
your
users
understand
that
as
well.
That
this
is
your
uk
stuff,
then
they'd,
be,
I
imagine,
very
okay
with
the
fact
that
they
navigate
to
a
different
workspace.
D
Yeah
that
makes
sense.
I
just
wanted
to
quickly
make
concrete
what
I
just
described
before
in
gcp,
because
it's
useful.
This
is
what
happens
when
I
go
to
gcp,
I'm
on
the
getting
started
page.
I've
got
up
here,
no
project
selected,
but
I'm
like
okay.
I
want
to
look
at
my
vm,
so
I
click
on
google
compute
engine
and
this
is
where
things
get
a
little
bit
quirky
but
explicit.
It
says
gitlab
qa
resources
up
here.
D
I
never
asked
for
that
project
and
I
have
access
to
lots
of
these
different
projects
here,
but
it
selected
one
for
me
and
I'm
you
know
I
might
get
confused.
Why,
when
I
search
I'm
not
finding
the
vm
that
I
thought
I
had
access
to,
etc,
etc,
but
that's
ultimately
because
I'm
scoped
here
so
that's
the
kind
of
quirkiness
we
might
expect
to
come
to
gitlab,
eventually
where
it's
like.
D
I
don't
know
if,
like
I
have
notifications
up
here,
I
don't
know
if
these
notifications
are
scoped
to
this
this
thing,
but
that
might
also
be
the
case,
and
I've
had
to
go
to
cloud
shell.
This
this
button
might
behave
differently
depending
on
what
project
I
have
selected,
even
though,
like
I
never
navigated
to
a
project,
I
never
you
know.
I
thought
I'm
sort
of
on
an
index
page
here,
but
it's
not
an
index
page
of
everything.
D
D
C
I
think
the
the.
C
True
for
google,
the
google
suite
as
well
at
least
to
a
certain
extent
where
that
is
more
associated
to
different
account
right
than
a
different
workspace.
C
C
I
I
personally
think
that
is
that's,
maybe
how
it's
going
to
go
and
or
would
go
in
the
pod
world,
because
that
would
make
it
pretty
clear.
You
know
what
the
sharding
key
is,
which
is
our
workspace
that
I
I
think-
and
this
is
something
at
least
listening
to
some
of
the
videos
recorded
with
sid
from
I
know
like
a
while
ago,
but
the
intent
was
also
for
a
workspace
to
be
very
similar
in
experience
to
what
you
would
see
on
a
self-managed
instance
with
the
capabilities
that
are
with
it.
C
Then
you
know
whatever
happens
in
there
is
fine
right,
but
you
wouldn't
necessarily
expect
that
everything
can
be
shared
outside
your
workspace
all
the
time,
and
I
think
then
you
can
make
it
very
explicit
what
the
flows
are
to
make
that
happen
right
like
forking,
for
example,
right
or
maybe
you
want
to
aggregate
audit
logs
or
I
don't
know
some
things
that's
to
be
figured
out.
I
I
I
think.
C
Maybe
where,
if
we
can
come,
come
in
right
and
kind
of
show
people
a
little
bit
how
that
would
look
like
that
would
be
a
strong
proposal
and
then
people
would
probably
be
like.
Oh
man,
you
know.
But
what
about
this?
What
about
that?
I
think
dylan
pointed
out
at
some
point
that
that
needs
a
strong
sort
of
direction.
Product
direction
as
well,
because
that's
a
big,
a
big
thing
right
for
kit
lab.
C
C
C
D
D
Yes,
functionality
wise,
like
I
am
kind
of
it,
doesn't
seem
to
make
too
much
of
a
difference,
because
practically
all
the
functionality
that
exists
on
groups
today,
it
will
also
exist
on
workspaces
and
it
will
still
exist
on
groups
and
they're
gonna,
add
more
functionality
to
groups,
but
the
the
workspace
will
still
be
the
top
level
name
space
or
effectively
this
first
component
in
the
url.
D
What
becomes
different
in
the
gcp
interface
is
like
right
now,
I'm
looking
at
gitlab
or
gitlab,
but
I
I
have
all
this
top
level
bar
context,
which
makes
me
feel
like
this
bar
is
out
of
scope
of
of
where
I
am
in
the
breadcrumbs
here
right.
So
this
is
like
ux,
the
git
label
git
lab.
This
is
my
breadcrumb
of
the
context
of
everything
below
the
purple
bar
at
the
top
of
my
page,
but
everything
above
the
purple
bar.
I
treat
this
as
my
global
context.
D
I
have
access
to
like
projects
that
are
in
a
completely
different
context
and
yeah
the
difference
comparing
that
to
gcp
is
that
the
breadcrumb
context,
the
highest
level
breadcrumb
context
is
up
here
in
the
in
the
blue
bar,
and
I
assume
everything
else
is
scoped
to
that.
So,
if
I
click
on
here
this
this
bar
this
I
mean
this
ui
is
so
similar
to
ours,
but
this
is
only
scoped
to
gitlab
qi
resources,
comparing
that
to
gitlab,
where
this
is
scoped
to
me
as
a
user
everything
I
have
access
to.
Yes,.
C
C
That
will
need
to
change
in
in
a
pod
world,
where
you
know
the
workspace
context
matters
more,
because
things
are
available
within
the
workspace,
but
not
as
much
across
the
workspace.
I
think
that
that
would
be
a
big
main
domain
sort
of
you
exchange,
which
you
know
yeah.
I
I'm
kind
of
appealed
by
that
or
it
appeals
to
me.
I
feel
that
it's
cleaner
than
how
it
is
right
now,
at
least
to
me,
but
yeah.
D
We
have
this
like
problem,
but
this
is
a
like
just
a
small
limitation,
that's
implemented
in
gitlab
code,
where
we
say
that
you
can't
put
issues
into
epics
that
belong
in
a
different
top-level
group,
but
we
do
make
heavy
use
of
linked
issues
and
group
group
sharing
and
and
and
and
linking
and
markdown
across
those
get
labcom
and
gitlab,
and
all
of
these
features
actually
work
today
for
us.
So
you
can
link
to
issues
that
are
in
two
different
top-level
namespaces.
D
So
they'll
be
like
all
of
this
list
of
things
that
we
use
today.
That
will
be
impossible
and
make
our
lives
more
difficult
in
future,
because
we
will
have
two
workspaces
as
a
company
and
that's
something
to
consider
and
then
then
the
logical
question
might
be
okay.
Can
we
migrate
to
one
workspace
and
move
them
all
into
that,
and
then
that
will
it
will
unearth
this
huge
pile
of
other
challenges?
D
If
you
know
that
that
will
reveal
to
us
the
challenge
with
this
right,
if
you
have,
if
you
have
links,
you
have
10
years
of
links
in
markdown
and
comments
that
are
all
now
pointing
to
the
wrong
space,
because
we
changed
the
namespace
of
every
project
and
group
in
gitlab.
You
now
have
all
of
this
content,
that
is,
that
is
no
longer
correct,
but.
A
D
There
might
be
there
might
be
places
where
redirection
works,
but
and
and
my
my
example
of
like
links
and
comments
and
and
merge
requests
and
issues
is
possibly
just
one
of
you
know
a
group
of
challenges
that
and
that
redirection
may
not
work
in
in
all
contexts
as
well,
possibly
in
markdown
rendering
and
things
like
that.
So
but
yeah,
that's
that's
the
kind
of
challenge
I
imagine
we
have
to
address.
If
we
want
it's
like
different
creative
ways,
we
solve
that.
One
is
like
pod.
D
Zero
is
allows
cross,
workspace,
workflows
within
the
whole
pod,
and
then
it
doesn't
matter
because
you
can
have
as
many
workspaces
as
you
want
within
pod
zero
and
everything
keeps
working
as
it
works
today,
which
would
be
ideal
because
then
no
customers
have
to
be
no
customers
of
pod.
Zero
are
gonna
notice
this,
but
it
also
means
that
we
have
pod
one
behaving
quite
differently
to
pod
zero,
for
example,
and
that's
complex
application
code
and
confusing
user
experience.
C
This
is
something
that
I
just
stumbled
upon
right
now
there.
Of
course,
these
are
the
things
like
if
you
have
a
self-managed
instance
and
it
is
allowed
to
have
many
workspaces,
you
know
the
url
is
likely
going
to
be
something
like
gitlab.customer.com
like
their
own
instance
and
then
they
say
well,
we
want
to
move
to
sas
and
they
have
like
their
workspaces,
are
named
project
one
project,
two
right.
They
will
want
to
move
onto
gitlab.com
dash
customer
workspaces
right.
C
C
It's
the
end
of
the
call,
so
we
can.
We
can
talk
about
this
for
it,
for
probably
we
will
talk
about
it
for
a
long
time,
so.
A
All
right
at
some
point,
but
we
can
talk
about
it
later.
It's
not
that's
a
big
year.
All
right,
bye-bye.