►
From YouTube: Manage:Import 13.9 planning
Description
This is the sync planning session for the 13.9 milestone for the Manage:Import group.
Planning issue shown:
https://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17303
Notable epics mentioned:
Complete Epic migration - https://gitlab.com/groups/gitlab-org/-/epics/5189
Scaling the GitHub Importer - https://gitlab.com/groups/gitlab-org/-/epics/5042
Tech debt - https://gitlab.com/groups/gitlab-org/-/epics/4931
A
So
unofficial
welcome
to
the
13
9
planning
call
for
import.
A
We
are
going
to
be
looking
at
the
milestone
and
just
discussing
high
level
roadmap
as
well
as
objectives
and
highlighting
some
of
the
issues
that
we
might
be
working
on,
even
if
we're
working
kanban
we're
not
going
to
try
and
predict
exactly
which
issues
are
going
to
come
across
and
where
the
line
is,
but
we'll
just
talk
about
it
in
terms
of
what's
possible
and
what's
probable.
A
A
I
don't
have
anything
noted
yet,
but
if
we
have
outages
for
more
than
a
couple
of
days
or
even
with
just
a
couple
of
days
during
39,
we
should
probably
just
note
that
so
anyone
planning
some
plans
to
take
off
any
time.
B
A
D
A
A
Cool,
so
that's
that's
that
team
velocity
for
13.8
does
not
does
not
reflect
everything
that
will
be
enrolled
in
in
the
next
five
days.
So
last
time,
when
we
looked
at
it,
it
was
kind
of
similar.
I
just
didn't
want
to
share
that,
because
when
we
looked
at
13
7
last
time
it
looked
like
it
was
going
to
be
a
really.
You
know
like
this
small
release.
It
ended
up
being
that
1307
is
the
highest
number
of
issues.
We've
ever
closed
in
thanksgiving.
B
Yeah,
it
was
the
the
ilia
front
and
also
that
urgent
demands
that
we
got
all
together.
Yeah.
A
A
So
that's
clearly
an
anomaly,
but
I
just
want
to
kind
of
point
out
that
we
really
never
during
this
meeting.
We
never
know
what
the
previous
month,
what
the
previous
release
kind
of
looked
like
like
13
7.
We
have
no
idea
where
that's
gonna
hit
unless
we
do
some
better
prediction
and
maybe
just
manually
add
up
some
of
the
things
that
are
in
progress
to
sort
of
see
where
they're
going
to
land,
which
I
used
to
do,
but
I
have
stopped
doing
that.
But
anyway,
you
know
the
the
larger
story
is.
A
I
believe
that
our
like
three
month
average
doesn't
seem
to
budge
much.
So
I
think
that
may
be
helpful
in
a
way.
So,
while
one
month
could
be-
and
this
is
about
weight,
so
yeah
one
mine
could
be
40,
the
other
one
could
be
15,
but
somehow
we
average
around
30
or
so
in
weight.
A
So
we'll
see
just
kind
of
something
to
keep
in
mind
now
that
we're
gonna.
This
might
be
helpful
only
in
trying
to
figure
out
which
things
we
might
mark
as
deliverable
sort
of
advertising.
Some
of
that,
but.
A
It's
an
interesting
data
point
really
at
this
point.
A
A
One
is
the
git
lab
group
migration
and
the
other
one
is
the
github
scaling
the
github
experience
and
getting
to
a
better
github
importer.
So
for
the
gitlab
group
migration,
I
have
laid
out
a
series
of
large
epics
that
take
us
from
where
we
are
today,
which
is
the
mvc
kind
of
the
minimal
something
we
can
show
and
start
getting.
Some
feedback
on
to
parity
with
the
current
group
export
import,
which
I
think
would
be,
would
make
it
a
viable
solution
for
anyone
migrating
groups.
So
I
don't
see
like
at
this
point.
A
If
we
do
this
right,
there
should
be
no
reason
for
people
to
use
the
file
export
import
to
just
migrate.
A
group
over.
They
could
still
potentially
use
it
for
backups
and
restores,
and
that's
something
that
I'm
gonna
have
to
deal
with
kind
of
understanding
what
those
needs
are
and
whether
we
could
deprecate
the
export
import
to
that
point
of
not.
A
But
I
think
that
really
makes
it
a
viable
solution
for
that
aspect
and
then
three
more
steps
would
take
us
to
complete
being
able
to
have
users
migrated
in
the
groups
and
then
adding
all
the
project
metadata.
You
know
issues
labels,
you
know
just
migrating
projects
and
then
also
migrating
repositories.
A
Commits
merge
requests
all
the
things
related
to
code
and
finally,
we
do
have
a
pile
of
things
that
kind
of
add
up
to
a
great
user
experience
to
just
make
this
a
world-class
feature
as
far
as
user
experience
goes,
however,
we're
not
going
to
wait
until
the
end
to
take
care
of
some
of
this
stuff.
A
A
So
I
expect
this
epic
to
be
closed
by
the
end
of
13
8.
So
for
39,
we're
gonna
take
the
next
step,
which
is
our
road
to
viable,
and
this
is
the
epic
to
do
that,
and
the
very
first
step
in
that
epic
is
finishing
off
epic
migrations,
so
epics
currently
are
migrated
with
half
of
the
attributes,
so
some
things
about
epics
come
across,
but
not
all
this
here
lists.
All
of
the
things
that
we
would
need
to
migrate
related
to
epics
in
order
to
complete
epic
migration
as
part
of
root
migration.
A
So
that's
on
the
gitlab
group
migration
side
of
things
for
the
github
importer,
I've
sort
of
identified
two
epics
that
will
help
us
reach
the
complete
maturity.
I
mean
this
is
currently
a
viable
product.
It
is
not
complete,
it
has.
Things
are
missing
before
the
market
will
admit
that
it's
complete
one
is
a
scalable
user
experience
so
being
able
to
migrate
larger
organizations
that
may
have
thousands
of
projects
successfully
in
this
way
currently
is
almost
impossible
and
it
would.
A
It
is
not
feasible
for
our
customers
to
use
the
current
user
experience
because
it
and
we're
unable
to
show
more
than
more
than
x,
we're
not
able
to
import
more
than
xu.
You
don't
know
where
you
are
in
the
process
and
it
just
does
not
scale
well
for
thousands
of
things
to
be
done
and
the
other
one
is
really
going
deeper
on
the
github
concept,
and
that
is
importing
things
that
we
currently
don't
import.
Like
snippets
organizations
and
sorry
go
ahead,.
A
I
did
change
it,
so
let
me
just
reshare
again
because
it's
probably
the
fastest
way
to
get
a
refresh.
I
don't
know
of
any
other
way
to
do
that.
D
A
Third
time's
charm
nope,
it
doesn't
seem
like
I
can.
A
Yeah
there
may
not
be
a
way
to
fix
this.
What
would
somebody
else
mind
just
maybe
sharing
the
either
the
board,
or
I
mean
I
can
I
can
move
forward
from
here.
I
don't
think
I
need
to
talk
about
the
github
report
as
much.
Maybe
just
the
planning
I'll
just
create
a
new
window
and
see
if
it
could
be
shared
and
then
stuff
would
just
I'll
stick
with
just
one
window.
A
No,
it
doesn't
seem
to
work
well.
I
could
talk
my
way
through
it
and
I'll
put
a
link
to
the
planning
issue
in
the
in
the
video
for
those
who
are
watching.
But
if
you
who
are
uncalled
online
just
opening
the
planning
issue,
that's
linked
in
the
meeting
invite.
A
Okay,
so
I'll
just
pause
here,
because
I
just
need
to
talk
through
through
the
items
on
here
in
a
way,
so
I've
talked
about
kind
of
two
different
directions
that
we're
trying
to
make
progress,
and
the
main
directional
item
for
us
is
the
gitlab
migration
and
the
goal
or
the
objective
for
this
milestone
is
to
start
on
the
road
to
parity
with
group
export
import
by
working
on
the
on
completing
the
epic
epic
migrations.
A
A
The
kind
of
secondary
arm
to
that
is
this
continuous
ux
improvement.
We're
going
to
wait
until
the
end.
To
just
add
all
the
usability
features
so
we'll
be
adding
features
along
the
way
two
features
are
in
progress
in
13
8
and
if
they
get
missed,
we'll
roll
them
into
39
they're
still
the
highest
priority,
but
past
that
we
are
gonna
start
working
on
the
pagination,
because
that
will
allow
our
experience
to
scale
and
also
this
is
somewhat
related
to
the
github
scaling.
E
A
Yeah,
that's
fair
enough,
so
well,
I
think
we'll
we'll
focus
on
the
git
lab
migration
view
and
finish
our
pagination.
The
way
we
like
it
there
that
would
include
selectable,
page
size
and
potentially
ability
to
multi-select
from
the
list
and
then
say
import
all
these
once
we
get
some
of
those
interactions
that
we
want
to
have,
I
think,
we'll
circle
back
at
that
point
to
github
and
make
that
the
same
experience.
So
I
don't
want
to
work
on
these
two
in
parallel,
because
they'll
be
chasing
each
other.
A
I
think
we
can
focus
on
the
migration,
the
the
group
migration
stuff
and
make
sure
that
its
pagination
is
kind
of
the
way
that
we
need
it
and
then
we'll
translate
that
over
to
github-
and
you
know
finish
that
up,
so
that
is
just
a
precursor
of
what's
coming
for
github
in
this
particular
milestone.
There's
there's
at
least
one
issue.
That
seems
like
it's
a
good
issue
for
front-end
to
take
on.
That
is,
I
believe,
independent
of
any
back-end
work,
and
that
is
the
refresh
of
the
status,
because.
A
Is
such
that
when
you
click
import
it
refreshes,
then
and
then
doesn't
refresh
again
until
I
either
refresh
the
page
or
I
hit
another
import,
and
then
it
refreshes
all
the
other
ones.
I
mean
it
is
very
confusing
as
far
as
how
the
experience
goes,
so
that
may
be
something
to
to
look
into
next
on
the
github
front,.
E
Yeah,
this
actually
needs
a
bit
more
investigation.
I
will
deal
with
that
because
basically
front-end
code
for
polling
is
here:
it
is
identical
for
other
importers,
so
and
I
saw
it
working
there,
so
I
just
need
check
some
time
ago.
I
saw
the
issue
with
background
jobs,
reporting
kind
of
stuck
status,
so
I
can't
100
guarantee
that
this
is
a
pure
front-end
issue,
but
I
will
take
lead
and
try.
Egypt
and
debunk
it.
Okay,.
A
Awesome
and
finally,
the
things
that
you
know
to
to
other
issues
that
I
want
to
highlight
are
the
instrumentation
we
had.
We
made
a
lot
of
progress
in
understanding
exactly
how
we
want
our
usage,
things
structured
to
look
like
which
usage
paints
we
want
to
keep
and
what
their
definition
definitions
are.
A
So,
I
think
that's
that's
kind
of
the
highlights.
There
are
other
things
in
the
ready
for
dev
and
and
in
the
ready
for
dev
column,
and
you
know
once
we
exhaust
those
and
ready
for
refinement
as
well,
which
we
can
pay
attention
to
if
we
get
through
everything
that's
listed
here.
So
that's
that's
kind
of
the
big
picture
for
where
we
are
kind
of
a
high
level
we're
trying
to
accomplish
what
are
some
midterm
goals
and
what
we're
looking
to
do
in
1390.
C
Yeah,
I
think,
there's
one
thing:
that's
would
be
good
to
work
on
regarding
the
bulky
importance
that
the
technical
improvements
are
epic.
C
Distributed
execution
of
the
import
process
is
one
of
them.
I
I
worked
on
only
partially,
but
the
issue
is
still
there
there's
another
issue
about
memory,
consumption
of
the
importer
itself.
C
A
So
would
you
be
able
to
identify
the
top
one
or
two?
As
I
mean
it
seems
like
you,
have
right
and
just
work,
those
into
13
8
sort
of
in
between
all
the
other
things
we're
delivering.
So
we
may
deliver
fewer
fewer
of
these
because
we
inserted
some
of
the
technical
debt
repayment
in
there.
So
I'm
okay
with
you
just
managing
that
and
working
on
those
as
it
makes
sense,
whether
together
or
in
between
things.
A
I
don't
think
we
do
have
to
pick
him
now,
but
then,
once
you
do
just
if
you
would
like,
in
this
case,
assign
13a
to
it,
then
it
might
be
easier
to
to
see.
Also
I
mean
if
you
would
like
to
just
open
up
this
epic
and
maybe
help
me
prioritize.
These
help
me
order
these
in
the
order
of
this
is
the
most
important
technically
or
for
for
engineering
to
the
least
important.
So
we
can
like
have
some
kind
of
order
and
know
what
what
what
to
work
on.
First.
A
A
Yeah,
yes,
so
that'd
be
good.
If
you,
if
you
identify
the
two
or,
however
many
you
can
definitely
add
in
here,
so
we
have
visibility
into
what's
happening,
but
also
past.
That
it'd
be
good
to
just
have
some
kind
of
ordered
list
here
to
work
off
of.
E
E
E
E
A
I
know
we're
lost
enough,
so
it
seems
that
the
empty
state
handling
is
one
of
the
issues
that
is
raised
here,
and
that
is
when
we
have
no
local
top
groups
available.
B
A
Yes,
we
can
hear
you
now
and
we
were
just
reading
through
the
comments
you
made
about
the
empty
state
handling.
E
Yeah,
it's
exactly
this.
Why
I'm
concerned,
because
I
expect
people
to
start
trying
this
feature
and
if
we
receive
feedback
like
hey,
this
is
totally
not
working.
It
will
not
be
like
useful
feedback
for
us,
so
it
would
be
from
my
point
of
view
worth
investing
at
least
at
some
low
hanging
fruits
on
like
flows
where
the
user
might
fail
and
fail
like
in
expected
way.
A
Okay,
that's
that's
fair.
We
should
probably
so
we
can
take
up
that
in
ux,
first
and
just
kind
of
quickly
describe
what
we
want
the
behavior
to
be
and
potentially
be
able
to
refine
it
for
39.
You
know,
while
you're
still
dealing
with
some
of
the
other
issues
that
are
on
your
plate
already.
E
Yeah
and
another
just
making
letting
you
know,
I
think
I'm
gonna
split
the
pagination
issue
in
one
making
the
trivial
pagination
we've
had
for
project
importers,
and
there
is
a
reason
for
that.
I've
discovered
that
actually
we
are
already
silently
paginating
remote
repositories.
E
So
right
now
there
is
no
way
to
access
something
beyond
second
page
for
users
and
when
we
will
add
the
status
like
it
is,
it
looks
extremely
funny
like
we
are
displaying
20
of
your
80
repositories
and
right
now
you
have
no
way
to
access
the
rest
of
them
while
filtering
is
not
landed.
So.
E
But
I
have
a
broader
question.
I
would
like
to
raise
with
the
entire
team,
because
it
concerns
me
a
bit
like
as
a
user
of
the
feature
and
from
what
I
understand
when
I
was
trying
to
use
it,
we
are
using
graphql
endpoints
to
fetch
data,
and
some
of
graphql
endpoints
are
currently
missing
for
data.
We
will
be
required
to
import.
Of
course,
we
could
probably
add
them,
but
this
will
limit
the
I
mean
these
endpoints
must
be
available
on
remote
server.
E
So
do
we
thinking
about
how
we
could
handle
when
the,
for
example,
some
endpoints
are
not
available
on
remote
server
and
like
hey?
This
version
of
gitlab
will
not
allow
you
to
import
this
this
and
this
because
this
might
be
a
very
interesting
problem
to
address
and
to
consider
in
our
future
moving
forward.
I
hope
I'm
clear
about
it
clear
enough
about
the
problem.
B
Yep
george-
and
I
actually
discussed
about
that
today-
I
think
or
yesterday-
and
we
are
already
facing
this
problem.
One
of
the
data
that
we
are
importing
from
epics
was
added
when
we
did
the
epic
importer.
So
we
started
to
discuss
about
that.
I'm
not
sure
if
we
open
an
issue
or
not,
but
it's
probably
one
of
the
technical
depth
issues
that
we
should
add.
B
Maybe
we
could
put
some
kind
of
version
validator
pair
importer
or
something
like
that
to
check
if
we
are
able
to
import
epics,
for
instance,
the
sirs
gitlab
version
should
be
at
least
x.
Otherwise
we
won't
be
able
to
import
that
because
we
probably
can
do
something
like
that.
E
That's
exactly
the
problem
I
want
to
raise
because,
like
if
people
try
to
import
2gitlabcom
from
there
just
a
bit
outdated
instances
that
might
fail
and
will
be
confusing.
C
Yep,
unfortunately,
that's
the
reality,
especially
with
epics.
There
there's
some
stuff
missing
the
moment
we
added
you
know.
If
we
try
to
fetch
that
information
from
remote
that
doesn't
have
it,
we
can't
import
it.
So
we
will
have
to
add
some
sort
of
logic
that
I
don't
know
how
we're
going
to
approach
it.
Yet
from
the
backend
perspective,
can
we
do
partial
import
or
not
like
let's
say
without
emojis
or
whatever,
but
yeah
right?
C
Now,
it's
a
straight
up
exception
that
is
uncaught
as
well,
so
yeah,
that's
something
we'll
have
to
take
care
of.
A
That's
it's
a
really
excellent
point.
Elia,
thanks
for
raising
that,
I
would
say
that
there's
probably
a
couple
different
things
we
can
talk
about,
one
is
documentation
upfront,
so
our
documentation
should
reflect
so
anyway.
Now
that
we
have
a
documentation
page
as
we
add
things
so
as
we
complete
the
epics,
if
there
is
a
minimum
remote
version
that
we
need
to
be
on
for
the
epics
to
be
completely
moved,
that
should
be
added
to
documentation
at
the
end
of
so
you
know
at
the
end
of
that.
A
Once
once
the
issue
is
implemented,
so
once
we
implement
the
issue
for
epics
and
we
add
the
fact
that
epics
are
now
completely
migrated,
there
should
be
a
note
in
there
for
the
minimum
version
of
remote.
So
that's
the
minimum.
What
should
we
should
do
is
as
we
implement
things,
and
we
should
note
the
minimum
version
for
that
to
work.
A
George
brought
up
something
that
I
think
I'm
interested
in,
that
is
kind
of
a
graceful
failures
so
being
able
to
import
some
things
and
not
some
so
not
have
just
one
big
failure
where
it
says.
Well,
you
just
can't
do
anything,
but
if
we
were
able
to
tell
the
user
in
the
warning
once
they
connect,
or
you
know
somehow
we'll
figure
out
how
to
do
that
once
they
connect
to
the
other
instance.
If
we
can,
you
know
detect
what
it
is
and
tell
them.
A
A
Result
like
you
know,
we're
gonna
start
telling
the
users
what
happened
in
the
end
pretty
soon,
because
we
do
have
that
issue
as
well
coming
up,
which
will
tell
you,
know,
give
the
users
kind
of
a
manifest
or
a
result
page
that
tells
them
this
worked
and
they
didn't
so.
We
should
be
noting
during
the
import.
What
worked?
A
What
didn't-
and
this
would
be
one
of
those
things
that
we
could
know
so,
even
if
we
didn't
predict
it
ahead
of
them
trying
if,
for
whatever
reason,
something
didn't
get
imported
it'd,
be
good
to
show
that
an
error
message
in
the
end.
So
anyway,
those
are
my
thoughts
and
the
other
one.
The
other
thought
I
have
is
well.
Is
there
anything?
We
can
do
right
now
to
sort
of
alleviate
that
as
much
as
possible.
A
E
C
A
Yeah
but-
and
we
can-
we
can
discuss
this
so
maybe
I'll
fast
forward-
some
of
those
issues
to
the
top,
maybe
for
the
next
milestone
to
sort
of
start
getting
a
better
result
to
the
user
and,
if
they're
errors
explaining
to
the
user.
What
the
what
those
are
we
have.
B
A
Okay,
that's
a
good,
that's
really
good
food
for
thought.
As
we
look
at
what's
next
and.
A
Plan,
I
think
that
might
be
it.
I
I'd
be
good
if
I
could
just
get
a
pulse
from
everyone
on
where
they
feel
like
they
might
end
up
at
the
end
of
39.
So
does
it
feel
like
these
epics
sorry,
the
the
issues
to
finish
off
epics
are
those
deliverable
in
one
milestone?
Is
this
two
milestones
three
miles
like?
I
don't
know
how
big
each
one
of
these
might
be.
You
said
some
are
small.
Some
are
big,
but
I
have
no
idea
if
it's
mostly
big
things
or
mostly
small
things,.
B
The
way
I
see,
I
think
it's
mostly
small
things,
but
I
agree
with
george
that
I
think
that
some
of
the
technical
that
might
be
more
important
just
to
avoid
keep
adding
features
and
stuff
on
an
architecture
that
already
have
some
type
of
technical
that
to
be
solved.
B
E
E
A
Yeah
and
I
agree-
that's
sort
of
what
I
had
in
mind
because
we
do
have
users
as
a
complete,
separate
epic,
and
at
that
point,
when
we
get
to
users
we're
going
to
have
to
start
connecting
users
to
things.
So
you
know
this
is
going
to
get
broken
down
into
what
all
different
things
are.
But
you
know
when
we
get
to
users,
one
thing
will
be
to
move
them,
the
other.
The
other
part
of
that
will
be
now
start
associating
users
to
all
the
things
that
we
migrating.
C
A
C
A
It's
all
those
metaphors,
but
I
feel
like
we
need
to
crack
that
as
much
as
we
can
and
I've
talked
to
professional
services,
you
know
developers
on
how
they
handle
it
congregate
and
it
feels
like
we
might
be
able
to
just
you
know
with
the
right
permissions.
A
So
if
you
have
the
right
permissions
on
on
the
destination
side,
create
a
user
and
just
reset
their
password-
and
you
know-
maybe
not
necessarily
move
all
of
the
all
of
the
authentication
with
them.
So
they
may
not
be
able
to
just
use
everything
like
password
may
not
work.
A
They
may
need
to
do
that,
but
we
could,
I
think,
at
the
minimum,
create
a
user
and
reset
their
password,
and
then
okay
user
would
be
there
for
us
to
map,
and
then
the
users
will
then
work
on
their
own
one
at
a
time
as
they
join
the
system
to
to
figure
out
what
their
authentication
is.
A
A
And
something
that
congrega
does
so
our
goal
is
to
put
some
of
that
some.
C
I'm
just
wondering
if
something
if
something
goes
wrong
or
whatever
somebody
made
a
mistake,
how
are
you
gonna
roll
back,
but
anyway
it
doesn't
matter.
That's
we
can
that's
a
discussion
for
discussion
for
another
time,
yeah,
okay,
well,
overall,
for
39,
I
feel
like
this
epic
alone
can
can
take
a
significant
amount
of
time.
C
A
Of
the
team,
I
would
say
the
priority,
then
I
mean
we're
gonna,
we're
only
gonna
do
as
much
as
we
can
right.
So
I
think
the
priority
is,
I
think,
cassio's
already
taken
up
these,
so
I
think
these
should
be
completed
before
we
move
on
to
move
back
to
group
migration
or,
like
you
know,
george
may
start
on
this
and
casual
may
join
later,
but
I
think
these
two
instrumentations
should
just
be
put
put
away,
and
hopefully
one
of
them
makes
13
8.
A
we'll
see
what
happens
so
that
that
would
be
priority
one
and
then
priority
two
would
be
going
down
the
list
of
these
six.
Not
so
none
of
the
github
stuff
should
be
a
priority
at
this
point,
and
also
the
technical
debt
should
be
put
kind
of
at
the
same
priority
level
as
this
direction
item
here,
so
we
should
probably
intermix
some
of
that
stuff.
A
So
that's
the
priority
order
of
things,
given
that
we
may
not
be
able
to
complete
the
full
thing.
I
think
you
know:
instrumentation
comes
ahead
of
the
epic's
migration
and
then
the
apex
migration
is
kind
of
on
the
same
level
as
the
technical
debt
and
then
that's
it.
We'll
just
go
as
far
as
we
can
down
that
priority
list.
A
A
Oh
well,
that's
helpful
to
me
as
well
to
sort
of
get
an
idea
of.
We
probably
will
start
this.
We
will
we're
not
likely
to
complete
it
in
this
milestone,
but
we
may
get
the
most
important
things
like.
I
have
put
these
in
order
of
kind
of
importance.