►
From YouTube: Plan group weekly meeting
Description
Plan group weekly meeting for 2019-05-29.
A
Okay,
thanks
everyone.
This
is
the
clan
meeting
for
the
29th
of
May,
and
if
anybody
is
watching
the
recording,
we
started
this
with
no
technical
difficulties
whatsoever.
The
first
thing
I
wanted
to
bring
up
which
I
don't
think
we
need
to
discuss,
but
we
can
discuss
if
we
want
to
is
that
Nick
Thomas
from
creates
made
a
suggestion
to
move
planning
to
happen
twice
monthly
instead
of
monthly
in
plan.
A
We
experimented
with
something
a
little
bit
similar
a
while
ago
and
I've
commented
to
that
effect
in
the
issue,
but
I
think
it's
an
interesting
idea
and
I'd
I'd
love
to
see
something
like
that
happen
where
we
can
be
sort
of
more
continuous.
Anyway,
we
do
have
the
delivery
team
are
working
on
a
thing
where
we
will
be
deploying
to
get
lab
on
a
sort
of
continuous
delivery
basis
as
well,
so
it'll
be
good
to
get
everything
sort
of
all
ironed
around
that
model
or
out
of
them
monthly
sort
of
big
bang
model.
A
B
A
A
It's
normally
a
few
messages
on
slack
or
in
its
dock
or
whatever,
but
ideally
like
you
know,
once
a
month,
Donald
and
I
have
to
go
figure
out
how
much
capacity
we
have
like
how
much
we
think
the
issues
in
a
release
way
Eric
has
to
figure
out
like
what
priority
these
issues
go
in
and
when
dole
do
I
say
we
don't
have
enough
capacity
which
is
used
to
cut
some
times.
So
if,
if
we
do
that
in
smaller
chunks,
the
idea
is
that
it
will
be
less
painful
and
kind
of
on
that
subject.
A
There
is,
there
are
quite
a
few
features
and
12.1
which
I
meant
to
link
to
here,
but
then
I
forgot,
so
I'm
just
gonna
find
that
link
now.
But
if
there's
anything
you
want
us
to
start
work
on,
you
know
we
might
not
be
able
to
bring
something
into
12.0
from
12.1,
but
we
can
certainly
get
a
head
start
on
12.1
with
some
of
these
things.
I'd.
Imagine
then
yeah
and
you
don't
have
to
answer
in
the
core,
but
we
can
certainly
talk
about
it
in
the
quality.
C
A
Yeah
I
think
I
think
it's
fine
if
someone
from
the
community
works
or
wants
to
work
on
it,
but
also
like
if
we
want
to
do
it
in
a
particular
release
or
by
a
particular
release,
it's
better
for
us
to
do
it
or
closely.
Here
we
have
no
control
over
it.
So
that's
fine
yeah!
Let
me
just
make
a
note
of
those
two
there.
Okay,
so
the
board
list
capacity
lion
I
saw
I,
didn't
read
it
I
did
see.
Alexis
had
done
creo
of
like
thinking
on
this
one.
A
D
Yeah,
because
the
even
if
we
get
to
a
point
with
the
capacity
line
where
it's
ready
for
dev
I,
don't
think
we're
quite
in
the
same
boat
as
back-end
in
that
I.
Don't
think
we
have
any
extra
capacity
for
12,
o
or
her
friend
and
stuff,
but
if
we
can
get
something
like
you
said,
if
we
can
kind
of
treat
something
as
a
as
a
spike
and
start
looking
at
it
in
1204
the
capacity
line
that
might
be
helpful
on
the
the
front.
A
A
E
E
F
And
there
is
related
announcement
like
animal
mentioned,
regarding
the
dragon
Rob,
because
current
implementation,
we
have
epics
and
issues
list
separate
both
of
them
allow
a
user
to
drag
and
drop
items.
But
for
tree
we
didn't
decide
to
do
regular
up,
at
least
in
the
initial
equation.
But
since
is
it
mr.
release
of
animalistic
like
we
should
rather
get
the
drag-and-drop
loaded
in
the
main
feature
and
then
push
it
to
the
public.
F
So
if
we
were
to
release
the
tree
as
a
part
of
feature
flag,
either
a
cookie
flag
or
proper
feature
flag,
then
we
can
maybe
have
the
regular
of
implemented
in
12.1
because
in
any
case,
are
doing,
drag
and
drop
within
fellow
who
is
not
possible.
Now,
because
the
tree
apps
food
is
still
not
in
master
yet,
and
we
are
already
29th
of
the
month.
So
we
don't
have
sufficient
time
to
get
the
title
top
40
and
that
would
be
a
significant
difference.
F
So
if
we
were
to
have
the
drag
and
drop
along
with
the
tree
before
we
make
it
available
to
the
wider
audience,
I'd
rather
have
a
feature
flag
in
place
and
then
do
it
in
5.1,
once
paired
office
function
will
be
basically
Ramudu
with
your
plug
and
make
the
tree
out
fully
available
within
failure
of
myself.
So.
A
E
That
and
the
fact
that
people
add
issues
to
ethics
currently
and
then
they're
able
to
order
them.
Let's
say
in
priority.
However,
they
want
once
we
implement
that
tree
can't
do
that
until
the
drag
and
drop
has
been
added
in
the
next
release
and
I'm
worried
that
people
are
gonna,
be
a
little,
the
workflows
might
be
disrupted
if
they
can't
drag
anything
for
a
whole
release
right.
F
F
So
the
current
term
are
only
adds
the
back
end
for
the
drop
cool
to
get
the
nesting
working.
We're
making.
Just
one
call
would
give
you
both
epics
and
issues
forgiven
as
far
as
drag
and
drop
back-end
is
concerned
by
only
we
already
have
support
for
drag
and
drop,
but
that
was
for
the
flat
list
now,
with
the
tree
in
place,
we
would
need
to
cover
scenarios
where
you
can
basically
drag
an
item
from
one
subtree
into
another
one.
If
at
all,
we
want
to
tour
it
I
believe
we
want
to
so.
F
For
example,
if
I
were
to
drag
an
item
which
is
in
one
subtree
and
drop
it
over
to
another
sub
tree,
we
would
basically
changing
the
relationship
between
those
epochs
while
the
item
gets
dropped,
so
that
requires
some
back-end
support
as
well,
because
right
now
the
only
support
providing
like
the
indexes
like
we're
exactly
within
the
list.
We
want
the
data
to
be
ordered
in,
and
that
is
a
very
basic
back-end
that
we
have
for
getting
the
regular
drop
in
place.
A
F
Know
so,
and
so
so
what
happened
was
in
last
release
where
we,
this
was
supposed
to
go,
11.11
I,
didn't
feature
flag
was
suggested
like
on
trip
or
6th
of
the
month,
so
we
didn't
have
sufficient
time
to
get
all
the
flags
in
place
for
both
the
front
end
and
back
end.
But
if
we
decide
now
to
have
the
feature
flag,
we
still
have
sufficient
time
to
implement
it.
F
I
can
ask
Brett
to
have
the
feature
flag
back
and
ready,
and
you
can
put
those
checks
in
place
within
the
front
end
so
that
we
don't
remove
the
flight
list
as
long
as
feature
flag
is
true
but
yeah.
That
was
something
that
came
up
very
last
in
the
development
phase.
Oh
it
didn't
decided
early
on.
We
started
working
on
okay.
A
A
But
I
guess
the
question
is
for
Annabelle
and
Erik
learn
like
do.
We
want
to
spend
the
extra
time
to
put
this
behind
of
feature
flag
so
that
we
can
at
least
merge
the
tree
and
then
still
work
on
the
tree
without
having
to
like
block
it
on
the
I,
can
drop
and
then
remove
the
feature
flag
once
the
dragon
drop
is
also
implemented
in
working.
E
C
Know
we
haven't
done
that
yet
that'll
happen
near
near
the
end
of
June,
like
June,
15,
+
or
I,
like
that
idea
too
I'd
like
to
understand
Annabelle,
like
the
link
between
the
display
of
the
tree
and
the
drag-and-drop
functionality,
it
seems
a
little
bit
counterintuitive
to
our
MVC
and
iterate
approach,
and
so.
E
I
agree
and
I
like
the
idea
of
implementing
these
these
iterations,
but
I'm,
not
in
favor
of
removing
functionality,
which
is
what
we're
doing
since
we
couldn't
do
driving
and
dropping
at
the
same
time
as
implementing
this
tree,
I
mean
that
drag
and
drop
is
going
to
be
a
significant
advert.
It's
much
more
complicated
as
Kajal
is
explaining
than
just
dragging
within
the
issues
list
and
I
just
want
to
make
sure
that
our
small
primitives
aren't
removing
functionality
is
kind
of
what
it
boils
down
to
you.
Can
we.
E
F
Wouldn't
suggest
on
having
both
of
them
in
place.
If
we
were
to
do
it,
read
only
because
that
would
mean
that
the
handful
of
changes
on
the
tree
app
itself,
we
want
to
remove
all
the
right
functionalities
within
the
tree
like
we
would
have
to
hide
the
remove
button
for
each
list
item.
We
would
also
have
to
hide
the
header
actions
which
allow
you
to
add
epics
and
issues
through
the
list.
That
would
mean
we
would
also
be
hiding
ability
to
create
child
epics,
which
we
added
along
with
the
tree.
F
So
it
is
like
adding
flags
to
a
bunch
of
places
just
to
make
that
entire
tree
read-only.
At
the
same
time,
if
user
is
allowed
to
make
the
changes
to
the
list
of
child
epics
or
list
of
child
issues,
then
user
would
have
to
first
go
to
the
upwards
in
the
page
and
then
add
all
the
epics
and
I'll
issues,
then
scroll
further
down
and
see
if
the
tree
shows
up
all
those
newly
added
epic
salvation.
F
So
as
animals
mention
it,
it
is
only
going
to
confuse
the
user
so
yeah,
so
I'd
rather
have
the
entire
daytime
show.
Only
when
we
remove
the
feature
flag
and
make
it
first
party
app
and
then
remove
the
older
implementation
and
as
long
as
we
don't
have
Reagan
drop
and
paste
that
entire
tree
tab
remains
behind
the
flag
and
we
continue
working
on
finishing
it.
C
C
We've
got
the
edit,
the
ACE
editor
we've
got
the
web
IDE
and
that's
like
a
confusing
experience,
although
it
also
is
something
we've
lived
with
for
a
very
long
time,
and
so
it's
not
necessarily
unprecedented
that
we've
done
that,
but
I
think
I
guess
going
back
to
number
2
on
the
agenda
so
so
Shawn.
If
there's
extra
capacity,
then
yeah
I
think
I.
C
Think
in
general
I
agree
with
what
what
what
Annabelle
is
is
proposing
here
that,
like
we,
should
not
touch
either
of
the
two
issues
I
talked
about,
we
should
focus
on
epic
tree
dragging
and
dropping.
This
is
the
really
important
functionality
for
like
an
incredibly
strategic
customer
of
ours,
but
they've
been
asking
for
since
January
so
yeah.
We
should
focus
on
this
one.
C
A
Just
to
be
clear,
this
is
issue
I'm
sure
I,
put
the
link
in
the
zoom
chat
just
for
the
sake
of
speaking
us.
This
is
this
issue.
Right
should
be
nine
three,
six,
seven
yeah,
that's
the
one
okay,
so
yeah
I
think
so
this
was
down
at
the
bottom
of
the
back-end
board
because
it
was
blocked
on
the
other
one.
But
I
can
add
a
comment
to
say
that,
from
a
back
in
perspective,
this
isn't
blocked
as
long
as
the
backend
for
the
epic
tree
view
is
merged,
or
is
it
doesn't
even
have
to
emerge?
A
It's
like
stable,
which
I
think
it
is
I.
Think
Brett's
just
fixing
up
a
couple
of
final
things
before
that
gets
merged.
We
can
start
work
on
the
backend
of
this
and
like
supporting
that
and
like
we
can
talk
to
Koosh
all
about
how
we
do
that
and
then
at
least
we're
not
blocking
ourselves
on,
like
you
know,
crucial
starts
ready
to
work
on
this
and
he's
back
in
to
go
over,
do
a
bunch
of
stuff
and
back
and
have
been
doing
all
this
other
stuff
instead
because
they
thought
this
was
blocked.
A
Like
you
know,
we
can
we
can
at
least
get
ahead
for
that.
So
I'll
add
a
comment
to
that
effect.
Basically
saying
you
know,
we
should,
as
a
back-end
team,
pick
this
up,
even
though
we
can't
finish
the
feature
right
now,
because
it's
blocked
on
another
thing.
We
can
do
the
backend
side
of
it
early
and
we
can
work
with
front-end,
sir,
make
sure
that
it
works
in
a
way
that
they
need
so
that
when
they
come
to
implement
it,
it's
it's
going
to
work.
It's
going
to
go
much
faster.
F
Another
follow
up
mr
right
away,
which
basically
adds
a
feature
flag
that
could
just
hide
the
tree
tab
so
that
we
don't
have
to
remove
anything
else
from
the
UI.
We
just
do
the
changes
related
to
feature
flag
in
a
separate,
mr,
so
that
this,
mr
doesn't
get
because
it
has
already
been
a
while
waiting
for
I.
Think
there's
a
proven
review,
so
I
would
yeah.
A
Ya
know,
as
always,
so
adding
a
feature
flag
afterwards
is
kind
of
the
opposite
way
around
the
way
we
normally
do
it,
but
I
think
it's
fine
as
long
as
the
intermediate
state
isn't
terrible
and
we
get
the
feature
flag
in
quickly
afterwards,
because
you
know
I
think
that
that's
pragmatic
in
this
case,
but
I
just
wanted
to
make
sure
that
that
would
work
and
it
wouldn't
be
like
horribly
broken
until
we
added
the
feature
flag,
in
which
case
like
you
know,
we
should
emerge
it
in
the
first
place.
Yeah
yeah.
D
That's
the
key
thing
is
the
getting
the
feature
flag
in
as
soon
as
possible
afterwards,
because
we
don't
want
to
accidentally
get
to
a
state
where
you
know
the
having
a
feature
peg
flag
is
is
pointless
because
we
end
up
with
the
feature:
oh
yeah.
We
just
released
it
yeah,
okay
and
then
I'll
just
talk
through
kind
of
your
priority.
D
F
Our
can
wait
for
on
the
release.
It
is
more
of
a
technical
debt,
so
we
don't
have
to
do
it
on
priority.
I'll
get
the
drag-and-drop
sorted
before
I
start
working
on
any
other
thing.
Maybe
I
can
include
the
follow-up
items
like
we
discussed
in
our
101
flip,
where
we
had
some
table
changes
to
the
tree
app
itself.
Maybe
I
can
cover
those
along
with
the
dragon
drop
rate
changes
and
then
we
can
push
out
the
whole
thing
in
a
lot.
1
sounds
good.
E
Okay,
I
think
I
am
the
next
point.
I
was
just
gonna.
Let
the
team
know
that
beautifying
UI
epic
is
not
just
last
week.
It's
through
the
seven,
so
I'll
continue
to
have
somewhat
limited
availability,
and
so,
if
there's
any
new
plan
related
questions,
please
reach
out
to
Alexis,
but
for
the
issues
I'm
already
assigned
to
you,
I'm
still
going
to
continue
working
on
them
like.