►
From YouTube: Plan group weekly meeting 2019-06-05
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
So
yeah
Eric
I
think
the
first
item
was
from
Donald
and
I,
so
we
already
have
a
bunch
of
stuff
in
12.1,
I.
Think
for
backend.
The
weight
we
can
take
is
about
130.
That
might
actually
go
up
because
I
kind
of
lost
track
of
where
Mario
was
with
them
working
on
elasticsearch
and
it
might
be
back
for
hip
knees,
sort
of
treat.
It's
not
gonna
like
exactly
line
up
with
a
development
milestone
because
he's
got
sort
of
one
task
in
flight,
but
I
haven't
spoke
to
him
about
it.
A
B
C
A
Think
I
spoke
to
you
a
bit
about
this
before,
but
I
think
I
put
too
much
technical.
There
is
this
milestone
like
when
I
was
going
through
it,
so
I
still
need
to
remove
some
of
that.
So
maybe
once
you
prioritize
features,
I'll
go
do
that.
The
other
thing
that
stood
out
to
me
was
that
I,
don't
think
we're
quite
there
on
the
boards
capacity
line
issue.
A
So
I
don't
know
if
it's
actually
ready
to
like
go
in,
but
potentially
be
okay
with
it,
and
then
the
third
thing
actually
is
something
I
haven't
spoken
to
Donald
about
and
just
occurred
to
me.
We
do
need
to
sync
up
on
the
front
in
the
back
in
the
shoes,
because
there
are
many
more
that
require
both
this
release
and
we
just
need
to
make
sure
we're
on
the
same
page
about
the
priorities
of
those.
If
people
are
going
to
be
available
to
work
on
both
the
same
site,
yeah.
C
Sure,
yeah,
Alexis
and
I
spoke
about
the
the
kind
of
whip
limit
line
yesterday
it
was
a
great
conversation
but
I
think
I
I
probably
agree
with
you
there.
So
that's
probably
one
that
we
can
take
a
look
at
potentially
pushing
out,
but
I'll
take
a
look
at
both
of
these
and
adjust
the
milestones
appropriately.
A
A
B
B
E
A
C
C
It
has
everything,
there's
actually
two,
that
I
use,
one
is
filtered
by
direction
and
one
is
filter,
actually
it's
by
filtered
by
yeah
filtered
by
direction.
This
one's
basically
just
got
everything
on
there,
so
I'm
going
to
drop
that
here.
This
is
the
full
kind
of
the
full
one
and
then
I've,
so
many
tabs
open
right
now.
A
F
Well,
I
kind
of
generalize
it
a
bit
in
a
sense
that
I'm
not
sure
how
to
address
this
specific
issue
where
we
want
to
duplicate
and
remove
the
dynamic
milestone
stuff,
but
I
guess
it
extends
more
to
my
general
question.
Well,
how
do
we
proceed
with
one
like?
We
have
concerns
and
commands
from
customers
asking
like
well
there?
F
We
should
not
do
that
because
they
kind
of
find
it
useful
and
they
need
it,
and-
and
these
specific
cases
are
not
sure,
we've
got
an
alternative
to
replace
the
information
that
used
to
be
on
that
page
with
something
like
for
them
for
them
to
be
using
so
yeah
I'm,
not
exactly
sure
what
should
we
do?
There
I
have
the
net
request
for
removing
the
stuff
on
cleaning
up
in
review,
but
I
mean
a
bit
skeptical
and
actually
moving
forward.
A
Just
gonna
give
Eric
a
quick
bit
of
context
here
is
that
I
remember
which
was
a
while
back
speaking
to
Victor
about
this
and,
unfortunately
I
didn't
care
about
it
that
much
I.
Remember
he
cared
about
it
more
than
me.
This
is
basically
what
I
remember
like
it's
not
really
costing
us
much
to
keep
those
there,
but
I
think
his
vision
for
how
milestones
would
work
and
how
boards
would
work
was
that,
like
this
should
be
replicable
by
other
stuff,
and
you
don't
have
to
go
to
a
milestone
page
to
find
it.
A
It
seems
like
people
want
it,
but
like
whether
it's
like
that
specific
feature
they
want
or
whether
it's
the
ability
to
do
that
somewhere,
that
they
want
it's
hard
for
me
to
say
just
cuz
I've
not
spent
much
time
on
it.
I
also
don't
think
I'm
gonna
check
the
issue,
but
I,
don't
think
I
think
it
was
just
added
to
a
release
a
while
ago,
like
a
future
release
a
while
ago,
so
I'm
not
sure
it
was.
C
A
Yeah
I'm
in
favor
of
removing
stuff,
if
it
gives
us
a
clear
benefit
towards
a
goal
like
if
we
have
something
to
replace
it
from
a
product
perspective,
everyone
and
drive
people
towards
this
part,
the
product
or
from
a
technical
perspective
like
it's
a
nightmare
to
maintain.
Maybe
we
need
to
talk
about
that,
but
the
certainly
the
second
part
isn't
true
right
now
like
this.
This
is
something
we
basically
never
look
at.
So
it's
not.
F
I,
don't
think
that,
like
we
have
an
option
of
making
this
like
adjusting
them,
making
a
like
a
predefined
board
with
the
information
that
used
to
be
on
those
dynamic
pages,
that'll
be
like
an
option
to
postpone
it
and
just
make
it
those
boards,
gonna
or
like
have
a
button
that
says
all
go
here
and
define
those
boards,
kind
of
or
predefined
them,
but
I'm
not
sure,
that's
actually
technically
possible.
So.
F
For
my
understanding
from
people
commanding
there,
they're
mostly
concerned
about
the
lease
of
his
shoes
like
throughout
the
projects
within
the
group
like
they
would
be
able
to
see
through.
Why
would
the
projects
within
the
group
if
there
are
still
issues
pending
for
that
milestone,
but
I'm
not
being
worked
on
or
was
the
progress
throughout
the
whole
group,
which
is
a.
A
Memory
so
I
might
be
wrong
here,
but
Alexandre.
Maybe
you
can
confirm
so
I
think
there
are
a
few
related
issues
here
and
I'm
trying
to
get
them
straight
in
my
head.
So
we
have
project
milestones.
We
have
group
milestones
and
we
have
these
dynamic
milestones,
which
is
what
this
issues
about
our
dynamic
milestone
is
what
we
used
to
have
before.
A
Yeah
thought
we
haven't
done
that
yet
so
if
we
did
that
first,
like
this,
probably
wouldn't
be
a
problem
because
they
wouldn't
have
access
to
information
anyway,
but
they'd
probably
also
object
to
us,
removing
that
and
I
think
there's
an
issue.
That's
quite
heavily
uploaded.
That
says,
please
don't
do
this
so
I
think
we
probably
got
the
sequence
wrong
here
and
looking
at
the
issue,
it's
it
got
moved
milestone
a
lot
of
times.
A
That
doesn't
surprise
me,
but
my
strong
temptation
here
is
to
just
put
this
back
to
the
backlog
until
we
can
spend
more
time
thinking
about
milestones
again,
because
I
think
it
would
be
painful
change
for
a
lot
of
users.
It
doesn't
really
buy
us
a
lot
at
the
moment.
We're
not
prioritizing
like
milestone
UI
in
the
near
term.
I,
don't
think
so
it's
it
seems
like
a
so.
F
Yeah,
my
understanding
of
it
is
that
I'm
not
for
a
long
time
here,
but
it's
like
a
legacy
thing
where
there
were
no
group
milestones
at
the
moment
where
these
dynamic
milestones
were
added.
So
they
would
group
the
milestones
from
the
projects
by
the
same
name
and
just
like
sort
of
make
a
group
milestone
out
of
that,
and
now
that
we
have
the
group
milestones,
it
doesn't
really
make
sense
to
help
them
took
out
this
dynamic
milestones,
which
is
fine.
A
And
the
reason
we
didn't
do
that
for
group
milestones
was
because
we
wanted
to
remove
or
Victor
wanted
to
remove
it
anyway
and
that's
why
I'm
talking
about
the
sequencing
here
as
well,
because,
like
it's
a
legacy
thing,
but
also,
maybe
if
we
added
it
to
the
group
milestone
pages,
we
could
remove
the
dynamic
milestone
pages.
But
if
we
add
it
to
the
group
milestone
pages,
are
we
saying
we're
going
to
keep
it
in
there
like
I,
don't
know
and
I
would
rather.
A
G
B
A
A
H
A
H
H
Maybe
it
would
be
useful
for
other
engineers
to
you
know,
take
a
look
at
the
the
code
base
as
well
when
we
are
creating
such
requests,
without
forcing
them
to
do
that,
but
of
optionally,
so
that
they
could
get
familiar
when
they
are
going
to
create
some
tests
or
updated,
and
it
does.
They
are
already
familiar
with
the
code
base.
Okay,.
F
Yeah
I'm
I'm,
okay,
it's
optional
I
mean
not.
If
it's
often
people
have
to
do
it.
I'm
I'm,
fine,
breathing,
whatever
called
I.
Think
when
most
at
least
I'd
a
speak
for
myself
when
I'm
I
do
write,
specs
or
tests,
I
would
often
look
into
existing
specs
and
kind
of
figure
out
what
they
already
established.
Kind
of
guidelines
on
yeah
I.
F
H
J
H
K
Yes,
so
our
next
point
is
mine,
so
there
is
just
a
quick
update
on
epic
tree,
like
we
discussed
in
last
team,
calling
that
we
want
this
feature
to
be
behind
the
flag
for
political.
The
merging
quest
is
ready
to
be
merged.
Now
there
is
one
failure
right
now
which
is
around
beautified,
and
it
is
also
happening
for
other
branches,
other
majah
quest,
so
we
can
ignore
it,
although
it
is
currently
in
conflict,
so
it
was
required
to
be
debased.
K
What
we
did
change
and
this
magic
quest
was
that
bread
basically
took
out
all
the
backend
changes
and
broke
it
down
into
smaller
remarks
and
those
dependent
back
in
Amar's
got
merged
into
master,
so
those
are
only
ap.
I
think
this.
It
didn't
include
any
front
end,
so
we
basically
reduce
the
diff
for
this
particular
module
because
it
was
already
going
out
of
proportion.
So
this
merge
request
is
very
small.
Now
and
so
right
now
it
only
inputs
front
end
changes
and
those
changes
are
already
accrued.
K
Additionally,
we
also
included
a
feature
flag,
related
changes
within
the
this
mirja
quest
itself,
so
in
case
something
goes
wrong.
We
have
of
a
to
revert
or
B
1
modulus.
So
basically,
once
this
merge
request,
gets
merged,
user
won't
be
seeing
anything
on
the
epic
page.
We
would
have
to
enable
the
feature
flag
first
to
I'd,
be
older
UI
of
epics
and
issues,
and
then
the
user
will
be
able
to
see
the
free
time.
So
that
was
of
one
thing.
Additionally,
as
a
follow
on
this
feature,
we
would
have
to
work
on
pagination.
K
So
this
is
something
that
we
realized
the
yesterday,
when
Bret
was
working
on
reducing
the
complexity
of
gravity.
So
right
now
we
have
a
limit
of
250
I
believe
on
the
complexity
of
the
graph.
So
what
happens?
Was
that
the
data
that
we
are
fetching
by
a
graph
theory
for
this
feature?
If
the
complexity
grows
beyond
that
threshold,
it
would
simply
feel
the
request
and
apparently
only
way
to
reduce
the
complexity
was
to
reduce
the
count
of
items
that
we
are
fetching
in.
The
one
go
so
right
now
in
production.
K
K
So
what
we
can
do
is
so
right
now
we
had
an
aspect:
failure
due
to
that
graph,
you'll
thresholds
that
we
have
set
up.
So
in
order
to
unlock
ourselves
in
the
query
itself,
we
have
limited
the
count
to
50
and
again,
since
this
tree
app
itself
will
be
behind
feature
flag.
We
do
not
have
to
worry
about
the
limb,
hard
limit
that
we
are
introducing,
but
before
this
feature
becomes
the
main
feature,
that
is
when
we
remove
the
feature
flag
and
make
it
as
primary
feature,
we
would
have
to
introduce
pagination
of
some
weight.
K
So
the
approach
that
we
have
discussed
yesterday,
both
break
and
I,
was
that
we
would
have
the
pagination
implemented
only
on
the
top
level.
So,
for
example,
epic,
epic,
a
has
like
200
direct
child
epics.
So
instead
of
fetching
all
200
at
once,
we
would
have
the
epics
edged
at
once.
We
can
decide
the
count
like
how
much
we
want
to
fetch
on
first
page
and
as
user
Scrolls
in
we
fetch
remaining
once
so.
K
The
experience
is
somewhat
similar
to
issue
boots,
but
again
animal
cancer
just
like
how
we
want
that
mediation
experience
to,
but
in
one
way
or
the
other,
we
would
need
to
have
pagination,
and
so
what
happens
in
case?
One
of
the
child.
Epic,
has
a
higher
count,
because
pagination
works
easier
works
easily
for
us
in
case.
We
want
to
have
it
for
the
top
level
parents.
So
there
we
can
have
a
different
approach
where
what
we
would
do
is
if
one
of
the
child
epic
nodes
when
expanded.
K
K
So
if
you
go
to
github.com
and
go
to
the
group's
page,
we
have
the
cold
there
and
what
it
does
is
that
if
you
expand
any
queue
and
if
it
has
subgroups
more
than
certain
number,
we
show
a
placeholder
item
at
the
end
of
the
two
groups
and
that
link
would
say
like
go
to
the
main
blue
page
in
order
to
give
all
the
medical
groups.
So
that
way
we
would
be
able
to
overcome
the
complexity
limit
for
the
child
nodes
as
well.
So
that
is
basically
the
idea
in
case.
L
L
K
I,
don't
think
we
have
it,
but
there
is
a
follow-up
issue.
Let
me
go
to
a
paste
in
within
our
document
itself,
so
that
follow-up
issue
is
striking
a
bunch
of
smaller
items
that
we
want
to
do
as
a
follow
up
on
the
tree
app
because
there
were
some
major
changes
suggested
during
Libby
that
we
couldn't
get
to
before
this
one
was
already
so
we
can
be
really
break
it
down
now
improve
yeah.
So
there
you
go
I'll
just
pasted
the
link
to
follow
up
issues.
K
So
this
includes
a
bunch
of
follow-up
items
that
we
want
to
do
to
free
app.
So
I
have
added
the
resignation
point
to
this
one
as
well.
So
if
you
want
to
handle
regeneration
in
all
eight
different
issue,
that
is
also
fine.
In
any
case,
all
those
bullet
points
that
you
are
seeing
in
the
mall
of
issue
will
be
doing
in
different
amounts.
E
J
Yeah,
if
you
need
a
workaround
for
pagination,
just
because
of
complexity,
you
can.
You
can
set
complexity
to,
for
example,
zero
or
one
for
the
wall
attic,
and
then
you
wouldn't
be
limited
by
the
number
of
items.
If
I
understood
that
this
is
a
blocker
that
you
are
hitting
complexity
limit
now,
so
you
can
override
it
also
now
as
part
of
your
mr
and
it
could,
and
this
override
can
be
removed
when
let's
improve
mantich
is
matched
yeah.
A
Api
we
wouldn't
have,
or
like
a
back-end
API.
We
wouldn't
even
have
this
complexity.
Question
like
if
the
backend
API,
let
you
do
something
without
pagination.
We
would
just
go
ahead
and
do
it
so
I
think
it's
great
that
we
are
coming
up
against
this,
but
we
shouldn't
necessarily
block
the
feature
on
it
like
at
least
not
if
it's
behind
a
feature
flag
as
well.
K
Like
we
have
just
modified
the
query
to
fetch
first
50
items
or
now
until
red
figures
out
to
reduce
the
complexity,
so
basically
we
had
fading
pipelines
just
to
basically
make
it
ready
for
merge,
because
we
don't
want
to
delay
this
mr
any
further
and
if
it
can
be
merged
behind
feature
flag,
even
with
the
limits
and
everything
in
place,
I
think
we
should
do
it.
Obviously,
once
we
remove
the
feature
flag,
we
can
definitely
have
either
the
pagination
implemented
or
the
complexity
remove.
Whatever
is
best
for
us.
J
K
K
Because
I'm
sure
there
are
plenty
of
Sepik
so
on
the
labrum,
where
we
have
more
than
hundred
direct
times,
because
I
believe
we
count
both
issues
and
epics
combined
as
a
child
of
any
ethic.
So
if
we
have
50
issues
and
like
from
the
hundred
attached
to
any
one
epic,
then
we
would
be
dealing
with
hundred
and
fifty
items.
So
in
that
case
we
are
essentially
hiding
the
results
beyond
hundred.
So
if
we
want
to
roll
it
out,
then
yeah.
The
initial
is
one
day
and
yeah.
E
A
A
L
K
K
And
as
Sean
of
us
gone
like
heavy
accounted
for
printing
diversity,
so
as
far
as
follow
up
on
the
following
shoe
is
concerned,
pagination
is
already
something
that
I
want
to
work
on
posting
before
we
one
implement
dragon,
because
there
we
are
basically
losing
the
results
so
and
as
far
as
front-end
effort
is
concerned
in
to
implement
the
Bey
generation.
Since
we
are
not
doing
any
UI
changes
like
we
are
not
showing
the
paging
bar,
where
we
have
with
the
previous
an
expert
on
send
it.
There
is
a
rather
a
straightforward
implementation.
B
K
K
A
Know
I
just
I
just
added
a
point
to
say
that
the
feature
fries
are
slightly
different
this
month
and
then
going
forward
in
that
we
are
going
to
deploy
to
get
lab
comm
at
least
once
a
week
and
then
whatever
is
deployed
on
get
lab
calm
on
the
20th
of
a
month
will
be
the
self-managed
release
for
that
month,
so
actually
stuff
will
get
to
production
sooner
like.
Hopefully,
we
reduce
this
whole
like
oh,
if
it
missed,
the
seventh
had
missed
everything
which
I
think
is
quite
a
harmful
model
for
us
at
the
moment
yeah.
A
So
you
can
make
that
in
mind
as
well.
I,
don't
know
if
I
she
changes
any
of
the
calculations
by
the
way
I
bring
it
up.
I
think
that
was
the
last
item
on
the
agenda.
Let
me
just
switch
back
to
the
dark.
Yep
great
well
have
a
great
day.
Everybody
thanks
for
joining
us
always
and
I'll
speak
to
you
soon.