►
From YouTube: Manage::Import UX Office Hours 2021-01-05
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Alrighty,
so
I
did
post
just
let's
see
something
to
the
agenda.
A
I'm
opening
the
agenda
where
the
heck
is
it
there.
It
is.
A
A
So
there's
been
a
lot
of
discussion
within
this
issue
regarding
not
only
pagination
but
also
how
we're
going
to
handle.
You
know
this
more
complicated
view
and
more
intricate
view
of
what
we're
going
to
be
showing
the
user.
A
So
and
I
I
left
you
a
comment
billy,
I
don't
know
if
you've
taken
a
look
at
what
andy
has
already
started,
he's
done
just
a
fantastic
job
of
you
know
creating
this
issue
in
regards
to
enhancing
the
capabilities
for
enterprise
users.
A
Cool
cool
yeah,
so
he's
done
a
lot
of
great
work,
but
I
just
want
to
make
sure
I
actually
have
a
meeting
with
him
tomorrow
that
I
can
go
over.
This
is.
C
B
From
what
I
saw
like,
he
is
not
focusing
on
like
he's
reusing
as
much
bootstrap
as
possible
in
term
of
ux,
but
we
do
not
have
any
kind
of
specific
like
table.
Library
selected.
C
You
know,
there's
there's
a
lot
of
you
know
action
buttons
in
row
as
well
to
create
new
things
and
parent
things,
so
pretty
much
work.
It
work
as
a
as
a
tree,
so
that
type
of
component
is
it's
just
a
lot
to
build,
and
I
know
that
there's
a
lot.
You
know
there's
some
out
there
that
we
can
maybe
take
and
extend
with
what
we
need,
but
you
know
maybe
faster
than
just
building
it
from
scratch.
That's
what
I
can
ask
something
to
consider
we'll
see.
A
Well,
that's
kind
of
that
brings
up
an
interesting
point
because,
like
it
andy
has
this
scheduled
for
13
8,
which
I
would
assume
is
you
know
just
the
design,
obviously
just
the
design
work,
but
then
I
just
I
mean
I
asked
him
this
tomorrow,
like
how
long
is
this
gonna
take?
Basically,
you
know-
and
this
comes
down
to
what
what
are
the
needs
for
import?
Do
we
need
to
figure
out
kind
of
the
interim
step
before
this
glorious?
A
B
Experience
implementing
these
will
take
a
very
long
time,
and
I
mean
that
even
with
not
fully
defined
scope.
B
What
we
currently
have
in
this
issue,
the
total
implementation
of
of
this
one
could
take
like
three
four
five
milestones
of
single
person-
job
and
I'm
not
sure,
I'm
the
person
who
wants
to
take
to
do
that,
although
it
seems
that
we
in
important
great
need
of
that,
but
so
for
this
issue
and
I'm
actively
keeping
an
eye
on
that
and
thinking
about
this,
it
is
very
important
to
first
of
all
slice
like
minimal
possible
pieces.
B
We
need
from
one
point
of
view,
but
from
another,
keep
in
mind
the
whole
picture,
because,
based
on
my
experience
with
all
that
complex
grids,
it
is
very
hard
to
consider
to
consider
all
limitations
if
they
were
not
properly
reviewed
at
the
very
first
phase.
So
we
should
be
very
careful
at
the
start
point
of
implementation.
Considering,
okay,
we
understand
that
we
kind
of
fixing
the
requirement
for
one
two,
three
four
milestones
and
or
otherwise
we
will
suffer
a
great
pain
from
engineering
side.
A
Oh
yeah,
you,
you
know
you
poor
poor
engineers,
they
always
get
the
the
tail
end
crunch.
C
Yeah
you
know
if
import
is
to
contribute
to
this.
I
think
you
know
we
would
need
to
start
with
a
starting
point
so
start
with
some
kind
of
a
table
that
has
a
lot
of
the
functionality
that
we
have
to
do
some
research
between
different
component
libraries
and
pick
one
that
gets
us
the
closest
to
where
we
need
to
be,
and
then.
A
A
I
think
this
is
this
is
just
andy
working
on
something
updating
the
pajamas
library.
So
I
think
this
is
something
he
just
kind
of
took
on
his
own
and
he
might
have
a
need
within,
but
I'm
I'm
not
aware-
or
here
here
here
in
the
vulnerability
list.
So
there
is
a
need
within
his
stage
group.
B
Yeah,
just
to
give
you
an
idea,
like
95
95
probability
that
we
will
pick
the
component
I've
linked
just
because
our
gitlab
ui
library,
which
is
our
implementation
of
pajamas,
is
built
on
top
of
bootstrap
view
and
like
it
already
has
part
of
requested
functionality,
and
it
will
be
easier
to
start
with
it
than
with
any
other
options
or
otherwise
we
will
spend
additional
time
time
dealing
with
bootstrap,
interacting
with
stables,
integrating
with
initial
look
and
feel
and
so
on
and
so
on.
C
B
Yes,
just
to
quickly
have
an
understanding.
What
do
you
have
you
could
scroll
open
that
link
and
scroll
to
the
link
which
is
in
zoom
and
scroll
to
the.
B
C
B
Yes,
it
is
the
great
start,
but
still
implementing
three
will
be
like
the
most
painful
one.
The
most
painful
thing.
C
I
know
so
how
how
much
work
would
it
be
to
just
insert
this
table
instead
of
the
table
that
we
currently
have
without
any
additional
functionality
like
we
may
get
pagination
for
free,
like
whatever
we
get
for
free
fine
but
like
without
implementing
anything
extra
just
using
this
table?
Instead
of
that
and
get
pagination
from
it
as
opposed.
B
So
it
is
tricky
because,
for
example,
it
is
tricky
because
it
really
depends
on
the
back
end.
Why,
when
you
look
at
the
demo
and
you,
for
example,
sort
base
it
on
some
column,
it's
just
a
client-side
sorting,
and
this
is
not
how
it
works
in
real
world.
So
it
really
question
a
good
question:
how
it
will
work
with
a
backhand
side.
B
If
we
speak
just
about
pagination,
it
is
quite
simple
to
do
if
we
have
a
proper
pagination
support
on
the
back
end
again
and
for
example,
as
you
remember,
there
is
no
good
way
to
implement
pagination
for.
B
Github
importers
and
so
on
and
so
on.
I
mean
project
importers
just
because
we
have
no
way
to
properly
build
a
pagination
offset.
There
probably
remember
we
discussed
it
some
time
long
ago,
so
it
really
depends.
It
is
not
big
deal
from
the
front-end
side.
I
mean
it
should
be
doable
within
one
milestone.
I
think,
but
it
might
require
a
heavy
support
on
back
end
and
heavy
additions
to
back
end,
which
obviously
it's
pretty
hard
for
me
to
evaluate.
C
Well,
I
mean
the
right
approach
to
this
is
really
for
me
to
stay
out
of
the
technical
solution
and
just
to
specify
the
requirements
that
we
have
the
functional
requirements
that
we
have.
So
we
have
what
we
have
right
now.
The
next
thing
we're
going
to
work
on
is
pagination.
C
I
think
I
would
leave
it
up
to
you
whether
you
feel
like
it's,
it's
a
better
technical
solution
to
switch
to
this
table
and
make
its
pagination
work
or
just
implement
pagination,
as
is
because
we
will
just
keep
adding
requirements,
and
the
next
thing
is
going
to
be
filtering
and
so
on
right,
eventually,
maybe
so
the
ability
to
do
checkbox
like
you,
select
many
and
then
do
a
do,
an
action
on
them.
C
We
will
never
need
the
ability
to
drag
and
drop
things
around,
but
if
you
look
at
like
epic
management,
like
you
know,
portfolio
management
people
have
epics
and
issues
and
they
want
to
be
able
to
just
move
issue
from
one
epic
to
another
or
one
epic,
to
be
higher
priority
than
another.
So
you
know
later
in
gitlab,
there
will
be
need
for
drag
and
drop
on.
C
B
Based
on
requirements,
what
I
saw
currently
I
mean
pagination
filtering,
you've
mentioned
and
so
on
and
so
on.
This
does
not
feel
for
me
as
the
right
solution
in
like
team
scope.
In
the
group
scope,
I
mean
we,
we
could,
we
will
be
able
to
faster
iterate
on
the
existing
implementation.
B
Basically,
because
I'm
familiar
with
it,
I
understand
its
limitations
and
things
like
pagination
already
available
in
pajamas,
because
we
saw
it
in
github
github
in
previous
version
of
github
importer
and
so
on
and
so
on,
but
just
to
make
sure
we
understand
that
if
some,
like
other
team
in
gitlab
picks
this
one,
I
don't
know
vulnerability,
management
and
so
on.
We
in
fact
will
end
implementing
two
solutions
with
similar
functionality
and,
as
a
team
will
require
additional
effort
of
like
throwing
away
solution
just
for
consistency
or
paying
for
maintaining
two
of
them.
B
Just
a
side
note
I'm
like
I'm
still
like
not
100
sold.
We
need
like
as
such
overkill
component
like
implemented
everywhere.
While
I
definitely
appreciate
this
work,
I'm
still
thinking
how
I
feel
about
that
just
because,
based
on
my
experience
with
gitlab
as
a
product,
our
requirements
for
tables
are
like
quite
different
in
different
spaces.
So,
like
each
time,
we
will
require
a
different
subset
of
that
functionality
and,
like
it's
usually
like
you
always
need
to
pay
price
for
functionality,
which
is
there
and
you
are
not
using.
B
Sometimes
it's
making
things
more
complex
and
so
on
and
so
on
and,
like
I
understand
that
a
lot
of
enterprise,
great
products
have
they
call
this
grids,
but
this
is
usually
when
they
visualize
a
lot
of
data
in
the
same
way
like
any
kind
of
crm
systems
and
so
on,
and
so
on.
So
a
lot
of
complex
grids
implemented
in
the
same
way
across
the
entire
application,
and
I
do
not
feel
100.
This
is
a
gitlab
way.
B
So
that's
why
I
probably
still
thinking
about
if
this
is
the
right
way
to
approaching
this
problem
or
instead
just
writing
a
precise
and
good,
well-documented
guidelines.
How
we
expect
the
pagination
filtering
and
so
on,
implemented
in
pajamas
and
leaving
to
engineering
to
properly
compose
that
pieces
and
proceed
forward.
C
Yeah
that
makes
sense
like
if
we
actually
had
this
as
part
of
our
component
library
like
if
this
table
was
used
elsewhere,
then
there
would
definitely
be
pressure
for
us
to
be
consistent,
even
if
it's
an
overkill,
but
you
know
it,
the
library
is
already
loaded,
and
you
know
it's
not
they're.
You
know
we're
not
introducing
complexity
that
hasn't
already
been
introduced
right,
but
in
cases
where
you
know
I
don't
think
we
should
be
the
first
ones
to
do
this
you're.
I
agree
with
you
that
just
what
we
have
right
now
works
for
us.
C
However,
if
there
was
a
more
powerful
table
it
would
be
useful
to
us
like
it
would
be
useful
to
be
able
to
have
more
powerful,
filtering,
sorting
and
another
functionality,
but
I
don't
think
that's
something
that
I
would
make
a
requirement.
So
my
requirement
is
still
going
to
be
just
the
pagination
and
so
on.
It's
like
we'll
just
keep
adding
requirements.
If
at
any
point
somebody
else
picks
a
table
and
we
have
it.
We
may
consider
the
cost
of
switching
to
that
or
staying
where
we
are.
B
Sorry
wrong
button,
and
so
if
we
decide
decide
to
proceed
with
the
tree
thing,
it
will
be
way
more
faster
to
implement
with
current
solution,
because
current
solution
is
simple
in
terms
of
other
pieces
and
integrating
as
a
tree
to
the
existing
table,
bootstrap
table
could
vary
from
hard
to
impossible.
C
Okay,
all
right
so
we'll
just
continue
doing
what
we're
doing.
I
think
it
will
still
be
valuable
what
amanda
asked
to
do,
which
is
list
our
requirements,
so
that
you
know
we
spell
out
what
our
requirements
are
right
now
and
what
our
requirements
are
for
things
we
have
in
design
so
things
we
have
in
the
pipeline,
so
pagination
search,
filtering,
being
able
to
multi-select
and
then
do
an
action
on
it
and
the
tree.
A
B
Yeah,
so
I
I
just
wanted
to
ask
or
share
a
thought
about
the
second
issue
mentioned
in
our
agenda.
I
mean
which
is
about
actually
implement,
implement
a
group
migration
list
pagination-
and
this
is
like
this-
is
actually
a
complex
decision
about
picking
the
standard,
pagination
or
infinite
scrolling
from
engineering
point
of
view,
because
I
still
have
a
feeling
that
we
are
in
great
risk
and
we
probably
should
discuss
it
with
beckon
team
that,
with
new
requirements
coming
up,
we
could
add
exactly.
B
B
I
simply
can't
understand
in
my
mind
how
we
will
build
a
page-based
pagination
if
we
will
implement
a
tree,
so
I'm
just
want
to
make
sure
we
do
not
proceed
with
a
dead
end
solution
like
we
already
had
the
issue
with
a
github
pagination
importer.
A
Of
course,
it
does
so
I'll
update
that,
but
I
did
see
if
you
go
to
groups
like
there
is
a
view
where
they
use
where
we
use
pagination,
along
with
a
tree
view,
so
you
can.
Is
that
what
you're?
A
A
Yeah
like
when
you
open
up
the
subgroups
and
projects
they
still
have
that
preview.
But
if
you
scroll
to
the
bottom,
you
know
we
show
20
per
page,
but
when
we,
when
the
row
is
expanded,.
C
Second
entries
in
the
table,
and
then
each
one
that
gets
expanded
adds
more,
so
you
can
show
more
than
20
for
sure.
B
Yeah,
yes,
and
there
is
yeah,
but
I
still
would
like
to
check
this
one
with
the
back
end,
because
this
is
just
a
bit
different
like
here.
We
are
using
the
private
api
of
our
local
gitlab
instance
and
when
we
are
building
this
one,
we
are
talking
to
the
public
api
of
another
gitlab
instance,
and
just
to
make
sure
that
this
will
possible.
B
I
understand
the
current
ux.
I
find
it
sometimes
a
bit
hard
and
confusing,
especially
when
you
combine
filtering
and
pagination,
but
I've
got
the
point.
C
I
agree
and
I
think
we
should
probably
just
iterate
in
that
direction,
so
I
don't
think
I
mean
we
can
list
some
of
the
requirements
so
that
if
we,
if
somebody's
evaluating
these
tables,
if
we're
valuing
tables,
we
know
what
the
requirements
are,
but
I
don't
think
we
need
to
solve
the
you
know
the
the
groupings
or
the
you
know
the
tree
any
of
that.
Yet
I
think
we
can
just
solve
the
pagination
and
then
vagination
may
have
to
evolve
or
not
like.
C
B
B
Can
you
just
just
make
a
search
on
gitlab
and
it
will
show
you
like
filtering
on
gitlab
for
groups,
and
we
will
see
that
it's
a
good
example,
I
believe
yeah.
It
takes
a
long,
oh
yeah.
Here
we
go
37
more
items
and
something
like
that
on
the
second.
C
C
A
B
A
B
Yes,
I'm
just
giving
an
idea
because
well
this
is,
I,
like,
I
said,
a
very
tricky
one.
C
A
A
Yeah,
all
right
cool,
so
do
we
want
to
quickly
go
down
the
a
list
of
of
requirements
just
so
we
capture
it.
B
C
A
A
Specific
for
yes,
import.
A
C
Well,
filter,
good
yeah
filter
is
another
one,
but
also
all
four
working
actually
together,
not
just
one
at
a
time.
C
C
You
were
correct,
yeah
filter
was
correct,
we
had
search
elsewhere
and
then
you
know,
people
thought
that
search
might
actually
just
replace
their
view
versus
filter.
It
just
seems
like
it's.
Just
gonna
show
fewer
things
like
everything
you
see
right
now.
You're
gonna
see
fewer
of
those,
but
it's
it's
like
keeping
the
same
view.
Yeah.
A
A
A
B
A
What
what
was
the
component.
B
It
was
filtered
search,
oh
really,
yes,
because
it
is
a
doom
for
building
it
at
least
accessible,
as
as
it
could
be,
I
mean
making
keyboard
navigation
works
properly,
making.
B
C
Use
case
that
I'm
thinking
about
is,
I
just
want
to
see.
You
know
all
the
things
that
I
can
import,
so
I
I
don't
want
to
see
the
things
that
have
already
been
imported,
so
maybe
I
just
want
to
sort
by
whether
it
was
imported
or
not,
or
I
want
to
sort
by
you
know.
So
I
want
to
sort
by
status
instead
of
sorting
by
by
the
name.
C
Yeah
grouping
would
be
more
like
you
know,
just
yeah
I
wouldn't
say:
grouping
grouping
would
be
another
tree
thing
and
then
that's
not
right,
like
I
would
just
sort
or
or
filter,
but
I
wouldn't
group
yeah.
B
And
also,
I
remember
in
prototypes
amanda
shown
us
some
time
ago,
the
sorting
actually
about
like
what
you
saying
to
see
what
could
be
imported
is
done
via
tabs.
So
we
have
tabs
like
available
for
import
in
progress
and
completed
and
all.
C
A
But
here's
we
already
have
table
header
sorting,
so
let's
say
they
want
to
do
sort
by
status.
You
click
on
well,
maybe.
C
A
Well,
I'll
just
leave
it
as
sorting
okay
and
we
can
figure
out
the
nitty
gritty,
okay,
so
sorting
so
we'll
just
continue,
I
guess
to
add
to
this
list
once
we
get
into
get
into
everything.
But
I
think
this
is
a
good
list
to
start
out
with
so
ilya
just
to
confirm.
C
A
All
right
well
we're
three
minutes:
past
elia:
do
you
have
anything
you
want
to
quickly
get
in?
Okay,
no.
B
I
feel
like
we
are
fine
and,
like
I'm
happy
because,
like
I'm
feeling
like,
we
are
proceeding
with
most
boring
solution,
which
is
like
what
is
expected
from
us.
C
And
this
may
be
something
to
bring
up
sort
of
in
the
manage
front-end
development
chat
whatever.
That
is
because
I
believe
that
the
tables
table
component
will
be
more
important
to
some
of
the
other
groups
that
manage
such
as
analytics,
so
that
may
be,
who
needs
to
also
put
their
requirements
together
and
even
maybe
lead
on
implementing
this,
but
it's
still
all
undermanaged.
So
I
feel
like
managed.
Development
should
lead
on
figuring
this
out.
B
A
Awesome
well,
y'all
have
a
great
rest
of
the
day
and
call
it
me
if
you
need
anything,
you
do
yeah.
Thank
you.