►
From YouTube: Plan stage weekly - 2020-03-25
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).
B
First
yeah,
just
a
quick
on
you
probably
know
about
it
by
now,
but
it
is
team
day
or
what
would
have
been
team
day
contribute
so
we're
having
a
remote
team
day
instead,
all
day,
please
join
the
slack
channel,
arrange
games
with
your
teammates
when
you
have
free
time.
We
also
have
a
team
fortress
2
server.
Now
and
after
this
call
will
have
a
dedicated
zoom
room.
So
you
can
join
all
your
teammates
and
kill
them
yeah,
but
this
mark
you're
up
next.
D
Oh
yeah,
the
Service
Desk
is
moving
a
core
I.
Think
people
were
generally
aware
of
that
would
have
not
want
to
make
sure
every
knows.
What's
going
on,
the
real
idea
here
is
that
we're
trying
to
drive
adoption
for
the
Service
Desk
and
a
premium.
It
wasn't
really
a
compelling
factor
to
upgrade
to
premium
so
hopefully
with
core
we'll
get
a
lot
more
community
contribution,
which
would
be
excellent
and
we
can
kind
of
pursue
some
of
those
really
interesting
things
we
want
to
do
with
it,
based
on
the
community
contribution,
so
that'd
be
great
there.
D
Current
plan
is
to
move
the
entire
feature
of
what
we
have
thus
far,
because
basically
the
idea
would
be
if
we
want
to
build
on
top
of
it
later
and
put
those
at
higher
tiers.
We
would
do
things
like
have
a
web
interface
or
you
know
it's
something
like
that
and
we
might
put
that
in
starter
or
if
we
go
into
like
an
advanced
help
desk
situation,
where
we
can
have
knowledge
pages
so
as
people
type
in
questions
they
get
knowledge-based
articles
or
something
that
pop
up
out
of
our
wiki
or
those
types
of
integrations.
D
We
may
move
those
to
something
like
premium,
but
this
way
we
can
build
on
top
of
it
as
we
see
fit,
but
everybody
gets
the
benefit
of
having
it
in
core
and
sort
of
going
through
and
allowing
people
to
contribute
more
people
seem
to
really
want
to
contribute
to
it
too.
So
that's,
hopefully
that
will
encourage
that.
C
I
just
added
the
last
bullet
there
check
out
that
issue,
there's
actually
more
to
come
as
well,
nothing
to
action
on
now
like
we
don't
need
to
prioritize
anything,
but
a
group
of
people
have
been
looking
at
what
other
features
submitted
core
an
open
source,
so
there's
some
smaller
ones
like
related
issues
and
like
focus
mode
on
issue
boards.
That
will
eventually
pick
up
and
talk
about,
but
just
so
everyone's
aware
and.
B
The
next
item:
we
have
a
lot
of
issues
that
have
come
in
performance
issues
that
I
think
come
from
the
weekly
performance
board,
grooming
and
most
of
these,
if
not
all
of
them
are
project
management's,
but
I'm
kind
of
wondering
like
how
we
should
best
go
about
prioritizing
these
three
out
of
the
five.
Are
s
2
s
which
would
make
them
I
guess
high
priority,
but
we
also
have
to
you
know
this
may
be
a
different
scale
from
the
one
we
would
use
for
bugs
and
also
some
of
these
issues
will
have
multiple
fixes.
B
So
a
good
example
would
be
listening
projects
through
the
API
that
endpoints
is
slow,
but
it's
slow
for
a
number
of
reasons
and
it
degrades
with
the
number
of
projects.
So
there
may
be
multiple
fixes.
So
this
is
really
a
question
for
the
PM's
I
think
like.
How
would
you
want
to
prioritize
these
kinds
of
issues?
Is
it
one
per
milestone?
What
happens
when
we
have?
You
know
three
s
two
is
pop
in
at
once,
and
we
need
to
do
them.
You
know
within
potentially
within
sixty
days.
E
One
question
I
have
about
some
of
this:
like
have
we
verified?
This
is
the
first
time
I've
seen
issues
like
this
performance
issues
and
when
I've
seen
them
before
the
benchmarks
are
sort
of
like
not
realistic,
so,
like
I,
do
think
that
there's
performance
problems
in
the
product
but
like
how
can
you
weigh
in
or
like
how
realistic
are
these
based
on
the
scenarios
that
they
were
run
against?
You
know
like
who's
gonna,
create
200
projects.
E
B
Yeah,
that's
a
good
question:
I,
don't
know
what
I
don't
know
what
the
typical
like,
how
many
clients
would
be
running
a
self-hosted
instance
at
that
level
and
I,
don't
know
what
the
stats
are
AFRICOM
and
that's
at
any
time.
We
see
a
performance
degradation
like
the
I'm
thicket
of
I'm,
not
sure
which
issue
you're
referring
to
there,
but
the
one
in
particular
for
the
project
list
endpoint
that
degrades
exponentially
with
numbers
of
projects,
and
so
anytime
I
see
something
like
that.
It
rings
alarm
bells.
B
B
Yeah
I
haven't
seen
any
for
a
while,
and
this
like
gas
comes
from
so
if
the
issues
themselves
are
week
old
or
more,
but
they
get
groomed
and
trashed
and
once
a
week
they
ended
up
on
our
on
our
radar
and
I
think
this
is
probably
part
of
the
continual
improvement
of
the
quality
discipline,
unlike
the
new
kind
of
processes
that
they
have
as
possible.
We'll
see
more
of
this
in
future
weeks,
but
like
to
get
five
I
mean
these
came
this
morning.
So
to
get
five
from
one
goes,
it's
quite
long.
B
There's
also
the
thing
that,
like
the
protex
list
is
the
API
endpoint
is
slow
for
a
number
of
reasons.
It's
slow,
as
I
said
it
degrades
according
to
the
issue,
description
exponentially
with
the
number
of
projects,
but
also
degrades
if
you
use
certain
attributes.
So
if
you
put
owner
to
true
it
slows
down
quite
substantially,
those
are
two
separate
fixes,
potentially
multiple
fixes,
so
there's
also
the
possibility.
We
promote
some
of
these
things
to
epics
and
we
tackle
an
issue
at
a
time
until
we
get
the
thing
under
its
500
milliseconds
target
I.
F
Think
one
of
the
best
things
we
to
help
us
understand
it,
so
we
can
help
plan.
It
is
just
high-level
idea
of
how
big
it
is
like
each
of
these.
So
even
if
it's
just
like
t-shirt
sizing
waiting
that
we
just
do
in
the
comments
just
something
to
help
us
understand
how
big
day
they
get,
how
big
we
think
it
could
be,
and
then
you
know
balancing
that
with
the
most
severe
ones.
E
This
also
might
be
a
point
to
bring
up
our
prioritization
framework,
basically
I'm,
looking
at
that
in
handbook
right
now
in
performances
in
there
anywhere,
it's
like
a
thing
like
availability,
which
would
is
up
there
Security's
first
day
lost
second
availability.
Third
I
just
put
this
in
here,
but
I,
don't
see
that
performance
is
something
that
like
should
be
prioritized
higher
than
other
things,
so
I
think.
E
Also
I'll
I'll
make
a
note
to
follow
up
and
ask
about
like
the
business
impact.
If
that
makes
sense,
because
I
would
like
to
understand
like,
is
this
dependent
on
X
amount
of
large
25k
use?
Your
you
know
deals
that
we're
trying
to
work
on
so
I
would
like
to
have
that
information
as
well,
so
I'll
follow
up
on
each
of
these
issues.
To
that.
B
A
Think
we've
really
done
it
yet
so
I
want
us
to
start
doing
that
and
I
am
choosing
to
demo
one
and
typically
I'd
have
the
engineers
that
actually
worked
on
it
or
we'd
have
the
engineers
that
actually
worked
on
it
demo,
but
I
just
pinged
Kong
a
few
minutes
ago,
so
I
won't
make
him
do
that
I'll
just
go
ahead
and
demo
this
on
it
is
actually
let
me
share.
First.
A
All
right,
the
the
an
ability
to
edit
health
status
on
the
sidebar,
so
I
believe
I,
know.
Tong
worked
on
the
front
end
I
believe
Philippe
worked
on
the
back
end
primarily,
but
it
is
now
in
master,
it's
behind
a
feature
flag,
so
we
don't
see
it
anywhere
on
Colette
calm,
yet
I'll
go
ahead
and
demo
it
locally.
A
A
And
that's
that
component
next
issue
next
part
of
this
next
iteration
is
getting
this
to
actually
show
outside
of
issue
of
you
I'm.
So
if
we
go
into
a
big
tree
being
able
to
quickly
see
not
only
the
individual
statuses
for
issues
but
a
rollup
count
to
the
to
the
pair
of
epic,
so
that
should
be
we're.
Now,
it's
working
on
the
front
end
of
that
and
that
should
be
in
to
get
live
comm
by
twelve
ten.
E
F
G
G
F
E
Think
ever
the
next
item-
I
I,
split
up
in
ad-hoc
retrospective,
because
I
wanted
this,
like
I,
guess
talk
openly
about
some
challenges
that
I've
been
facing
is
a
p.m.
and
just
like.
It's
not
related
to
just
this
stage.
So,
like
I,
think
it's
a
it's
a
problem
that
I've
noticed
across
all
stages
and
as
I've
been
looking
at
like
open
issues
right
now
discussing
adding
more
kpi's
like
around
merge
request
efficiency
like
I,
think
like
I'm,
starting
to
see
this
paddle
like
we
have
engineers
who
were
working
at
him.
E
Merge
requests
and
EMS
who
were
working
on
issues,
and
we
have
everyone's
like
trying
to
do
their
best,
but
like
I,
would
like
us
to
start
working
together
to
figure
out
how
to
collaborate
together
more
effectively.
So
just
take
time
to
read
the
issue
and
some
of
the
things
that
have
been
linked.
Please
contribute
to
it,
and
collaborate
like
I
said
I,
think
John.
You
said
this
and
you
can
verbalize
it
to,
but
contrarian
opinions
are
definitely
welcome.
E
It's
just
the
sort
of
thing
where
I
would
like
to
figure
out
how
to
be
a
better
product
manager
for
our
stage
and
better
support
the
engineers,
but
ultimately
so
that
can
better
deliver
customer
value
and
business
real
business
results.
So
please
participate
and
I'm
thankful
that
you
will
hopefully
take
the
time
to
do
so.
B
Yeah,
like
there's
a
couple
items
just
but
yeah:
firstly
like
thanks
for
taking
the
time
to
actually
write
that
out
and
I
think
like
it
can
be
useful,
certainly
for
me
anyway,
to
get
the
perspective
from
your
point
of
view.
I
don't
think
it's
obvious
at
all.
High
motivations
can
be
different
for
different
roles
within
the
team.
B
From
the
point
of
view
of
delivering
things.
In
the
same
milestone,
we
have
a
lot
of
focus
on
iteration.
Currently
we
have
resources
in
the
handbook,
they're
being
gathered
into
training
issues,
and
that
is
kind
of
being
demoed
with
combinations
that
believe
of
PM's
and
EMS.
I
definitely
got
an
issue
anyway
and
I've
linked
it.
There
I've
also
iteration
officers
with
CID
later,
so
that's
probably
one
thing.
B
We
could
like
all
continually
improve
that,
but
I
do
think
that,
like
maybe
there's
some
kind
of
lesson
to
be
taken
from
the
JIRA
importer
in
the
way
that
we've
had
you
know
one
or
two
people
responsible
for
the
work.
We've
pulled
together
as
a
team
to
do
reviews
within
the
team
to
kind
of
monitor
progress
of
that
really
closely
and
to
kind
of
ruthlessly
manage
scope
to
try
and
make
make
up
and
we've
drawn
resources
from
elsewhere
to
make
that
happen.
B
B
F
Yeah
I
mentioned
this
yesterday,
but
I
thought
maybe
something
we
talked
about
in
our
meeting
and
just
talked
through
it
like
post,
milestone
or
trio
for
cleanup
like
when
we
have
issues
that
are
past
review,
like
there's
still
a
couple
items
still
signed
at
twelve
nine
and
their
verification
and
I'm
not
sure
if
that
means
that
we're
continuing
to
like
count
the
wait,
completed
finished
into
twelve
nine
or
if
we
should
carry
it
over
in
at
Oulton
I'm,
just
not
sure
I,
don't
I'd
like
we
should
talk
about
and
figure
out
what
we
want
to
do
with
that,
because,
at
least
for
me,
like
the
best
way
for
me
to
keep
track
on
where
stuff
is
without
bullion,
everybody
is
the
board
and
usually
I
scoped
my
board
back
to
the
current
milestone
as
soon
as
we
kick
it
off,
and
there
was
a
couple
items
missing
and
then
I
found
out
they're
still
in
the
twelve
nine
they're
still
signed
a
12-9,
so
I
just
wanted
to
open
up
a
conversation
on
how
you
want
to
like
the
data
milestones
ends
what
gets
moved
over
and
what
doesn't
I
guess,
if
you
guys
have
any
clarity
on
what
we're
doing
now,
or
maybe
we
haven't
thought
about
it
at
my
shirt.
A
A
So
I
think
the
problem
there
is
that
we,
so
if
something
is
pushed
in
12
nine
on
the
cutoff
day,
so
on,
say
the
18th,
it
may
not
show
up
on
gitlab
calm
until
the
22nd
or
so,
but
that
should
also
be
still
make
it
in
12
nine,
because
it
was
before
the
cutoff,
but
we
don't
verify
it
until
it
actually
shows
up
on
get
lab
calm,
so
I
think.
Maybe
if
we
on
the
22nd
I
think
by
the
22nd,
it
should
be
on
get
live
calm.
A
So
if
we
make
an
effort
as
a
team
to
everyone,
every
engineer
that's
responsible
for
or
that
is
still
the
assignee
on
an
issue
that
is
in
verification,
if
we
could
just
go
in
there
and
and
update
it
on
the
22nd,
if
it's
on
you,
let
that
come
and
close
it
out.
If
it's
not,
then
that
means
it
didn't
make
it
in
the
milestone
anyway.
So
let's
go
ahead
and
move
it
forward
to
the
next
milestone.