►
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
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.
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
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
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
D
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
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.
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
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
E
E
E
E
B
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
E
E
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
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?
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
B
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,.
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
A
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.
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.