►
From YouTube: Manage:Import 14.8 planning
Description
This is the sync planning session for the 14.8 milestone for the Manage:Import group.
Planning issue shown:
https://gitlab.com/gitlab-org/manage/general-discussion/-/issues/17439
A
So,
as
you
can
tell-
maybe
maybe
not
we
have
finally
hired
someone
for
the
ux
position
on
the
team,
so
I
know
front-end
will
be
cheering.
A
So
dan
has
been
hired
and
introduced
himself
and
in
slack,
but
I
still
need
to
extend
the
invitations
to
turn
for
the
team
meetings
and
planning
sessions.
So
hopefully,
starting
next
week,
you'll
be
able
to
start
joining
some
of
our
calls.
A
As
far
as
capacity
goes,
you
want
to
take,
and
just
tell
us
a
little
bit
about
what's
going
on
here,
andre.
C
I
will
be
on
vacation
for
a
week
as
it
says
in
the
issue
from
it's
yeah
from
14th
till
20th
of
february.
I
think
it's
in
this
milestone.
I'm
actually
not
sure.
B
Yeah
we
have
some
ongoing
work
on
this.
I
lead
the
global
frontend
initiative
on
some
technical
tasks
migrating
to
view
free
and
as
a
part
of
this,
we
have
some
kind
of
time
boxes
thing
to
complete
one
of
the
epics,
so
I'll
be
dedicated
some
of
my
times
there
that-
and
I
would
like
to
especially
mention
it
so
we
could
plan
accordingly
perfect.
A
So
team
velocity
has
not
been
updated
with
anything
14
7,
but
we
can
sort
of
see
the
fourteen
six
stuff
the
and
that's
just
the
charts
your
chart
lagging
a
little
bit.
It's
kind
of
interesting
how
we
had
that
spike
when
the
tetcon
recent
started,
but
then
we
kind
of
leveled
off.
So
I
think
these
four
all
four
of
these
releases
are
kind
of
the
levels
off
the
headphone
reset.
A
Interestingly
enough,
the
backhand
velocity
seems
to
be
just
holding
with
or
without
headcount
reset,
and
the
final
velocity
has
come
up
significantly.
So
that's
that's
really
good
news.
We
seem
to
be
like
still
churning
through
things
proposed
objectives,
so
this
is
the
milestone
where
we
slowly
pivot
from
security,
infrared
engineering
allocation,
headcount
reset
with
those
things
and
start
looking
ahead
at
the
year
2022.
A
So
in
this
particular
particular
milestone.
We
do
you
know
the
direction
work
that
we're
going
to
split
our
time
between
directional
items
and
still
some
of
the
security
for
them.
As
far
as
directional
items
go
the
project
migration
mvc,
so
this
is
kind
of
completing
the
minimum.
A
What
we
need
to
have
the
projects
included
in
the
group
migration
is
going
to
be
the
top
priority
for
for
the
directional
items
and
in
particular
this
is
the
top
issue
in
that
epic,
and
that
is
migrating.
The
project
members
I
feel
like
if
we
had
that
issue
some
of
the
other
things
are
remaining,
such
as
some
of
the
pipeline
stuff
lfs.
A
Typically,
people
will
not
use
a
feature
until
that's
available,
so
I
would
say
that
once
we
have
this,
you
know
we
could
start
looking
at
announcing
and
maybe
even
you
know,
flipping
the
feature
flag
in
production,
maybe
not
by
default,
but
for
for
for
our
fitlab.com
production
so
that
we
can
get
some
exposure,
so
I
feel
like-
and
once
we
get
this
in
the
rest
of
it
can
trickle
in,
but
we
might
have
enough
to
start
actually
getting
some
traffic
in
the
future.
A
So
that's
important
as
far
as
security
goes
and
there's
not
a
lot
of
informative
right
now.
It's
mostly
security.
That's
kind
of
left
over
from
the
engineering
allocation,
in
addition
to
some
of
the
items
that
are
left
on
the
board,
like
there's
these
two
open
items
that
we
can
look
into
picking
up
a
few
items
in
progress
still
assigned
to
some
of
the
people
from
had
kind
reset.
A
In
addition
to
the
board,
there
are
a
few,
a
few
issues
that
came
out
of
recent
escalation
and
one
is
the
super
cup
rule
for
file
extractions,
which
we're
gonna
implement
in
import.
But
it's
something
that
is
potentially
then
reusable
and
should
be
done
for
other
groups
as
well,
and
the
other
kind
of
a
bucket
is
the
threat
model
discussion
that
we've
had.
A
We
talked
about
actually
creating
issues
for
each
one
of
the
vulnerability,
concerns
that
we
have
in
the
threat
model
and
slowly
going
through
that
doing
the
research
and
doing
any
work.
That's
needed
to
mitigate
these.
So
you
know
those
would
be
kind
of
the
themes
for
backhand
for
the
for
14
8.
So
george.
D
That
makes
sense
yeah.
The
only
question
I
have
is
github
is
out
of
the
scope
of
this
monster
right.
A
Yeah
I
mean
I
don't
think
that
we
can
make
progress
against
that
too,
we'll
see
if
we
can
get
some
additional
help
to
to
help
with
that,
it's
going
to
be
hard
to
to
make
progress
against
it,
otherwise,
over
the
next
several
months,
I
believe
so.
I
think
we're
still
several
milestones
away
from
being
able
to
pay
a
lot
of
attention
to
it.
A
So
yeah,
so
this
is
it.
This
is
going
to
reduce
scope,
we'll
try
to
split
time.
I
know
if
it's
50,
50
or
who
knows
what
the
ratio
is
gonna
be,
but
we
need
to
kind
of
split
time
between
these
two
buckets
and
make
some
progress
in
each
and
if
it's
one
issue
in
each
and
that's
one
issue
in
each,
but
you
know
so
the
depth
of
progress,
we'll
we'll
see.
A
As
far
as
front
end
goes
a
couple,
a
couple
things
that
we
talked
about
that
were
identified,
I
haven't
looked
into
whether
there's
any
spillover
from
fourth
and
seven.
B
A
The
one
big
thing
that
we
talked
about
was
this
detail
status
for
github
importer,
and
you
know
I
feel
like
this
also
introduces
a
new
interaction
that
we
can
then
use
for
migrations.
So
you
know
each
time
we
introduce
kind
of
a
great
solution
for
one
importer
we
at
least
want
to
have
both
github
and
the
get
latitude
we're
working
on.
You
know
get
to
this
point,
so
the
back
end
for
this
data
already
exists.
It's
something
casio
did
so
for
the
front
end.
A
We're
proposing
that
we
kind
of
allow
expansion
of
the
single
line
that
says
importing
where
you
can
click
on
it
and
you
can
see
sort
of
where
we
are
in
the
importing
process
and
then
once
it's
completed,
also
kind
of
allow
to
to
show
kind
of
the
breakdown
of
what
got
completed.
What
didn't
and
whether
it's
a
partial
success,
success
or.
D
A
Kind
of
show
the
details
so
that
the
user
can
actually
make
judgment
on
whether
oh
just
one
out
of
100
things
made
it
or
99
out
of
100
things
made
it
there's
a
big
difference
between
that,
and
especially
if
we
don't
show
partial
success.
If
we
just
store
success,
success
or
failure,
then
you
really
have
no
idea
how
it
all
went.
A
So
I
think
this
will
be
very
valuable
for
us
to
have
even
for
ourselves,
so
we
could
troubleshoot
it,
but
also
we
do
get
a
lot
of
escalations
where
people
ask
this
happened,
but
I
don't
know
how
to
like
decide
what
happened.
B
Should
we
because
is
the
way
it
is
displayed
in
the
issue
at
the
moment?
Sorry
for
thinking
about
it
just
now,
but
I
just
realized
it.
The
user
will
probably
miss
unless
it
hovers
that
that
it
is
expandable.
So
we
need
some
good
ux
way
to
communicate
that
hey.
You
can
expand
this
thing.
A
Yeah-
and
I
wonder
if
there's
any
any,
is
there
any
affordances
in
in
the
current
pipeline
this
place,
so
I
think
we
can
lean
into
that.
If
there's
any
affordance
there,
that
would
be
a
similar
affordance
that
we
would
apply
here.
A
I
wouldn't
want
to
like
invent
something
new,
so
I'm
thinking,
if
there's
something
there,
then
we
should
lean
into
it.
Do
you
know
if
there's
already
an
affordance
there
or.
B
Yes,
I
believe
we
have
a
scenario
when
we
expand
the
pipe
in
the
pipeline
to
see
the
grouped
one
group,
the
group
of
the
group
of
jobs
in
pipeline.
I
believe
you
need
some
big
one
and
inside
not
for
the
handbook
it
will
be,
but
whatever,
but
anyway,
this
will
be
a
better
help.
A
So
I
guess
the
hover
state
is
going
to
be
important
for
it
to
to
to
work,
and
then
we
may
need
to
figure
out
what
it
means
for
this,
because
this
is
a
filled
out,
shape
versus
kind
of
a
hollowed
out
shape
here.
That
then
fills
in
as
you
hover,
so
that's
probably
where
the
ux
person
can
help
us
out,
because
our
icons
are
not
the
exact
same
icons
that
we
have
here.
A
So
the
hover
will
look
different,
but
I
don't
know
that
we
need
more
than
kind
of
changing
the
on
hover
and
then
also
the
cursor
changes,
of
course,
to
the
pointer.
So
you
know,
as
you.
D
B
First
of
all,
which
this
might
include
reusing
existing
pipeline
ui
or
maybe
might
require
going
other
way,
implementing
the
new
way,
which
will
be
compliant
to
our
design
system
requirements
and
being
the
first
one
to
introduce
it
and
force
pipeline
developers
to
import
our
use
case.
But
let's
see
I
will
handle
that.
A
Yeah
and
definitely
like
this
box
that
we
see
here
hopefully
gets
reused
in
a
way,
so
it
shouldn't
be
a
different
box
with
different
boundaries
and
kind
of
different
look
and
feel
for
sure.
So
I
don't
get
too
much
into
design
of
this.
So
it's
exciting
and
that's
you
could
talk
about
a
lot,
but
I
need
to
move
on.
So
this
is
a
follow-up
and
this
one
that
keeps
coming
back,
it's
the
one
that
keeps
giving
so
hopefully
we
can
put
this
to
rest
and
then
viewing
the
history.
A
I
know
that
you
wanted
to
finish
the
back
end
and
then
get
on
to
the
front
end.
So
do
you
know
sort
of
if
how
much
work
is
going
to
be
in
left
over
from
from
this.
B
This
will
be
something
around
like
say,
two
points
for
back
end
and
three
point
four
front
end.
So
it's
like,
and
I
have
super
quick
question
since
we
will
be
doing
the
project
migration
nvc
in
this
milestone.
George,
do
you
have
an
insight?
Will
these
the
projects
imported
via
project
migration
vc
will
be
identical
to
projects
migrated
via
our
old
importers?
I
mean
they
will
have
like
with
import
state
in
the
database.
B
Okay,
this
is
just
a
question
I
would
like
to
verbalize.
We
will
need
to
remember
because
this
will
be
a
bit
a
tiny,
tricky
thing
if
I
initialize
the
importer
via
our
group
migration
feature,
I
probably
expect
it
to
be
visible
in
the
group
migration
history
which
we
already
implemented.
B
But
if
we
will
have
a
super
separate
project
migration
history
for
all
the
importers,
it
might
probably
also
appear
there,
and
we
should
consider
how
these
two
features
will
interact.
D
I'm
not
sure
I
understand
to
be
honest,
but
the
group
migration
will
have
project
migration
included
in
them.
Once
we
flip
the
feature
file
and
every
entity
there
are
group
entities,
there
are
project,
entities
and
project
entities
will
have
the
same
state
the
same
kind
of
progress
state
as
we
have
with
group
entities
and
when
it
comes
to
the
project
itself,
it
will
most
likely
to
have
import
type
to
be
github
migration.
B
Okay
and
because
yeah
for
current
project
importers,
we
have
an
import
state
on
the
project
entity,
and
this
was
my
question.
This
is
great
to
know
to
know
I
will
be
able
to
easily
defer
them.
Okay,
great,
thank
you,
and
I
will
just
keep
an
eye
to
make
sure
we
on
the
track
for
this
milestone.
D
A
A
One
thing
that
we
so
we
have
the
source,
which
I
guess
then
you
can.
You
know
you
can
tell
where
it
comes
from
this
one
comes
from
a
github.
This
one
comes
from
big
bucket.
Another
one
may
come
from
git
lab,
so
somehow
we'll
be
able
to
tell
that
you
know
what
group
just
came
from
or
what
the
cloud
instances
came
from
from
looking
at
the
history
here,
but
we
expect
every
project
that
was
imported
as
part
of
the
group
migration
to
have
an
individual
line
item
in
this
table.
Right.
B
Actually,
I
will
put
it
for
probably
weekly
discussion,
so
we
do
not
need
too
much
time,
because
this
is
actually
my
question.
Do
we
expect
it
to
be
here
or
do
we
expect
it
to
be
in
group
migration.
A
B
Not
yet
because,
at
least
for
that
back-end,
I'm
developing
now
I'm
pulling
the
projects
which
have
like
an
import
state
in
the
project.
Entity
like
this
is
the
way
the
previous
importers
work
and,
as
george
told
we
have
another,
let's
call
it
modern
approach
to
migration,
where
the
import
state
is
separated
from
the
any
kind
of
entity
which
I
believe
is
more
correct.
So
we
just
need
to
figure
out
how
we
should
do
that.
B
A
A
And
maybe
in
45,
if
the
discussion
becomes
long
in
14
8,
we
can
do
an
mdc
where
we
just
pull
what's
there.
So
we
can
work
on
the
front
end
and,
like
you
know,
kind
of
a
communication
and
all
that
and
then
we
can
go
back
and
add
more
detail
or
fix
the
detail
that
we
don't
like.
A
Trying
to
keep
the
scope
possible
for
you,
I
know
you
have
an
outage
as
well,
and
you
have
you
know
two
fairly
large
things
on
your
docket.
B
Yeah,
I
will
try
to
embrace
iteration
value
and
we'll
let
you
know
if
you
need
further
split
yeah
yeah.
A
And
yeah,
to
reiterate
that
point
it
it's
better
to
just
have
something
in
148,
a
smaller
iteration
than
to
have
a
larger
deliverable
that
takes
multiple
milestones.
So
definitely
looking
for
that,
and
I'm
in
support
of
that.
C
Yeah,
so
the
first
two
items
are
kind
of
related,
so
the
project
migration
tests
are
extremely
flaky
so
and
by
flaky
I
mean
the
project
quite
often
isn't
being
imported,
I'm
still
kind
of
finding
fighting
on
understanding.
What
exactly
is
causing
it,
because
it's
not
like
a
thing
that
is
easily
reproduced.
C
That's
why
I
feel
it's
an
issue
with
the
resources
on
ci,
but
I
might
be
wrong
and
but
the
like,
the
worst
part
about
it
is
we
have
zero
visibility
into
actually
how
much
resources
we
have
for
the
instance.
We
run
tests
against
and
like
yeah,
so
I
don't
see
much
benefit
to
adding
more
tests
right
now
before
I
figure
out
how
to
make
them
stable,
because
they
do
create
quite
a
lot
of
noise
right
now,
so
I
will
be
focusing
on
trying
to
figure
it
out
the
next
milestone.
C
The
last
task
is
just
one
more
spec
that
is
from
the
previous,
must
on
the
ci
pipeline.
If
I
do
kind
of
manage
to
solve
the
flakiness,
I
will
pick
up
the
the
test.
C
C
Maybe
it's
also
a
factor,
but
from
the
logs
I've
been
able
to
check
so
far.
It
does
look
like
there
are
just
some
random
timeouts
internally
for
either
like
a
graphql
request
or
stuff
like
that.
C
D
C
It
it
kind
of
adds
a
lot
more
entities
and
what
I
think
is
happening
because
of
that,
especially
if
the
project
also
has
a
repository,
then
it's.
It
also
involves
like
git
operations
and
stuff,
and
I
I
have
a
feeling
that
the
then
the
environment
starts
to
struggle
a
bit.
If
it's
an
empty
group,
it's
fairly
lightweight.
I
guess,
if
you
could
call
it
but
yeah
something
something
with
projects
and
same
as
like.
C
C
Yeah,
I
wasn't
able
to
reproduce
it
on
gdk.
Maybe
I
will
try
to
reproduce
it
with
the
the
full
like
dockerized
gitlab
instance,
the
the
same
way
it
is
spun
up
on
ci,
but
again
I
I
guess.
Maybe
I
will
try
to
create
a
script
that
runs
the
test,
like
I
don't
know,
10
or
20
times
in
a
row,
because
it's
not
consistent
on
ci
as
well.
D
D
A
There's
also
a
documentation
issue
that
I
think
we
need
to
you
know,
take
a
look
and
see
if,
if
it
makes
sense
to
get
into
14.8-
and
it
is
really
about
sort
of
an
overall
updating,
overall
user
documentation
with
all
the
little
things
that
have
changed
with
the
gitlab
migration
and
ensuring
that
we
have-
you
know
a
logical
layout
for
both
group
and
project
and,
what's
being
migrated,
so
the
documentation
lags
behind
and
we'll
need
to
get
that
going.
A
I
think
this
will
be
collaboration
between
backhand
and
documentation
in
a
way
probably
to
to
get
accomplished,
and
I
see.
B
A
George
and
nick
are
already
discussing
it
so
and
that'll
be
kind
of
the
final
thing
to
work
in
this
time
frame.
So
you
know
I
don't
use
the
words
commit
much
around
here.
It
really
depends
on
how
much
time
we
have
and
how
far
down
the
list
we
get,
but
these
are
overall
the
priorities
that
hopefully
we
can
get.
A
So
I
guess,
if
nothing
else,
I'm
just
gonna
quickly
open
it
up.
For
you
know
any
kind
of
process,
thoughts,
comments,
how
we're
doing
quick
retro
on
the
last
milestone,
anything
that
we
should
be
discussing
outside
of
just
what
we're
working
on,
but
how
we're
working.
D
A
Maybe
maybe,
if
you
take
a
look
here
at
14,
0,
14,
114,
2,
that's
prior
to
the
headcount
reset,
we
were
hovering
around
20
and
then
during
the
headcount
reset
we
were
hiring
around
30
with
that
one
spike
over
40..
So
there
is
there.
Isn't
there
is
a
change?
It's
just
not
you
know
double
or
anything
that
you
might
expect
by
just
putting
twice
as
many
people
on
it,
but
I
think.
A
All
right
cool,
thank
you
all
for
your
time
and
I'll
see
y'all
next
weekend.