►
From YouTube: GitLab 13.0 Kickoff - Manage
Description
The Product team for GitLab's Manage stage (including the Access, Compliance, Spaces, and Import groups) assemble to showcase what's ahead for us in 13.0:
- Access: 0:31
- Spaces: 5:32
- Compliance: 18:37
- Import: 27:14
Agenda and issue links are publicly available at https://docs.google.com/document/d/e/2PACX-1vRnN91k9Rx1AyF8cIQga3KGFpjkI-sheTB16Jg-4e8fO3snZas2Th4hJC5C5wKIrNWbzr8aYDjI-T7-/pub.
A
Hey
all
thanks
a
lot
for
joining
we're.
Gonna
talk
a
little
bit
about
what's
ahead
for
the
native
stage
in
release,
13.0
kicking
off
just
a
few
days
here
and
releasing
May
22nd.
So
this
is
gonna
cover
the
manage
stage.
All
groups,
except
for
analytics,
John,
Mason
analytics,
is
gonna,
be
doing
his
kickoff
asynchronously.
A
So
if
you
have
maintainer
Zoar
developers
or
reporters
or
guests
in
a
sub
group,
you're
able
to
actually
remove
them
from
being
inherited
from
the
parent
group,
so
you're
able
to
kind
of
create
these
and
a
more
more
confidential
kind
of
sub
groups
to
kind
of
hide
projects
that
you
might
want
to
have
kind
of
confidentiality
on.
This
is
great
for
organizations
that
have
like
a
sub
group
of
you
know
more
secretive
projects
that
they're
sensitive
to
even
internal,
so
only
certain
people
in
the
company
you're
able
to
really
manage
that
kind
of
membership.
A
This
ago,
she's
working
hard
on
this
and
we're
looking
forward
to
seeing
that
delivered
and
in
13.
The
next
thing
is
really
restricting
personal
access
to
and
specific
projects,
and
the
idea
here
is
we're
going
to
try
to
in
it
a
new
back-end
point.
That'll
allow
us
to
restrict
personal
access
tokens
to
only
certain
projects,
something
that
we've
working
on
in
previous
releases.
But
now
we're
gonna,
try
to
finish
this
up
in
14
on
access,
and
this
change
is
going
to
allow
on
the
back
end
or
a
front
end
image
and
front
end.
A
Changes
are
gonna,
be
coming
in
kind
of
a
future
issue,
but
allows
you
to
be
able
to
create
a
back
end
personal
access
token,
that
is
specific
to
a
particular
project.
So
this
is
going
to
be
great
for
meeting
kind
of
security
needs
of
organizations
that
typically
rely
on
like
service
users
or
automation
variables
like
more
tightly
control.
The
blast
radius
of
these
credentials,
which
I
think
is
really
exciting,
and
the
last
thing
that
we're
kind
of
working
on
is
enabling
Girt
managed
accounts
in
get
lab.
A
A
C
C
So
we
need
to
establish
whether
or
not
there
needs
to
be
any
changes
to
the
terms
conditions
that
the
users
need
to
sign
when
they
are
converting
their
account
or
group
managed
account,
because
when
they
originally
create
an
account
on
github
calm,
it's
an
individual
contract
so
that
obviously
changes
and
when
they
allow
their
group
owner
will
they
managed
group
to
then
take
control
over
their
account
and
their
data
and
and
whatnot.
So
it's
important
that
we
understand
what
we
need
to
do
there
before
we
release
it
into
the
wild.
Do.
A
You
feel,
like
that's
a
blocking
issue,
before
we're
able
to
release
that
I
make
that
generally
available
on
get
lab
calm
because
based
off
of
what
I
know
that
group
managed
accounts
can
do
today.
Do
you
feel
like
they're,
like
group
owners,
are
able
to
assert
like
a
lot
of
control
over
these
group
managed
accounts
because
I
feel
like?
If
the
answer
is
yes,
then
maybe
that
should
wait
for
that
change,
but
based
off
of
what
I
know,
the
answer
is:
there's
not
a
lot
right
now.
A
C
So
is
that
you,
when
you
currently
enable
it
you
you're
saying
to
users,
you
can
no
longer
fork
projects
outside
of
this
group.
That's
the
level
of
protection
that
you
get
in
thirteen,
we're
going
to
be
the
spaces
group
we're
going
to
be
working
on
a
few
other
oceans
to
greet
accounts,
one
of
them
being
group
owners
will
then
be
able
to
reset
and
disable
two-factor
for
their
users,
which
is
it's
really
big.
Ask
from
not
only
our
customers,
but
also
our
support,
team
and
group
managed
accounts
activity
will
also
be
restricted
to
the
group.
C
So
one
caveat
of
when
you
enable
group
manage
accounts
right
now
is
that
your
users
will
lose
access
to
the
projects
and
groups
and
whatnot
that
have
been
created
prior
to
them.
Converting
their
account
to
a
group
managed
account,
and
it's
a
couple
of
things
with
that.
One
is
if
they
have
an
existing
independent
individual
subscription,
they
will
lose
access
to
that
subscription.
C
So
we
need
to
make
sure
that
we've
we've
mitigated
any
risk
of
potential
user
turn
there
and,
secondly,
if
a
user
is
if
they
lose
access
to
their
projects
and
groups
and
whatnot
that
they've
already
created
once
we
enable
group
managed
accounts,
they
will
then
be
able
to
carry
on
creating
projects
and
groups
whatnot
after
that.
So
it
kind
of
goes
against
the
point
of
what
they
were
originally
not
be
able
to
do
as
a
result
of
turning
that
on.
So
there's
that
and
then
there's
a
slightly
lower
priority.
C
One,
which
is
that
group
manage
accounts,
will
no
longer
be
able
to
be
visible
to
users
outside
of
the
managed
group,
that's
specifically
via
the
API,
via
that
people
won't
be
able
to
see
their
user
profiles
and
if
you
try
and
invite
and
manage,
a
group
managed
account
to
a
different
group.
They
weren't
show
up
in
member
autocompletes,
so
there's
some
pretty
big
ones
that
are
going
to
be
completed
in
the
same
time
as
the
blocker
issues
that
you
mentioned.
C
A
If
there's
an
issue
on
the
terms
and
conditions
changes,
I
would
love
to
see
it.
Maybe
there's
an
MVC
there
that
we
could
kind
of
consider
when,
like
you're
doing
the
mapping
process
with
with
the
group
that
there's
just
a
message
that
like
if
you
you
know,
proceed
past
this
point
or
like
you,
you
can
set
to
do
to
those
to
these
things
and
that's
simply
like
a
message
and
I.
A
C
C
A
C
Does
anyone
want
to
talk
about?
Anything
group
managed
account
related
before
I
move
on
to
the
the
next
point.
Four
spaces
cool
all
right,
so
the
other
big,
exciting
thing
that
we're
working
on
in
spaces
in
thirteen
is
we've
had
a
lot
of
really
great
feedback
from
customers
around
the
need
for
a
type
of
service
user
account,
and
we
did
quite
a
bit
of
research
and
spoke
to
quite
a
few
customers
about
this,
and
once
we
actually
dug
into
it.
C
So,
instead
of
having
an
individual
user
account,
create
a
personal
access
token
and
then
use
that
for
their
automations.
We're
taking
similar
UI
and
we're
taking
the
work
access
is
working
on
and
we're
going
to
position
that
actually
as
a
project
setting
option
so
that
maintain
is
and
owners
can
go
to
their
projects
and
they
can
create
an
access
token,
that's
restricted
to
that
project
and
then
run
the
automations
that
they
need
and
underneath
the
seat
beneath
the
behind
scenes.
C
They're
going
to
be
creating
it's,
they
don't
have
access
to
this
user,
but
it's
going
to
be
a
user
account,
that's
similar
to
a
support
bot
or
in
a
lot
what
we
have
some
other
BOTS
that
already
exist
on
system.
So
it's
gonna,
look
a
little
bit
like
that
and
everything's
going
to
be
prefilled
so,
except
their
name.
Their
name
I
think
we'll
just
be
project
name,
but
so
it
will
look
like
it's
identifiable
to
that
project.
Only
and
then
so.
That's
a
big
effort
that
we're
going
to
be
doing
hope.
C
That's
gonna
solve
a
pretty
big
problem
for
a
lot
of
customers
and
then
as
well
as
that
in
13.
We're
also
gonna
be
beginning.
The
work
on
extending
that
also
to
groups
so
you'll
be
able
to
what.
If
we
were
to
have
group
level
access
tokens
as
well,
but
the
project
level
access
tokens
is
on
track
to
being
completed
for
thirteen
point.
No,
so
we're
really
excited
about
being
able
to
give
that
to
our
customers.
That's.
A
Awesome
I'm
really
excited
about
that
too.
I
think
that
I
was
actually
we
were
Melissa
and
I
were
talking
to
a
customer
this
morning.
Actually
they
were
talking
about
managing
authentication
in
this
kind
of
convoluted
way,
because
they
had
some
users
that
were
all
using.
They
want
to
use
SSO,
and
but
they
had
a
bunch
of
service
users
that
they
were
using
username
and
passwords
for
and
they
were
like.
A
Well,
we
want
to
just
turn
on
single
sign-on
across
a
little
instance,
but
we
can't
do
that
by
managing
both
of
these,
and
my
feedback
to
them
was
like
working
on
these.
This
project
level
access
to
open
these
service
users.
You
can
just
convert
all
your
on
a
to
that
type
of
user,
and
then
you
can
just
use
all
the
humans
getting
getting
them
on
SSO
and
they
were
really
excited
on
that.
A
So
be
sure
that
async
gets
a
feed
back
to
them,
make
sure
that
works
for
them,
but
this
is
going
to
be
huge
for
customers.
I
think
one
question
I
had
was
I
know
that,
like
the
secure
stage
was
thinking
about
using
bots
in
a
way,
do
you
know
if,
like
this
helps
them
in
any
way
that
they
can
kind
of
leverage
or
are
they
kind
of
doing
their
own
things?
Yeah.
C
So
we've
actually
been
syncing
up
with
them
a
little
bit
on
this.
We
both
were
doing
our
own
sort
of
independent
effort
on
on
similar
things.
What
they're
trying
to
do
is
an
auto
really
a
remediation
bot,
so
it's
kind
of
similar
to
things
like
alert,
bot
and
support.
Basically,
they
all
have
kind
of
different
requirements.
C
There
are
all
bots
that
do
that
do
specific
things,
but
the
way
that
we've
been
collaborating
on
them
is
just
basically
in
for
keeping
them
informed
on
how
we're
shipping
this
and
how
we're
kind
of
handling
the
logic
of
the
actual
bot
user.
On
the
back
end
and
there's
been
some
discussions
around
basically
creating
a
kind
of
standardized
way
of
any
group
who
is
an
any
engineering
group,
that's
working
on
a
type
of
bot
for
a
particular
reason,
so
that
it's
really
easy
for
them
to
pick
up
that
kind
of
logic
and
go
hey.
C
A
B
C
Far
as
that,
as
far
as
I'm
aware
they're,
not
using
anything
we're
doing
at
the
moment,
they're
just
sort
of
waiting
to
see
what
we
do
and
then
learning
from
it
they're
a
little
bit
kind
of
behind
at
the
moment
that
they've
done
a
lot
of
work
just
on
the
front
end
of
how
they
want
this
to
work
for
users
and
then
I
think
they're,
trying
to
see
how
we
how
we
handle
the
back
end
of
it.
So
maybe
we
don't
know
yet
yeah.
A
Their
use
case
is
primarily
like
we
don't
we
don't
have
any
automation
on
our
knee
box
right
now
them
aware
of
that
specifically
do
things
in
the
product
on
your
behalf
and
that's
like
we
have
some
box
of
the
supply
users
in
the
product
right
now,
but
they're
not
they're.
Very
specific
use.
Cases
like
one
is
ghost
user,
which,
when
you
delete
a
user
all
of
their
stuff
gets
migrated
to
to
ghost
you
sure.
So
you
lose
the
user
model.
A
E
A
Think
their
use
case
is,
you
know
when
they
find
security
vulnerabilities,
that
you
can
go
ahead
and
fix
like
there's
a
dependency
update
that
you
can
just
immediately
like
create
a
merge
request,
or
we
should
have
a
bot
user
that
just
creates
that
merge
request
for
you,
so
that
you
can
either
merges
it
automatically
or
a
human
checks
it
and
they
click
on
the
merge
button.
Then
that's
done
that's
kind
of
first
time.
We've
ever
had
anything
like
that
before,
and
so
they
were
originally
like
spiking
on.
B
Yeah
I
think
interesting,
like
feature
iteration
of
this
would
be
like
to
create
BOTS,
have
very
narrow
access
like
right.
Now,
it's
just
project-based
right,
but
a
future
iteration
would
be
like.
Can
only
do
these
like
two
or
three
things,
and
it
can
do
nothing
else
right.
So
that
way
you
can
scope
it
very
specifically,
I
think
customers
would
really
like
that.
I
mean.
That
sounds
like
what
we're
trying
to
do.
Oh
yeah.
C
But
the
big
I
mean
honestly,
the
big
thing
that
we're
trying
to
try
to
help
customers
with
here
is
things
like
right
now:
they're
they're,
anxious
about
creating
users
for
this
for
a
couple
of
reasons
like
one
they
might
be
a
small
company,
they
don't
necessarily
have
the
you
know
the
budget.
So
how
like
tons
of
users,
for
example,
that
and
having
a
single,
an
actual
paid
user
account
means
that
normal
users
have
access
to
that.
That's
a
potential
security
risk
on
top
of
that,
because
they're
trying
to
save
money
on
license
costs.
C
What
they're
actually
doing
is
they're
creating
one
user
to
do
lots
of
things,
and
that
then
makes
it
really
hard
for
them
to
audit
what
that
users
doing
and
like
actually
keep
track
of
things.
So
that
kind
of
bleeds
a
little
bit
into
places
like
compliance
and
security,
is
a
problem
there.
So
those
are
some
of
the
problems
that
we're
trying
to
mitigate
here
and
we've
learned
that
the
cost,
whilst
it
was
it's
painful,
it's
actually
just
a
really
awful
symptom
of
having
to
utilize
user
accounts
for
this.
C
So
it
turned
out
that
security
and
whatnot
is
actually
the
biggest
problem
they
were
trying
to
solve
here
for
this,
so
you're
right,
like
it
being
able
to
kind
of
shrink
down
in
scope
as
small
as
possible
as
to
what
these
bots
are
doing
versus
are
some
customers
that
want
to
just
expanded
everything
like
if
we're
able
to
provide
that
functionality
and
flexibility
to
customers.
That'd
be
amazing
as
an
end
vision
for
this.
E
So
yeah
so
there's
several
issues
that
were
planning
for
thirteen,
oh
and
a
lot
of
it
has
to
do
with
art
events.
Some
iteration
on
the
combines
dashboard,
but
where
we're
starting
is
an
iteration
on
feature
released,
I
believe
it
was
in
twelve
nine
that
allows
administrators
to
set
merge,
request
approval
rules
at
the
instance
level,
and
the
first
iteration
was
meant
to
provide
that
functionality
period.
Now
we
have
to
focus
on
how
do
we
allow
the
flexibility
to
refine
the
scope
of
where
those
rules
apply,
because
applying
it
to
every
single
project?
E
In
an
instance
is
not
practical,
it's
not
solving
the
problem.
It's
like
it
could
create
more
work,
and
so
what
the
next
iteration
here
is
we're
gonna
allow
administrators
that
if
they
enable
those
settings
at
the
admin
level,
only
administrators
can
then
toggle
on
or
off
those
settings
at
the
project
level
and
in
a
future
in
13:1.
E
Actually
we're
going
to
follow
that
up
by
allowing
them
to
refine
the
scope
to
specific
projects
based
on
a
compliance
label
so
trying
to
work
towards
that
holistic
solution
to
allow
them
the
flexibility
to
enforce
that
at
a
global
level.
We're
also
adding
audit
events
for
admin
impersonation.
So
a
critical
point
of
audit
logging
is
something
called
non-repudiation.
Basically,
nobody
somebody
could
not
deny
that
they
took
some
action,
and
so,
if
an
admin,
if
an
administrator
right
now
impersonate
someone
take
some
action,
it
shows
up
in
the
audit
log.
E
E
One
of
the
issues
that
we've
been
working
on
and
had
some
technical
challenges
that
should
allow
to
ship
in
13o
is
filtering
audit
events
tables
within
the
application.
So
right
now,
customers
are
having
to
build
custom
tooling
via
API
is
to
be
able
to
pull
the
data.
They
need
aggregated
into
other
systems,
but
there's
a
demand
by
especially
non-technical
users
of
our
platform,
to
be
able
to
go
and
dig
through
the
audit
events
without
that
complication
or
that
technical
hurdle.
E
So
adding
simple
functionality
to
improve
usability
such
as
sorting
and
filtering
seems
like
a
pretty
obvious
choice,
and
so
we're
excited
to
bring
that
a
simple,
friendly
experience
to
the
app
we're
also.
So
this
is
another
one
that
proved
to
be
technically
challenging,
but
bringing
push
rules
to
the
group
level.
So
in
this
iteration
in
13,
oh
I
believe
it
will
be
the
first
iteration,
that's
actually
available
or
visible
to
users.
E
It
currently
exists
in
the
production
code
base,
as
of
1210
or
or
will
I
should
say,
but
in
13
oh
that'll
be
when
it's
actually
available
to
users
and
then
we'll
continue
to
make
some
improvements
on
the
back
end
and
13:1.
But
that'll
provide
the
flexibility
that
customers
are
asking
for
to
be
able
to
define
these
not
quite
at
the
global
scale,
but
also
not
with
the
the
tedium
of
having
to
go
into
projects
to
define
this
and
the
last
one
is
an
iteration
on
the
compliance
dashboard.
E
E
But
if
you
know
using
some
conditional
logic,
if
merge
request,
authors
command
committers
are
not
allowed
to
merge,
merge
requests
and
if
the
minimum
number
of
provers
is
set
to
two,
for
example,
then
we
should
surface
a
signal.
It
says.
Yes,
everything
here
looks
great
segregation
of
duties
is
maintained,
no
need
to
dig
any
further.
Conversely,
if
we
find
that
one
or
multiple
of
those
conditions
are
not
true,
and
maybe
authors
can
approve
VMR,
and
maybe
the
number
of
approvers
is
zero,
then
that
should
raise
a
signal
for
somebody
to
go
and
investigate.
E
Why
is
that
the
case?
Maybe
it's
an
unregulated
project,
a
personal
project
and
that's
fine,
but
maybe
it's
not,
and
so
we're
trying
to
be
able
to
save
time
and
effort
by
aggregating
this
key
data
at
the
compliance
dashboard
level
that
pretty
much
sums
up
the
compliance
group.
Are
there
any
questions.
F
Question
about
the
end
result
that
you
propagate
up
off
those
checks.
It
seems
like
you
have
three
states
like
all
pass.
Some
paths
and
known
pass
is
that
kind
of
the
smallest
thing
that
we
could
should
do?
I
was
thinking
like
just
nap
or
down
would
be
a
smaller
iteration
I,
don't
know
if
there's
value,
so
you
probably
have
feedback
from
the
customer.
If
there's
value
in
distinguishing
between
some
passing
and
non
passing,
yeah.
E
I
mean
that's
a
great
question:
I
think
that
we
could
break
it
down
even
smaller
and
we
may
have
to
add
a
necessity
because,
prior
to
like
planning
finalization,
we
had
the
bandwidth
to
do
exactly
what
was
proposed
there.
But
as
we
come
concluded,
the
planning
meeting
we've
realized
that
we
might
be
kind
of
short
as
far
as
capacity,
so
we
may
have
to
have
necessity.
E
There's
value
I
think
in
showing
a
simple
like
thumbs-up
thumbs-down.
But
the
problem
we're
trying
to
solve
is
that
we
don't
want
them
to
have
to
go
into
multiple
projects
unnecessarily.
So
the
more
insight
we
can
provide,
initially
the
the
fewer
projects
are
having
to
dive
into
and
now
that
you
know
that
for
a
project
or
sorry,
a
group
that
has
ten
projects
not
a
huge
deal,
but
we
have
these
enterprise
accounts
that
have
thousands
of
projects.
E
A
Cool
things:
can
you
tell
me
a
little
bit
more
about
the
problem
in
allow
admins
to
modify
a
more
approval
settings
at
Project,
gobble
I'm,
just
wondering
to
myself
in
thinking
like
this
is
an
improvement
that
affects
only
administrators.
At
the
moment
it
looks
like
so
and
the
type
of
user
that
an
admin
generally
is
is
it's
generally,
like
a
you
know,
they're
very
small
handful
of
like
blessed
users,
because
they
have
pseudo
access
to
basic
everything
in
the
instance
rate,
so
the
is
there.
A
Have
we
considered
like
owners
in
this
or
other
babies
of
like
thinking
about
other
types
of
users
because
like
if
we're
allowing
admins
to
be
able
to
subvert
approval
settings
at
the
project
level,
I'm
just
wondering
is
that
something
that
they're
going
to
be
doing
on
a
frequent
basis?
Is
that
the
right
type
of
user?
What
was
the
kind
of
motivation.
E
There
you
think
so
the
the
motivation
I
as
I
understood
it
was
the
the
admins
of
these
self-managed
instances
tended
to
be
the
folks
that
were
either
engaging
with
internal
audit
and
compliance
or
were
they
themselves.
The
maybe
I'll
call
them
program
managers
for
lack
of
a
better
phrase
right
now,
and
so
they
basically
said
we
want
full
control
of
this.
We
want
to
be
able
to
set
this,
and
then
we
want
to
be
able
to
go
determine
which
of
these
projects
should
be
exempted.
E
However,
comma
I
do
believe
that
a
natural
iteration
is
to
bring
it
to
both
to
bring
to
the
group
level
in
some
way
and
or
to
allow
group
owners,
because
I
think
the
reaction
right
now
is
largely
based
on
you
know,
kind
of
being
audit
season.
A
lot
of
the
conversations
we
had
were
either
before
during
or
immediately
following
an
audit
and
so
I
think
there's
a
particular
sensitivity
but
I.
A
Makes
total
sense
cool
cool
thanks
for
thanks
for
considering
that
I'm
also
really
excited
about
the
audit
event
for
admin.
Impersonation,
like
I,
know
that
you
know
you've
been
working.
The
collectors
were
working
a
lot
of
events
for
some
time,
but
it's
always
been
something
that
I've
hoped
we
could
get
to
to
make
sure
that
we
we
don't
we're
attributing
other.
That's
to
the
right
user
and
I'm
really
excited
to
see
that.
So,
thanks
for
prioritizing
that
yeah.
A
F
You
bring
us
all,
oh
so,
imports
in
13,
oh,
is
continuing
down
down
the
path
of
two
different
direction.
Issues
I've
talked
about
both
of
these
last
time
around
and
I'll
update
this
to
12:10.
So
this
these
are
both
carryover,
but
I'll
talk
about
each
one
of
them
to
see
where
we
are
and
how
far
we've
gotten
and
what's
what's
to
be
expected
in
13.
Oh
the
first
one
is,
you
know,
looking
at
the
user
experience
for
for
importance
in
particular
to
for
the
new
project
creation
flow.
F
We
are
looking
to
replace
this
view
with
a
more
explicit
selection
for
whether
the
user
wants
to
start
with
a
blank
project
created
from
template
or
or
import
in
order
to
increase
the
discoverability
of
those
choices.
So
this
is
kind
of
the
new
landing
page
when
you
view
that
we're
looking
to
implement
in
order
to
do
that,
so
all
four
choices
will
be
described
on
the
page
and
the
user
will
be
able
to
kind
of
make
a
more
educated
selection
on
which
which
path
they'll
take
we're
not
looking
to
fully
realistic
spear
Ian.
F
So
once
you
land
on
this
page,
the
page
is
further
down.
The
flows
are
going
to
be
very
similar.
The
pages
are
going
to
look.
A
little
different
will
have
new
graphic
there,
but
the
flow
past.
This
first
page,
is
going
to
be
kind
of
the
same
from
there.
So
you'll
be
able
to
select.
You
know
whether
a
template
or
an
import
you're
going
to
work
with,
and
once
you
hit
the
import
and
going
to
get
you
there,
so
that
is
in
play
for
13.
F
Oh,
the
other
feature
is
as
actually
and
we've
turned
it
into
an
epic.
It
was
a.
It
was
a
issue
when
we
talked
about
it
first,
but
we've
created
several
issues
to
sort
of
break
it
down
further
and
get
and
be
able
to
deliver
some
of
them
in
one
milestone
and
the
rest
in
the
next.
So
the
this
is
the
first
attempt
to
put
a
user
experience
or
a
UI
on
the
group
export/import,
which
up
until
now
exists
only
through
API.
F
So
we're
doing
this
to
make
it
so
that
people
can
use
the
UI
to
migrate
groups
and
further
down
will
look
to
incorporate
that,
together
with
the
project
export
import,
to
create
an
experience
where
the
user
will
be
able
to
migrate
entire
groups
and
all
the
sub
projects
using
the
UI
between
two
instances
of
good
lab.
Where
we
are
on
this
right
now
is
we
are
on
track
to
complete
the
export
part
of
it.
The
import
is
actually
the
import
of
the
groups
is
the
is
in
progress,
but
it's
not
going
to
make
30.
F
F
So
when
the
export
is
completed,
the
user
will
receive
an
email
and
also
on
the
import
side,
adding
an
import
state
to
to
the
group
so
that
we
we
can
query
the
state
of
the
import
and
know
where
the
import
is
in
order
to
tell
these
are
the
import
is
in
progress
where
the
import
has
actually
completed
or
failed.
So
these
are
in
various
state
of
implementation
and
all
targeted
for
13o.
F
F
The
group
will
get
an
export
button,
export
dialog
on
the
on
the
settings
page
where
these
are
we'll
be
able
to
kick
off
an
export
and
then
once
the
export
is
kicked
off.
These
are
will
be
able
to
import
a
group
on
the
page
where
the
group
is
created.
So
the
group
creation
page
will
will
start
looking
a
lot
like
the
project
import
page
where
the
user
will
be
able
to
select
either
new
group
or
an
imported
group.
B
F
Question
so
for
for
this,
the
prep,
the
kind
of
reason
why
we
started
some
of
this
is
for
allow
for
the
migration
of
its
host
customers
to
dot-com,
but
this
is
definitely
used
for
for
migration
in
both
directions.
So
a
large
customer
that
may
have
outgrown
or
may
have
requirements
to
get
off
of
calm
and
go
into
self
hosted
scenario
can
use
this
tool
from
common
to
self
hosted
and
vice
versa.
Somebody
who's
self
hosting
will
be
able
to
to
to
to
migrate
to
calm.
So
really,
both
scenarios
are
supported.
A
F
So
so
the
process
of
good
is
going
to
be
exactly
the
same,
as
is
for
project
right
now.
You
will
be
able
to
download
archive
file,
and
then
you
will
use
that
archive
file
to
import
or
upload
into
your
newest
instance.
So
what
we're
looking
sort
of
in
as
a
direction
or
vision
for
for
the
import
group
is
to
move
this
out
of
the
realm
where
people
have
to
save
off
large
files
and
then
upload
them
later.
We're
gonna
we're
researching
right
now.
F
The
ability
to
move
into
an
instance
instance
communication,
where
the
files
will
no
longer
be
the
way
to
do
to
transfer
the
groups
or
projects
so
we're
going
to
try
to
move
away
from
files,
but
for
this
MVC
we're
pretty
much
putting
a
UI
on
top
of
the
API.
That
org
is
this
and
the
API
is
such
that
it
kicks
off
a
file
creation.
It
lets
you
download
that
file
and
then
it
lets
you
upload
a
file
into
new
instance.
That's.
A
Great
very
cool,
thank
you.
The
other
thing
that
I
would
I
would
I
would
consider.
Is
I
I'm
really
excited
to
see
the
the
better
UX
for
project
creation,
the
MOC
that
you
showed
her
a
really
interesting
kind
of
direction?
I'd
be
really
interested
to
see
if
we
can
make
sure
that
we
have
data
to
see
how,
when
we
ship
this,
how
it
affects
kind
of
confronted
completion
and
can
music
and
conversion
to
actually
people
many
projects.
A
So
if
you
hadn't
haven't,
haven't
thought
about
that,
it
courage
you
to
kind
of
reach
out
to
the
data
team
or
CID
the
telemetry
PM,
to
say
like
hey.
How
can
we
make
sure
that
we
measure
the
impact
of
this
I
know
the
growth
growth
stage
has
been
thinking
about
a
be
testing,
I,
don't
know
for
yet
we
are
a
be
testing
at
the
moment.
This
would
be
really
cool
candidate
for
it.
Something
to
consider,
but
I
think
we
should
have
some
measurable
outcomes
for
this.
So
we
can
see
what
the
impact
is.
A
A
That's
a
great
example
of
a
cool
change
that
is
gonna
directly
impact
a
North
Star.
So
thanks
for
that
awesome
well,
thank
you
all.
So
much
really
excited
about
13,
as
always,
but
IRA
preciate
I
really
appreciate
you
sharing
all
your
thoughts
and
questions
on
this
discussion.
So
thanks
again
for
the
great
kickoff
I
appreciate
it.
Thanks
all
y'all
Cheers
I
see.