►
From YouTube: Plan Team Weekly 2020-11-11
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
B
Okay
hi
all,
hopefully
it
works,
though,
let's
see
actually
let
me
stop
just
okay.
First,
just
in
case
I'll
be
sharing
my
screen.
B
Can
you
see
two
browsers,
yep,
okay,
so
I'll
try
to
show
the
so
here
on
the
left.
This
browser
is
basically,
I
think,
yesterday's
master
or
something
without
so
I
want
to
show
that
what
we
currently
have
and
what
this
change
kind
of
brings
and
what
I'll
do.
B
B
Well
what
this
actually
does
right
now
in
production
is
this
sets
these
templates
for
file
templates,
so
in
gitlab
we
have
two
concepts
of
file
templates
and
description.
Displays.
Description
templates
are
for
issues
and
match
requests
and
files
in
place
are
for
all
sorts
of
other
files
that
I'll
go
through
in
a
moment.
So
let's
say
we
have
a
couple
groups
here
with
this,
with
some
hierarchy
and
I'll
go
straight
into
a
deeper,
deeper
level,
just
to
show
how
this
file
team
plays.
Well.
Let's
say
we
go
here.
B
So
when
you
add
a
file,
you
have
this
selected
type
of
template.
So
if
you
just
took
your
file
down,
you
have
all
of
these
types
of
templates
from
different
levels
listed
here.
There
is
a
bug
here
that
somehow
it
doesn't
really
differentiate
like
between
the
content
of
the
two
files,
but
that's
fixable.
I
guess
anyway,
the
structure
is
here
now
what
we
have
instead,
for
instance,
for
an.
B
B
We
just
don't
have
the
option
just
because
this
specific
project
within
its
cifo
doesn't
have
the
the
description
templates
specified
and
just
to
make
it
clear
for
the
team
place
for
the
files
in
place.
You
just
go
to
the
specific
group
and
pick
from
which
project
you
want
it
in
place
to
be
pulled.
B
B
B
Then
you
have
all
of
the
same
templates
that
are
being
inherited
from
one
group
to
another.
Now
there
is
a
ui
problem
here.
If
you
have
them
deeper
and
deeper
and
deeper,
then
this
will
go
just
longer
and
longer.
I
don't
know
how
best
to
approach
this
and
to
solve
it,
but-
and
this
doesn't
have
the
bug
where
you
don't
like
the
they
will
just
return
the
right
simply
so
yeah,
that's
that's
the
devil.
Pretty.
B
D
Yeah
so
the
in
the
drop
down,
I
think
you
said
it
was
a
bug,
maybe
that
you
were
showing
the
same
templates
lots
of
times
like
you
only
have
to
find
two
templates
in
one
project
right,
like
description
templates.
B
D
Okay,
so
in
the
drop
down,
if
if
we
only
have
two
basically
two
there's
another
issue
template
so
we're
showing
like
the
do.
A
duplicate
template
from
with
is
inherited
from
each
parent
group,
but.
B
So
I
have,
I
have
another
example.
Let
me
just
do
that
field
test,
where
I
don't
inherit.
This
stuff
is
like
yeah,
where
it
doesn't
override
itself.
So
here
I
have
this
top
group
and
if
I
go
to
general.
B
Templates
yeah
this
is
just
in
here,
is
the
instance
template.
So
so
what
will
happen
here
in
the
projects?
It
will
only
show.
B
A
B
B
So
I
didn't
specify
any
kind
of
template
repository
for
this
subgroup
right
and
now,
if
I
do
a
new
issue,
it
will
just
inherit
the
instance.
One
so
instance
ones
are
pretty
much
always
well
yeah.
It's
pushed
down
from
the
instance.
If
you
remove
the
instance
in
place,
then
you'll
have
nothing
here
as
well.
B
Repository
structure
is
slightly
different,
like
for
docker
and
for
other
things.
You
need
to
have
this
structure,
whereas
for
for
description
to
place,
you
need
them
to
be
in
dot
gitlab
and
then
you
should
in
place
measure
question
place
and
we
can
have
epic
templates
and
whatever
we
want
to
add
here
as
well.
B
Maybe
we
can
somehow
fix
this
structure
to
be
more
coherent,
so
we
don't
have
some
stuff
in
that
gitlab
and
some
stuff
in
this
root
directory
and
so
on,
but
yeah
at
least
this
is
one
step
closer
to
having
like
a
single
place
where
you
can
define
all
of
your
team
plays
and
then
just
reuse
them,
as
you
wish
at
different
field
travels
and
so
on.
D
Yeah,
that's!
This
is
a
awesome
next
iteration
on
templates,
so
I
think
it
will
be
valuable.
I
know
like
this
is
one
of
the
most
upvoted
issues
and
our
stage
is
group
level
issue
templates
and
epic
templates
in
our
templates.
So.
B
A
Yeah,
like
just
an
observation
like
just
because
eugenie-
and
I
were
talking
about
this
in
relation
to
page
titles
and
it'll-
be
nice
for
it
to
be
standard
yeah.
A
So
just
for
the
side,
scrolling
bug,
yeah,
we're
gonna,
go
with
this
kind
of
group
and
then
ellipsis
and
then
the
subgroup
in
the
project
where
the
ellipsis
just
covers
all
the
subgroups
in
between-
and
I
think
we
already
use
this
for
page
titles
to
compress
page
titles,
and
I
think
it
has
all
the
information
you
need
in
most
cases
like
it
tells
you
what
the
top
level
group
is.
It
tells
you
what
sub
group
you're
working
at
and
what
project
you're
in.
So
I
don't
know
if
that's
helpful.
A
A
Eugene
you
want
to
verbalize
that.
C
Yes,
the
one
I
know
is
called
full
name,
it's
just
not
sure
how
it
became
with
subgroups,
so
groups.
I
think
it
will,
because
that's
what
we're
using
for
the
title,
but
the
title
of
a
page,
for
example,
is
showing
a
project,
but
I'm
not
sure
I
probably
have
to
go
and
see
if
the
method
or
a
page
that
is
using
it.
I
guess
it
will
make
sense
that
it
has
the
subgroup
so
groups.
A
A
A
A
We
lifted
the
feature
flag
on
this
yesterday4.com,
so
it's
available
to
everyone
who
uses
dot
com,
but
we
haven't
defaulted
the
feature
flag
to
on,
and
there
does
appear
to
be
some
conflicting
guidance
around
how
we
should
manage
documentation
when
there's
a
feature
flag
used
in
this
way.
So
I'm
kind
of
asking
everyone
for
discussion
on
the
issue,
although
I
do
just
want
to
take
action
on
it
as
quickly
as
possible
and
merge
whatever
improvements
we
need
if
you're
like.
If
you've.
A
If
you
can
imagine
how
this
happened
like,
we
basically
have
two
not
great
possibilities.
One
is
that
we
document
a
feature
before
the
feature
flag
is
ready
to
be
switched
on
on.com,
and
then
we
have
documentation
and
no
feature
or
the
opposite
where
we
turn
it
on
for
com
without
having
written
the
documentation,
and
we
periodically
like,
like
for
a
short
period
of
time,
have
no
documentation
for
a
feature.
That's
live
on.com!
That's
the
situation,
we're
in
now
with
quality
management.
A
So
one
possible
solution
is
that
we
would
have
like
a
draft
mr
ready
to
merge
when
we
just
before
we
flip
on
the
feature
flag,
something
like
that,
but
I'm
looking
for
more
input,
more
ideas,
because
that's
still
not
great
so
alex
you
have
the
first
response.
B
Yeah,
I
was
just
thinking
if
we
like
want
to
force
it.
Maybe
we
can
just
add
these
checks
to
some
sort
of
a
pipeline
and
and
hard
sale,
the
the
mr,
so
we
would
not
be
able
to
merge
it
unless
it
has
documentation
where,
unless
it
has
an
improvement
from
a
technical
writer
that
this
is
okay
to
be
merged
with
our
documentation
and
so
on
and
so
forth.
B
So
yeah,
that's
that's
my
thinking
right
now
because
like
if
we
want
to
afford
that
that
will
obviously
add
to
the
time
that
the
marvel
makes
to
the
production,
because
there
are
multiple
parties
now
involved
in
just
doing
that,
and
but
like
you
need
to
compromise
either
one
everything
with
documentation
never
seen
takes
a
little
bit
more
time
or
sometimes
measures
something
without
the
information
yeah.
A
Yeah,
so
that's
as
well
like
the
guidance
sort
of
well
any
mr
that
has
the
documentation
label,
I
believe,
is
supposed
to
be
reviewed
by
a
technical
writer
and
it's
possible.
We've
missed
that
once
or
twice
just
gone
by
the
feedback
from
martin
and
the
retrospectives.
I
think
the
last
one
was
from
134.
He
left
pretty
detailed
comment
on
that.
The
other
thing
is
like
that.
Some
of
the
feature
flag
guidance
says
that
we
should,
if
we're
using
a
feature
flag,
include
the
documentation
when
we
default
the
feature
flag
to
on.
A
B
A
B
We
keep
doing
like
this
future
flag,
enable
and
then
we
need
to
juggle
with
multiple
groups
or
work
places
where
some
specific
features
does
not
work.
So
we
need
to
turn
off
the
feature
flags
such
as
specific
customers
and
so
on,
and
so
on.
F
Yeah,
this
is
where
I
really
struggle
with
brand
new
features.
It's
less
of
an
issue
for
established
features
where
we're
adding
things
on
and
the
documentation
may
be
slightly
wrong
for
those.
The
problem
with
like
an
mvc
is
from
my
understanding
the
feature
flag,
rollout
process.
You
want
to
turn
it
on
and
get
feedback
for
it.
So
if
we
add
the
documentation
now
and
turn
it
on
for
com,
that's
great,
but
then
some
people
aren't
going
to
be
able
to
see
that.
F
So
you
want
to
turn
it
on
without
enabling
it
to
default
to
on
first,
and
we
can't
currently
do
that.
So
as
soon
as
we're
like
oh
yeah,
well,
turnoff.com
give
it
a
few
days,
make
sure
it
doesn't
break
anything
dramatically
and
then
we'll
enable
it
by
default.
If
we
merge
the
documentation
when
we
enable
it
for
com,
then
we
have
to
turn
it
back
off.
Then
we're
just
going
to
get
complaints
that
this
is
in
the
docs
and
isn't
in
the
product.
F
I
think
there's
no
way
around
that,
because
we
can't
keep
pulling
it
back
out
of
the
documentation
if
we
were
to
have
to
disable
the
feature
flag
once
it's
enabled
by
default.
I
completely
agree
the
documentation
needs
to
be
present,
but
in
this
in
this
test
period,
it
seems
to
me
like
we're
just
going
to
have
to
accept
the
fact
that
there
may
be
a
misalignment
occasionally
but
again,
maybe
I'm
simplifying
it
too
much.
D
I
don't
know
whose
brilliant
idea
it
was
that
was
working
on
iterations.
It
wasn't
mine,
but
one
of
the
things
that
we
did
do
that
I
thought
was
really
useful,
especially
when
we
were
working
with
some
customers
who
want
to
be
early
adopters.
D
The
I
think
the
first
piece
of
documentation
we
put
was
the
feature
flag
documentation.
So
I
linked
to
it
but
basically
says
like
this
is
disabled
by
default
right
and
here's
a
feature
flag.
If
you
want
to
enable
it
and
then,
as
we
added
new
things
to
the
feature
itself,
we
would
like
add
the
documentation
but
like
that,
gets
it
and
gets
it
a
placeholder
in
the
documentation
itself,
so
that
people
like,
if
they're
not
sure
it
is,
can
go
there
be
like.
D
Oh,
this
thing
is
disabled
by
default
because
it's
still
like
an
alpha
or
whatever
you
want
to
call
it
in
the
documentation
and
then
like
it's
there
and
you
can
kind
of
it's
more
additive.
If
that
makes
sense-
and
you
don't
have
to
wait
for
like
a
big
roll
out,
so
it's
almost
like
the
first
time
you
create
the
feature
flag
for
the
feature,
create
the
documentation
with
the
blurb
about
the
feature
flag,
and
that
way,
it's
there
at
least,
is
something
that
then
people
can
iteratively
add
on
to.
D
So
I
feel
like
if
it's,
if
it's
not
there,
sort
of
like
what
you
said
marked
in
it's
almost
like.
When
do
you
add
it?
Where
do
you
put
it?
What
should
it
say,
and
then
it
becomes
like
this
sort
of
insurmountable
thing
that
is
feels
harder
to
iterate
on,
because
you
have
to
like
write
a
whole
bunch
of
stuff
before
you
can
make
something
go
live
instead
of
just
like
little
bits
as
with
each
merch
request.
F
No
gabe,
I
really
like
that.
I
think
that
highlights
an
opportunity
here
is
we
could
go
back
the
idea
that
all
code,
mrs
that
enable
a
feature
should
have
documentation
on
them.
It's
just
when
we
merge
that
code.
Even
if
it's
behind
a
feature
flag,
we
then
have
the
documentation
in
that,
mr,
like
we
are
supposed
to
from
the
get-go
in
theory,
and
we
just
say
in
the
documentation.
F
This
is
currently
behind
the
feature
flag,
but
we
have
all
the
documentation
there
that
way
when
we
enable
it
the
feature
flag,
mr
that
enables
it
to
default
on
when
we
then
that's
the
memoir,
where
we
rev
the
documentation
and
take
out
the
little
blurb
that
says
this
is
behind
a
feature
plot.
Maybe
that
will
make
people
more
happy
because
then
it's
there
and
they're
like
hey,
I'm
seeing
this
well,
it's
behind
a
feature
flag.
F
That
must
be
enabled
right
now,
but
at
least
it
gives
them
documentation,
but
then
people
aren't
expecting
it
if
they
see
it,
it's
there
if
they're
on
but
they're,
not
expecting
it
to
be
there.
I
don't
know
we
can
talk
more
on
it.
I
know
you
open
up
an
issue
for
it,
so
I
appreciate
that
but
yeah
I
I
feel
like
there's
got
to
be
there's
going
to
be
in
between
time
when
we
launch
a
new
thing
like
an
mvc
or
something
like
quality
management.
G
A
That
again,
if
you
wouldn't
mind,
go
around
again
from
the
start,.
G
She
was
too
much
too
cold
with
documentation
since
beginning
and
just
point
out
in
documentation
that
it's
behind
feature
flag,
and
my
understanding
is
that
the
documentation
still
says
this
and
the
moment
you
enable
this
on
dot
com,
even
if
it's
still
behind
the
feature
flag,
you
are
supposed
to
have
a
documentation
on
place,
so
I
would
expect
that
nothing
changes
here.
Maybe
it's
just
a
wrong
wording
in
the
documentation
page,
but
I
would
expect
that
the
commentation
is
still
there
from
the
beginning,
and
it's
stated
that
it's
behind
the
feature
flame.
F
So
john,
is
it
possible
for
us
to
get
kashal
to
go
ahead
and
merge
the
documentation
update
ahead
of
enabling
the
feature
flag
by
default
and
just
have
it
on
and
recognizing
that
we
might
have
missed
this
one
a
little
bit
and
and
just
go
ahead
and
do
it
and
then
we'll
in
the
future
have
a
better
system?
It
sounds
like
we're
working
toward
a
better
system.
I
don't
know
if
that
would
make
people
happier.
I
just
don't
want
to
get
under
a
lot
of
scrutiny
for
this.
F
A
Yeah
exactly
like,
so
that's
why
I'm
looking
to
just
take
an
action
on
this
as
soon
as
possible,
move
on
with
their
lives,
I
think
like
it
would
be
worse
to
switch
off
quality
management
at
this
stage
and
then
document
and
then
switch
it
back
on
like
we
just
have
to
learn
from
it
and
kind
of
figure
out
what
went
wrong
honestly
when
we
give
feedback
once
that
something's
wrong,
that's
fair
enough.
A
We
can
adjust
course,
but
this
is
two
or
three
times
now
that
documentation
around
feature
flags
has
come
up
as
a
problem.
So
it's
just
at
that
point
where
we
have
to
fix
something
but
yeah,
like
you
said,
I
don't
recommend
switching
off
quality
management,
we
just
kind
of
make
sure
we
learn
for
next
time.
A
A
Cool,
so
I
have
the
next
item
as
well.
It's
just
a
short
one,
I'm
sort
of
still
working
on
our
well,
I'm
definitely
still
working
rq
for
back
end,
so
I'm
taking
sort
of
last
minute
ideas
on
it.
All
I've
got
at
the
minute
is
that
we
have
a
nine
lcp
leaderboard,
for
I
guess
roots
of
interest
in
in
gitlab.
A
That
has
quite
a
few
product
planning
and
general
plan
routes
that
are
problematic.
One
approach
to
the
okr
is
that
we
just
have
a
goal
of
bringing
a
certain
number
of
these
back
into
the
into
the
green,
like
that
means
less
than
2.5
seconds
for
largest
content
full
paint
render.
A
I
don't
know,
I
can't
say
that
that's
still
quite
ambitious
like
because
we
have
a
few
of
these
roots
are
actually
in
the
red,
like
so
they're
taking
close
to
10
seconds
so,
and
it
could
also
be
something
we
could
collaborate
on
the
back
end
with
front
end
on
yan's,
also
working
on
tooling
improvements,
so
that
fits
in
nicely.
That
could
be
another
key
result
as
well
and
yeah.
A
I
mean
it's
not
an
area
of
focus
at
the
minute,
but
transient
bugs
are
an
area
of
focus,
and
you
could
consider
some
of
these
transient
bugs
there
are
parts
of
the
site
that
just
kind
of
feel
bad.
To
use.
An
example
is
the
filter
bar
if
you've
gone.
A
Looking
for
the
first
time,
you
enter
a
label
into
the
filter
bar,
and
you
have
to
wait
four
or
five
seconds
to
see
the
list
of
labels,
and
then
you
have
to
retype
whatever
filter
you
were
already
typing,
or
you
like
a
classic
one
for
me
is
I'm
looking
for
everything.
That's
back
end
labeled,
so
I
type
back
in
without
the
d
and
wait
for
the
response
to
fill,
and
then
I
type
the
d.
So
it
does
the
final
sort,
it's
stuff
like
that.
That
just
doesn't
feel
great.
A
So
if
we
could
maybe
pick
out
some
back
end
requests
that
people
use
on
a
daily
basis
or
even
look
at
like
user
journeys
through
gitlab
and
tune
those
up.
I
think
that
would
be
a
good
fast
follow
for
this
okr.
I
think
probably
for
this
one.
We
want
to
focus
just
on
those
routes
that
are
of
most
interest
in
the
leaderboard.
A
So
anyway,
if
you
have
any
ideas
want
to
make
any
contributions
to
the
okr
itself.
Please
let
me
know
if
you
have
ideas
as
a
pm,
how
things
like
this
can
be
scheduled,
while
also
keeping
up
with
our
normal
feature
deliverables.
Please,
let
me
know
about
that
as
well.
E
One
of
the
one
of
the
routes-
that's
really
bad.
That's
under
our
preview
is
the
boards
like
project
management
boards
and
it's
mostly
slow
because
of
issue
lists
they
take
along,
like
the
actual
issue
list,
ends
up
being
the
largest
content,
full
paint,
and
it
takes
some
of
them
to
take
four
to
five
seconds,
given
that
we're
currently
kind
of
in
the
middle
of
a
refactor
on
boards
do
like.
E
I
don't
know
if
anyone
on
this
call
has
like
any
insight
on
whether
or
not
we'll
be
that
will
be
like
likely
to
improve
or
change
drastically.
Based
on
that
refactor,
I'm
like
hesitant
to
like
focus
on
sort
of
like
improving
the
speed
of
that
route,
given
that
we
are
kind
of
in
the
middle
of
a
of
the
refactor
for
it.
But
I'm
curious
like
if
we're
just
gonna,
if
it's
actually
gonna
end
up
being
worse
and
then
we'll
have
to
go
back
and
visit
through.
E
D
The
I'll
let
the
engineer
speak,
but
I
was
playing
around
with
it
a
little
bit
and
yesterday
with
swim
lanes
and
stuff,
and
I
think
what
we
were
doing
before
the
swim
lanes
was
making
a
request
for
each
list
separate
one.
I
think
we're
doing
the
same
thing
with
with
graphql
now
in
swimlane.
D
So
I
don't
know
if
we
really
changed
how
we
approach
building
up
the
board,
but
this
is
also
sort
of
the
thing
where
I
wonder:
if
things
like,
adding
an
or
operator
would
make
it
a
little
bit
more
performant.
So,
instead
of
making
10
requests,
we
can
make
one
request
that
has
like
basically
an
or
operator
in
the
filter
say
like
the
issues
with
the
these
different
labels.
D
Basically,
instead
of
a
singular
request
for
each,
I
don't
know,
though,
it's
like
it's
a
super
hairy
problem
when
you
really
start
thinking
about
how
how
you
have
to
build
the
board
up
to
get
the
view
you
want.
So
I
don't
know
I
would
really
defer
to
yon
and
charlie
and
flory,
and
the
folks
have
been
working
on
it.
A
Yeah,
I
think
just
given
the
maturity
of
the
the
internal
api,
we're
unlikely
to
see
any
performance
benefit.
In
my
opinion,
from
moving
to
graphql.
A
What
would
be
interesting
from
my
point
of
view
would
be
like
things
that
are
going
to
have.
I
mean
serious
improvements
on
performance
like
caching,
you
know,
okay,
the
first
load
of
the
issue
board
like
if,
if
there
are
10
views
of
the
issue
board
for
every
one
edit
of
the
issue
board,
then
that's
a
candidate
for
some
serious
caching.
D
What
if
we
and
as
a
a
long
time
ago,
I
built
a
couple
of
front
ends
where
I
would
basically
store
everything
in
the
client
on
client-side
database
and
indexeddb?
I
think,
and
I
use
service
workers
to
update
things
asynchronously
in
the
background
via
web
sockets,
so
like
for
all
of
the
whatever
the
database
size
was
basically
that
I
basically
stored
a
rolling
inventory
of
all
the
things
and
when
any
of
those
things
change
the
I
got
the
change
pushed
over
websockets.
D
So
that
way
like
I
never
had
to
load
a
bunch
of
stuff
every
time
on
the
server
and
you
you
basically
can
validate
that.
Your
client
side
database
is
right
and
if
it's
not,
then
you
basically
purge
it,
and
then
you
resync
stuff
in
which
takes
a
little
bit
longer,
but
that
basically
made
it
so
that
the
first
load
took
a
little
while.
But
everything
after
that
was
fine.
D
E
There's
also
some
magic
we
could
do.
If
I
mean
this
is
a
little
bit
trickier
in
front
and
more
front
and
heavy,
but
if
we
had
what's
in
view
load,
I
think
right
now
we
just
load
like
the
last
issue
list
first,
which
is
usually
off
the
page
in
terms
of
the
browser
like
it's
usually,
you
know
scrolled
over
to
the
right,
and
then
we
don't.
E
We
don't
make
any
sort
of
prioritization
decision
on
what
we're
loading
based
on
where,
if
it's
visible
or
not,
so
if
we
loaded
the
ones
that
are
in
the
viewport
first
versus
the
ones
that
are
not
visible,
but
I
don't
know
if
you
know
one,
I
don't
know
if
that
actually
helps
the
largest
content
for
paint
at
all.
Not
that
not
that
it's
about
that.
There
should
be
work
to
improve
the
metrics
but
or
improve
the
performance.
E
But
you
know:
there's
maybe
something
there
too
in
terms
of
prioritizing
the
loading
of
those
issue
lists.
G
D
We
should
create
a
issue
to
track
it.
I
would
think,
or
just
have
an
async
discussion
about
it.
I
also
linked
in
the
semi
that
alex
pulley
and
manage
was
working
on.
D
It's
basically
like
I
don't
know
if
it
would
be
applicable,
applicable
here,
but
specifically
like
the
group
board,
where
you
have
to
sort
of
like
pull
things
through
a
bunch
of
different
subgroups
and
projects,
and
that
sort
of
thing
like
he
was
working
on
this
idea
of
doing
traversal,
basically
queries
by
traversing
instead
of
like
recursing
and
some
of
the
early
benchmarks
they're
running
in
the
mr
was
showing
like
some
like
six
times
faster
than
the
current
method
that
they
were
doing
it.
D
B
Yeah,
that
would
probably
be
helpful
for
the
epics
as
well.
We
have
the
irish
kind
of
stuff
there,
so
we
can
sort
of
store
the
paths
to
the
like
between
the
child
and
the
parent.
Epic,
maybe
in
terms
of
his
id,
is
separated
by
something
or
or
some
sort
so
yeah
that
that
probably
can
help
on
the
epic
street
sort
of
thing.
B
But
back
on
onto
the-
and
I
don't
know
from
top
of
my
head
in
the
usually
do
we
have
a
limit
on
the
issues
that
we
was
released.
Maybe
we
can
have
some
sort
of
a
imagination
to
that
and
and
you'd
love
more
issues
on
scroll
or
something.
I
don't
know
how
that
hurts
your
ass
or
something
like
that,
because
it
does
seem
like
from
the
time
it
doesn't
that
we
do
a
lot
everything
that
we
have
in
the
list
in
initially
and
that
hurts
as
well.
A
It
seems
like
also
it's
a
really
good
candidate
for
russian
doll,
cashing,
I'm
not
sure
if
russian
doll
cash
is
still
considered
acceptable
like,
but
back
in
the
day
it
was.
It
was
the
big
thing
and
like
because
you
have
like
a
parent
board
and
then
all
the
issues.
If
I
move
one
issue
from
a
list
to
another,
I
just
bust
the
cash
for
those
two
lists.
I
don't
bust
the
cash
for
the
whole
board.
A
The
problem
is
like
there
are
so
many
ways
that
you
could
bust
the
cash
for
an
issue.
You
know
you
can
do
it
from
the
issue
itself.
You
can
do
it
from
an
epic
by
simply
moving
it
in
night.
So
you,
you
know
you
can
kind
of
change
this.
In
so
many
places
it
becomes
really
difficult
to
manage
the
cash.
G
A
Yeah:
okay:
we
can
do
this,
async
cool,
that's
our
last
item.
Unless
anyone
has
anything
else.
D
Oh
sure,
I
think
the
young
was
suggesting,
like
a
tighter
connection
between
issue
boards
and
issues.
D
This
has
always
been
the
thing
that
I
found
the
hardest
about
how
we
have
like
iterated
on
boards
and
to
the
point
where
you
can
have
as
many
project
boards
as
many
issues
or
group
level
boards,
as
you
want,
and
there's
no
like
direct
correlation
to
to
like
an
issue
in
a
board
so
like
if
you
wanted
to
set.
I
was
thinking
about
this
for
things
like
automations
and
rules
where,
like
other
products,
will
have
automations
that
you
configure
on
the
board
itself
to
take
on
issues.
D
But
you
can't
do
that
in
our
product,
because
it
would
impact
all
the
issues
across
all
the
boards
right
and
so
like
there's
this
like
weird
thing
where
we
made
it
so
flexible.
That
we've
also
made
it
difficult
to
like
from
a
performance
standpoint,
but
also
to
like
have
a
tighter
relationship
between
issues
and
boards.
So
if
there
is
a
way,
if
anyone
can
think
of
a
way
to
like
basically
get
to
the
point
where
you
can
have
one
board
project
or
group,
that
would
be
awesome.
D
But
I
know
that
that's
never
going
to
happen
so
yeah,
I'm
open
to
changing
how
things
work
from
the
proc
standpoint,
for
if
it
like
leads
to
performance
gains,
and
I
think
that's
where
we
really
as
we
move
forward
building
new
things
and
iterating
on
things
it
like.
D
Always,
let's
have
that
conversation
about
trade-offs
and
what
what
could
we
not
do,
because
it
will
be
not
as
performant
versus
like
if
we
take
this
other
approach,
that
kind
of
gets
us
90
away
there
if
it's
100
more
performance
like
that's
a
a
win,
and
so
I'm
very
open
as
a
product
manager
to
doing
some
of
those
like
trade-off
discussions
with
the
engineers
instead
of
just
saying,
hey,
go,
build
this
and
then
not
taking
your
wisdom
into
consideration.
So
that's
what
I
wanted
to
verify.
A
Yeah,
that's
interesting,
I
wonder
like
if
the
concept
of
having
like
a
locked
board
would
also
work
like
so
once
you're
done
editing
the
filters
and
the
milestones
you
lock
the
board
and
it's
no
longer
editable,
and
in
that
sense,
as
issues
move
through,
you
can
have
historical
data
like
I'm
used
to
something
like
redmine,
which
is
extremely
simple.
Where
you
have
a
board,
I
also
have
a
burn
line
chart
associated
with
that
board
right
so
like.
A
I
know
that
this
board
has
scoped
a
certain
number
of
things
and
that
when
I
see
that
burn
down
char,
it's
historically
accurate
and
visually
like
I
can
associate
the
two
and
whereas
you
can't
do
that
with
our
boards
because,
like
I
could
just
go
in
there
today
and
change
the
milestone
you
know,
I
know
everything's
like
on
that
board
has
has
changed
the
context
completely
changed.
D
Yep
we
have
to
figure
out
how
to
play
analytics
and
boards
burn
down
and
burn
up,
charts
and
cumulative
flow
diagrams,
and
all
these
other
things.
So,
like
that's
one
of
the
requirements
from
some
of
the
analysts
that
were
doing
a
demo
for
in
january,
I
believe
we're
supposed
to
have
analytics
on
boards
by
then,
which
I
don't
know
how
that's
gonna
work
but
yeah.
I
agree
with
you.
D
It's
a
huge
challenge
to
solve
and
if
it's
locking
boards
or
if
it's
saving
another
thing
that
we
talked
about,
I
was
like
saved
filters
on
boards,
so
you
can
like
switch
between
different
views,
but
if
you
save
the
filter,
it's
sort
of
like
locking
it
to
a
certain
degree,
because
you
can
then
build
your
data
up
against
that
that
fill
that's
a
filter.
So
that
could
be
another
approach
too.
A
Why
don't
we
have
a
board,
that's
scoped,
to
a
milestone
like
when
you
create
a
milestone.
It
automatically
has
a
board
so
that
I
can
go
and
look
at
that
board
and
I
can
filter
it
any
way.
I
want
it's
the
same
as
with
iterations
right.
A
If
I
go
to
the
iterations
view
now
like,
I
can
see
a
list
of
all
the
issues
that
are
in
that
iteration,
but
it's
every
issue
I
get
lab
and
every
group
that's
using
that
iteration
at
the
minute,
whereas
if
I
just
had
a
board
scope
to
that
iteration,
I
could
go
in
and
see
and
then
I
can
filter
it
like
I'm
interested
in
product
planning
or
wider
plan
things.
Somebody
else
interested
in
verify.
D
That
would
work
for
the
use
case
where
you
are
in
a
single
you're
you're
like
working
inside
of
the
time
box,
but
it
it
doesn't
work
when
you
need
to
plan
across
many
time
boxes.
So
if
I
have
four
iterations
coming
up-
and
I
have
an
epic
that
has
20
issues
in
it,
I
want
to
sequence
it
across
four
upcoming
iterations,
then
that's.
We
would
have
to
have
a
different
way
to
sell
for
that
right,
which
would
be
a
little
bit
more
flexible,
but
I
have
thought
about
the
idea
of
like
more
formatted
boards.
D
If
that
makes
sense
where
you
basically
pick
the
use
case,
you
want
to
use
a
board
for
and
that's
like
it
right
and
then
you
can
like
switch
switch
between
your
different
use
case
boards,
instead
of
like
making
it
100
configurable.
D
I
think
that's
where
like
we
could
always
support
the
freeform
boards,
but
then,
as
we
identify
these
use
cases
where
it
does
make
sense
and
it
does
improve
performance
to
like
have
these
sort
of
special
case
boards
that
only
do
certain
things
and
then
switching
back
between
the
different
things
easily
is
it's.
It's
like
I've,
been
talking
to
alexis
and
holly
about
that
too.
It's
just
we've
been
thinking
about
boards.
So
that's
not
a
bad
idea.
B
Like
what
what
you're
mentioning
is
like
improving
the
user
experience
on
using
board,
it
seems,
but
I
don't
see
how
that
solves,
for
the
performance,
because
if
a
board
needs
to
display
a
million
issues,
it'll
still
be
performing
poorly
right.
You
cannot
there.
There
is
no
other
way
around
it
because,
like
you
can
configure
a
board,
make
it
locked
on
the
filters
or
whatever.
But
if
you
keep
adding
issues
that
need
to
pop
up
on
this
board,
it
will
just
be
slow.
A
Yeah,
it
might
open
some
options
up,
though,
like
if,
if
we
did
go
with
some
kind
of
caching
option
down
the
line,
I
can
simply
bust
the
entire
cache
by
changing
one
of
the
filters
on
the
board
and
we're
back
to
square
one.
But
if
the
filter
is
locked
to
say
a
milestone
that
at
least
takes
some
of
the
query
away.
B
If
you
change
the
milestone
on
a
different
issue,
you're
still
going
to
pull
those
issues
as
well,
so
you
cannot
cache
the
issues
themselves,
you're,
just
caching,
the
they
filter,
which
is
not
the
biggest
problem
here.
As
far
as
I
understand
so,
yeah
they're,
like
the
only
way
I
can
think
right
now,
is
just
logged
in
smallish
chunks,
but
yeah.
I
don't
like
the
other
way.
The
other
thing
is
they
think
that
someone
mentioned
about
making
the
relationship
between
the
board
and
the
issues
somewhat
hard
linked.
B
So
what
that
would
mean
is
that
every
single
well,
every
issue
that
needs
to
be
displayed
on
the
board
will
be
we'll,
have
a
relationship
kind
of
in
the
table
or
somewhere
and
and
that
can
potentially
make
it
easier
to
just
load
those
issues
into
the
board.
Right,
you
don't
have
to
query
a
huge
database
of
labels
and
filters.
You
just
know
that
these
issues
need
to
be
on
these
boards.
And
now,
how
do
you
get
to
those
links
is
a
different
problem.
B
A
G
G
G
G
A
Cool
looks
like
we're
done
we're
nearly
at
time,
so
let's
call
it
there
thanks.
Everyone
see
you
next
week.