►
From YouTube: Pods Direction - Discussion with the Workspace Group
Description
Agenda doc - https://docs.google.com/document/d/1snuNMYsXs_u7esVuoSruvmVrzZrVtZs-jtX1zJCTufc/edit?usp=sharing
A
So
we
wanted
to
discuss
some
pods
or
really
we
started
discussion
discussing
the
naming,
but
but
then
there
are
all
these
questions
that
come
up
about.
Okay,
forget
the
name
or,
as
Shakespeare
said,
what's
in
a
name,
what
actually
happens
with
the
implementation
of
pause
and
its
impact
on
different
features
and
functionality?
A
I
don't
know
if
we
know
to
answer
that
yet.
But
my
kind
of
question
and
concern
comes
with
how
we
are
going
to
define
the
separation
between
pause
because
I
saw
Camille's
POC
and
it
looks
like
if
something
is
on
different
pods.
You
can
basically
not
see
it
and
you
can't
do
anything
with
resources
in
between
pods.
A
And-
and
the
question
is,
is
that
interpretation
correct,
or
are
we
going
to
do
some
limbo
weirdness,
where
we
can
share
some
resources
in
some
way
or
or
is
like
no
not
at
all,
or
are
we
going
to
find
some
ways
and
the
reason
I
ask
that
is
because
there
is
different
concerns
around
group
sharing
permission
sharing.
Another
question
I
had,
for
example,
is
from
the
user
point
of
view
like
if
I
may,
if
I'm
a
user,
that
I
belong
to
both
an
organization
Acme
and
also
I'm
a
community
contributor.
A
How
do
I
see
my
things
like
what
happens
to
my
notifications
to
my
to-do's,
to
like
one
of
the
things
that
users
complain
about,
for
example,
is,
oh
I,
don't
see
my
private
contributions
on
my
contribution
calendar
for
them?
What
happens
in
all
those
situations?
So
that's
kind
of
the
some
questions
floating
around.
In
my
mind,
cool.
B
B
Let
me
outline
briefly
how
we
arrived
at
this
point
and
what
we're
doing
right
now,
because
I
think
that's
important
for
you
to
understand,
because
I
think
there
may
be
a
perception
that
this
is
all
a
done
deal
and
things
are
just
happening
and
you
have
to
deal
with
it,
which
is
not
the
case.
So
maybe.
C
B
First
thing
regarding
naming
because,
what's
in
a
name
but
naming
is
notoriously
hard
right,
so
I
actually
personally
think
this
bucket
that
we
opened
on
the
naming
concerns
I,
don't
think
that
needs
to
block
making
that
decision
on
names
and
I
think
that's
important,
because
you
get
otherwise
that
we're
going
to
spin
in
circles
for
a
long
time.
So
that's
at
least
my
perception
so
I'm
happy
once
we
have
this
naming
thing
out
of
the
way,
because
I
think
unblocks
remote
development
as
well.
So
that's
number
one,
the
second.
B
B
The
reason
why
we
are
at
this
point
is
more
than
a
year
ago
we
were
in
quite
a
bit
of
trouble
with
regards
to
our
gitlab.com
architecture,
and
we
knew
already
at
that
point
that
we
needed
to
do
something
in
order
for
us
to
actually
continue
to
scale
and
not
topple
over,
and
that
is
a
big
company-wide
risk
right.
If
gitlab.com
can't
actually
like
essentially
becomes
unstable,
you
know
unavailable
and
we
can't
scale
it
anymore.
B
That's
a
big
business
risk,
and
so
at
that
time
we
already
did
some
investigation
of
what
to
do
and
arrived
at
CI
decomposition,
taking
all
of
the
CI
tables
and
moving
them
to
a
separate
database
cluster
as
a
first
iteration,
which
already
took
us
almost
a
year
to
do,
and
we've
done
it
I
think
in
July
and
that's
done,
but
we
already
knew
that
this
is
only
the
first
step.
So
it's
not
like
we
did
it,
and
now
we
are
indefinitely
fine.
B
So
we
have
certain
business
goals,
I'm
not
going
to
go
into
details,
so
we
can
hopefully
make
this
public,
but
we
know
that
ultimately,
we
want
to
be
able
to
scale
gitlab.com
and
we
want
gitlab.com
to
be
reliable
for
our
customers
and
the
current
architecture,
as
it
exists,
is
very
likely
not
going
to
deliver
this
we're
still
doing
other
things
to
make
it
better.
For
example,
partitioning
CI
tables,
you
know,
there's
a
lot
of
optimization
and
and
other
work
going
on.
So
pause
is
not
the
only
thing
here,
but
we
know
we
need
something.
B
B
That's
going
to
group
things
right,
and
we
also
knew
that
if
we
just
look
at
top
level
groups-
and
we
disconnect
things
at
the
top
level
group
level-
that's
going
to
be
pretty
bad,
so
we're
kind
of
thinking
about
possible
solutions
and
then
I
started
reaching
out
to
to
Christina.
In
my
to
understand
what
workspaces
are
if
they
are
going
to
potentially
solve
some
of
those
concerns
or
not
and
I.
B
Think
where
we
are
at
the
moment
is
they're
not
really
going
to
solve
all
of
those
concerns,
but
maybe
some
of
them
and
it's
complicated.
This
is
where
I
think
we
we
are
at
the
moment,
but
we
don't
have
all
of
the
answers
to
any
of
this,
but
I.
Also,
my
intent
and
I
think
the
intent
of
group
pods
is
to
have
those
conversations
early
right
to
gather
people's
input
and
gather
like
their
concerns
rather
than
spending
a
year.
B
Implementing
pods
and
saying
like
this
is
happening,
go
deal
with
the
Fallout
right,
because
I'd
rather
have
a
an
overview
of
the
impact,
the
trade-offs
that
we're
making
and
then
coming
to
actually
sort
of
a
product-wide
decision
that
this
is
something
that
we
believe
is
potentially
worth
it.
So
this
very
long
summary
I'm
going
to
stop
talking,
but
Camille
and
Barry
can
tell
me
if
I
forgot,
something
or
if
I'm,
if
I'm
wrong,.
D
D
B
B
It's
very
likely
that
you
can.
You
can
kind
of
Imagine,
let's
say
gitlab.com
as
it
is
right
now
like
a
single
massive
pod
and
maybe
over
time
we
can
move
people
off
that
part.
Somehow
so
we'll
get
smaller
and
smaller
and
smaller,
and
then
at
some
point
it
may
fully
disappear
or
become
just
a
regular
thing
that
we
maintain,
given
that
github.com
has
been
online.
For
you
know
a
decade
plus
there's
always
going
to
be
sort
of
a
bottom
bit
where
we
don't
even
know
what
this
is
right.
B
E
But
then
we
like
create
this
empty
for
people
and
existing
companies
to
transfer
into
organization
hey.
This
is
like
this
is
your
organization,
it's
isolated
from
the
rest.
We
really
want
to
do
it
or
do
you
want
to
work
in
the
old
style
in
the
let's
say
the
current
github.com
as
it
was
running
so
so
this
may
be
like
like
two
types
of
the
decision,
one
that
is
like
by
us,
but
secondly,
like
providing
incentive
for
the
customers
for
them
to
move
into
organization
model.
E
Because
then,
if
we
have
this
like
smaller
entities,
we
could
actually
migrate
them
away
from
the
github.com
into
something
providing
Superior
stability,
because
I
think,
like
the
car,
the
thing
that
we
think
about
the
pots
right
now,
it's
like
every
single
part
would
be
completely
self-sufficient.
It
would
have
its
own
Runner,
it
would
have
its
own
cues.
E
So
I
I
would
kind
of
consider
like
if
the
organization
model
with
the
isolation
becomes
acceptable.
I
would
consider
these
two
things
probably
be
essential,
basically,
first
doing
that
for
ourselves
and
then
kind
of
creating
incentive
for
existing
github.com
users
to
migrate
into
this
model.
But
I
would
not
say
that
it
would
happen
forcefully.
It
seems
pretty
disruptive,
so
I
would
say
that
this
would
rather
be
a
conscious
decision
of
the
of
the
companies
doing
that,
and
also
very
likely
this
in
my
head
in
the
initial
period.
E
It
would
probably
be
a
revertible
decision
to
make
so.
Let's
say
you
chose
the
isolation
you
have
like
90
days
for
go
back
if
you,
if
you
figure
out
that
this
is
something
that
is
not
working
for
you,
so
at
least
at
least
this
is
how
I
would
Envision
that
from
the
from
the
product
side,
if
we
follow
isolation
model
that
is
currently
proposed
in
a
Bots
foreign.
B
I
think
this
is
this
is
a
really
valid
concern.
We
certainly
see
this
right
now.
I
I
think
if
we
take
a
step
back
from
this
specific
concern,
this
is
also
going
to
be
true
for
Italy
for
other
things
right,
so
we've
already
started
doing
some
pocs
on
our
end,
just
to
make
it
a
little
bit
more
visual.
B
What
this
would
look
like,
for
example,
the
demo
that
Camille
did
but
I
think
that
urid
watched,
because
it
makes
everything
already
much
more
clear
what
this
would
do,
but
and
I
think
this
is
something
that
is
more
for
me
and
Barry
and
to
some
extent
or
retail
line
on
all
of
this
is
work
right.
It's
like
this
is
something
where
sometimes
we,
as
in
group
Parts,
can't
do
this
necessarily
because
we
don't
know
every
single
bit
of
gitlab.
B
So
one
of
the
suggestions
that
I'm,
having
or
like
that
we
are
trying
to
put
forth
is
we
are
I
think
at
the
point
where,
let's
say
a
pod
architecture
from
the
back
end,
things
is
plausible.
It's
a
ton
of
work,
but
it's
potentially
plausible,
but
now
we
are
we've
discovered.
All
of
these
potentially
impacted
features,
and
it
may
be
necessary,
let's
say
for
all
affected
groups.
B
B
A
D
Yeah
my
question
was
but
I
guess
it's
related
to
how
or
read
phrased
it.
So
I
put
your
question
in
the
beginning:
read
what
happens
like
pods
are
separated.
We
see
them
as
very
isolated
structures,
but
how
would
that
impact
when
people
want
to
collaborate
in
an
organization,
for
instance,
what
if
I
have
an
external
contractor
or
a
guest
user
from
another
organization
that
wants
to
work
with
me?
How
would
that
look
in
a
pod,
so
I
think
Camille
tried
to
answer
that
there.
E
I
I
guess
there
is
like
a
few
different
ideas,
though
right
first
I
think
it's
like
organizational
membership.
We
already
have
like
the
concept
of
external
contributors,
so
maybe
this
was
actually
like
evolving
to
explicitly
adding
a
person
to
a
group.
I
mean
we
already
have
that.
So
it's
I
guess
it's
no
different
like
to
how
you
like
manage
existing
members
of
a
group.
E
Probably
we
like
it's
about
the
forking
model.
The
carbon
14
model
is
pretty
permissive.
You
can
Fork
into
your
personal
namespace,
even
private
project,
but
now,
like
it's
kind
of
organizational
model.
It
raises
like
a
few
questions
like
one
that
I
offline
I'd,
like
organization,
provides
like
a
strict
control
and
like
Street
boundaries.
This
is
like
this
arrival
that
you
really
can
Fork
private
project
outside
of
the
organization.
If
this
is
not
the
desire,
it's
completely
different
to
the
public
projects
and
maybe
Forex
for
the
public
practice.
E
G
E
Maybe
if
you
contribute
within
an
organization
there's
like
some
automated
created
space
for
your
contributions
within
organization,
so
they
see
managed
by
the
organization
so
kind
of
moving
away
from
working
into
personal.
Maybe
this
is
like
the
public,
maybe
a
fork
into
personal
project
and
it
kind
of
works
as
a
better
writer.
Maybe
it's
actually
implemented
as
a
directed
much
cheaper.
That
can
actually
work
within
the
same
GitHub
we've.
Indeed
the
same
pattern
within
different
GitHub
instances.
There
is
like
platter
of
different
options.
E
How
we
can
apply
that
and
I
don't
have
answer
I'm,
just
kind
of
throwing
the
ideas
to
kind
of
think
like
what
else
we
could
actually
offer.
If
we
have
this
like
isolation
and
what
other
problems
you
we
could
solve,
based
on,
like
the
contrast
and
what
people
expect
so
I
think
like
at
least
my
goal
right
now
for
at
least
Forks,
because
I
think
this
is
like
the
key
headline
feature
that
we
need
to
figure
out
and
then
like
it's
much
easier
to
talk
about.
How
actually
are
possible
approaches
to
this
much
harder.
E
Cross-Talking
problems
could
give
us
like
some
hints
of
the
possible
designs,
because
I
think
or
if
you're
asking
each
other
like.
We
know
this
strong
acceleration.
There
is
no
communication
with
any
products.
It's
not
true.
We're
Not
Gonna
avoid
cross
talking
to
pods.
It's
just
it's
gonna,
be
super
more
complex
to
do
it
than
doing
that
through
database.
How
we
doing
it
now,
because
you're
gonna
have
to
use
a
proper
RP
to
like
refresh
data
from
another
Port,
but
I
I
would
not
say
that
this
is.
It
will
not
happen.
E
It
will
for
sure
happen
for
some
features,
because
it's
like
inevitable
we're
gonna,
be
sharing
data
across
cluster
at
these
user
sessions
and
we're
definitely
gonna
be
have
to
some
data
aggregate
across
cluster.
It's
just
I
I
think
the
default
is
like
there
is
no
cross
talking
so
I
think
it,
at
least
in
the
current
proposal
it's
like.
If
you
want
to
do
crosstalking,
it
has
to
be
implemented
using
a
well-defined
RP,
probably
graphql
or
whatever
else,
to
do
this
intra
communication,
but
it
would
never
be
forbidden.
E
It's
because
we're
gonna
have
some
cross
talking.
Always
it's
just
gonna
be
more
expensive
and
a
more
complex
to
do
so.
I
think
Fox
could
be
like
a
good
example
to
show
how
different
approaches
could
be
applied
with
crosstalking
our
memory
without
crosstalking.
Taking
some
of
these,
let's
say
new
opportunities
with
the
organization
in
mind
of
like
stick
track.
Access
Control
may
be
a
slightly
different.
Contributions
to
public
may
be
Federated.
Mars
I
think
this
is
like
three
or
four
ideas
that
I
have
on
my
head
right
now,.
B
And
I
can
comment
on
this
a
little
bit
further
and
I
think
this
is
an
important
it
pops
up
later
on
for
a
read
as
well.
I
think
it's
not
like
communicating
with
pods
is
impossible
right
and
will
be
completely
forbidden.
It's
just
going
to
be
significantly
more
expensive
to
do
this
type
of
operations
right.
So
if
you
require
real-time
updates
or
complex,
joins
right,
these
kinds
of
things
that's
going
to
be
undesirable
from
in
that
architecture.
B
B
I
think
we
know
that
we
will
have
to
make
certain
trade-offs
right
and
some
use
cases
for
gitlab
may
be
significantly
less
common
or
there
may
not
be
something
that
we
prioritize
as
a
company
I
think
there
it
may
be
more
acceptable
to
say
like
well
yeah,
that's
that's
harder
or
not
how
we
work.
But
of
course
there
are
some
workflows
like
Forks
or
whatnot,
where
we
already
know
they're
super
super
important
and
we
we
need
to
make
sure
they
continue
to
work.
I,
think
that's
that's
something
where
I
I
don't
have
a
great
idea.
B
A
Yeah,
so
on
the
topic
of
contractors
just
to
to
kind
of
make
life
more
complicated,
we
have
large
customers
who
own
several
companies,
I'm
not
going
to
name
names
so
that
we
can
make
this
public
that
will
have
10
000
users
or
more
I'm,
not
even
sure
that
they
would
roll
up
to
a
single
organization,
because
they
are
multiple
companies
and
they
would
probably
need
to
share
data
either
from
an
executive
standpoint
or
a
contractor
standpoint,
and
just
another
use
case
for
this
Partners.
Our
partners
get
Lab
Partners.
B
I
think
that's
a
great
question.
A
couple
of
thoughts
on
that
one
I
think
this
is
something
where
we
also
need
to
do
better
job
is
like
I.
Don't
think
companies
with
external
contractors
in
the
10K
range
are
necessarily
a
target
for
our
shared
multi-tended
SAS
service
right.
This
is
maybe
something
where
dedicated
is
much
more
suitable
for
them.
So
I
think
we
also
have
to
maybe
think
about.
Is
there
you
know
a
recommended
range,
but
it
is
also
the
case.
E
B
So
I
could
see
that
being
potentially
beneficial,
but
I
I
agree
that
we
may
have
to
like-
and
this
is
a
concern
I
think
I've
heard
from
Gabe
and
maybe
from
Mike
I'm,
not
quite
sure
that
okay,
so
organizations
is
good
enough
for
the
99.
But
then
there
are
maybe
Enterprises
and
they
have
different
organizations,
and
where
does
that
end?
Right
and
I
think
that's
a
discussion
that
we
we
need
to
make
and
I'm
not
sure
that
we're
addressing
that
with
at
the
moment,
particularly
those
are
a
couple
of
thoughts.
A
E
No,
you
did
not
I
think
the
whole
design
goal
was
like.
You
have
a
singular
account
for
the
gitlab.com.
You
can
have
Usman
organizations
as
you
want.
Maybe
in
the
organization
you
have,
let's
say,
organization,
specific
profile
that
describes
your
reward
title
whatever,
but
you
should
not
have
to
create
many
accounts.
I
I
think
this
is
like
the
headache
of
the
camera,
github.com
and
and
I
I.
E
Think
that's
also
like
sit
so
to
us,
like
as
one
of
the
design
goals
that
like
on
github.com,
you
need
to
have
right
now,
personal
and
professional
account
to
sell
segregate
duties.
I
think
the
the
pods
architecture
with
the
organization
is
like
tries
to
avoid
that
at
all
costs
it's
used
to
basically
have
be
able
to
interact
between
many
organizations.
Switch
between
them
do
not
know
that
you
are
on
Airport
100.
E
B
No
I
I
think
that's
true
this
on
the
technical
level
right
this
may.
Actually
what
this
may
require
is
taking
everything
that
has
to
do
with
authentication
and
users
and
isolating
that
out
of
gitlab
to
make
it
some
kind
of
global
Service,
which
is
actually
desirable
for
a
number
of
different
reasons:
security,
for
example,
right
and
others,
but
we
we
are
not,
at
least
in
our
current
plans.
You
know
the
the
design
goal
was
to
have
some
shared
State
and
users
would
be,
would
be
one
of
them.
B
Given
the
complexity
of
all
of
this,
and
given
that
you
know
there
is
a
lot
to
unpack
I
think
the
next
step
here
may
be
to
say:
look
this
is
you
know
from
a
pods
perspective.
You
know
this
is
the
technical
architecture.
You
know
these
are
some
of
the
constraints.
These
are
the
impacted
features,
do
an
evaluation
of
the
impact,
but
I
I
would
want
that
to
be
aligned
on
in
terms
of
company
priorities,
because
that
could
take
some
effort
right
and
I.
B
I
think
we've
already
seen
that
if
I
enter
a
room
and
mention
pods
and
what
it
could
do,
you
know
people
are
generally
a
little
bit
okay,
this
changes
everything.
What
are
we
going
to
do
here
and
so
that
that
may
be
the
the
learning
that
I'm
taking
from
having
taking
up
some
some
time
in
the
in
other
groups,
but.
B
B
A
B
I'll,
let
you
talk
about
it
as
well,
so
I
think
the
the
idea
is
that
pods
should
be
mostly
isolated,
but
pods
will
host
many
organizations,
and
anything
that
happens
within
a
pod
can
essentially
continue
to
operate,
as
it
does
right
now,
but
anytime,
a
feature
whatever
that
is
needs
to
cross
into
something
that
is
not
located
on
the
same
pod.
Then
you
know
that
let's
say
would
break
unless
we
fix
it,
and
so
the
the
idea
is
I.
B
Think
from
our
perspective,
that
pods
is
a
potentially
good
fit
if
we
are
treating
isolation
sort
of
as
a
default,
and
then
we
make
exceptions
in
cases
where
we
believe
that
that
needs
to
be
needs
to
be
done
or
where
that
makes
sense,
and
some
of
the
things
are.
You
know,
for
example,
search
if
we
ever
wanted
to
search
across
everything
or
like
things
that
are
maybe
like
or
Forks.
You
know
that
we
just
discussed.
B
That's
the
that's
the
idea,
but
that
is
this
is
desirable
because,
let's
say
a
large
like
a
number
of
customers
are
on
a
specific
pod
and
they
do
something,
but
they
sometimes
that
happens.
Let's
say
they
or
let's
say
the
the
data
center
burns
down
right
then
that
part
goes
offline.
We
have
Disaster
Recovery
capabilities.
The
entire
fleet
continues
to
work.
That's
not
the
case
at
the
moment
right.
Somebody
does
something
on
github.com,
it's
it's
a
problem.
This
is
why
that's
desirable.
E
E
E
The
idea
of
the
organization
is
like
that
organizations
are
built
on
the
current
architecture,
and
parts
would
benefit
from
the
organization
isolation,
and
this
is
I
think
like
that
something
that
would
be
kind
of
prerequised
to
to
their
thoughts,
because
what
you
saw
as
a
POC
was
like
organization
equal
spots.
It's
not
something
that
how
that
we
could
run
so
I.
B
Yeah,
that's
I
think
the
that
my
high
level
migration
idea
that
we
had
is
that
we,
you
know
we
have
to
kind
of
figure
that
out
first
and
then
once
it's
in
place,
we
can
actually
start.
For
example,
like
we
can
do
several
things
right.
We
can
migrate
certain
things
off
gitlab.com
as
it
is
right
now
or
we
can
add
new
customers
onto
pods
right
and
say
this
is
how
it
works,
slow,
the
growth
of
gitlab.com.
B
There
are
several
things
to
that
may
be
possible,
but
the
I
think
Christina
linked
to
a
discussion
that
we
had
with
Mike
right.
There
are
several
scenarios
on
like
how
to
actually
migrate
people
and
what
that
would
look
like
and
that's
a
huge
undertaking,
and
it's
probably
one
of
the
harder
things
to
do.
B
B
B
Yeah
for
sure,
but
I
think
another
another
thing
to,
and
this
is
maybe
not
a
more
technical
thing
and
an
idealistic
view
of
how
the
world
could
be
at
some
point
right.
It's
it.
Pods
has
at
least
the
potential
right
to
be
run
in
a
multi-tenant
way
right,
the
for
github.com,
but
it
could
also
very
simple,
simply
be
used
to
run
something
like
dedicated
in
a
way.
B
Maybe
dedicated
is
the
the
starting
point
for
operating
in
many
parts,
because
dedicated
is
a
single
tenant
system,
so
you
would
have
one
organization
per
part
and
they
get
it
all
or
you
know
maybe
multiple,
but
at
least
one
customer.
You
know
that
is
associated
with
it,
but
you
may
be
able
to
extrapolate
that
to
a
multi-ten
system
and
if
all
of
those
things
run
on
the
same
architecture
and
they
all
run
with
at
least
similar
Concepts,
you
know
of
organizations,
then
that
may
make
things
easier
to
like
move
between
items
and
migrate
them
eventually.
B
But
it's
very
complicated
and
I.
Think
myself,
I
can't
quite
remember
myself,
but
this
is
very
hard
right
and
there's
always
intricacies.
So
it's
not
something
where
you
snap
a
finger
and
it's
going
to
be
done,
but
at
least
we
may
enter
a
state
where
our
like,
self-managed
or
multi-ten,
our
Singleton
offerings
all
sort
of
share
a
lot
of
like
underlying
building
blocks
and
that
I
think
is
quite
desirable.
A
B
B
I
think
the
only
place
where
I
could
see
this
being
handy
is
for
CIS,
admins
or
personas
that
have
administrative
capabilities.
If
this
becomes
something
self-managed
folk
need
to
do
at
some
point,
but
regular
users
should
never
really
know
this.
We
should
be
able
to
say
hey,
we
support
regions
right
and
we
can
offer
you
slas
and
disaster
recovery,
and
they
may
be
a
consequence
of
having
migrated
to
that
architecture.
But
those
are
the
valuable
features
I
think
pods
should
be.
B
F
B
Then
you
would
have
to
build
some
kind
of
capability
that
retrieves
all
of
these
to
Do's
from
your
different
organizations,
which
may
be
on
different
pods,
and
then
you
would
have
to
say
in
your
list,
for
example,
at
least
this
is
which
do
it
comes
from
this
organization
and
when
you
click
on
it,
you
get
there
right
on
a
very
high
level.
I
I'm
not
saying
this
is
the
this
is
the
way
to
go,
but
you
know
you
can
definitely
explain
those
things
without
saying
you
know.
This
is
on
a
different
part.
F
B
So
I
think
this
is
this.
Is
why
I'm
talking
about
the
the
organization
space
so
technically
right?
If
all
of
those
organizations
were
on
the
Single
part,
if
nothing
would
stop
us
from
aggregating
them
exactly
in
the
way
that
we
did,
but
because
of
the
architecture,
we
wouldn't
make
a
guarantee
that
they,
these
organizations
live
on
the
same
park.
B
We
may
have
to
move
them
right
at
some
point,
and
so
you
would,
you
would
have
to
scope
them
to
this
specific
entity,
which
is
an
organization
or
you
know
you
decide
that
the
user
experience
for
this
is
poor
people.
Don't
they
want
a
single
place
to
look
at
all
of
their
to-do's
as
it
is
right
now
and
then
we
would
have
to
fix
it
right
and
that's
not
impossible
in
Imports
to
do.
But
that
is
something
that
we
have
to
actively
evaluate
and
that's
true
for
for
other
things
as
well.
G
E
Right
now,
there
are
like
I,
think
benefits
for
the
aggregation,
but
there
also
benefits
for
the
separation
to
prevent
also
like
the
data
leakage
between
these
spaces
and
also
focusing
on
you
on
what
is
important.
For
example,
I
now
have
like
50
todos.
Most
of
them
are
from
git
love,
but
if
I
work
in
my
personal
and
on
weekends,
I,
don't
want
to
see
these
Studios
because
I
focus
on
something
different.
So
there
is
I
guess
person
comes.
D
Yeah
I
think
that
needs
to
be
investigated,
like
when
I
I
kind
of
like
the
separation
and
slack,
but
I
can
also
tell
you
I,
don't
go
to
the
other
places
as
much
as
I
should
to
see
what's
going
on
there,
because
I'm
focused
on
gitlab,
so
I
neglect
that
part.
So
it's
actually
better.
If
it
served
to
me
all
the
time
so
I
don't
forget
about
it.
Yeah.
B
That
may
be
a
a
Persona
and
a
profile.
You
know
that
we
want
to
go
after,
because
that
is
something
where
we
see
growth,
however,
and
I
think
this
is
important
to
note
right.
This
is
not
necessarily
the
same
way
that
people
behave
in
open
source
contributions
right
and
where
they
interact
with
many
different
projects
and
that's
something
to
figure
out
right
like
and
how
that
would
work
and
I
I.
Don't
we
don't
know
right,
that's
another
piece
of
investigation
that
will
need
to
happen
because
I
think
I
I,
like
Camille,
said
you
know.
B
A
B
Ish
I
think
the
only
discussion
I
had
was
with
the
Fulfillment
engineer
and
I
didn't
really
realize
that
usage
paying
data
is
pretty
complicated
at
the
moment
because
we're
we
get
instance,
level
data
from
self-managed
instances
and
we
get
top
level
group
information
for
gitlab.com
and
that's
all
kind
of
hard
right.
So
if
we
could
move,
for
example,
the
usage
level
ping
to
let's
say
an
organization,
you
know
that
would
maybe
harmonize
usage
data
across
self-managed
and
gitlab.com
I.
Don't
know
how
possible
that
is,
or
if
that
even
makes
sense.
I
don't
know.
E
Right
I
think
like
it
was
probably
not
perfect
and
I.
Don't
think
that
this
would
also
be
like
more
like
iterative
approach
like
to
figure
out
how
to
scrape
that
I
like
looking
at
how
users
think
is
being
on
my
personal
idea
would
be,
will
simply
scrape
each
box
individually
and
aggregate
this
data,
and
this
is
probably
how
it
would
be
implemented,
because
it's
like
aggregating
across
outputs,
it
seems
unrealistic,
so
very
likely
it
would
not
affect
a
lot.
Some
data
would
probably
be
affected,
but
you
would
solve
them.
E
A
E
A
E
More
people
like
to
work
with
us
on
writing
these
proposals
and
affected
features
because,
like
it,
takes
significant
amount
of
time
for
us
like
to
to
decipher
how
these
things
works.
So
if
someone
familiar
with
the
matter
would
simply
speed
up
it
and
be
much
more
accurate,
it
would
have
much
better
answers
to
you
than
others.
A
A
We
have
an
open
discussion
related
supporting
multiple
top
level
groups,
see
how
I
refrain
from
using
the
terminology
as
to
not
confuse
people
on
the
call,
and
even
if
we
do
decide
to
support
multiple
top
level
groups,
I
think
this
is
going
to
take
a
really
long
time
to
implement.
So
my
question,
which
I'll
try
to
refine
right
now,
is
this
something
that
is
an
absolute
requirement
for
pods.
B
So
I
think
this
is
this:
is
a
contentious
I'll,
try
to
explain
it,
the
best
I
can
right-
and
this
is
I-
think
maybe
Christina
in
a
sense,
the
intricacies
here
better.
My
simplistic
idea
of
an
organization
was
to
put
it
above,
a
top
level
group,
and
then
the
organization
would
group
multiple
top
level
groups.
B
The
reason
for
this
is
that
you
know
this.
The
example
I
used
for
git
gitlab
right.
We
have
gitlab
Dash
org
gitlab.com,
they
are
top
level
groups
and
I
want
those
top
level
groups
to
be
part
of
the
same
organization,
because
that
means
they're
on
the
same
pod,
which
means
everything
in
those
multiple
top
level
groups
you
know
can
essentially
continue
to
work
as
as
is
right.
Now,
that's
I,
think
the
the
simple
thing
but
and
I
think
this
is
the
this
is
the
sort
of
more
of
like
how
to
get
there.
B
You
know
there
is
this
notion
of
what
makes
the
top
level
group
a
top
level
group
right
and
right
now,
I
think
it
is
billing,
some
admin
settings
and
a
number
of
other
things
that
I
and
if
we
remove
all
of
that
move
it
to
an
organization,
then
these
groups
just
become
regular
groups
that
happen
to
be
at
the
top
level.
So
to
speak.
B
I,
don't
know
right,
but
ultimately
I
like
the
end
state
for
me
would
be
that
you
have
an
organization
and
that's
the
that
sits
at
the
top.
And
then
you
have
multiple
groups
underneath
you
know,
and
you
should
only
have
groups
and
subgroups
and
projects
and
at
the
top
you
know
the
thing
that
groups
everything
the
container
is
an
organization.
That's
my
view
of
it.
B
I
think
it
wouldn't
at
all
it
just
it
just
happens
to
be
inheriting
I
think
this
is
the
other
thing
where
I
made
that
statement
somewhere
as
long
as
you
have
this
from
a
pod
perspective.
That
is
right
purely
from
our
sort
of
standpoint.
As
long
as
you
have
this
container,
where
you
can
say
this
is
the
the
thing
the
things
that
belong
together.
However,
you
organize
these
inside
that
container
right,
it's
like,
if
you
make
it
a
completely
flat
structure
or
if
you
have
inheritance
or
I,
think
that
is
from
from
a
pods
architecture.
B
D
Well,
not
for
us
anymore,
I
think
for
Eric's
team
it
will
be,
but
to
build
it
out.
I
think
it
would
be
important
for
us
where
to
place
it
whatever
we
call
it
I
think
we
were
not
even
expose
it
much
to
users,
so
it
doesn't
really
matter
what
it
is
called
organization
seems
to
fit.
Well,
maybe
it
pushes
organizations
to
actually
stick
within
that
thing
for
themselves
instead
of
spinning
up
more
but
I.
Don't
think
that
there's
anything
we
can
do
if
they
decide
to
open
up
another
one.
No.
B
D
B
I
think
I
think
this
is,
and
this
is
a
data
point
that
I
don't
have
right.
I
guess
I
kind
kind
of
do,
but
not
really
right.
Now,
billing
sits
at
the
top
level
namespace
right
at
the
top
level
group
and
it
will
potentially
move
to
the
organization
level,
so
I
think
what
would
require
be
required
there.
B
Yes,
you
can
make
more
than
one
organization,
but
if
you
want
features
like
epics,
you
know
to
exist,
you
will
have
to
buy
these
things
twice,
so
I
think
in
case
people
want
that
for
good
reasons
that
they
may
consider
this.
But
if
they
I
think
that's
the
that's
the
potentially
limiting
factor
and
I
don't
know.
I
generally,
don't
know
how
many
customers
of
gitlab.com
right
now
maintain
multiple
paid
top
level
groups.
B
B
C
Yeah
so
I
just
wanted
to
talk
about
like
communication
from
pods,
so
we've
we've
been
thinking
about
and
we've
kind
of
been
in
a
bit
of
a
huddle
working
out
the
the
first
few
aspects
of
PODS
and
now
we're
at
a
state
where
we
can
talk
about
it,
not
necessarily
answer
a
lot
of
questions
but
surface
the
questions,
and
that's
that's
been
a
great
conversation.
I
I
think
today,
going
forward
we'll
be
starting
up
an
AMA
so
that
there's
space
for
questions
for
for
the
pods
group.
A
Good
great
well,
thank
you
for
your
patience
and
answering
all
our
questions.
It
seems
like
there's
a
lot
of
unknowns
still
and
that
we
still
need
to
have
a
lot
of
discussions.
Going
is
my
conclusion,
but
thank
you
I
think
I
understand
it
a
little
bit
better
Marcela
Christina.
How
are
you
feeling
Chris.