►
From YouTube: Plan stage weekly - 2021-03-17
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
So
I
caught
up
with
liam
this
morning,
who's
an
emnn
manage,
and
he
basically
said
that
we
probably
should
just
like
pick
a
feature
and
do
the
first
step
towards
merging
groups
and
projects,
because
there's
a
lot
of
opinions,
but
we
just
like
need
someone
to
be
a
dri
for
making
the
decision
on
how
we're
gonna
like
approach
it.
And
so
I
wanted
to
talk
with
y'all.
A
I
think,
from
my
vantage
point,
the
biggest
thing
that
we
would
need
for
our
stage,
like
the
long-term
vision,
is
to
make
issues
available
to
group
level,
because
then,
once
we
introduce
types
of
issues
and
all
that
good
stuff,
it
unblocks
requirements
being
at
the
group
level.
It
unblocks
eventually
migrating
epics
to
types
of
issues,
and
so
I
was
just
curious.
A
If
john
you
said,
you
would
be
willing
to
maybe
like
drive
the
blueprint
forward,
or
at
least
could
get
us
to
a
point
where
we
know
how
to
take
the
first
small
step
of
getting
issues
at
the
group
level
without
like
duplicating
them
from
a
model
standpoint.
A
B
A
Oh,
that's
the
that's
just
the
the
issue
is
the
that
merge
request.
Resolve
is
the
issue
if
that
makes
sense,
so
we
can
talk
in
just
the
merge
requests
if
you
want,
but
like
the
the
the
issue
is
in
the
architecture
project
about
opening
up
or
like
creating
a
blueprint,
and
then
the
merge
request
that
you
commented
on
is
the
merge
quest
that
will
close
that
issue.
So
if
that
makes
sense.
B
So
I
quite
like
the
idea
of
project
shadowing
where
the
idea
is
that
we
would
basically
deprecate
groups
in
favor
of
projects
and
to
make
this.
Alternatively,
we
could
we
could
create
a
shadow
or
hidden
project
for
each
group
and
start
migrating
resources
from
the
group
to
the
shadowed
project
and
once
all
features
or
resources.
I
are
migrated
to
this
shadow
project,
so
basically
group
would
be
just
an
empty
wrapper
around
this
shadow
project.
B
We
could
just
expose
this
project
instead
of
the
group,
so
that's
one
of
the
ideas
how
to
make
this
consolidation,
but
at
this
point
I
left
the
I
left
the
the
commander
a
week
ago
and
I
think
that
before
diving,
deeper
or
investigating,
this
idea
deeper.
I
would
appreciate
some
feedback
from
some
architects
or
other
engineers.
B
What
is
either
a
problem
with
this
approach,
or
if
there
is
something
else,
some
some
other
way
we
should
focus,
because
otherwise
it
might
be
just
waste
of
idea
to
trying
to
create
a
detailed
plan
which
elaborates
on
top
of
this.
B
A
Yeah,
I
think
it's
I
would
like
to
get
feedback
from
other
folks
too.
I
think
basically
alex
in
is
working
on
rapid
action
stuff
and
is
not
thinking
about
this,
and
I
just
am
worried
that
it's
going
to
sit
here
for
months
and
nothing
will
happen
because
it's
a
hard
problem
to
solve,
and
so
I
just
appreciate
it
if
any
of
the
engineers
in
our
stage
wanted
to
contribute
towards
that
to
figuring
out
the
solution.
A
That
would
be
awesome,
because
I
know
that
there
are
lots
of
other
teams
that
want
to
contribute.
They
just
don't
know
sort
of
like
they
don't
know
how
to,
because
there's
not
like
a
good
direction
page
for
them
to
to
kind
of
take
to
figure
out
how
to
like
implement
their
features
in
a
similar
type
pattern.
So
if
we
can
lay
the
groundwork
basically
for
how
to
do
that
with
our
own
features,
I
think
it
would
be
really
beneficial
for
for
the
entire
product
and
the
rest
of
the
team,
so
yeah.
So.
B
I
think
that
yeah,
you
touch
this
because
of
how
we
would
get
epics
on
project
level
and
issues
on
group
level,
and
I
think
that
this
is
closely
related,
because
I
forgot
to
mention
it.
The
point
is
that
if
you
deprecate
groups
in
favor
and
we
replace.
C
B
With
projects
we
basically
get
bought
for
free
yeah,
because
group
will
would
be
replaced
by
by
project
yeah,
so
we
wouldn't
have
to
implement
epics
on
project
level
now
or
issues
on
group
level
now,
but
if
we
focus
on
deprecated
deprecating
groups
or
projects
or
just
one
of
this
containers,
we
get
this.
We
get
this
for
free
yeah,.
D
Yeah,
this
also
means
that
we
first
need
to
bring
all
of
the
group
features
to
the
project
right.
Even
before
creating
the
shadowing
project
itself.
We
just
need
to
bring
everything
in
the
project
to
have
everything
there
in
order
to
be
able
to
create
this
shadowing
project
that
will
kind
of
replace
the
group.
D
B
B
No
on
api
layer
layer,
you
would
still
talk
to
the
you
would
still
reference
group,
but
internally
the
group
would
just
delegate
this
feature
request
to
the
shadowed
project
yeah.
So
it
will
be
internal
delegation
to
the
shadow,
okay.
A
And
make
the
inheritance
model
work,
because
I
know
right
now
manage
is
working
on
some
like
a
proof
of
concept,
basically
to
have
cascading
settings
and,
from
instance,
to
a
namespace,
but
it's
not
implemented
like
they
haven't
implemented
it
to
from
like
a
namespace
to
a
subgroup
and
then
from
a
subgroup
to
a
project,
and
so
this
is
sort
of
like
why.
Understanding
how
this
will
work
will
also
help.
A
Everyone
else
understand
like
when
to
when
to
move
forward
like
doing
something
that
will
not
be
necessary,
hopefully
in
the
near
future,
or
at
least
contribute
to
like
moving
it
forward.
B
B
Okay,
this
makes
sense
please
proceed
or
we
can
focus
on
this,
and
then
we
can
work
in
working
group,
two
trying
to
figuring
out
detailed
steps,
or
there
may
be
a
pushback
from
architects.
Okay,
this
will
not
work
and
we
should
figure
out
some
other
way
yeah.
But
so
I
I
don't
have
this
feedback
yet.
A
All
right
I'll
go
I'll,
go
start
picking
a
bunch
of
people
too,
and
just
seeing,
if
like
we
can
get
some
feedback
on
it.
I
would
hope
deezy
would
have
responded
by
now,
but
he
hasn't
but
I'll
I'll,
add
a
comment
to
that
and
see
if
we
can
get
somebody
to
give
us
some
more
feedback
cool.
Thank.
E
You
cool,
I
could
talk
about
some
road
map
stuff.
Let
me
share
my
screen.
E
I'm
sharing
the
right
screen
cool,
so
kushal
and
I
have
been
looking
at
road
maps
and
specifically
kind
of
like
the
date
picking
experience,
which
we
don't
have
at
the
moment
and
what
that
could
look
like.
It
ended
up
being
a
little
more
complicated
and
thanks
for
bearing
with
me
here,
kashal
but
yeah.
E
So
instead
of
having
like
a
traditional
date,
picker
where
you
can
pick
any
range,
I'm
thinking
for
nbc,
we
just
add
kind
of
like
a
default
date
picker
into
the
roadmap,
with
a
few
kind
of
sane
defaults
like
let's
say:
let's
this
quarter
this
year
within
three
years,
which
I'm
thinking
could
be
like
from
today
back
a
year
and
a
half
and
forward
a
year
and
a
half.
E
Something
like
that,
and
what
I
like
about
these
kind
of
set
defaults
is,
then
we
could
control
what's
presented
on
the
roadmap
and
like
what
kind
of
empty
states.
Let's
say
it
might
appear.
E
So,
for
example,
when
I
looked
into
this
I'll
kind
of
take
y'all
through
my
process,
I
thought
about
like
what
dates
might
make
sense
and
what
that
means
for
our
current
roadmap
and
how
we
display
data,
because
we
have
these
kind
of
fixed
columns.
E
It
can
get
a
little
unwieldy
if
you
have,
for
example,
short
time
frames.
So
I
kind
of
mapped
out.
You
know,
thinking
about
the
different
time
frames
by
the
view
or
like
how
you
would
be
segmenting
them.
So
let's
say
I'm
looking
at
months.
I
want
to
look
at
a
month
by
quarters,
or
I
want
to
look
at
a
month
by
a
month.
E
I
want
to
look
at
a
month
by
week
like
so
what
could
that
look
like
for
all
these
time
frames,
and
this
is
where
it
got
kind
of
wacky,
which
is
what
we
discovered
while
we,
while
we
were
trying
to
look
at
this
and
thinking
about
building
it
and
especially
for
any
time
frame
ever
you
run
into
all
these
weird
kind
of
empty
states,
because
our
columns
are
set
by
that
segment.
E
So,
if
I'm
looking
at
month
by
quarter
on
my
screen,
I'm
only
seeing
basically
one
column
of
data,
so
this
whole
block
is
basically
like
a
19
like
a
screen
red
screen
resolution
of
like
1920,
and
then
this
would
be
like
a
more
like
13,
60
or
13
20,
something
like
here.
E
So
even
if
you
have
not
an
ultra
wide
monitor,
you'd
still
you'd
still
only
be
seeing
one
column
of
data
here,
so
it's
kind
of
like
what
is
this
empty
state
right
and
then
thinking
about
that
across
all
those
different
segments.
I
mentioned.
There's
just
a
lot
of
empty
data
states
in
here
which
might
not
be
terrible.
Could
look
something
like
this
right
and
you
know.
Maybe
we
just
don't
have
the
drop
shadow
here,
because
you
can't
scroll
and
then
there's
just
kind
of
like
grayed
out
time
frame
up
here.
E
I'm
not
sure
like
is
that
super
useful?
I
don't
really
think
so,
and
you
know
I
want
to
zoom
out
this
time
frame.
It
gets
so
long
that
you're,
perhaps
having
a
scroll
a
whole
lot
just
to
see.
Maybe
one
epic,
that's
just
like
way
at
the
end.
Here
so
I'm
thinking
for
iteration
one,
we
could
just
kind
of
like
scope
it
down
to
a
few
different
time
frames
that
don't
have
those
weird
empty
states.
E
I
just
showed,
and
I
don't
think
that
it
would
be
too
much
of
a
different
experience
than
we
have
now,
but
it
could
be
a
step
forward
to
something
better.
So
I
picked
out
the
the
states
that
we
have
currently
that
don't
have
that
empty
state
on
them,
and
that
would
be,
I
believe,
six
these
six
here.
So
if
we
look
at
the
picker,
it
would
look
something
like
this.
So
when
I
selected
this
quarter,
I
would
only
be
able
to
view
it
by
weeks,
so
I
wouldn't
even
have
like
that.
E
Little
segmenting
experience
for
the
different
views.
If
I
have,
if
I
select
this
year,
I
could
select
by
you
know
viewing
that
by
months
or
by
weeks
that
I
select
within
three
years,
I
can
see
quarters
months
and
weeks
like
it
is
currently
and
then
within
the
roadmap.
E
It
looks
something
like
this
so
not
too
different
for
iteration,
two,
which
I
have
here
here
yeah
I
attached
it,
I'm
thinking
it
might
be
interesting
to
make
those
column
widths
more
dynamic,
so
I'm
I'm
kind
of
like
zooming
into
the
roadmap,
based
on
how
I'm
setting
my
dates
so,
instead
of
having
the
column
widths,
always
set
like
this,
when
I
select
a
time
frame,
it
kind
of
zooms
me
in
so,
for
example,
you
can
see
it
kind
of
side
by
side
in
the
the
issue,
but
I'll
just
show
you
here.
E
So
I
would
see
something
like
this,
for
example,
so
I
want
to
see
my
quarter
segmented
by
quarter.
I
see
this
instead
of
this,
which
has
you
know
a
bunch
of,
has
an
empty
state
or
if
I
want
to
see
that's
a
better
one
month,
segmented
by
week,
half
my
screen
would
be
an
empty
state
here,
as
I
see
month,
segmented
by
week.
Here
you
know
it's.
It
could
take
up
my
entire
viewport,
which
would
be
nice,
and
maybe
we
could
play
around
with
even
like
do.
E
We
even
need
them
to
scroll,
or
you
know,
left
and
right,
or
can
we
just
have
this
be
fixed
in
the
viewport
like
this?
I
don't
know
that
could
be
something
to
think
about,
but
it
just
it
it's
an
easier
way
to
see
the
data.
So
this
is
something
not
nvc,
but
I
think
it'd
be
nice
to
explore
here
and
we
can
even
get
you
know,
fancy
with
the
brush
and
zoom
control
things
like
that.
E
But
you
know,
as
you
see
here
like,
I
could
see
in
my
viewport
an
entire
three
years
of
data
segmented
by
week,
and
it
looks
a
little
weird.
I
don't
know
if
you
want
to
do
that,
you
can
and
that's
a
lot
more
usable
than
having
to
scroll.
E
You
know
a
million
million
times
to
view
all
those
epics
and
then
the
intention
here
is
that
we
can
make
the
roadmap
more
performant
as
well,
and
you
know
I
think
that
this
is
not
going
to
solve
the
performance
problem.
I
think
what
we
need
to
do
is
start
by
giving
the
user
like
narrow
data
and
letting
them
broaden
it
instead
of
starting
abroad
and
letting
them
narrow.
So
maybe
even
like
templates
or
making
them
pick
a
group
to
start
or
you
know
who
knows,
don't
get
scared.
E
A
I
think
for
the
nbc,
if
you
sl,
set
a
date
range
of
whatever
it
is,
don't
have
the
little
picker
next
to
it,
to
let
them
specify
the
date
or
the
week
or
month
or
whatever,
just
automatically
change
the
chart
to
or
the
roadmap
to
reflect
that
if
that
makes
sense,
because
that
way
like
it
would
declutter
things
and
it's
almost
like
the
giving
them
the
option
to
toggle
between
months
and
weeks
is
something
that
you
could
add
later
is
like
an
enhancement,
but
you
could
just
default
to
like
you
know
when
it
when
you're,
when
the
date
ranges
this
year,
you're
always
going
to
show
things
in
months
when
the
date
range
is
three
years,
you're
always
going
to
show
things
in
quarters,
and
that's
like
it
for
right
now
and
then
later
you
can
explore
like
the
zooming
option.
A
That
would
be
something
a
little
bit
like
more
global,
but
that's
that's
my
feedback
on
the
picker
itself
on
the
the
general
idea
of
adding
a
date
range.
I
don't
understand
why
other
than
for
performance
is
there
a
reason
that
we
want
to
do
this
other
than
performance?
I
guess
is
the
question.
E
I
think
it's
just
you
can
kind
of
zoom
into
the
dates
you
care
about
right
rather
than
endless
scrolling,
and
then
I
think
it
gets
more
useful,
like
I
said,
if
you
add
in
the
idea
of
kind
of
like
zooming
into
those
dates
as
well
like
right
now,
it
is
kind
of
weird
because
it's
it
doesn't
really
dynamically
change
your
roadmap,
except
for
the
performance
issues.
E
It
could
mitigate
that
a
little
bit,
but
even
at
gitlab
we
have
so
many
epics
within
the
year
that
maybe
that
wouldn't
even
help
too
much,
but
it
could
be
a
step
in
the
right
direction.
E
If
that
makes
sense,
and
then,
like
I
said
like
just
seeing
the
the
view
you
care
about
like
configuring
that
view,
but
I
think
that's
one
of
the
jobs
to
be
done
is
like
crafting
the
view
you
care
about
and
then
maybe,
if
we
get
into
like
saving
views
things
like
that,
just
kind
of
having
that
snapshot
that
time
frame
of
you
know
what
you
want
to
focus
on,
I
think,
is
helpful
and
then
the
segmenting
thing
I
agree
like
we
could
default.
E
I
have
seen
in
other
products
that,
like
they
default
the
time
frame
to
like
three
years
or
four
years
and
have
these
these
segmenting
options,
but
I
think
both
are
going
to
be
useful
at
some
point.
They're
just
not
super
useful
at
the
moment,
but
I
don't
know
I
mean
like
as
a
pm
kristin
gabe,
marcus
you're.
Here
I
think
you
are
like
what
would
be
useful
to
you
and
narrowing
down
a
time
frame.
A
I
want
to
narrow
down
like
what
what
I
see
on
the
what
I
see
on
like
the
actual
epics
list,
and
I
want
it
to
be
really
really
fast
right,
like
that's
where
it's
safe
filters,
there's
ongoing
this
open
discussion
right
now,
where
I
think
amelia
the
designer
and
monitor,
is
like
exploring
some
ideas
for
safe
filters,
but
that
would
be
way
more
valuable
for
me,
because
then,
every
time
I
go
to
the
epic
board
or
the
road
map
view,
I
don't
have
to
go
from
a
bookmark
to
my
browser.
A
G
I
would
say
for
me
as
well
seeing
the
whole
thing
is
really
important,
like
I
wouldn't
be
segmenting
my
dates
as
when
I'm
for
getting
there,
but
I
would
potentially
hit
that
the
three-year
or
zoom
to
fit
in
so
it
like.
Maybe
if
I'd
misplaced,
something-
and
it
was
like
way
out
in
2030,
the
whole
thing
could
zoom
and
I'd
see
the
whole
picture.
G
So
I
could
go
make
adjustments,
but
I
wouldn't
be
hitting
it
with
the
mindset
of
like
I'm
gonna,
set
a
date
range
and
then
look
at
this
I'd
more
so
see
the
whole
thing
then
adjust
the
zoom
level
or
this
where
it
was
centered
to
find
the
quarter.
I'm
currently
on
I'd
just
be
afraid.
I
wouldn't
see
something
if
it
were
off.
If
I
accidentally
queried
it
out
with
the
date
range.
C
I
was
going
to
say
for
me
I
kind
of
agree.
I
don't
think
I
want
to
filter
by
dates
what
I'd
rather
filter
out
is
by
epics
or
by
like
removing
vertically,
what's
shown
and
zooming
in
on,
like
a
specific
epic
or
specific
handful
of
epics
or
a
parent
epic,
with
multiple
child
epics
and
being
able
to
see
how
that's
progressing,
because
one
of
the
things
that's
really
hard
to
do
right
now
for
me
is:
I
have
organized
all
the
epics
for
like
certify
by
like
category
maturity
stages,
and
then
I
want
to
know
hey.
C
When
will
this
category
maturity
stage
be
complete
and
underneath
that
it
might
be
like
10
other
epics
which
each
have
other
sub
epics?
So
it
would
be
nice
to
be
able
to
like
zoom
in
in
that
way
like
like
filter
out,
what's
being
shown,
so
I
can
say:
okay,
this
epic
is
the
long
pole.
Let's
look
at
it,
let's
plan
it
out.
Let's
understand
why
it's
it's
sticking
out
so
far.
A
I
was
also
going
to
add
to
like
I
want
to
eventually
I
hope
we
eventually
merged
the
idea
of
a
fixed
date
and
an
inherited
date
into
one
so
that,
on
a
board,
I
can
like
drag
and
drop
an
epic
into
like
a
date
range
and
then
see
like
what
all
the
things
within
it
like
are
planned.
If
the
plan
basically
over
time,
if
it
lines
up
with
my
fixed
date
that
I've
set
if
the
inherited
date
is,
is
basically
on
track
for
that
fixed
date.
A
So,
like
you,
can
actually
track
the
drift
between
the
two.
But
if
we
filter
our
scope
to
a
specific
date
range
when
I'm
dragging
and
dropping
the
like
the
epic
dates
on
a
roadmap
like
I
would
be
restricted
to
that
date
range,
which
I
don't
know
if
I
would
necessarily
like.
That's
just
like
another
thing
to
think
about
for
the
future,
but.
E
E
G
Ten
years
would
be
accessible,
potentially,
but
probably
five.
If
I
need
to
zoom
out
and
see
longer
term
vision,
we
don't
go
that
far
yet
at
get
lab,
but
a
lot
of
companies
do
and
then
the
day-to-day
would
be
segmented
by
release,
probably
like
so
about
a
four
week
marker
and
showing
around
six
months
worth
just
to
see
high
level
like
where
things
are
in
terms
of
the
upcoming
releases.
G
Either
my
quarter
or
by
release
would
be
the
toggle
and
I
would
probably
only
zoom
to
weak
if
it
were
real
specific,
but
we
only
really
track
into
releases
in
terms
of
dates.
So
it's
not
like
we're
looking
like
it
has
to
be
done
by
wednesday,
we're
not
like
going
to
that
day,
granularity
at
get
lab,
but
some
of
our
customers
are
probably
doing
that.
F
A
F
Thoughts
around
the
design
and
specifically
in
the
implementation
part
of
it.
So
right
now,
when
we
look
at
roadmap,
I
think
the
fundamental
problem
we
are
trying
to
solve
is
performance,
because
that
is
immediately
affecting
us,
the
load
times,
as
well
as
the
general
interaction
times,
and
there
are
a
couple
of
reasons
why
performance
is
slow,
barring
the
back
end,
because
we
are
trying
to
pull
in
a
lot
of
data
in
one
go,
so
that
is
obviously
gonna
slow
down.
F
F
C
F
Is
because
we
are
trying
to
render
a
lot
of
things
at
once,
which
means
that
our
horizontal
timeline,
which
is
not
even
part
of
the
viewport,
is
extending
beyond
the
viewport,
and
we
are
trying
to
render
a
lot
of
nodes
there
and
that
slows
down
and
vertically
as
well.
There
are
too
many
epics
that
we
render
at
the
same
time,
even
if
user
is
not
going
to
see
those
epics
by
scrolling
all
the
way
to
the
bottom
of
the
list.
F
There
are
some
libraries
that
we
did
try
to
utilize
in
the
past
like
implement
some
form
of
buffered,
rendering
where
a
user
would
see
only
20
epics,
then
only
20
epics
are
actually
rendered
rest
of
the
epics
live
within
the
javascript
object,
so
the
rendering
doesn't
take
a
hit
and
interaction
is
smoother.
But
as
we
added
new
features
like
milestone
lines
within
the
roadmap,
it
kind
of
broke
the
behavior
of
buffer
rendering
because
the
library
was
not
compatible
with
the
ux
that
we
have
around
the
roadmap.
So
today.
F
One
key
reason:
one
key
behavior
that
you
notice
within
roadmap
is
that
the
horizontal
bars
where
we
show
the
timeline.
That
is
months
which
month
it
is
which
quarter
it
is
which
week
it
is.
Those
are
horizontally
scrolled
when
you
horizontally
scroll
the
timeline.
But
when
you
scroll
the
list
vertically,
you
see
that
the
headers
remain
affixed
and
that's
via
a
css.
Behavior
same
thing
happens
with
the
first
column,
where
we
show
epic
details
where,
when
you
scroll
the
list
vertically
details,
rows
will
be
scrolling
along
with
the
timeline
bars.
F
But
when
you
scroll
horizontally
first
column
remains
a
fix,
then,
and
that
is
the
very
initial
behavior
that
we
started
with
when
we
created
rhoda.
F
But
when,
when
we
think
about
zoom
in
zoom
out
features
donald
and
I
had
a
very
detailed
conversation
around
how
a
typical
zooming
zoom
out
behavior
needs
to
be
in
our
one.
On
one
and
the
analogy.
F
Thought
of
was
think
of
google
maps
or
any
maps
app
where,
when
you
zoom
out
all
the
way
out
from
the
map,
you
don't
want
to
see
the
city
names
or
even
the
county
names
on
the
map.
If
you
really
zoom
out
from
the
map,
all
you
see
is
the
state
teams.
If
you
are
looking
at
a
particular
country
and
if
you
zoom
out
further,
you
see
country
names
and
not
even
state
names
or
city
names.
F
So
I
like
to
think
of
zooming
functionality
to
match
with
that
behavior
and
to
correlate
it
with
how
road
map
would
work.
If
user
wants
to
see
a
time
frame
of,
say
five
years
or
ten
years,
chances
are
that
they
are
interested
in
epics
which
span
across
that
timeline
right
and
they
are
not
interested
in
breaking
down
those
epics
into
say
week's
view.
F
So,
if,
if
we
do
implicit
view
switching
by
determining
on
how
long
the
time
frame
is
so,
for
instance,
if
user
selects
say
five
years,
we
don't
show
a
preset
switcher
on
ui
at
all.
Rather,
we
show
years
as
follows,
because
user
knows
that
these
epics
are
spanning
across
years,
which
is
why
they
selected
five
years
in
first
place
and
that
will
solve
our
performance
problem,
where
we
don't
render
the
entire
horizontal
timeline
for
the
viewport
extended
viewport.
Essentially.
Instead,
we
would
just
render
five
columns
and
be
done
with
it.
F
We
show
all
the
12
months
or
a
quarter
of
a
year
as
a
preset.
So
we
don't,
let
user
determine
what
preset
they
use,
because
we
might
end
up
in
a
similar
situation
that
we
have
now
where
we
are
rendering
too
much
of
items
or
nodes
within
the
dom
at
once.
Instead,
we
be
opinionated
depending
on
what
the
time
frame
is.
This
will
not
only
free
our
filtering
area
on
ui,
where
we
don't
show
a
lot
of
knobs
and
buttons.
F
F
Only
scrolling
that
will
be
possible
from
this
behavior
is
vertical
scrolling,
and
then
we
can
use
the
buffer,
rendering
libraries
where
we
show
the
number
of
epics
that
are
visible,
because
the
reason
why
we
had
to
revert
our
code
where
we
initially
had
the
buffer
rendering
in
place
was
because
our
timeline
was
scrolling
in
both
the
directions
and
particularly
horizontal
infinite
scrolling
was
the
culprit
there.
F
So
if
we
get
rid
of
horizontal
scrolling
entirely,
then
we
might
be
able
to
reimplement
the
usage
of
that
library
and
then,
even
if
there
are
2000,
fx
and
say
10
years
of
time
frame,
that
user
is
selected,
we
won't
be
bothered
about
performance
there.
So
that's
just
my
thought
process
on
the
history
behind
the
implementation
and
what
we
can
do
going
forward.
E
Would
would
this
help,
then,
in
your
opinion,
or
do
we
want
to
be?
I
mean
like
this
could
be
post
nbc
and
then
like
we
like
be
opinionated
and
just
like
show
like
three
views
for
mvc.
Is
that
kind
of
what
you're
thinking,
because
I
also
like
so
in
my
in
my
thinking
this
would
be
the
viewport
and
they
wouldn't
necessarily
have
to
scroll
horizontally,
like
you
were
talking,
yeah
and
yeah
so
and
then
we
could
have
the
defaults.
E
I
don't
think
I've
seen
many
products
that
don't
allow
users
to
zoom,
and
that
would
be
my
only
worry
right.
But
I
don't
I'm
not
like
opposed
to
doing
that
for
mvc,
just
like
having
those
those
defaults
and
then,
like
you,
said,
adding
it
in.
F
We
are
not
taking
away
zooming
functionality
at
all.
We
are
still
keeping
it
as
it
is.
We
are
just
taking
away
the
presets,
so,
for
instance,
if
we
still
continue
to
show
preset
and
if
user
selects
say
start
and
due
date,
which
fall
within
the
same
month,
it
doesn't
make
sense
to
help
resets
in
first
place
because
they
select
the
date
and
they
try
to
fiddle
around
like
what
happens
if
they
select
one's
view,
while
the
time
frame
itself
is
only
a
month
long
right.
F
So
if
they
zoom
in
down
to
the
last
week,
then
in
that
case
we
don't
show
preset.
We
just
render
week's
view
for
that
time
frame
and
depending
on
whatever,
and
we
can
still
have
some
form
of
validations
in
place
like
how
big
of
a
gap
between
time
frame
is
or
how
small
gap
can
there
can
be,
and
that
way
it.
It
makes
implementation
much
straightforward
without
having
to
deal
with
a
lot
of
conditions
and
excuses.
A
Oh
was
going
to
show
this
is
how
I
I
get
a
lot
of
customers
or
that
I've
talked
to
you
that
have
used
roadmap,
that,
like
it
or
are
using
it,
and
this
is
how
they
don't
support
horizontal
scrolling,
but
they
let
you
like
basically
drag
your
time
range
and
and
that
will
change
like
the
columns
that
are
shown.
So
you
can
zoom
in
and
zoom
out
this
way
and
they
only
ever
like
segment
things
by
month,
but
this
is
sort
of
how
you
can
go
out
to.
A
If
you
want
to
solve
this
problem
too,
because
it
more
or
less
does
the
scrolling
for
you
based
on
your
little
slider
appear,
but
you
can
kind
of
scope
things
down
to
as
granular
like
time
frame
as
you
want
and
then
kind
of
like
move
that
around
if
you
want
to
like
explore
stuff
further
out
anyway,
it's
I
just
thought
I'd
share
that
because
it's
an
interesting
way
to
solve
the
problem
too.
E
Well,
I'm
just
saying
I
think
that
was
what
I
was
envisioning
for
the
mvc2
I'm
showing
and
like
instead
of
having
that
brush
and
zoom
I'm
seeing
that
like
the
little
segmenting
controls.
But
maybe
maybe
we
just
go
with
like
that
kind
of
control
instead
we're
like
literally
zooming
it
out,
and
I
think
to
your
point
gabe.
You
said
they're
only
showing
months
so
I
think
krishna,
that's
kind
of
what
you're
being
yeah
yeah.
F
F
So
exactly
like,
we
already
have
implemented
views
in
place
for
quarters
and
weeks
few,
so
the
behavior
would
be
similar
to
what
gabe
showed
just
that.
When
user
really
expands
the
timeline
to
cover
multiple
years,
we
just
switch
the
views
instead
of
shrinking
the
columns
to
really
smaller
width
columns
right
because
then
we
can
avoid
the
problems
of
empty
cells.
F
Like
you
mentioned,
initially
analysis
where
user
may
have
epics
falling
within
just
one
or
two
quarters,
but
they
are
still
trying
to
view
five
years
of
data
where
all
the
rest
of
the
columns
are
not
being
utilized
and
that
doesn't
really
make
sense
unless
we
introduce
a
feature
where
they
can
just
drag
and
drop
the
timeline
parts
to
update
the
range
but
yeah.
We
start
with
the
initial
design
like
this,
where
we
switch
between
the
views
and
then
when
we
are
ready
to
implement,
drag
and
drop
functionality.
F
Where
user
can
expand
and
collapse
due
dates
based
on
just
dragging
the
timeline
bars,
then
we
can
maybe
switch
to
a
single
type
of
view,
either
weeks
or
months.
But
I
think
implicit
view
switching
where
we
have
three
different
views
and
if
you
do
decide
to
go
ahead
with
the
fourth
view,
that
is
the
year's
view.
In
case
you
want
to
cover
five
years
or
ten
years
of
time
frame.
F
E
G
So
I
think
this
looks
really
cool.
I
want
to
make
sure
that
we
do
hit
the
use
cases
for
people
who
are
also
editing
road
maps.
I
know
right
now
we're
really
focusing
on
getting
the
zoom
right
and
getting
the
objects
in
and
maybe
like
a
static
consumption
of
it,
but
keep
in
the
back
of
your
mind
that
this
also
needs
to
be
an
editing
environment.
G
I
did
mention
in
like
point
two
just
to
consider
looking
at
how
notion
has
handled
that
and
sort
of
almost
building
it
into
a
grid.
Like
experience,
I
can
just
quickly
share
my
screen
here
where
you
can
easily
work
on
your
timeline
as
well
as
zoom
to
it
and
or
jump
to
it.
Using
these,
it's
pretty
lightweight.
G
B
I
think
I
mentioned
it
in
some
comment,
but
it
might
be
that
even
for
the
three
years
window,
if
you
request
for
four
quarters,
it
might
be
still
quite
a
big
time
frame,
so
we
would
still
require
quite
many
epics,
so
I
think
that
we
might,
it
still
might
not
scale
very
well,
but
I
think
that
it
will
improve
the
situation
compared
to
the
current
state.
So
it's
worth
to
try
it,
but
I
wanted
to
ask:
did
we
did
we
consider?
B
F
Yeah,
so
we
really
wanted
to
use
pagination,
but
since
infinite
scrolling
was
in
place
where,
if
you
scroll
in
the
future
or
in
the
past,
the
time
frame
changes
and
then
we
basically
inserted
or
removed
a
relevant
epics
from
the
timeline
depending
on
what
direction
user
scrolls
in
horizontally.
F
That
kind
of
prevented
us
from
using
pagination.
Because
then
things
would
look
out
of
order,
because
there
is
this
also
short
drop
down
in
place
within
the
filtering
area,
where
user
must
might
have
selected
to
sort
epics
within
the
roadmap
by
either
start
date
or
a
due
date.
So
that
was
the
reason
why
pagination
could
not
be
used.
F
But
like
we
discussed,
if
we
not
have
horizontal
scrolling
at
all
and
we
make
the
entire
rendering
opinionated,
then
obviously
we
can
use
pagination
where
and
yeah,
depending
on
whether
we
want
to
sort
by
start
or
due
dates
or
not,
because
if
user
is
selected
to
sort
by
due
date
and
then,
if
user
sees
only
20
epics,
then
they
would
have
to
click
multiple
times.
For
the
next
button
to
see
the
data
for
next
couple
of
pages.
B
E
And
I
think
I
said
that
probably
here's
I
can't
I
need
more
coffee.
All
the
problem
to
solve
here
is
more
about,
I
think,
like
the
filtering
aspect
or
just
like
not
letting
users
get
into
the
state
where
there's
just
like
a
million
epics
that
aren't
relevant
to
them
within
the
red
map
and
then
they're
having
to
paginate
through
them.
E
So
if
we
could
solve
that
problem
it,
it
may
not
be
such
an
issue
with
the
vertical
scrolling,
but
that
would
just
be
my
assumption
and
I'm
sure
we
still
could
get
into
a
state
with
a
lot
of
epics
that
the
user
cares
about
within
vue,
but
maybe
we
could
also
be
more
opinionated
about,
like
you
can't
use
the
roadmap
unless
you
first
add
like
a
group
filter
or
like
some,
you
know
like
there's
or
saved
filter,
or
I
think
that
might
be
a
good
problem
to
solve.
E
E
Can
you
instead
go
to
maybe
like
a
dashboard,
and
you
know
before
you
enter
the
roadmap
state
you're,
building
out
your
roadmap
kind
of
like
a
board
right
and
or
maybe
better
than
that
experience
as
well,
because
we
have
issues
there,
but
really
paring
it
down
before
you
get
into
that
view,
making
sure
you're
only
going
to
see
what
you
care
about
once
you
enter
the
roadmap,
I
think
kristin,
you
were
talking
sorry.
G
No,
I
wasn't.
I
was
just
trying
to
catch
up
in
the
agenda
now
that
it's
moving
here,
I'm
not
sure.
If
gabe
did
you
mention
your
performance
question
just
around
saving
the
dates
and
in
terms
of
performance.
G
A
That
was
just
one
thing
I
was
going
to
bring
up
is
like
have
we
considered
also
like
storing
the
inherited
date
ranges
on
epics
themselves,
instead
of
like
queering,
that
and
all
the
children
basically
at
when
we
want
to
render
the
road
maps
we
more
or
less
just
like,
if,
if
a
child
changes
that
it
triggers
an
update
to
the
parent,
basically
to
calculate
that
date
and
then
store
it
on
the
database
in
the
back
end.
F
F
Another
example
that
I
noticed
there
is,
for
instance,
if
any
epic
has
no
start
or
due
date
defined,
and
if
it
has
a
weights
present,
then,
when
you
horizontally
scroll,
the
timeline
bar
remains
affixed
within
the
view
and
the
implementation
logic
for
that
particular
behavior
is
really
heavy
and,
like
jan
mentioned,
that,
if
we
could
leverage
pagination
as
well
as
the
fixed
columns
instead
of
having
to
scroll
horizontally,
then
it
would
allow
us
to
immediately
see
performance
gains,
because
then
we
don't
have
to
worry
about
dynamically,
inserting
or
removing
items
from
the
list.
F
At
the
same
time,
all
the
additional
logic
that
is
currently
going
on
like
what
to
do
when
user
scrolls
past
the
edge
will
be
gone.
There
is
a
lot
of
code
removal
that
we
are
looking
at
if
we
go
forward
with
the
zooming
in
behavior.
G
H
Do
you
know
the
answer
to
that?
So
what
were
what
we
initially
tried
to
solve
with
this
is
to
reduce
that
at
least
11
second
load
time
of
epics
on
gitlab.org.
H
H
So
I
I
think
we
still
need
to.
We
still
need
to
solve
that
problem.
So
if
we
don't
want
to
have
dates,
we
need
to
alexis,
like
you
said,
either
enforce
filtering
by
group,
though
that
doesn't
that
solves
our
issue,
our
use
case-
I
don't
know
if
it
solves
other
use
cases
that
don't
maybe
use
groups
that
have
a
lot
of
epics
like
we
do.
E
Yeah
just
be
more
in
force
filtering
in
general,
but
that's
just
one
option.
B
Yes,
I
mean,
I
agree
that
both
shrinking
the
time
frame
and
also
introducing
filters
both
approaches
will
help
for
sure
with
the
performance
on
backhand
side,
because
we
assume
that
we
will
request
less
epics.
Currently,
when
we
do
the
request,
we
fetch
two
thousand
of
epics
and
we
do
need
to
do
complex
queries
for
this.
So
if
the
idea
is
okay
in
the
time
frame,
we
will
have
less
epics
with
the
filters.
Then,
yes,
it
will.
It
will
help
with
the
performance.
H
Have
we
done
a
investigation
and
where
the
because
yeah
I
mean
3,
000
epics
are
a
lot,
but
I
feel
like
11
seconds,
to
query
3000.
B
Well,
the
good
news
is
that
now
it's
only
12
seconds
because
before
it
was
timing
out
on
the
sql
query,
this
sql
query
is
now
relatively
fast.
It
takes
around
three
or
four
seconds
to
get
these
epics,
but
then
there
is
also
extra
time
to
fetch
milestones
which
are
fetched
because
of
doing
multiplex,
graphql
query,
but
anyway,
another
portion
of
time.
I
think
another
six
seconds
I
is
done
outside
of
the
sql
queries
somewhere
in
the
code,
I'm
not
exactly
sure
where
it
would
require
some
profiler
on
github.com
to
investigate
this
further.
B
I
H
To
figure
out
our
our
first
iteration
here
like
what
we
should
force
filtering
of
as
just
as
an
nbc.
If
it's
not
going
to
be
the
the
dates,
we
should
figure
out
something,
and
then
we
can
do
some
of
these
side
things
and
alexander
your
comment.
H
It
looks
like
the
inherited
dates
already
stored
on
the
epic,
so
that's
probably
like
that
may
not
be
where
the
time
is,
but
we
I
mean
we
should
definitely
do
that
investigation,
but
we
still
want
to
figure
out
what
the
nbc
to
to
get
the
road
map
loading
in
quicker
than
12
to
15
seconds
on
fricking
lag
board.
G
The
filters
high
up
like
alexis
was
mentioning
like
when
you
set
up
a
board,
so
you
kind
of
set
that
just
one
time
essentially
into
the
filter.
G
H
Are
we
saying,
then
we
want
to
require
a
some
filter
before
we
render
the
road
map
part
of
it
like
initially
until
we
get
safe
filters.
E
Sounds
like
it's
yeah
like
thinking
through
the
onboarding
into
a
roadmap
like
what
is
that
step
before
you
enter
a
roadmap?
What
is
that?
What
is
kind
of
like
the
creation
flow?
So,
like
think
about
it
less
of
like
I
want
to
view
every
item
in
gitlab
or
in
my
group,
I'm
more
about
like
I'm,
going
to
build
my
roadmap
first
and
then
I'm
going
to
do
it.
If
that
makes
sense,
so
then
scoping
that
back
we'll
have
to
think
about
what
the
nbc
of
that
is,
but
we
could
do
that
async.
H
Yeah,
because
I
mean
there
is
probably
a
use
case,
maybe
in
other
organizations
for
that
top
level
view
I
just
don't
know
with
with
3000
and
not
being
able
to
see
them
all
on
a
single
screen
without
scrolling.
Both
ways
there's
a
whole
lot
of
value,
but
as
like,
like
a
board
level
or
c-level
executive,
they
may
there
they
may
be.
There
may
be
value
there
and
seeing
that
top
level
everything
view.
E
I
think
that's
where
the
zooming
in
could
be
helpful
right,
like
if
we
at
least
get
it
like.
If
you
change
the
interaction
where
the
viewport
is
maybe
you're
not
scrolling
horizontally,
at
least
like
that
could
be
a
start
to
help
with
that
and
then
you're
like
zooming
into
the
data,
instead
of
just
seeing
everything
in
those
fixed
columns,
and
so
we
we
could
think
about
that
more
too,
and
so
basically
circling
back
to
everything
else.
Everyone
else
has
said
this
entire
meeting,
but.
G
Yeah,
this
is
also
just
epic
soon,
we'll
have
issues
on
the
board,
so
that
will
also
magnify
about
could
be
ten
issues
per
epic.
So
we
do
have
to
think
about
this.
It's
gonna
get
a
lot
bigger.
I
have
seen
on
previous
team.
We
had
30
000
rows.
We
had
to
render
we
used
collapsing
and
bought
a
grid
component.
That
was
really
lightweight
that
helped
us
do
that
and
have
like
just
it
was
working
out
of
the
box
because
it
was
such
a
hard
problem
to
solve.
To
have
that
many,
but
yeah.
G
B
A
You
could
you
could
also
with
that,
instead
of
loading
them
all.
What
is
it
like?
It's
like
optimized,
fetching
or
whatever,
where
you
you
basically
put
the
fetch
on
the
mouse
over
event,
instead
of
the
click
of
it
or
the
hover
event
in
that
area,
and
usually
like
that,
and
then
you
would
just
be
making
such
a
small
request
for
just
that
children
that,
generally
like
the
response,
would
be
pretty
fast.
A
So
you
could
look
at
that
too.
F
Yeah
right
now
in
the
roadmap
relationship
between
child
effects
and
parent
effects
is
built
after
the
data
is
loaded
so
like
the
entire
decomposition
happens
before
the
roadmap
gets
rendered.
So
if
we
can
avoid
that
computation,
then
we
definitely
should.
Instead,
when
the
node
gets
expanded,
that's
when
we
fetch
in
the
child
data.
We
are
already
doing
it
in
groups
dashboard,
where
we
show
tree
of
all
the
groups,
but
we
fetch
child
groups
for
a
given
group
only
when
the
node
is
expanded,
and
that
is
fairly
fast.
F
So
I
think
if
we
want
to
avoid
making
a
subsequent
request
right
away
once
the
page
is
loaded,
we
can
avoid
it
and
wait
for
user
to
either
do
mouse
over
or
click.
I
would
go
for
a
click
instead
of
mouse
over,
because
if
user
is
just
hovering
over
the
timeline
bars,
we
don't
want
to
end
up
throwing
bunch
of
requests.
G
You
everyone
that's
good
discussion.
I
know
we're
close
to
time
here,
so
I
don't
want
to
cut
it
off
early,
but
I
want
to
make
sure
we
get
in
by
9
30.
G
G
The
goal
of
that
would
be
that
we're
hearing
from
design
the
work
that
would
be
broken
down
in
planning
breakdown,
so
there
could
be
some
discussion
ahead
of
time
in
real
time
and
have
like
a
mini
kickoff
of
some
of
those
features
from
the
design
team.
G
Okay
and
then
the
second,
this
is
just
something
I
learned
when
I
was
ceo
shadow
were
some
of
these
skills
around
meetings
and
if
I
actually
encourage
all
of
you
to
sign
up
for
that,
there's
a
lot
of
open
spots
right
now
in
terms
of
just
encouraging
participation
as
a
team
there's
just
a
few
things
we
can
do-
and
this
is
these-
are
like
80
20
rules.
It's
not
a
hard
fast
thing,
but
if
you
do
it
most
of
the
time,
meetings
will
get
a
lot
more
inclusive.
G
So
when
you're
gonna,
if
you
have
a
point
choose
to
raise,
you
can
just
indent
and
put
your
name
and
type
your
point
and
then
it's
up
to
everyone
else
to
also
be
just
sort
of
referencing
that
and
asking
the
person
to
speak
next.
So
we
kind
of
retain
a
little
bit
of
order.
G
Also
take
notes
for
your
colleagues
so
like,
if
someone's
in
the
middle
of
a
thought
and
they're
thinking
it
through.
You
can
try
your
best
to
take
notes
down
as
they're
going
and
then
a
really
other
cool
tip.
Is
the
space
enter
technique
for
adding
new
bullets
at
the
bottom?
You'll
note
like
if
you
just
hit
enter,
sometimes
it
doesn't
work.
G
So
yeah
just
thought:
I'd
just
bring
that
up.
So
we
can
all
think
about
that
and
try
to
have
more
people.
Speaking
up
on
these
calls.
H
Sorry,
alexis
you
didn't,
have
you
didn't
get
to
leave
early
and
prepare
for
your
showcase?
So
oh
no.
E
It's
gonna
be
a
real
weird
one.
It's
fine
I'll
do
a
30
minute.
Prep,
we'll
see
what
happens
thanks
for
all
the
feedback.