►
From YouTube: Plan | Weekly Sync 2022-08-31
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
Cool
all
right,
so
here
we
are
31st
of
august,
depending
on
where
you
are
in
the
world.
It's
autumn
or
spring
has
sprung.
I
guess
depends
so
yeah
blair.
You
have
the
first
item.
B
Yeah,
I
you
guys
have
seen
the
announcements
on
slack
and
whatnot.
I
I
figured
I'd.
Do
I'd,
make
it
official
everybody,
please
welcome
dan
mitzi
harris.
He
will
be
starting
officially
tomorrow
as
the
new
product
designer
on
certify,
and
I
believe,
he's
here.
B
Take
come
off.
You
put
the
video
on,
say
hello
to
the
world
if,
if
you're
comfortable
doing
that,
if
not
just
chat.
C
I'm
in
barry
island
in
south
wales,
uk.
C
D
C
Forward
to
getting
started
and
work
out
what's
going
on
tomorrow,.
B
Yeah,
I'm
working
on
that
dan
by
the
way
dan
is
not
a
new
face.
He
comes
to
us
from
manage
both
import
and
optimize
where
he
was
the
product
designer
there.
So
he's
not
a
new
elabor.
He
will
or
not
supposed
to
use
that
tournament
he's
not
a
new
face.
He's
he's
been
here
for
a
little
bit
and
yeah.
I'm
super
excited.
A
Awesome,
what
a
great
start
all
right,
we're
straight
into
demos,
then
heinrich!
Do
you
want
to
kick
us
off.
C
F
Yeah,
okay,
great
so
so
in
the
last
milestone,
we
introduced
the
move
to
the
start
and
move
move
to
the
end
for
the
damn
for
the
boards
cards.
But
then
the
move
to
the
end
was
limited
only
to
the
fact
when
all
the
issues
are
loaded
in
the
list.
But
then
in
this
milestone
we
are
trying
to
have
that
action
for
all
the
cards,
but
that
heinrich
has
added
a
backend
graphql
argument
to
add
the
list
position
so
for
the
starting.
F
So
that's
what
we're
trying
to
do
so,
there's
a
catch
here
that
when
all
the
items
are
not
loaded,
so
it's
like
kind
of
a
ux
thing
so
having
a
demo,
for
this
is
a
great
idea,
thanks,
henrik,
so
when
so
in
the
list,
when
all
the
items
are
loaded
and
we
try
to
move
to
the
move
to
the
end,
for
example,
here
then
what
we're
doing
is
so
move
to
the
start
is
just
basic.
F
You
see
the
when
you're
moving
to
the
start,
you
should
see
it
visible
on
the
list
in
the
starting,
but
moving
to
the
end
is
a
little
tricky
in
the
part
that,
when
all
the
items
are
loaded
like
if
in
this
case,
when
at
first
they're,
just
10
items
are
loaded
in
the
list
when
I'm
moving
it
to
the
end,
it's
just
visible
that
I
just
move
this
number
three
at
the
end,
so
sorry
number
16
to
the
end,
so
it's
just
visible,
for
example,
number
three.
F
When
you
know
even
before
the
next
page
is
loaded
or
just
remove
it
from
the
current
visible
list,
and
when
you
append
it,
when
you
append
the
next
page
to
the
list,
it
automatically
comes
from
the
added
list,
because
the
move
to
end
item
action
has
already
been
done.
For
example,
just
to
see
how
it
works
here
is,
as
you
can
see,
just
10
are
loaded.
F
So
when
I
just
have
like
21
look
at
the
end,
it's
not
there,
but
then,
when
I
load
more
it
automatic
it's
not
like
it's
not
dependent
on
the
ui.
When
I
have
the
less
next
list,
it
is
there.
So
there
like,
there
were
two
opinions
on
the
same
nick
had
something
and
heinrich
had
something,
and
I
just
think
that
this
is
the
best.
It
just
looks
better
when
we
have
both
the
when
we
see
both
the
use
cases
when
all
the
items
are
loaded
when
all
the
items
are
not
loaded.
F
There
are
different
like
they
can
be
different
points
of
view,
and
how
should
we
just
move?
You
know
show
the
actions
when
there's
just
one
card
in
the
list,
or
we
should
just
remove
it
from
that.
Other
follow-up
like
feedback.
If
you
have
for
these
actions,
so
yeah,
that's
what
we've
implemented
and
it's
just
work
in
progress
the
tests.
Yes,
cases
are
not
done,
but
it's
good
to
take
feedback,
because
boards
are
like
widely
used
across
the
team,
so
any
feedback.
What
do
you
think.
G
Am
I
allowed
to
like
the
issue
with
moving
this
down
to
the
bottom
of
the
list?
Is
that
you
don't
see
it
right?
What
if
we
do
like
a
notification?
Toast
message
like
this
got
moved
down,
so
someone
has
a
confirmation
that
this
worked
out.
F
Yeah,
I
guess
nick
mentioned
in
the
comments,
so
yeah
that's
one
of
the
points
we
can
do
that
yes,
but
do
we
also
want
like
to
undo
that
action?
Because
then,
if
we
have
another
action
to
be
called
and
just
or
just
a
notification
that
it's
been
moved
to
the
end,
because
we
don't
like
show
anything
when
we
move
the
list
when
we
drag
it
like
yeah,
so
it's
just
different
there.
H
Yeah,
so
toast
messages
do
support,
undo
action,
but
you're
right
like
for
doing,
drag
and
drop
moments,
so
we
do
not
show
any
confirmation.
In
fact,
even
if
even
when
the
request
fails,
the
the
card
item
basically
restores
back
to
its
original
position,
and
I
I
think
we
do
show
error
message.
There's.
H
Yeah,
yes,
I
think
that's
that's
what
we
have
done.
We
do
not
show
any
undo
action
for
drag
and
drop
movements.
I
Yeah,
I
wouldn't
add
the
toaster
for
drag
and
drop,
because
when
you
drag
and
drop
like
you
see
the
outcome
right
like
you,
don't
it's
really
only
the
scenario
where
you're
like
moving
something
to
you
know
the
end
of
100
item
list.
Then
you
can't
visibly
see
that
it
succeeded
that
we're
that
we're
talking.
F
Yeah,
so
do
you
think
it
would
be
better
to
shoo
to
have
an
undo
action
here
or
just
show
the
toaster.
I
I
don't
think
undo
is
like
strictly
required
because
you
can
still
like
do
it,
but
if
we,
if
we're
able
to
do
it,
I
think
it's,
I
would
say
it's
nice
to
have,
but
you
know
there.
I
I
think
I
mentioned
in
the
issue
comments
on
this
like
we
would
basically
have
to
be
like
really
careful
with
the
logic
like
that
toast
would
have
to
go
away
anytime.
Any
other
list
is
changed
so
that
your
like
undo
stack
is
kind
of
pristine,
otherwise
you're
like
trying
to
move
it
back
to
a
position.
I
That's
no
longer
the
same
position,
so
I
I
can
see
how
that
could
get
tricky.
I
don't
think
it's
like
strictly
required.
I
think,
because
users
can
still
like
it's
not
destructive
right.
You
just
moved
it.
You
can
always
move
it
back,
but
like
it's
nice
to
have,
if
we
can
do
it
only
for
the
only
for
the
action
menu
moves,
not
for
dragon
drop.
F
F
So
I
don't
know,
maybe
I'm
not
sure
about
adding
that
here
so
yeah
yeah,
maybe
when
you
know
when
when
we
all
are
in
sync
that
okay,
this
is
how
it
should
work,
and
we
just
have
more
time
maybe-
and
I
can
try
implementing
that
and
share
it
in
the
next
session.
But
only
when
you
know
at
least
the
the
major
use
cases
that
we
have.
The
reason
for
which
it
was
implemented
is
clear,
and
it's
not
like
confusing
for,
like
anyone,
yeah.
D
Honestly,
I
would
be
against
undo
because
I
believe
we
need
undo
button
for
destructive
operations
if
something
is
clearly
distracted,
like
least
remote
or
something
else,
but
for
moving
issues.
We
also
need
to
preserve
the
previous
position
somewhere
and
it
will
be
complicated
with
ux,
which
is
current
implementation.
It
will
be
no
easier
with
apollo,
which
is
next
implementation,
so
probably
not,
let's
not
undo
the
move.
F
Sure,
and
what
about
the
fact
that
do
we
need
to
have
these
actions
here
when
there's
just
one
card
in
the
list
or
just
like,
remove
it
or
what?
What
do
you
think.
C
F
I
If
there's
just
one
action,
what
would
you
have
instead-
or
maybe
I
misunderstood
the
question-
if
you
have
one
action
in
this
list
like
how
do
you
get
to
the
list.
I
Yeah
this,
the
complication
that
we've
talked
about
with
this,
is
really
in
like
do
you
actually
have
one
card
in
this
list
or
do
you
have
a
filter
applied
that
makes
it
seem
like
there's
one
card
in
this
list,
but
actually
there's
like
10
and
you're
only
seeing
one,
I
think
if
it's
actually
one
like
there's
literally
nothing
else,
then
it's
fine
to
remove
if
it's
like
filtered,
then
I
would
keep
it
in
because
you
could
like
there
is
technically
still
like
movement
possible
there.
That's
like
that's!
I
F
Yeah,
that's
a
good
point
actually,
so
I
didn't
think
of
that
so
yeah
when
we
put
the
filter
and
we
still
might
want
to
move
that
to
the
test.
Okay,
let
me
check,
if
that's
just
a
small
thing,
and
then
I
can
check
that
filter
is
applied
or
not
and
then
add
the
action
remove.
F
The
action
accordingly
would
just
wanted
to
be
clear
in
the
fact
that
it
should
be
like
not
be
confusing
for
the
user
that
I'm
seeing
it
once
and
I'm
not
seeing
again,
that's
the
only
reason
I'm
asking
yeah:
that's
it.
I
I
F
Hopefully
yeah
okay,
so
the
other
thing
is:
do
we
want
to
have
these
actions
in
the
closed
list
so
heinrich
mentioned
that,
like
maybe
yes,
there's
no
need
of
it,
but
maybe
we
can
just
have
a
consensus
if
you
want
these
actions
in
the
closed
list
or
not.
E
Yeah
the
thing
with
the
closed
list
is
that
the
sorting
is
actually
supposed
to
be
disabled,
because
if
you
like
try
dragging
cars
there,
it
gets
persisted
in
the
ui.
But
if
you
refresh
the
page,
it
goes
back
to
the
closed
ordering
because
that's
how
we
order
it
from
the
back
end.
So
the
idea
here
is
to
the
ideal
state
is
to
disable
sorting
in
the
closed
list.
Although
there's
a
complication,
because
even
if
we
disable
sorting
or
like
dragging
on
this
list,
we
still
want
it
to
be
a
drag
target
right.
E
We,
you
want
a
card
to
be
dragged
to
the
closed
list
to
close
an
issue
and
it
should
just
go
up
to
the
top.
So,
instead
of
having
a
card,
you
know
target
like
that,
where
you
choose
which
position
you
wanted.
The
closed
list
should
be
just
one
drop
area
or
something
where
you
can
drop
something
to
the
closest.
So
it
adds
some
complication.
E
A
We
probably
want
that
list
to
be
a
drag
target,
but
because
did
you
say
it's
ordered
by
closed
at
so
it's
ordered
in
reverse
by
closed
dots.
The
most
recently
closed
will
be
at
the
top,
so
it
should
be
a
drag
target,
but
the
card
should
pop
to
the
top
of
the
list
right,
because
when
you
refresh
it,
it's
going
to
be
at
the
top
of
the
list
anyway,
right.
E
I
E
A
C
E
C
F
E
There's
one
more
comment
that
gabe
mentioned
about
continuing
to
iterate.
Would
you
like
to
verbalize
that.
K
Yeah,
I
was
just
curious
if
we
were
going
to
continue
to
iterate
and
add
the
like
move
to
a
specific
list
or
position
within
the
list.
I
was
just.
I
know
we
had
designed
it,
but
I
know
it
was
technically
more
difficult.
So
I
just
didn't
know
if
we
were
going
to
abandon
that
or
tackle
it
in
another
iteration.
E
Yeah,
actually,
the
back
end.
I
did
today
supports
like
arbitrary
position,
so
you
could
pass
in
zero
for
start
negative
one
for
end
and,
like
any
specific
number
for
specific
position
in
the
list,
the
only
complication
here
is
for
with
filters.
So
if
you
filter,
you
add
filters
to
this
board
and
if
you
move
to
position
three,
that's
different
from
the
unfiltered
board
position.
Three
right,
so
it
doesn't
take
that
into
account
yet,
but
you
know
it's
doable.
If
you
wanted
to.
K
I
was
thinking
we
just
ignore
filters,
but
that's
just
me
because
I
think
it's
weird
when
you
do
when
you
do
include
filters,
then
it's
like
a
different
behavior
when
you
have
filters
on
that
when
you
don't
because
like
if
you
ignore
filters
and
filters
are
active,
they
will
still
move
to
that
position.
If
that
makes
sense,
I
would
think
relative
to
everything
else.
That's
in
the
list,
but
maybe
it
wouldn't
work.
I
don't
know.
E
Yes,
for
example,
I
filter
the
list
and
I
see
like
five
issues
right
and
then
and
move
the
first
one
to
position
three.
So
I
would
if
I
were
looking
at
this
list,
I
would
assume
that
it's,
the
it's
gonna
be
between
those
five
issues
that
were
filtered
right,
but
then,
when
it
goes
unfiltered
you're
saying
it's
position,
five
of
the
unfiltered
list
right,
so
it
could
be
like
position
two
in
this
filtered
list
or
something
like
that.
C
I
You're
going
to
do
that
with
grouping
it'll
be
a
little
bit
different
but,
like
I
know
that
was
one
of
the
things
that
we
talked
about
when
this
came
up
before
it
was
like.
Do
you
you'd
never
break
the
grouping
right
based
on
the
position?
I
would,
I
wouldn't
think
so.
It's
more
like
you're
moving
it
within
the
relative
group,
but
it
is
some
of
the
same
sort
of
weirdness
as
filtering.
I
would
guess.
B
Do
we
have
the
chance
to
put
it
in
front
of
a
small
group
of
users,
get
get
some
feel
on
that
or
just
test
it
in
production?
And
if
we
hear
feedback.
I
I
I
know
it's
come
up
before
we've
talked
about
it
with
at
least
one
customer
and
it's
I've
seen
it
requested
from
other
customers
as
well,
but
I
wonder
how
many
problems
like
move
to
start
move
to
end
resolve,
because
the
bigger
pain
points
tend
to
be
I'm
at
the
end
of
the
list,
because
that's
where
my
new
items
are-
and
I
want
to
put
it
at
the
top
of
the
list
and
dragging
an
item
through
you
know,
50
parts
of
the
list
is
pretty
tedious,
but
yeah
I
mean
it
would
be
pretty
easy
to
user
test
some
of
this
and
just
understand
the
expectations.
I
K
Roy's
worth
I
use
it
every
day
when
I
use
trello
like
move
to
specific
positions,
because
I
would
sort
of
order
everything
and
then,
if
I
wanted
to
maybe
say
I
want
this
thing
to
be
third
or
fourth
position
right.
I
would
just
it's
just
a
shortcut
to
do
that,
but
it's
not
the
end
of
the
world.
If
we
don't
do
it
too,.
A
I
actually
use
this
currently
for
prioritizing
tech,
death
and
bugs
for
milestones,
and
so
this
allows
me
to
do
like
a
binary
sort
first,
so
I
can
move
all
the
stuff
I'm
interested
in
just
move
it
to
the
top
everything
I'm
not
interested
in
moving
to
the
bottom.
That
gives
me
a
rough
approximation
and
then
I'm
just
trying
to
drag
between
like
the
top
10
items.
J
John,
you
brought
up
my
point
because
you
were
saying
top
and
bottom.
I
was
just
wondering
we
say
start
and
end
and
I'm
wondering
when
should
we
say
start
end
versus
top
bottom
and
it
looks
like
nick
there's
some
points
below
if
y'all
want
to
vocalize.
I
J
I
Mentioned
this
earlier,
but
like
there's,
this
distinction
of
like
visible
top
like
what
invisible
bottom
like,
because
we
only
load
10
items
at
a
time.
So
the
actual
bottom
of
the
list
may
not
be
the
end
of
the
list
and
if
you
have
filters
applied,
it
may
not
be
the
actual
top
or
bottom
I
mean
I
don't
think
that's
something
most
users
are
going
to
think
about,
but
that
was
kind
of
the
logic
of
of
using
start
versus
top
just
to
try
to
like
nudge
a
little
bit
of
that
behavior.
I
Otherwise,
I
would
say
top
and
bottom,
like
are
probably
more
common.
Actually
I
don't
know
I'm
going
to
look
real,
quick
and
see
what's
most
common,
but
that
would
be
my
guess.
As
top
and
bottom
probably.
J
C
C
D
D
Probably
you
all
remember
that
we
had
a
bunch
and
we
still
have
a
bunch
of
bugs
where
we
desynchronized
sidebar
from
the
actual
issue.
So
there
was
a
quite
an
interesting
bug
where
you
could
apply
and
assign
it
to
this.
One
switch
to
the
second
one
and
assign
is
applied
to
the
second
part,
and
this
bug
still
exists
because
our
sidebar
here
and
our
board
here
use
different
states,
ux
and
apollo
respectively.
D
This
one
is
used
as
a
polo
client.
The
whole
page
has
the
same
state,
including
sidebar.
It
allows
us
to
remove
around
400
lines
of
code
of
interaction
between
sidebar
and
the
board,
which
was
ridiculous.
Honestly
and
currently,
it
works
pretty
good
on
the
main
functionality,
so
reordering
the
lists,
opening
and
fetching
the
data
moving
the
cars,
and
you
can
see
that
label
is
removed
here
because,
apparently
on
issue
boards,
we
don't
show
labels
on
the
label
list
on
epic
boards.
We
do
show
label
on
the
label
list.
D
D
That
is
what
is
working.
Pagination
is
working
opening
our
tricky
sidebars
is
working
too,
because
that's
a
huge
chunk
of
logic.
I
was
surprised
on
the
front
end.
The
biggest
part
of
the
problems
right
now
is
for
epic
boards,
because-
and
I
would
like
to
bring
this
to
the
back
end,
because
maybe
we
can
simplify
this
a
bit,
because
when
I
move
the
card
here,
you
can
see
that
I
pass
variables
and
there
are
list
ids
from
list
id
to
list
id,
and
these
are
just
integers.
D
I'm
not
sure.
Why
do
we
have
this
difference
in
format,
so
I'm
trying
to
pass
ideas
and
my
mutation
fails
as
it
should,
because
it's
wrong
type,
maybe
we
could
eventually
just
bring
it
to
the
same
format,
I'm
fine
with
like
moving
issues
to
gid,
so
moving
epics
to
ids
or
whatever,
because
applying
a
bunch
of
front-end
logic.
On
top
of
that,
I'm
not
sure
that
is
a
good
idea.
We
just
split
the
logic
for
the
same
component,
which
is
board
list,
but
this
is
so
worth.
Migration
is
halfway.
D
I
would
say
50
to
60
percent
in
depends
on
the
scope,
because
scope
of
the
boards
is
undefined.
It's
very
large
and
I
don't
even
know
all
the
features
of
the
boards.
I
doubt
like
anyone
knows
all
the
features
on
the
boards
and
how
they
should
work.
We
don't
have
really
good
description
in
terms
of
spec.
We
have
nice
user
documentation,
so
what
users
should
expect,
but
we
don't
have
a
specification
for
words
so
like
when
the
list
is
highlighted.
D
Nobody
knows
how
do
we
move?
How
does
it
work
like
very
unintuitive
one
they
mentioned
to
nick
is
when
you
move
the
card,
it's
you
have
on
both
lists
to
open
it's
removed
from
all
the
lists.
It's
in
this
is
something
to
be
implemented
with
real
time
and
yeah.
The
purpose
of
all
these
popular
factoring
is
we
want
to
print
real
time
to
boards.
We
want
to
bring
subscriptions
here.
It
was
discussed
with
heinrich
too,
and
in
order
to
do
this,
we
need
to
change
the
implementation
of
the
boards.
I
The
one
question
around
whether
this
gives
us
any
different
opportunities
for
loading,
because
the
like
10
item
at
a
time,
scroll,
load,
scroll
load,
scroll
load,
is
like
not
like
my
favorite
interaction.
I
D
We
can
we
can
do
this
by
user
interaction,
but
without
scrolling
down
all
the
way
to
the
bottom.
So,
for
example,
we
can
start
perfection
when
user
scrolls,
like
maybe
two
issues
down,
and
we
start
for
patching,
already
just
place
enough
intersection
observer.
So
this
is
doable.
We
can
prefetch
it,
so
we
load
first
down
and
then
we
load
like
the
second
10
and
the
background.
But
it's
basically
endless
possibilities.
We
can
do
whatever
you
expect.
First
here.
K
I
can
keep
helping
you
define
like
some
of
the
specs
and
stuff
and
nick's
already
part
of
that,
so
whatever
you
need
to
do,
if
we
do
want
to
document
it
somewhere
outside
of
that
comment
or
that
thread
that
we've
been
having
on
the
issue,
we
can
do
that
just
so
that
other
team
members
can
look
at
the
single
source
of
truth.
The
other
thing
that
I
would
love
to
see
if
we
can
move
away
from
multiple
different
types
of
lists
like
mixing.
K
You
know
labels
with
the
signees
like
it's
just
it's
just
sort
of
weird,
and
I
think
the
reason
why
we
do
it
is
like
we
sort
of
it's
a
hack
for
people
wanting
swim
lanes
like
proper
swim
lanes
where
you
can
have
your
x-axis
is
all
one
type
and
your
y-axis
is
all
like
a
different
type
or
a
different
attribute.
K
I
think
if
we
had
that
it
would
sort
of
negate
the
need
for
having
to
have
mixed
lists,
but
if
we
did
want
to
work
towards
that,
we
we'd
have
to
like
think
about
how
to
gracefully
do
it,
because
it
would
break
everyone's
current
list,
like
maybe
you
just
prevent
it
on
feature
lists
and
then
slowly
phase
it
out
over
time.
I
don't
know
how
to
approach
that,
but
that's
just
one
thought.
A
Yeah
cheers
sorry,
you
did
bring
up
something
there
about
different
ids
in
the
backend
response.
Is
there
something
we
can
do
about
that
like?
Is
there
an
issue
to
even
long
term
to
investigate
this,
and
when
you
say
it's
separate
ids,
do
you
mean
some
of
the
ids
on
issue
boards
are
gids
and
some
on
epic
boards
or
not,
or
vice
versa,.
D
D
If
you
try
to
pass
an
integer,
it
just
fails
and
it
would
be
nice
to
just
have
the
same
format
for
all
the
issuable
types
on
the
boards,
like
I'm
fine
with
either
if
it's
gid
and
it's
easier
for
the
backhand
fine,
if
it's
id
still
fine,
just
the
same
one,
because
I
don't
even
understand
why
do
we
have
different
formats?
There.
E
I
think
this
is
more
like
a
legacy
thing
before
we
kind
of
made
it
mandatory
to
use
the
ids
everywhere
that
was
kind
of,
like
I
think,
more
recent
versus
when
we
started
using
graphql
so
yeah.
I
think
it's
a
legacy
thing.
The
tricky
thing
here
is
graphql
is
public
api
and
we
can't
make
breaking
changes
so
yeah
we'd
have
to
have
like
a
new
mutation
endpoint
and
all
that
stuff
too,
and
deprecate
the
old
one
in
six
months.
Remove
it
and
all
of
that.
E
I
mean
we
probably
you
know
eventually
want
to
clean
up
the
back
end,
to
accept
the
same
types
of
ids
to
you
know,
lessen
confusion
or
stuff
and
regarding
the
tech
we
also
have
like
boards
and
points
and
rails
controllers
actions
that
we
have
to
remove,
because
when
we
moved
to
graphql
boards,
these
were
left
behind
and
these
don't.
These
aren't
used
anymore.
So
there's
a
lot
of
these
kinds
of
stuff.
A
Presumably,
that's
true
of
a
few
different
things
in
graphql,
then
that
before
we
brought
in
the
rule
about
using
gids
so
yeah
I
mean
if
the
only
solution
is
like
the
six-month
deprecation.
That's
pretty
painful.
But
if
there
was
some
other
thing
we
could
come
up
with
like
support
both
for
a
while
and
deprecate
one
and
then
remove
that
one
like
I
don't
know
if
that's
possible,
but
that
would
almost
be
preferable.
I
think
I
don't
know
if
it's
possible,
because
I
don't
don't.
K
I
was
also
going
to
just
say
that,
keeping
in
mind
that
epics
will
hopefully
be
converted
to
work
items
in
the
not
so
distant
future,
so
whatever
we
choose
to
do,
I
mean
there
will
have
to
be
eventual
consistency,
anyways,
because
they're
going
to
use
the
same
object
model.
So,
however,
that
helps
make
engineering
decisions
just
wanted
to
call
that
out.
E
A
Can
somebody
write
that
in
the
agenda
and
I'll
push
on
with
the
next
item
just
to
keep
things
moving
yeah?
So
I
just
want
to
give
a
quick
update
on
the
main,
the
primary
deliverable
for
product
planning.
We
don't
have
anything
to
demo
yet,
but
for
the
benefit
of
planned
stage
members
who
aren't
in
this
team,
you
might
be
interested
in
what
we're
working
on.
So
the
idea
is
to
allow
customers
to
add
issues
to
epics
in
different
groups.
You
currently
can't
do
this.
A
You
can
only
add
issues
from
the
current
group
hierarchy
that
the
epic
is
in
so
yeah.
We
have
a
few
things
to
do.
You
can
read
these
here.
Adding
has
epic
to
the
graphql
issue
response
that's
in
review.
It
also
blocks
item
two,
which
is
the
front-end
change,
to
show
that
in
the
sidebar
widget
that
the
issue
has
an
epic,
but
you
can't
see
the
epic,
which
is
something
we
haven't
had
up
until
now.
A
A
Then
there
are
a
couple
of
security
fixes
and
the
interesting
thing
here
is
that,
like
you,
don't
normally
see
community
contributors
pick
up
deliverable
items,
but
in
this
case
they
have
so
we
need
to
keep
an
eye
on
this.
I
guess
and
make
sure
that
we're
providing
enough
support
because
we
intend
to
actually
ship
this
in
15-4
and
it's
a
priority
for
us
so
yeah
just
to
draw
attention
to
that.
If
there's
no
questions
nicholas,
you
can
tear
on
with
point
d.
A
G
Yeah,
I
I
don't
have
a
good
discussion
point.
I
just
wanted
to
highlight
eugenia's
work
on
the
poc
to
have
epics
on
different
priorities,
and
I
saw
a
few
discussions
in
the
spike
issues
that
she
brought
up
about
not
being
able
to
use
like
current
optimizations
for
permissions,
because
you
now
have
an
epic
that
could
be
have
issues
like
for
multiple
groups
outside
of
the
group
that
is
in
right
now.
So
I
don't
have
full
knowledge
on
this.
So
I'm
trying
to
get
up
the
speed
of
this,
but
I'm
was
thinking
like.
G
Is
it
possible
for
us
that
we
have
like
constraints
or
assumptions
about
a
permission
model
that
we
can
use
to
optimize
and
not
check
every
group
separately?
It's
more
like
a
question
into
the
room.
I'm
not
eugene
knows
more
about
this,
and
so
I
don't
want
to
steal
the
show
there,
but
I
want
to
bring
it
up
as
a
fruitful
fault.
K
I
was
just
getting
not
an
engineer,
but
I
was
just
thinking
that
when
I
thought
about
this
before,
I
don't
think
we
sort
of
made
the
decision
that
some
of
the
roll-up
data
like
counts,
and
things
like
that
is
if
we
don't
have
to
hide
those
for
confidential
issues
because
we're
not
exposing
anything
confidential.
K
And
I
wonder
if
you
could
do
one
one.
Basically,
one
query
when
you
load
the
epic
tree
that
just
loads
all
the
roll
of
data,
but
then
you
don't
make
you
you
don't
do
like
the
full
permissions
check
for
that.
But
then,
once
you
basically
unfurl
one
of
the
epics
within
the
tree,
you
do
the
permission,
checks
for
the
next
layer
down
so
you're
just
running
on
a
smaller
subset
of
the
overall
permissions.
K
K
So
it's
definitely
worth
thinking
about
the
performance
stuff
now,
and
the
other
thing
I
was
to
say,
is
maybe
check
with
alex
pulley
in
workspace,
because
he
did
a
lot
of
work
around
traversal
queries
for
namespaces,
which
is
a
very
much
more
perform
performant
way
to
check
access
than
what
we
were
doing
before
with
so.
Maybe
somebody
we
could
bounce
some
ideas
off.
A
Yeah
felipe
actually
used
those
in
some
of
his
optimizations
and
it
was
quite
incredible.
The
difference
I
mean
with
a
certain
large
customer.
We
were
seeing
60
seconds
just
to
load
the
epics
list
for
that
customer.
At
the
top
level
we
were
seeing
60
second
request
times
and
then
timeout
and
those
same
queries
might
take
like
between
one
and
two
seconds,
like
still
quite
long
for
a
request
duration.
A
But
given
how
complex
and
like
this
we're
talking
like
99.9
percentile,
like
a
pretty
incredible
increase,
so
those
are
useful,
I
think
like
we
need
to
look
at
each
use
case.
Like
you
pointed
out,
I
I
don't
anticipate
that
listing.
Epics
is
gonna,
be
slow,
but
what
is
slow
like?
Is
it
the
like
if
you're
looking
at
an
issue
like
we
just
have
to
check
the
that
epic
that
it's
attached
to?
I
guess
it's
the
epic
tree,
then
that's
a
problem
nicholas.
A
Is
it
like
if
you
have
a
lot
of
epics
and
are
a
lot
of
issues
in
the
epic
tree
that
we
have
an
m
plus
one
there
or
something.
C
L
C
L
Victory
would
display
the
epics,
the
child,
epics
and
every
epic
could
belong
to
a
different
group.
So
if
we
belong
we're
checking
only
the
epic
group
and
the
ancestors
and
descendants
now
we
will
check
those
for
the
parent
epic.
If
there
is
an
epic
in
there,
but
also
we
can
have
every
epic
could
be
from
a
different
group.
So
for
every
epic
we
have
to
check
the
parent
group
and
the
ancestors
and
descendants,
so
the
optimization
from
felipe
helps,
but
the
query
is
still
quite
slow.
I
think
that
there
might
be
options.
L
J
I
think
we
can
consider
a
limit.
I
would
look
to
you
all
to
tell
me
what
you
think
is
a
good
limit
and
then
I
can
ask.
G
L
Yes,
the
the
limit
is
for
how
deep
the
the
soap
epic
can
go.
I
don't
remember
the
limit,
but
if
it
was
10
you
can
have
the
limit
is
in
the
ancestors,
so
you
would
have
one
child
that
has
another
child
who
has
another
child
has
another
child,
but
all
of
these
cases
at
the
moment
are
in
the
same
group
or
ancestors
or
descendants.
So
that's
limiting
the
the
number
of
groups.
L
I
don't
know
if
that
would
be
welcome
or,
for
example,
if
you're,
adding
a
new
epic
and
you
already
have
10
different
groups
in
your
child
epics,
it
might
say
you
reach
the
level
of
well
different
groups,
you
can
add
as
a
so
epic
or
I
I
think
that
could
be
a
limiting
factor,
but
if
the
client
doesn't
have
a
use
for
having
many
many
groups
in
trial
olympics,
it
would
help
a
lot
with
performance.
L
I
don't
think
so,
but
it
could
be.
We.
K
A
L
L
They
are
paid,
but
in
in
this
case,
even
if
we
display
them
page
we're
going
to
collect
all
the
groups
and
check
their
permissions
because
we're
not
checking
permissions
for
each
child,
epic,
we
check
in
their
groups
and
because
you
can
inherit
permissions
from
another
group,
so
just
checking
their
pick.
Checking
the
group
doesn't
help
so
we're
going
to
collect
all
the
groups,
it
could
be
200
and
then
we're
going
to
look
into
all
their
ancestors
and
descendants
and
check
the
permissions
in
each
of
them.
And
so
that's
basically
the
problem
at
the
moment.
A
L
Yeah,
I
think
that's
been
done
already
in
the
because
this
is
doing
the
same
as
epics
finders,
but
limiting
removing
the
what
the
collection
of
groups
would
be
different,
but
the
checks
for
the
group's
permissions
would
be
the
same.
It's
just
a
much
bigger
sample
of
groups,
but
yeah
we're
going
to
do
what
we're
doing
now
in
a
larger
sample
of
groups.
J
J
C
A
So
far,
I've
avoided
creating
any
issues
in
this
meeting.
It's
awesome
just
assign
them
to
other
people,
okay
cool,
so
we
can
follow
up
after
the
meeting
for
that
one,
any
other
items
before
we
have
one
minute
left.
If
anyone
would
like
to
raise
anything.