►
From YouTube: Plan Stage Weekly Meeting 2022-02-16
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).
B
Yeah
I
just
got
here:
I'm
never
yeah.
So
by
now
you
probably
all
saw
the
note
or
scott
reached
out
to
you,
but
he
is
no
longer
at
gitlab.
As
of
monday,
I
linked
to
his
known
in
slack.
I
believe
all
his
open
projects
have
been
transitioned,
but
if
you
do
need
anything
that
he
was
working
on
or
if
you
have
any
questions
on
anything,
he
was
working
on.
Just
let
me
know
currently
working
on
backfilling
his
position.
B
The
role
should
be.
The
wreck
should
be
open,
hoping
for
today
it's
been
a
bit
since
we've
opened
any
engineering
positions
on
the
plan
stage
and
things
have
changed
a
lot,
but
I'm
still
trying
to
refamiliarize
myself
with
the
process,
but
hopefully
that
should
be
open.
Today,
questions
comments.
C
Hello,
all
right,
let
me
share
my
screen
and
all
that
stuff,
so
I'm
looking
into
epic,
I
guess
links
I've
been
calling
them
because
I'm
trying
to
keep
them
for
mvc
fairly,
similar
to
what
we
have
now.
I
think
that's
what
we've
been
discussing,
so
the
idea
of
just
like
linking
you
know,
epics
as
dependent
or
related
basically
blocks
is
blocked
by
the
ones
we
have
currently.
C
First,
I
think
you
know.
One
of
the
problems
we
would
have
to
think
through
is
like
how
to
differentiate
this
widget
from
the
current.
I
guess
epochs
in
issue
widget.
We
have
like
the
epic
tree
right.
I
think-
and
this
is
all
kind
of
rough
and
I
want
to
validate
it
more,
but
what
we
could
do
is
just
kind
of
style
that
epic
tree
more,
like
our
other,
I'm
gonna,
say
widgets
so
much
our
other
widgets
and
instead
of
having
that
tab
at
the
top
start.
C
Thinking
about
how
we
could
show
these
items
like
in
a
in
a
view
because
we're
kind
of
thinking
of
view
types
so
switching
that
for
now
to
a
different
component,
lessening
the
hierarchy
a
little
bit
and
then
that
could
be
contained
in
this
widget
instead
and
then
the
user
could
perhaps
collapse
this
entire
widget.
I
know
we've
had
some
feedback
that
the
epic
tree
can
get
long,
for
example.
So
maybe
we
could
just
collapse
the
whole
thing
that
doesn't
necessarily
collapse.
Every
single
object
within
the
tree
or
anything
just
the
whole
widget
minimizes
it.
C
And
then
maybe
we
can
think
about
how
to
contain
that
road
map
view
within
this
widget
as
well.
I
know
it
kind
of
has
some
issues
at
the
moment,
or
maybe
we
I
don't
know,
maybe
we
hide
that
view
for
now.
Maybe
we
could
look
at
usage
and
see
if
people
are
using
that
and
if
we
could
just
kind
of
focus
on
the
tree
and
then
at
some
point,
maybe
we
will
merge
these
widgets
together,
but
for
a
pc.
C
I
think
it
makes
sense
to
just
kind
of
keep
them
separate,
and
then
I
get
you
know
as
we
see
now
just
the
tree
view,
and
this
would
be
nested
all
the
stuff
it
does
now,
and
then
this
also,
having
kind
of
like
two
rows
here
for
counts
and
for
like
settings
just
gives
it
a
little
bit
more
room
to
breathe
again,
I'm
still
playing
with
this
and
then
at
some
point.
C
We
might
have
more
kind
of
like
settings
here,
and
maybe
this
turns
into
like
a
drop
down
with
you
know,
show
labels
and
anything
else
the
user
wants
to
do.
Maybe
they
want
to
hide
closed
items
here.
I
don't
know
we
could
play
around
with
different
things
to
do
there.
So
that's
just
like
thinking
through
updating
the
current
epic
tree
so
that
maybe
we
can
then
place.
Let's
say
this
new
linked
epics
widget
below
it
and
they
look
similar.
C
But
not
quite
you
know
not
exactly
the
same,
but
you
understand
they're
part
of
the
same
system
and
it
doesn't
look
so
jarring
together
and
you
could
also
collapse.
You
know
some
of
these
so
that
you
can
better
focus
on
different
with
widgets
again
within
an
epic
and
then
playing
around
with
that.
So
I
put
like
the
different
things
I'm
discussing
here
in
the
agenda.
So
if
you
have
questions
you
can
put
them
there.
C
So
thinking
through
how
that
would
look,
I
think
what
could
be
awesome
if
we
can,
you
know,
swing
it
and
I'm
not
sure
we
can
it's
just
allowing
the
user
to
kind
of
search
across
all
groups
and
so
not
quite
federated
search,
but
when
they're
searching
within
the
search
bar,
for
example-
maybe
it
just
indicates
what
group
each
of
these
items
is
within.
So
I'm
searching
for
epic
d,
I
see
epic
daisy
dog
donut
right.
Those
are
the
ones
that
exist
and
they're
in
different
groups
or
different
subgroups.
C
I
see
that
there
and
then
actually,
yes,
that
is
one
part
of
it
and
then
it
would
be
also
interesting
if
the
user
could
just
create
an
epic
if
it
doesn't
yet
exist,
just
straight
from
this
experience,
instead
of
having
to
click
a
separate
button
so
that
they
could
just
say:
okay,
I
don't
see
epicd
in
this
list.
I
just
want
to
create
it.
C
Whatever
that
experience
is,
I
think
it
would
be
nice
if
there
was
just
contextual.
We
could
just
maybe
plop
a
modal
there
for
nbc,
they
create
it,
and
then
you
know
once
they
create
or
once
they
click
create.
They
go
back
to
the
context
they
were
at
before,
and
they
see
it's
added
and
they
can
add
that
linked
epic
or
if,
let's
say
we
want
to
allow
users
to
create
or
add
many
epics
at
once,
it
would
be
kind
of
similar.
C
And
then
you
know,
if
we
can't
allow
for
this,
then
we
would
have
to
add
some
kind
of
group
selector.
I
don't
know
exactly
what
that
could
look
like
if
you
want
to
have
it
more
conversational
like
we
do.
Currently,
it
was
just
like
you
know
the
following
epic
located
in
the
only
reason
I
don't
love.
This
is
that
you
know
they're
logically
wanting
to
select
probably
a
group
before
the
epic,
but
they
might
not
know
the
group
it's
in.
C
D
Yeah,
so
I
have
a
small
question
there,
so
we
are
planning
to
reuse
the
linked
issues,
front-end
app
as
it
is
for
the
epics,
and
we
have
done
some
backstage
work
to
clean
up
all
the
hard-coded
strings,
etc,
and
one
limitation
or
the
feature
behavior
you
could
say
is
that
in
the
linked
issues
we
do
not
support,
searching
for
plain
text
issue
titles
you
would
either
have
to
paste
in
the
entire
issue
link
or
you
just
need
to
have
an
issue
id
so
in
case
we
want
to
introduce
a
title
based
search
for
the
linked
epics.
D
Then
there
will
be
a
disparity
between
the
two
widgets.
So
do
we
want
to
continue
having
the
similar
mechanism
for
the
epics,
where
user
will
be
allowed
to
just
paste
the
epic
link
or
an
epic
id
followed
by
the
symbol?
Or
do
we
want
to
do
the
other
way
round
where
we
introduce
the
title
based
issue
search
in
the
linked
issues,
because
I
would
rather
prefer
to
have
a
consistency
and,
as
a
first
iteration,
we
can
skip
on
not
having
title
based
search
and
just
have
the
widget
be
reusable
as
it
is.
B
So
kushal,
I
think
there
is
title
search,
it's
just
hidden,
so
you
have
to
hit
the
hashtag
pound
symbol
first
and
then
you
can
title
search
after
that.
So
I.
D
I
I
I
have
it
open
in
front
of
me
and
the
moment
I
put
in
hash
as
a
symbol
for
issue.
It
does
show
the
issue
title
along
with
the
issue
id
number,
but
I
cannot
just
type
in
the
issue
title
from
the
appearing
drop
down.
I
would
still
need
to
put
the
number
which
is
representing
that
issue
before
I
can
add
it
automatically.
C
B
D
Okay,
okay
yeah,
so
the
issue
that
I
am
looking
at
has
all
the
titles
beginning
with
the
certain
string.
So
obviously
it
is
awesome.
C
D
Are
just
pulling
in
the
issues
for
the
current
project,
but
when
it
when
it
comes
to
linked
epics
the
equation
changes,
because
we
also
have
nested
groups
and,
depending
on
how
wide
of
a
scope
we
want
to
have
here
like
from
which
hierarchical
groups
do
we
want,
allow
epics
to
be
linked.
Our
search
space
would
either
be
broad
or
narrower,
so
that
basically
elevates
the
problem
a
bit
in
case.
D
B
C
D
Yes,
I
think
we
can
begin
with
a
similar
ux,
but
eventually
we
can
have
a
single
component
that
can
be
utilized
for
both
issues
and
epics,
because
the
underlying
app
is
still
the
same,
and
we
already
have
a
component
within
gitlab
ui
that
we
can
use
here
to
have
a
tokenized
search
and
not
have
to
worry
about
a
local
search.
That
is
happening
right
now.
We
can
even
introduce
a
network-based
search,
at
least
for
the
epics,
because
there
will
have
a
lot
more
children
groups
to
worry
about.
A
I'm
going
to
skip
mine
and
and
go
to
jans,
because
I
think
that,
like
they're
related
anyway,
I
think
we
use
the
auto
suggest
endpoint
for
this
right.
A
There's
there
are
specific
endpoints
auto,
I
think
it's
auto
suggests
or
auto
complete
slash
issues
and
slash
epics.
I
think
we
use
that.
Does
anyone
know.
A
G
Yeah,
I
think
we
have
autocomplete
endpoint
in
internal
api
which
could
be
used
for
this.
So
from
the
discussion,
it
seems
that
we
load
all
issues
in
in
the
project.
If
I
understood
it
correctly,
which
might
be
a
big
problem
and
and
it's
the
response
could
be
pretty
huge.
Also,
I
wonder
if
the
same
would
be
used
for
epics
or
if
we
plan
to
use
auto
completion
and
retain
only
10
results
or
20.
D
Yeah
I
just
tested
it
out
and
if
you,
if
you
try
to
just
put
in
the
hash
in
any
of
the
issue
within
gitlab
project,
we
are
loading.
43,
000,
plus
issues
in
a
single
api
call
and
then
doing
local
search
on
front
end.
So.
B
Yeah-
and
we
used
to
do
that
on
for
the
through
the
auto
complete
api
for
filtered
search
within
the
issue
page,
which
is
within
the
group
issue
page
and
forget,
lab
org.
That
call
took
forever
since
we
switched
it
to
graphql,
it's
not
nearly
as
bad,
but
I
don't
think
we
can
get
away
with
loading
all
of
the
epics
within
a
within
an
epic.
H
A
The
view
issue
list
feature
flag
is
that
switched
on
for
olive.com,
no
okay
cool,
so
there
was
one
endpoint
that
refused
to
go
away
and
it
was
the
epics
controller
index
action
and
we
couldn't
figure
what
was
still
calling
that
and
we
tracked
it
down
to
the
old
filter
bar
and
we
wanted
to
remove
that
endpoint
entirely
because
it
loads
all
epics.
A
D
And
looking
at
the
payload
that
we
are
trying
to
load,
I
think
then,
then
I
kind
of
agree
with
alexis
here
that
we
should
rather
have
the
widget
from
the
get-go,
where
we
just
leverage
graphql
and
support
full
title
bases
for
both
issues
and
epics
and
do
the
pagination
as
well,
because
I
don't
see
implementing
such
an
api
call
for
epics,
where
the
number
of
epics
that
we
end
up
getting
in
single
call
is
even
huge.
B
Yeah
so
for
first
iteration,
because
I
don't
think
we'd
have
we'd
be
able
to
get
it
all
over
to
graphql
in
time.
But
the
first
iteration
should
just
be
no
title
search,
just
paste
the
links
or
use
the
epic
id.
G
Out
of
curiosity,
what
are
we
using
on
front-end
side
in
the
epic3
widget,
because
I
remember
it's
possible
to
add
sub
epics
too,
and
there
is
some
auto
completion.
So
do
we
use
a
autocomplete
endpoint
there
or
are
we
loading
all
epics
there
too,
and
the
following
question?
Can
we
reuse
the
same
auto
condition
in
this
new
upcoming
related
epics
widget,
because
it
would
be
the
same
right
so
we
want
to
provide
the
same
list
of
epics
as
we
provide
in
the
epics
tree
right.
A
D
Yeah
and
I
believe
it
is
doing
the
exact
same
thing-
that
as
we
would
want
it
in
the
linked
epics,
because
on
on
gitlab
org
project,
it
is
our
group,
it
is
basically
loading
all
the
8000
epics
at
once.
A
Yeah,
I
just
ran
it
there.
It
took
milliseconds
not
great,
not
awful.
D
Yes,
yes,
so
if
you,
if
you
try
to
add
an
existing
epic
as
a
child,
epic
and
you
put
ampersand
symbol,
it
would
basically
do
the
autocomplete
sources
thrust
call
and
it
will
pull
all
the
epics
from
that
group
as
well
as
child
groups
and
then
show
you
exact
same
context
menu
as
you
would
see
in
daily
english.
D
D
Yeah,
so
basically
we
get
backend
for
free.
In
case
we
want
to
reuse
the
exact
same
endpoint.
A
A
I
B
Oh
in
in
that
search
for
the
epic
tree,
we're
only
searching
by
group
right.
Well,
we're
sorry
we're
only
searching
through
a
specific
group
group.
B
D
Yeah
so,
at
least
in
the
api
call
that
we
are
making,
we
are
not
passing
any
query
patterns,
so
we
have
had
these
query
params,
like
include
descendants
and
include
ancestors
whenever
we
want
to
search
through
a
group
that
is
not
happening
in
this
particular
endpoint,
and
if
you
try
to
add
an
existing
epic,
it
doesn't
even
ask
you
to
select
the
group
first.
It
assumes.
D
Trying
to
look
for
an
epic
which
is
available
for
current
group
that
you're
in
we
are
not
passing
any
query
param
to
determine
whether
we
want
to
include
hierarchy
or
not.
D
Wait
wait.
It
does
include
the
child
groups
because
I
can
see
that
it
is
trying
to
bring
up
epics,
which
are
part
of
gitlab
org,
as
well
as
gitlab
org,
slash,
charts
group.
A
A
It's
not
going
to
be
possible
until
we
solve
the
problem
of
just
so.
It's
not
performance
at
all
to
search
across
like
every
group
that
you
have
access
to
and
all
the
epics
in
those
groups
it's
just
too
slow,
so
at
least
for
now
it
won't
be,
but
but
you,
since
you
can
still
add
epics
from
subgroups,
you're
still
going
to
need
that
label.
That
shows
the
group.
A
C
D
So
we'll
have
to
see
how
the
tree
widget
basically
behaves
currently
like
right
now.
You
can
either
have
a
permalink
to
the
epic
with
the
domain
etc,
and
you
just
paste
that
link
and
it
determines
which
group
to
look
for
that
particular
epic
and
in
case
you
do
want
to
search
for
an
epic
which
belongs
to
a
certain
child
group.
D
Then
I'm
I'm
guessing
you'll
have
to
do
the
title,
search
which
happens
locally
instead
of
async,
so
yeah
I
mean
I,
I
wouldn't
expect
a
user
to
provide
a
group
path,
at
least
either.
They
need
to
have
a
link
to
an
epic
directly
from
the
address
bar
or
they
just
should.
They
ideally
should
remember
the
title
of
the
epic
that
they
are.
They
are
trying
to.
A
G
Yes,
exactly
and
on
backhand
side
what
is
happening
when
passing
these
references
is
that
we
parse
it
exactly
as
we
will
do
in
your
markdown.
If
you
reference
some
issue
in
the
issue,
description,
for
example,
so
the
exactly
same
happens,
then
we
are
parsing
these
references,
so
you
can
use
ampersand
number
to
reference
local
to
reference,
epic
in
the
same
group
or
you
can
use
the
four
group
parts
ampersand
number
to
reference,
cross-group
epic
references
or
even
urls.
C
Okay,
I'll
have
to
play
around
with
the
issue
links
too
just
to
kind
of
conceptualize
the
behavior
but
you're
saying
that
like
if,
if
I'm
in
group
a
and
I
type
ampersand
2,
I'm
still
going
to
see
like
that
drop
down
with
the
matches
to
ampersand
2
within
group
a
and
then
maybe
group
a
slash
subgroup
c
or
whatever.
Okay,
I
see
nodding.
C
C
C
And
then
I
wonder
if
we
could
look
into
it,
but
maybe
they
I
guess
they
would
need
that
group
selector
for
mvc
as
well
yep
cool.
C
So
my
next
question
wise,
I
mean
this
is
probably
a
silly
question
to
y'all,
but
why
is
the
global
like
advanced
search
so
different
than
ours
like
what's
the
logic
there,
because
that
one
seems
to
be
able
to
search
fairly
performantly?
I'm
talking
about
the
one
like
in
the
top
nav.
I.
I
Yeah,
so
it
uses
a
totally
different
search
technology
and
the
reason
that
we
can't
use
it
for
things
within
plan
is
because
there's
a
two
minute
delay
on
indexing.
So
if,
like
you
make
a
new
issue,
it
doesn't
show
up
there
for
a
while
and
then
there's
some
like
overarching
long-term
discussions
on
how
we
would
eventually
be
able
to
use
elasticsearch,
because
it's
definitely
the
like
preferred
solution
for
big
searching,
big
bodies
of
text
like
we
do,
but
so
far
it's
just
kind
of
like
totally
separate.
I
It's
called
there's
a
group
called
global
search
that
works
on
it.
So
that's
why.
A
C
Someday
cool
I'll
just
go
over
my
last
point
really
really
quickly
and
then
we
can
move
on.
So
just
the
last
thing
around
I
mean
there's
a
lot
of
things,
but
we'll
just
talk
about
this
one
that
with
like,
I
don't
know
exactly
what
to
call
these.
So
if
you
have
an
epic
that
is
not
confidential,
but
it's
in
a
group
you
don't
have
access
to
I'm
thinking.
C
It
would
be
nice
for
the
user
to
be
able
to
see
that
that
the
epic
exists,
but
they
don't
have
access
to
it
and
maybe
there
would
even
be
counts
on
it,
probably
not
display
the
group
it's
in
and
again.
This
is
all
kind
of
just
like
ideation
rough,
but
I'm
thinking.
Maybe
and
again
I
don't
know
exactly
what
to
title
it
like
private,
epic
or
just
like
I
don't
know
it's
not
confidential,
just
like
or
epic
or
whatever,
but
and
then
allow
the
user
to
perhaps
request
access.
C
I
know
we
were
thinking
about
like
read-only
modes
for
epics,
but
I'm
thinking
it
would
be
interesting
to
allow
the
user
to
at
least
see
that
something
exists
there
and
perhaps
be
able
to
get
some
kind
of
some
kind
of
view
of
it.
What
do
y'all
think.
A
I
think
it's
awesome,
but
I
don't
think
it's
mvc,
but
like
a
very
early
version
of
this
might
be
just
to
simply
like
subtract.
Since
we
don't
have
relative
positioning
in
the
mvc
anyway,
I
believe
it
wouldn't
really
matter.
We
could
put
all
these
to
the
bottom
and
simply
do
account
right
and
say,
like
you
know,
if
there
are
10
epics,
but
you
only
see
it.
We
fill
in
the
remaining
two
with
just
a
placeholder
that
says
you
know
private
epic
and
that
way
as
well.
A
We
can
avoid
any
incoming
like
bug
reports
which
say,
like
I
see
a
count
of
12,
but
I
only
see
10
epics
like
what
am
I
missing.
You
know,
I
think
it's
a
cool
idea.
Yeah.
F
I
I
don't
know
why,
but
in
gitlab
we
usually
the
resources
that
you
don't
have
access
to
usually
four
or
four
on
them.
I
don't
know
if
that
was
a
security
related
thing
that
was
raised,
because
even
if
they,
for
instance,
a
project
exists
and
you
want
to
access
it,
you'll
not
get
a
permission,
denied
you'll,
get
a
404
and
that's
the
same
for
issues
and
for
epics.
I
think
so
I
don't
know
like.
F
Obviously
this
will
solve
some
of
the
issues
that
we
have
with
the
accounts
right
all
over
the
place
where
you
don't
have
permission,
but
the
thing
exists,
but
I
don't
know
where
the
discussion
started
or
how
this
was
decided,
but
we
seem
to
even
kind
of
like
decide
not
to
even
show
the
the
fact
that
something
like
that
exists
to
a
user
that
doesn't
have
permission
to
to
see
that
information
so
yeah.
It
may
be
a
bigger
question.
I
don't
know
why
it
was
decided
this
way.
B
Yeah
and
then
you
also
have
access
to
some
like.
If
you
go
to
a
link-
and
it
says
you
don't
have
access
to
this-
you
still
have
access
to
some
things
in
the
url.
So
to
like
john's
point,
you
can
use
that
to
to
brute
force
information
off
of
it.
So
for
the
mvc.
B
What's
the?
What
is
the
plan
on
epics
that
the
user
doesn't
have
access
to?
Are
we
just
not
showing
them
within
the
within
the
epic
link?
Widget.
C
C
G
Yes,
I
think
you
are
right.
We
ignore
permissions
for
counts,
for
performance
reasons,
and
I
think
it
was
agreed
some
time
ago
that
it's
okay
to
show
not
matching
counts.
At
least
we
don't.
We
ignore
permission
checks
in
all
counts
in
left,
sidebar
and
on
other
places.
So
I
would
expect
this
is
the
same
case.
C
So
I
think
the
problem
to
solve
there
would
I
mean
that's
a
problem
to
solve,
like
maybe
there's
something
small.
We
can
do
to
improve.
That,
like
john
said,
even
I
don't
know
like
even
just
some
some
kind
of
weird
little
placeholder.
That's
just
like
you.
Don't
have
access
to
this
item
or
like
you're,
I
don't
know,
there's
an
epic
here,
but
then
that
would
be
kind
of
behavior
that
we
have
elsewhere
that
we
might
have
to
amend.
So
it's
kind
of
a
global
thing.
So
because
then
what
would
we
do
in
a
board?
C
For
example?
Would
we
then
show
like
a
card
like
that?
So
it's
something
you'd
have
to
think
through.
G
G
C
So
for
nbc,
perhaps
like
we
could
work
on,
I
think
we're
looking
at
this
a
little
bit
just
some
kind
of
notification
that
the
counts
may
be
mismatched,
and
why
can
we
trigger
like
that?
Like?
Can
that
be
conditional
that,
if
the
if
the
user
doesn't
have
access
to
some
of
the
items
in
the
list,
they
see
something
a
notification
that
tells
them?
Why
or
do
we
know
that
would
have
to
just
be
ever
present.
C
G
I
assume
that
a
simple
check
would
be
that
front-end
may
check
if
the
number
of
retrieved
epics
matches
the
number
it
requested,
so
it
if,
if
it
requests
100
epics
and
it
gets
only
98
epics,
then
the
reason
might
be
that
some
are
missing
due
to
permission
check.
But
this
is
more
complicated,
because
if
there
is
less
than
100
epics,
we
return
less
epics
anyway
and
with
key
set
patchination,
we
don't
return
total
amount
of
epics.
G
G
D
Yeah
I
was
going
to
suggest
exact
same
thing,
but
then
I
realized
yes
with
pagination
in
the
mix
we'd
have
to.
Maybe
we
can
do
something
on
the
rails
level
before
even
we
do.
The
graphql
api
hit,
like
maybe
backend,
provides
a
flag
that
the
counts
are
ignoring
permissions,
but
there
may
be
some
epics
that
are
required
to
have
permission
before
you
can
access
them.
So
just
a
boolean
flag
should
be
sufficient.
I
mean
we
don't
need
to
show
how
many
apex
or
issues
user
doesn't
have
access
to.
D
C
All
right
I'll
create
a
issue
and
kind
of
tinker
on
it
and
we
can
work
on
it
there
any
other
questions
here
and
then
we
can
move
on
to
demos.
Sorry
took
off
all
this
time.
A
I
think
we
have
nobody
left
to
demo
this
one,
which
is
a
shame,
but
I
got
to
play
with
germany,
but
there
is
a
a
demo
project
where,
where
it's
enabled
on
which
I
think
people
can
go
and
check
out
I'll,
find
that
afterwards
and
put
it
in
the
agenda.
A
That's
the
next
point
after
this:
let's
see,
if
I
can,
if
my
voice
will
stick
with
me
for
the
whole
point,
but
anyway,
it's
just
a
quick
update
on
the
back
end
planning
spike
for
epic
dependencies,
which
we
were
just
talking
about.
A
We
made
some
key
decisions:
we're
going
to
use
the
internal
rest
api,
mostly
for
issue
links,
because
it
makes
it
easier
for
front-end
and
back-end.
Basically,
we
can
copy
more
stuff
over
it's
a
known
thing.
We
know
how
it
works.
We'll
also
expose
one
endpoint
by
the
external
rest:
api,
that's
for
customers
to
be
able
to
access
their
epic
dependencies
through
the
rest
api.
A
We
have
a
stretch
goal
for
that
as
well
to
include
the
rest
of
the
rest
api,
but
it
is
a
strategical
we'll
be
focused
on
just
making
sure
we
get
out
with
the
mvc
first
hit
some
naming
things
so
we've
gone
with
related
epic
link,
since
epic
links
is
already
defined,
it's
defined
for
epic
hierarchy
relationships,
which
is
annoying
and
dissatisfying,
because
issue
link
means
related
and
blocking
issues.
So
there's
just
a
little
cognitive
overhead
there,
but
like
we
can't
do
anything
about
it.
A
Now
yeah
permissions
checking
performance
should
be
acceptable,
but
we'll
need
to
test
as
we
go
and
we've
decided
well.
If
we
didn't
decide,
we
were
informed
that
the
tier
is
ultimate
so
yep
huge
thanks
to
eugenia.
She
drove
the
spike
forward.
Yeah
awfully
big
michelle
donald
gave
melissa
and
everyone
else
who
participated
and
kept
it
unblocked
and
yeah.
I've
linked
the
the
mvc
epic,
it's
all
nicely
laid
out
in
issues
weighted
ready
to
rock
and
we've
actually
already
started
the
database
work
because
it's
usually
the
single
blocker
to
everything.
A
We
started
that
already
it's
gone
into
maintainer
review
today.
That's
it
any
questions.
C
Yeah,
it
looks
a
little
different,
but
donald
created
this.
So
this
is
the
donald
test.
Basically,
now,
when
you
go
into
roadmap,
you'll
see
the
settings
button
that
took
some
of
those
items
outside
out
of
the
header.
You
can
select
a
date
range.
It
defaults
to
this
quarter.
You
select
this
year,
for
example,
it's
kind
of
conditional,
so
you
can
change
the
segments.
C
Get
more
the
longer
the
time
frame
you
can
turn
off
milestones
entirely
or
this
one
we're
kind
of
tinkering
on
still
or
you
could
select
just
like
a
certain
segment
of
milestones
like.
Maybe
you
only
want
to
see
project
milestones,
you
can
show
open
closed
or
all
fx
like
as
we
have
currently,
it's
just
styled
in
a
different
way
and
then
the
cool
thing
is
you
could
either
turn
progress
tracking
off
or
you
can
now
display
it
by
issue
count
and
quantify
that
progress
tracking
in
that
way,
that's
our
questions.
G
D
D
So
I
I
reviewed
a
couple
of
these,
mrs,
I
think
what
we
are
doing
here
is.
We
are
introducing
query
param
for
every
setting
that
you
touch
so
essentially
what
happens
is
if
you
have
the
url
bookmarked
and
if
you
hit
that
url
it.
It
basically
won't
request
milestones
in
case
the
query.
Param
is
representing
that
the
milestones
are
not
shown
so
that
way,
you
are
basically
preventing
unnecessary,
graphql
calls,
but
yeah
until
we
introduce
some
form
of
preferences.
D
B
G
Now
the
question
was:
rather,
if
the
query
which
is
done
to
backend
is
updated
with
only
necessary
attributes
depending
on
settings
yeah.
So
if
user
checks
that
he
doesn't
want
to
see
milestones
in
the
roadmap,
then
we
don't
request
milestones
from
the
weekend:
yeah,
no,
not
yet
yeah.
G
A
B
Yep,
I
think
that's
something
we're
taking
on
next
in
14
9
is
to
unbatch
those
queries.