►
From YouTube: Plan group weekly meeting
Description
Plan group weekly meeting for 2019-06-19
A
A
A
A
B
So
if
there
are
more
than
hundred
issues
of
hundred
epics
attached
as
children,
then
we
would
limit
first
load
to
include
only
first
hundred
items
and
then,
if
n
cursor
is
provided
for
a
particular
less
than
we
would
fetch
in
another
hundred
from
that
starting
point
which
is
represented
by
any
for
sure.
So
the
order
currently
is
such
that,
like
in
current
implementation
of
three
of
the
API,
returns
both
epics
and
it
shows
in
two
different
arrays
from
back.
B
So
we
are
essentially
concatenating
those
arrays
into
single
chunk,
and
then
we
are
rendering
it
on
UI.
So
my
default
issues
show
up
at
the
top
of
the
list
or
rode
by
epics.
So
in
case
there
are
more
items
than
what
force
page
can
handle.
We
would
be
making
another
request
and
it
would
again
fetching
results
in
two
different
arrays
for
issues
and
epics
and
we
would
again
how
to
quantize
in
it.
So
the
order
doesn't
really
feel
intuitive
because
we
currently
do
not
follow
any
kind
of
solid
order.
B
C
Good
morning,
yeah
I
think
that,
as
a
couple
things,
the
default
support
order
in
terms
of
receiving
the
ethics
and
the
issues
is
an
ID
order
and
I
need
to
go
home
and
add
in
the
sort
argument
or
ethics
and
issues
and
the
graph
QL.
So
then
that'll
control
that'll
give
you
the
opportunity
to
sort
them.
C
B
So
initial
idea
was
to
have
those
in
that
way,
but
now
that
we
have
a
limit
of
how
many
items
are
returned
by
graphical
API
on
first
request,
so
in
case
the
page
size
is
currently
100
and
if
items
are
more
than
hundred,
then
the
first
batch
would
show
hundred
issues
at
the
top
followed
by
hundred
epics
at
the
bottom
of
the
list.
And
if
we
are
showing
a
length
as
didn't
fix
that
issue
like
we
would
show
a
show
more
descendants
link
in
the
bottom
of
the
list.
So
Fe.
B
If
user
clicks
on
that
link,
then
we
would
edge
another
page
of
the
data
where
we
would
again
show
issues
at
top
of
the
list
and
epics
and
bottom
of
the
list.
Now.
The
question
here
is
like
whether
we
want
to
insert
new
leaf
edge
issues
within
the
existing
list
or
whether
we
want
to
append
the
results
as
if
we
were
to
append
the
results,
then
we
would
help
kind
of
zigzag
style,
rendering
where
you
would
have
less
bunch
of
issues
followed
by
a
bunch
of
a
fixed
and
again
bunch
of
issues
month
of
Appeals.
B
B
And
if
you
were
to
do
it
on
server
side,
then
in
that
case
we
cannot
have
two
different
arrays
of
items,
because
right
now,
issues
and
effects
are
in
two
different
arrays
provided
by
API,
which
is
basically
part
of
the
problem
like
if
API
would
return
a
single
Eric
of
which
combines
issues
and
epics
in
certain
order,
and
then
front-end
wouldn't
have
to
worry
about
how
to
order
the
right.
Currently,
we
are
receiving
be
dying
at
it.
I
was.
D
D
C
No
defined
way
to
interleave
issues
and
epics,
because
the
relative
position
order
are
separate
entities
upon
them.
So
there's
a
relative
position
sorting
on
epochs,
there's
a
relative
position
sorting
on
issues
and
they
don't
match
so
there's.
No
that
at
least
that
I
can
determine
there's
no
good
way
to
say
yeah.
You
can
interleave
these
exactly.
C
The
the
other
situation
that
we
were
talking
about
in
the
issue
is
what
happens
when
you
add
a
new
issue?
How
does
that?
Where
does
that
fit
into
the
whole
thing?
If
you,
if
you
create
an
issue,
come
up,
if
you
add
an
existing
issue,
that
fits
in
with
a
different
sort
order,
does
that
get
out
of
the
top,
or
is
that
in
get
interleaved
in
and
I
think
that
was
one
of
the
other
questions
we
had.
B
So,
like
Brett
mentioned
currently
the
Ammar
that
I
opened
for
that
issue
follows
the
simplest
approach
like
we
are
offending
the
results.
If
you
want
I
can
show
a
quick
demo
I
have
it
running
where
you
can
be
legally
limit
the
paid
sales
and
then,
if
the
first
edge
of
the
list
is
beyond
certain
feed
size,
then
we
would
show
that
link
that
is
shown
in
those
screenshots
and
once
user
clicks
on
those
links.
B
Whatever
results
that
are
provided
by
API,
we
would
simply
append
it
into
the
list
just
like
we
would
have,
as
I
explained
earlier
like,
we
would
have
a
bunch
of
issues
followed
by
epics
or
by
issues
basically
alternating
within
the
distance.
So
if
we
are
ok
with
it,
then
it's
a
simple
approach,
and
in
that
case,
if
any
newly
added
items
are
tied
upon
like,
for
example,
if
user
tries
to
add
a
new
epic
or
an
issue
to
the
existing
list,
we
would
simply
show
it
on
the
top.
B
But
then,
when
Paige
gets
reloaded
we
would
have
a
different
order,
so
that
becomes
tricky
because
we
also
want
drag
and
drop
to
be
in
place.
So,
for
example,
user
had
like
100
plus
items
as
I,
say,
and
then
user
tries
to
reorder
them
in
a
certain
order,
and
then,
when
the
page
is
reloaded
we
would
by
default,
shows
out
a
number
of
items.
B
C
So
we'll
have
to
I
saw
your
branch
crucial
about
the
demo
stuff,
but
I
haven't
had
a
chance
to
load
that
up
today.
So
I'll
do
that
and
take
a
look
at
that
I
think
I.
Think
appending
to
the
end
of
the
list.
Is
it's
perfect
for
the
for
the
more
situation
and
we'll
want
to
see
how
the
how
adding
new
items
Fitz
and
I
we
may
have
to
insert
it
into
the
proper
relative
position
within
the
issue
list.
I,
don't
know,
I,
don't
know
what
the
right
answer:
yeah.
B
Or
very
probably,
we
can
schedule
a
call
with
enable,
like
three
of
us
can
have
a
call
later
this
week
or
probably
next
week
and
then
decide
on
how
to
like
what
are
the
cases
that
we
want
to
handle.
And
then
once
we
are
on
the
same
page,
we
can
go
about
it
and
analyze
the
UX
or
the
pagination
and
then
approach
it
accordingly.
E
Poole,
thank
you
all
sorry,
I
was
a
bit
late.
I
threw
this
issue
on
to
the
agenda,
because
this
one
came
up
in
the
party
meeting
yesterday
where
PMS
are
essentially,
we
find
this
filtering
very,
very
useful
in
terms
of
not
filtering,
you
know
filtering
out
all
the
things
that
aren't
bugs
or
doing
more
advanced
AI
filter
options
as
they're
growing
their
backlogs,
and
so
it
was
one
of
one
of
those
cases
where
we
obviously
want
to
dog
food.
Here
we
had
this
schedule
already
for
12.
B
E
In
c
ii,
which
I
didn't
know,
the
current
issues
are
in
EE,
and
so
this
seemed
like
it
warranted
a
conversation
because
I
read
through
the
entire
thread:
that's
linked
there.
It
was
just
an
interesting
thread
to
read
through
and
there's
like
two
hundred
and
some-odd
up
votes
for
putting
this
into
c
e.
Now,
I
wanted
to
kind
of
get
the
team's
thoughts
on
historical
context
and
whether
or
not
this
should
actually
be
a
paid
feature.
E
D
E
D
A
We
haven't
like
from
a
technical
perspective,
I
think
it's
from
a
technical
perspective,
it's
generally
easier
to
put
stuff
in
core,
especially
if
it
a
lot
of
places
is
all
I'll
say
there.
That's
not
the
way
we
should
make
product
decisions
necessarily,
but
that's
that's
generally
how
it
works
from
that
side.
I
see,
Alexis
had
some
comments
as
well.
F
Yeah
I
mean
my
question
would
be
same
as
Eric's
like.
Why
would
it
be
in
EE
I,
don't
really
understand
the
context
there
either
in
my
opinion,
yeah.
It
seems
to
add
so
much
value
to
so
many
users
that
I
don't
know
why
we
wouldn't
have
it
in
core
and
I
was
doing
like
a
I
just
started
a
competitive
analysis
and
it
seems
like
a
pretty
basic
feature
in
many
products
like
a
very
core
feature
to
allow
people
to
just
zoom
in
out
of
their
data.
So
I
mean
I
think
we
should
include
it.
D
We
we
make
a
promise
that
we
try
to
decide
who
the
likely
type
buyer
is
to
decide
whether
it's
in
C
e
or
EEE.
So,
basically,
we
need
to
consider
who,
who
was
with
the
person
that
will
use
this
feature
like
would
a
what
an
individual
contributor
will
be
using
these
filters
and
the
search.
And
if
the
answer
is
yes-
and
this
should
probably
go
to
port.
E
E
A
And
I
think
you
can
assume
that
from
those
287
up
votes,
then
all
the
like
managers
or
directors
or
whatever
as
well
right
like
that's
the
persona
thing.
The
other
thing
about
this
is
I,
think
we
discussed
in
one
of
the
issues
or
somewhere
that
we
wanted
to
do
not
and
then
do
all
we
don't
want
to
do
the
most
in
the
same
release,
ideally
and
also
I,
don't
think
the
UX
has
really.
A
Happened
like
we've
talked
about
it
a
bit,
but
we
haven't
like
really
sat
down
and
done
it
and
that's
quite
a
big
part
of
this.
We
can
like
work
on
the
backend
and,
to
a
certain
extent,
the
front-end,
without
that,
but
I
think
it's
a
very
important
part
of
this
as
well.
So
if
we
can,
if
we
definitely
know
that
we're
going
to
work
on
this
in
12.2,
then
it's
good
to
call
out
early
I.
Think.
D
Okay,
by
the
way,
I
just
noticed
that
the
epic
actually
has
more
information
as
to
why
it's
an
so.
What
Victor
has
said
was
that
yeah
you
this
would
be
most
likely
used
by
somebody
higher
up
to
track
the
team
itself.
You
know
like
filtering
out.
Other
teams
makes
it
bad,
but
you
know
I
get
like
you
said
it
we
can.
We
can
basically
talk
about
this
either
way.
E
A
Okay,
well
go
ahead,
so
yep
we've
got
a
new
engineering
manager,
starting
on
the
22nd
of
July,
which
I'm
very
excited
about
so
I've,
been
announcing.
A
bunch
of
places
will
start
the
work
of
splitting
the
teams
once
they
start
and
yeah
I,
just
linked
to
a
slack
thing
in
the
thanks,
Channel
Eric
Johnson
put
in
because
of
how
positive
for
feedback
for
was
for
this
person
overall,
so
I'm
definitely
really
excited
that
they're
joining
and
then
I
had
the
next
thing
as
well,
which
was
just
asking
Eric.
A
E
So
one
of
the
things
we
ran
into
we,
we
were
going
to
change
team
planning
to
project
management
and
enterprise
planning
to
put
folio
management,
but
in
our
the
way
that
our
pages
are
rendered
and
the
way
that
the
categories,
the
groups
and
the
stages
are
structured.
You
can't
actually
have
the
same
name
as
a
group
and
a
category
name.
So
that
means
that
we
would
have
to
either
change
the
category
that
is
called
project
management
to
allow
for
a
group
called
to
be
called
project
management.
E
But
if
we
do
that
the
group
is
the
one
piece
of
in
that
higher
if
it's
actually
not
customer
facing.
So
the
stage
is
customer
facing
and
the
category
is
customer
facing.
But
the
group
is
not
it's
just
the
way
that
we're
internally
organizing,
and
so,
if
you
move
portfolio,
sorry
project
management
to
the
group
level,
we
actually
get,
no
goodness
from
any
sort
of
marketing
terms.
Seo
optimization
that
kind
of
stuff,
and
so
we
don't
really
want
to
take
project
management
away
from
our
category.
E
D
E
It's
called
agile
portfolio
management,
okay,
we're
good,
then
yeah,
so
so
that
was
once
again
another
optimization
to
get
as
much
marketing
goodness
as
possible.
Okay.
So
in
that
case
we
aren't,
we
have
we're
not
kind
of
limited
so
yeah.
We
don't
have
to
consider
it
there,
but
maybe
that's
the
latest
Shawn
cool.
A
A
E
E
G
E
G
A
Please
sorry,
Eric,
are
you
gonna,
say
something?
No
yeah
we're
just
gonna,
say
Alexandra's.
Sorry,
if
this
wasn't
clear
before
so,
like
you
know,
in
general,
like
the
documentation
goes
with
the
feature
thing
is
a
I
get
loud
wide
thing,
so
it's
not
specific
to
plan.
So
what
I'm
talking
about
here
is
sort
of
general,
but
we
don't.
The
documentation
is
probably
higher
priority
than
pretty
much
anything
else.
A
You'll
be
working
on
if
something's
already
shipped
without
documentation,
because
in
the
release
process
we
want
to
link
to
the
documentation,
and
also
you
know
it's
not
really
done.
Is
it
has
documentation?
I
guess
is
the
point.
That's
a
definition
of
done.
So
in
general,
that's
how
the
priorities
work,
like
ideally,
documentation
being
the
original
MRO.
If
it's
not
it's
a
high
priority
to
add
it
was.