►
From YouTube: Plan stage weekly meeting - 2019-08-28
B
Sure
it's
pretty
much
just
what
it
says
right
there
and
it's
probably
jumping
the
gun
a
bit
but
I'm
trying
to
get
a
an
indication
of
our.
We
intend
in
like
a
clean,
split
and
12:4
so
at
the
minutes
and
I'm
encouraging
people
to
draw
issues
from
both
sides
of
the
team
just
depending
on
what
they
feel
they
can
best
contribute
to,
but
I
trying
to
get
an
idea.
D
C
A
Sorry,
oh
it's
muted
for
me
that
works
too.
The
only
question
I
have
is
is
Keenan
sore
temporarily
taking
certify
like?
Is
that
still
with
gabe
like
how
does
that
shake
out?
Because
when
we
slit,
we
just
said,
you
know
that
exact
mechanics
of
how
we
split
between
portfolio
management
and
certify,
a
kind
of
up
to
john,
basically
and
donald
and
the
pms
for
those
areas.
A
C
There's
a
new
p.m.
starting
for
certify
and
I
think
the
8th
of
September,
so
in
so
much
as
that
impacts
this
and
there
will
be
a
dedicated
p.m.
for
that
cult
in
a
couple
weeks.
So
I
think
it's
kind
of
a
moot
point,
but
once
we
do,
then
that
p.m.
will
work
with
John
to
get
the
resources
for
whatever
issues
are
in
certify
yeah.
E
Yeah
I
mean
on
the
front
end
it's
a
little
different,
because
I
mean
just
we're
still
working
on
same
kind
of
plan
board,
just
even
12,
for
we
are
just
with
a
preference
for
the
group
that
they
are
a
part
of
that
engineers
are
part
of
so
yeah
I.
Think
I
mean
it
makes
sense
to
do
it
in
12
for
as
much
as
it
makes
sense
to
do
it
in
future
on
the
front
end.
So
I'm,
okay,
with
having
a
clean
split
for
the
back
and
stuff
in
the
project
management
stuff
in
twelve.
B
A
Yeah,
sorry
and
I
think
as
far
as
things
are
now,
we
plan
to
start
working
on
12.4
which
is
in
quotes,
because
obviously,
that
isn't
exactly
lined
up
with
when
things
get
deployed,
beliefs
and
plans
start
working
on
12.4
on
the
8th
of
September,
which
is
also
in
the
new
certified
p.m.
starts,
so
that's
kind
of
sumption
I've
been
using.
But
if
anybody
wants
to
change
that
I'm.
Okay
with
that
too,
you.
D
D
So
I've
been
working
with
our
UX
and
back-end
on
how
to
get
the
backend
of
working
and,
as
we
discussed
in
last
planting
call
that
currently,
interspersed
reordering,
is
not
supported
from
the
backend
perspective,
which
means
that
we
cannot
have
an
issue
between
two
epochs
manually
ordered
and
vice
versa.
So
what
we
decided
was
to
how
to
basically
communicate
this
on
UI
very
user
can
still
reorder
issues
amongst
themselves
and
epics
amongst
themselves,
but
still
not
be
able
to
reorder
with
each
other
in
cross
fashion.
D
So
right
now,
I
have
the
tree
available
here,
as
you
notice
that
the
moment
I
start
dragging
this
issue,
you
would
see
this
small
line.
Obviously
a
color
line
color
and
the
styling
is
not
final,
but
this
is
more
of
a
work-in-progress
thing,
so
this
will
basically
show
a
tentative
position
where
it
can
be
placed.
But
since
we
want
drag
and
drop
to
be
also
be
able
to
change
the
parent
of
an
item,
we
want
to
keep
the
UX
similar.
D
So
the
way
it
happens
is
that
when
you
cry
over
again
issue
on
top
of
epics
or
the
position
line
goes
away
instead,
you
would
notice
that
individual
epics
are
highlighted
into
blue.
What
this
means
is
that
if
user
releases
the
button
here,
the
issue
will
go
inside
the
epic
and
that
epic
itself
will
become
parent
for
this
video.
So
again,
there
is
not
integrated
in
back-end.
D
So
if
I
release
the
button,
nothing
would
happen,
but
this
is
what
we
are
aiming
for,
where
user
can
basically
grab
an
issue,
put
it
on
top
of
effects,
and
if
user
wants
to
reorder
it,
they
can
just
keep
it
confined
to
the
list
of
issues.
The
moment
they
go
outside
the
issues
list
itself
within
the
tree
or
the
line
will
go
and
blue
highlight
will
show
up
when
it
comes
to
epics.
We
want
similar
experience.
D
That
user
should
be
able
to
reorder
it
among
itself,
but
if
user
tries
to
move
it
on
top
of
issues,
nothing
happens
like
if
I
release
the
button,
it
will
go
back
to
its
original
roots,
so
that
is
how
we
are
restricting,
or
basically
confining
issues
and
epics
within
the
tree
to
be
reordered
within
themselves.
But
there's
one
problem
here
is
that
we
not
only
we
want
to
allow
user
to
change
parent
of
issues.
We
also
want
to
change
parent
of
epics.
D
So
just
to
give
you
an
analogy,
we
basically
want
this
experience
to
be
similar
to
file
managers,
so
think
of
epics
has
folders
and
issues
as
files,
so
I
want
to
user
I
want
user
to
be
able
to
put
file
inside
of
a
folder
I
want
user
to
be
reordered.
Just
the
folders
and
I
want
user
to
be
able
to
move
a
folder
inside
of
a
folder,
but
we
cannot
put
a
file
between
two
folders
and
we
cannot
put
folder
between
two
files.
Those
are
the
restrictions,
otherwise
it
is
a
somewhat
similar
to
file
manager.
D
So
what
happens
here
here
is
that
ideally
I
would
want
that
when
I
move
an
epic
between
the
epics
or
at
a
certain
cursor
position,
this
line
would
show
up,
which
means
that
I
can
reorder
it
in
a
way
I
want.
But
if
there
is
a
certain
cursor
position
in
place
that
I
want
this
epic
we
move
inside
of
an
epic,
then
this
line
should
go
away
and
instead
it
should
highlight,
as
blue
now
here's
the
problem.
We
are
using
a
sortable
JS
library
to
do
this.
D
So
this
way
we
can
move
an
item
inside
of
an
item
here,
but
if
it
is
collapsed,
that
is
not
possible
and
I
tried
the
exploring
any
other
libraries
that
we
can
use
along
with
or
double
J's
and
I
also
looked
at
what
are
the
event
handlers
that
sortable
exposes
in
order
to
achieve
this,
and
it
is
not
possible,
like
there
are
a
few
which
are
available
for
jQuery,
but
we
don't
want
to
go
that
route.
Sort
of
a
Jas
is
one
of
the
options
and
sortable
simply
doesn't
support
this
sort
of
mechanism.
D
That
issue
and
I
would
move
that
issue
inside
of
anything,
and
also
since
we
cannot
put
issues
between
two
epics,
this
kind
of
interaction
is
possible,
but
since
the
epic,
sorry
orderable
among
themselves
and
epics
can
also
be
put
inside
of
each
other,
we
cannot
combine
both
the
interactions
in
a
single
type
of
interface.
So
that's
the
problem
we
have.
Alternatively,
what
I
was
thinking
of
and
since
as
I
say,
that
this
is
obvious
limitation,
that
you
cannot
put
an
epic
inside
of
an
epic
as
unless
you
expand
that
are
great
I.
D
Think
and
for
example,
if
epic
doesn't
have
any
children,
then
you
cannot
expand
it
and
without
having
any
children
is
there.
You
cannot
put
any
other
epic
inside
of
it.
So
that's
a
clear
limitation,
so
we
don't
want
to
deliver
a
half
big
dragon
drop
just
because
we
cannot
put
epics
inside
of
an
epic,
so
the
alternative
mechanism
of
changing
parents.
D
What
I
was
thinking
of
was
that
right
now
like
in
12.3,
we
already
pushed
in
mr,
where
you
can
open
any
issue
and
in
the
issue
sidebar,
there
is
an
option
to
change
parent
epoch
like
we
have
an
epoch
drop
down
within
the
issue
sidebar.
So
technically
you
can
change
event
of
any
issue
by
visiting
that
issue
page.
Similarly,
we
can
use
that
same
cyber
drop
down
in
case
of
epic
sidebar
as
well
like
right
now.
D
The
only
way
to
change
parent
of
an
epoch
is
to
either
move
to
that
epoch
and
then
use
this
epoch.
Slash
command
like
parent
topic,
but
child
epoch,
or
you
can
go
to
the
tree
tab
and
use.
Basically,
this
add
epoch
and
paste
in
the
link,
but
it
is
like
a
multi
click
process,
but
what
if
we
had
the
sidebar
option
right
away?
Where
user
can?
Just?
We
can
edit
and
select
one
of
the
existing
eligible
parent
effects
and
change
the
epoch
directly.
D
That
way,
we
will
still
allow
user
to
change
parent
epics
directly
without
going
multiple
places
and,
at
the
same
time,
we'll
be
able
to
goo
reordering
in
a
normal
fashion,
like
reorder
of
issues
can
happen
among
itself,
and
the
order
of
ethics
can
happen
in
itself.
So
those
are
basically
the
problems
like.
There
are
a
lot
of
things
going
on
on
how
we
want
to
do,
drag
and
drop.
There
was
one
more
UX
research
that
we
have
been
doing.
D
The
third
option
that
I
thought
of
apart
from
the
sidebar
option
was
that
roll
out
our
own
right
and
wrong,
and
that
is
a
lot
more
effort
than
we
think
it
is
because
we
would
then
help
you
implement
and
a
drag
and
drop
library
just
to
suit
our
needs
with
all
the
baggage
restrictions
and
things
so
I
just
wanted
to
bring
this
up
with
rest
of
the
team
mind.
Let
me
know
what
you
think
about
like.
D
If
you
want
to
go
with
reordering
part
and
get
done,
get
basically
this
feature
done
for
12.3,
then
we
skip
the
parent,
chaining
interface,
part
at
least
and
just
allow
the
reordering
manually.
And
then,
if
user
really
wants
to
change
the
parent,
they
can
always
click
on
the
link
and
go
to
the
side,
but
Rotom
IG.
E
D
Yes,
yes,
only
for
epics,
like
I,
can
change
a
parent
of
any
existing
issue
by
just
dropping
on
top
of
it,
because,
as
you
can
see
there
is
this
blue
highlight
already
present,
so
that
can
be
done
again.
This
is
not
something
so
audible.
Yes,
of
course,
we
are
doing
this
manually
by
exploiting
the
the
sort
of
a
CSS
event
handlers
using
mouse
movements.
D
So
that
way
we
can
do
it,
and
that
is
possible
because
we
cannot
put
issues
between
two
ethics,
which
is
why
we
can
do
this
other
out
of
identifying
where
exactly
user
is
trying
to
top.
This
drop
this
issue
on
top
of
ethics,
but
when
it
comes
to
epics
itself,
we
have
two
things
going
on.
We
want
to
be
able
to
reorder
the
epoch
between
two
epochs,
but
at
the
same
time,
if
user
is
keeping
it
just
at
the
right
position,
we
want
to
move
that
epoch
inside
of
the
target
app
against
them.
E
Yeah
for
me,
I,
don't
know
that
I
mean
that
almost
feels
more
natural
to
so
I'm
completely
fine
with
that
being
the
first.
You
know
our
first
iteration
of
getting
this
out,
because
the
the
the
other
thing
that
that
gives
us
by
forcing
users
to
expand
the
epic
first,
is
that
we
don't
need
to
get
the
order,
assuming
we
just
put
it
like
at
the
bottom
of
the
order.
Yeah
but
I,
don't
know
if
that's
the
right
way.
F
D
So
so,
basically,
if
we
want
to
allow
changing
parents,
then
I
think
we
should
not
allow
that
by
doing
drag
and
drop,
we
only
keep
drag
and
drop
limited
to
just
reordering
items
and
that
wasn't
simplify
our
implementation
as
well
like
right
now
we
have
we
held
a
mildly
hacky
way
of
what
we
are
doing
right
now.
You
want
to
achieve
the
current
state
of
this
feature.
Like
I
know,
there
are
some
CSS
changes
that
I
have
done
to
highlight.
Individual
epics
has
new
the
moment.
D
User
tries
to
drag,
and
this
shoe
on
top
of
epics
and
at
the
same
time,
just
to
show
this
line
like
right.
Now.
If
you
move
any
item,
you
would
notice
this
blue
line.
It
is
not
actually
a
line
indicator
that
sortable
J's
supports
sortable
supports
showing
entire
ghost
elements
so
like.
If
you
check
the
library's
page
itself,
then
it
basically
shows
the
entire
target
element
like
notice,
how
I'm
dragging
this
item
six
and
while
I'm
having
this
item
six
draggable
right
now.
D
The
placeholder
that
it
shows
is
the
actual
element
that
I
am
trying
to
that
it
doesn't
show
line
indicator.
The
way
I
am
doing
line
indicator
part
here
is
that
I
basically
use
CSS
to
shrink
the
hype
of
it
and
using
model
color
to
show
it
as
a
line,
and
that
was
more
natural
because
otherwise
things
would
jump
around.
So
I
would
disable
the
animations
here.
D
I
have
reduced
the
height
to
zero
for
the
placeholder
item
and
that's
how
I
am
showing
the
line
so
that
a
lot
of
small
hex
going
on
just
to
achieve
the
kind
of
UX
we
have.
But
if
we
were
to
allow
just
reordering
part,
there
won't
be
any
hex.
The
implementation
will
be
very
simple
and
straightforward,
and
at
the
same
time,
if
we
user
wants
to
change
parents,
they
can
just
visit
the
page
itself
and
do
it
from
the
sidebar,
like
I,
showed
so.
A
G
I'm
not
I'm
not
totally
sure
now,
if
we
need
the
line
because
we're
just
moving
things
up
and
down
in
their
current
boxes,
so
right
now
I'm
going
to
look
into
it
a
little
bit,
but
when
we're
changing
parents
got
really
messy
and
ugly,
and
so
the
lion
was
good
for
that.
So
we
might
want
to
go
back
to
the
default
shadowing,
which
we
already
have
for
all
of
our
other
drag
and
drop
elements,
but
I'm
going
to
think
about
that.
We
I
think
that
might
be
just
a
more
straightforward
solution.
G
D
A
G
And
then
for
the
for
further
enhancements,
we
we
have
an
issue
somewhere,
I,
don't
have
access
to
it
where
it
might
have
been
gave
actually
who
opened
it
were.
You
know,
you'll
click
on
an
issue
or
an
epoch
and
it
slides
out-
and
you
can
see
all
the
metadata
associated
with
that
and
we
can
update
things
right
on
that
page.
D
D
G
Don't
think
we're
ready
to
put
it
in
the
sidebar
the
UX
is
the
UX
team
is
working
on
implementing
in
our
pattern,
library,
a
drawer
or
a
slide-out
that
will
work
for
multiple
places
and
I.
Don't
want
to
rush
something
like
this,
where
we
just
kind
of
I,
don't
know
overlay
it
or
push
it
out
further,
so
I
think
that
should
be
for
12.4
at
the
earliest.
It
requires
a
little
bit
more
UX
work.
G
E
Question
so
are
we
saying
we're
also
going
to
get
rid
of
the
ability
to
to
move
parentless
issues
into
a
parent
epoch
in
drag-and-drop
or
into
it
an
epoch?
I
didn't
get
your
question
on.
Can
you
immediately
go
back
to
you,
go
back
to
the
lists
or
close
those
Constance
epics,
okay,
so
the
issues
listed
here?
Can
we
drag
those
into
an
epic
like
you?
Can
right
now.
D
We
can,
but
at
the
same
time,
if
we
are
not
allowing
epics
to
be
dragged
inside
of
an
epoch,
then
I
don't
think
it
would
be
wise
to
allow
that
just
for
issues
because
it
would
be
confusing
like
if
we
want
to
restrict
users
from
changing
parents.
We
do
it
for
everything
within
the
tree.
We
don't
just
do
it
for
epics
catcher,
okay,
okay,
so
in
that
case,
I'll
update.
The
scope
of
the
written
issue
to
which
this
tomorrow
is
bound
to
I,
will
update
that
for
now.
D
For
this
particular
iteration,
we
would
just
do
reordering
part.
We
won't
allow
user
to
change
panels,
and
then
we
can
revisit
on
how
to
change
parents
like
do
it
with
that
slide
over
sidebar,
or
do
it
in
some
other
way
and
yeah,
and
that
would
simplify
the
implementation
because
currently
graphed
your
back
end
that
we
have
in
this,
mr
already
supports
reordering
within
the
context
itself.
D
So,
for
me
it
is
as
simple
as
integrating
with
the
graph
to
achieve
this
I
think
by
end
of
day
tomorrow
we
will
have
fully
functional
reordering
feature
at
ease,
and
then
we
can
do
the
remaining
of
the
UX
changes
that
we
received
after
will
be
enabled
the
future
plug-in
get
or
calm
like
moving
free
and
roadmap
tabs
to
the
description
area
of
the
epics
and
then
showing
discussions
in
the
bottom.
So
those
changes
can
be
done
once
we
finalize
on
how
we
want
to
route,
I
can
drop,
and
then
we
can
push
everything.
E
D
So
the
you
exchanges
that
were
proposed
do
are
very
simple
once
it
is
merely
reordering
of
items
within
the
page,
so
it
is
essentially
a
Hamill
page
update.
So
that
should
be
simple
and
once
we
have
the
drag-and-drop
completed,
I
will
do
those
you
exchanges,
probably
within
same
mr,
because
the
diff
size
for
those
hinges
is
really
small.
So
don't
want
to
open
another.