►
From YouTube: Plan | Weekly Planning 2020-09-02 (EMEA/AMER)
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
Hi
everyone
thanks
for
pushing
the
button,
whoever
did
still
getting
used
to
the
earlier
time
start
here.
Okay,
let's
go
ahead
and
start,
though
plan
stage
weekly.
A
This
is
just
three
recently
changed
to
what
do
we
call
now
plan
plan
stage,
planning
plan
stage
planning
for
september,
2nd
2020..
I
have
the
first
update
here.
Congratulations
to
julian,
who
is
now
a
full-time
front-end
engineer
on
the
plan
stage.
Super
excited
to
have
him
on
the
team
permanently
so
congrats.
A
B
Congratulations
to
elian,
yeah
nick
was
unable
to
attend,
so
he
asked
me
if
I
could
verbalize
this,
for
him.
Nick
will
be
transitioning
off
of
the
certify
as
the
designer
at
the
end
of
1304.
For
those
who
are
not
aware,
austin
will
be
transitioning
part-time
into
sport
plan
and
nick
and
I
have
been
working
and
will
continue
to
work
over
the
course
of
13-4
to
ensure
the
smoothest
possible
transition.
A
B
A
So
then,
when
you
say
austin's
coming
on
part-time,
does
that
mean
he'll
be
split
between
certifying
another
group.
A
All
righty
over,
but
someone
have
a
question
comment
or
over
to
gabe.
C
All
right,
I
just
I'm
gonna
miss
you
nick
you're,
watching
art
but
yeah
the
next
one.
I
think
this
is
more
a
big
picture
update
because
sometimes
it's
I
don't
like
pinging
everyone
all
the
time,
because
it
can
be
noisy
and
distracting.
So
I
figured
like
I'd
make
a
general
update
here
about
some
of
the
stuff.
That's
going
on
in
terms
of
other
groups
that
are
contributing
to
like
our
stage
vision
in
various
ways
as
there
is
natural
overlap
with
what
these
other
groups
are
trying
to
accomplish.
C
The
first
one
is
the
health
group
is
using
issue
types.
They
were
the
first
group
that
actually
implemented
issue
types
and
they're
kind
of
pushing
forward
with
that
for
incidents,
and
then
they're
also
going
to
be
looking
at
issues
like
widgets
and
and
like
just
generally
making
things
a
little
bit
more
extensible.
I
believe
we
were
talking
about
using
issue
types
for
test
cases
as
well.
So
that's
another
like
overlap,
it's
inner
stage,
it's
still
overlapping,
but
one
of
the
things
that
I
noticed
there.
C
That
would
be
helpful
for
us,
since
we're
kind
of
going
to
own
it.
Moving
forward
is
getting
the
reference
architectures
right,
so
those
other
groups
want
to
contribute
like
greenfield
widgets
or
these
things
to
support
their
jobs
to
be
done
in
their
use
cases
that
it's
built
in
a
consistent
way
that
works
across
all
issue
types
like.
I
noticed
as
incidents
we're
working
on
adding
a
widget
for
severity.
C
They
created
a
separate
data
model
and
kind
of
tightly
coupled
it
to
incidents.
But
when
I
look
at
things
when
I
have
like
a
bug,
issue
type
severity
would
be
a
very
important
like
widget
or
type
field
to
have
there.
So
just
to
help
with
that,
so
I
asked
jake
to
start
working
with
the
engineers
and
putting
together
some
reference
architectures
for
like
simple
things
and
complex
things
and
somewhere
in
between,
so
that
other
teams
can
kind
of
push
the
forward
push
forward
while
remaining
autonomous
and
unblocked
by
us.
C
So
that's
that
the
analytics
group
I've
been
talking
about
nick
post
is
the
interim
product
manager
there
they're
they're,
willing
and
interested
in
picking
up
velocity
and
adding
velocity
calculations
for
iterations,
which
is
something
that
was
on
a
road
map
that
we
were
going
to
do.
C
Probably
after
burn
down,
burn
up
charts,
so
they're
going
to
probably
pick
that
up,
and
then
we
also
through
that
conversation,
highlighted
that
right
now,
since
issues
can
be
closed
for
different
reasons,
and
sometimes
it's
because
they're
done
other
times,
because
they're
marked
as
duplicate
or
moved
or
just
not
completed,
we
need
a
little
bit
more
flexibility
with
our
issue.
Statuses,
so
also
our
map
was
making.
Issues
to
us
is
more
extensible
and
customizable
and
they're
going
to
do
the
first
nbc
with
adding
a
new
close
type
called
result.
C
So
you
can
resolve
an
issue
or
you
can
close
it
or
you
can
mark
it
as
duplicate,
but
that
will
also
impact
our
iteration
reports
and
milestone
reports
and
everywhere
anywhere.
We
basically
show
progress.
Reporting,
we'll
probably
only
want
to
include
those
issues
that
have
been
marked
as
resolved
instead
of
just
the
general
ones.
C
That
have
been
closed
and
then
yesterday
I
started
talking
with
the
source
code
group
about
making
reviewers
concepts
and
probably
approvals
available
across
all
issuables
they're,
pretty
far
along
with
it,
and
so
at
some
point
in
the
future,
we'll
probably
have
to
like
refactor
some
of
that
and
work
with
them
to
abstract
some
of
the
things
out.
That
should
be
shared
across
all
issuables,
but
there's
an
increasing
ask
for.
Can
we
have
design
reviews
on
issues?
C
Can
we
have
some
sort
of
approval
checkpoints
when
there's
a
bunch
of
merge
requests
that
are
on
staging
before
we
put
push
them
to
production,
that's
largely
for
compliance
related
organizations
or
larger
enterprises
that
want
to
more
tightly
control
for
legal
reasons
or
not
how
issues
go
through
a
given
workflow?
So
just
saying:
that's
all
stuff!
That's
going
on
that!
You
might
not
see
or
you
might
get
pulled
into
or
whatever,
but
as
best
we
could
support
those
groups
but
also
kind
of
maintain
some
sort
of
consistent
implementation
path.
C
C
No,
although
it's
labeled
as
next
up
and
it
would
be
kind
of
necessary
or
at
least
follow
quickly
with
the
velocity
which
nick
said
you'll
be
able
to
get
to
in
the
next
one
to
two
releases.
Awesome.
E
Cool
yeah,
it's
pretty
straightforward
item
like
eugenia
surfaced
this
issue,
the
group
sidebar.
We
currently
do
some
caching
on
the
project
sidebar
and
we
don't
do
any
on
the
group
sidebar
and
things
like
in
particular.
The
issue
count
is
quite
slow
and
it's
done
in
the
initial
page
load,
which
means
that
the
whole
page
is
quote-unquote,
slow,
so
yeah.
I've
wanted
to
ask
first
of
all
if
any
engineers
had
context
on
why
we
cached
the
project
sidebar
and
not
the
group
sidebar.
Are
there
any
blockers
that
you
know
of
that?
E
F
Sure,
yeah
I
mean
heinrich
mentioned
this,
so
I
take
no
credit
for
this
knowledge,
but
I
guess
the
when
you
the
group
sidebar,
if
in
each,
if
any
change
at
like
a
child
project,
you
know,
then
you
have
to
invalidate
all
the
caches
all
the
way
up
through,
rather
than
just
having
one
cache.
I
think
it's
a
little
bit
trickier.
F
I
think
I
think
it's
a
solvable
problem,
so
I
think
we
should
do
that,
and
I
think
this
this
would
be
a
huge
win
for
both
of
the
kind
of
like
pages
that
we
have
as
our
okr
for
performance
too,
and
just
a
general
performance
win.
So
we
should
figure
it
out
and
do
it.
I
think
it's
great.
C
I'll
just
verbalize
this,
I
think,
if
it's
a
smallish
fix,
we
should
do
it
now.
One
of
the
things
that
we're
really
exploring
in
the
simplify
groups
and
projects
working
group
is
smashing
groups
and
projects
together
into
one
thing
yet
to
be
named
largely
because
I
think
sometimes
we
found
that
stuff.
C
I
mean
you
can
read
the
problems.
I'm
not
gonna
go
over
the
problem
statement
again,
but
we're
getting
closer
on
solution,
validation
and
hopefully,
by
the
end
of
this
month,
we'll
be
at
a
point
where
we
kind
of
know
what
the
implementation
path
would
look
like
there,
but
alex
fully
from
manage,
has
been
working
on
that
and
he's
exploring
the
idea
of
wrapping.
C
What
is
now
a
group
and
project
with
some
thing
that
would
allow
all
features
to
be
available
within
that
thing
and
then
eventually
breaking
like
refactoring
the
stuff
to
pull
everything
out
of
groups
and
projects
into
this
thing
and
then
eventually
those
would
go
away.
So,
just
if
you're
interested,
you
can
hop
on
the
working
group
or
there's
a
slack
channel
for
it.
If
you
want
to
talk
about
stuff
or
brainstorm,
I'd
love
to
have
input
as
well.
E
No
not
on
hand,
but
I
think
eugenia
is
working
on
that
in
the
issue,
and
I
saw
some
figure
of
I
think
250
milliseconds
just
for
the
count
for
issues,
but
that's
quite
a
big
table,
and
that
would
be
the
longest
like.
That
would
be
that
we
would
expect
that
to
be
that
the
highest.
G
E
Yeah,
so
that's
what
I
was
thinking.
We
could
probably
measure
like
the
ratio
of
hits
to
the
sidebar
versus
the
number
of
times.
We
would
have
to
invalidate
the
cash
in
each
case
and
just
go
like
with
whichever
one
is
the
highest
ratio,
because
we're
most
likely
to
get
the
highest
reward
for
that
like
it
is
true,
though,
we
also
have
to
take
into
account
like
private
issues,
confidential
issues,
so
we
might
have
to
maintain
like
multiple
caches
or
something
I'm
not
quite
sure,
and
then
there's
also
russian
doll
cash
cashing.
G
Yeah,
historically,
one
of
the
reasons
why
I
think
we
didn't
catch
these
counts
was
that
we
historically
counted
precise
number.
So
we
took
into
account
the
user's
visibility
of
issues,
but
I
think
we
don't
do
this
anymore
and
if
we
can
ignore
any
permissions
check,
we
can
cache
this
on
application
level.
For.
E
Everybody
thanks
so
the
issues
there
like,
if,
if
anyone
can
contribute
to
even
if
we
could
get
an
idea
of
complexity,
then
that
will
help
us
get
some
of
the
work
scheduled
at
least
and,
as
gabe
said,
like
there's
trade-off,
depending
on
what
we
want
to
do
with
simplifying
groups
and
projects
but
like
ultimately
like
whatever
comes
out
of
that
group,
we're
probably
going
to
have
to
solve
some
of
these
problems.
E
Anyway,
like
say,
we
went
down
the
route
of
always
having
of
every
project
having
a
parent
group,
an
individual
parent
group,
then
we
would
have
to
solve
this
problem
anyway.
For
that
case,
as
well
so
yeah,
okay,
cool.
I
have
the
next
item
as
well.
It's
a
quick
one,
as
you
know
like
from
the
last
couple
of
stage
meetings.
We
have
a
test
efficiency.
Okr
we've
actually
met
the
original
goal
of
that
okr,
which
is
awesome
kevin
that
it's
only
month,
one
probably
means
the
okay.
E
Anyway,
we
have
a
pretty
cool,
mr
in
progress,
which
will
improve
test
efficiency
across
our
factories
by
using
something
called
parent
strategy.
I'm
not
going
to
explain
it
just
basically,
if
you're
writing
a
test
and
you
build
a
factory,
sometimes
it
will
create
the
the
parent
factory.
So
if
you
build
a
project,
it
will
create
a
namespace
which
is
not
necessary.
In
most
cases,
we
just
want
to
also
build
the
namespace,
so
we
can
avoid
databases,
peter
cut
the
mr.
Originally,
there
was
a
lot
of
pipeline
failures.
E
Those
were
fixed
by
heinrich,
there's
now
40
odd
commits
in
that,
mr.
They
need
to
be
pulled
out
reviewed
individually
before
we
can
merge
the
mainstay
of
that.
Mr
that's
all
so
all
you
have
to
do.
Is
cherry
pick
the
commit
site
get
them
through
the
review
process.
We
can
even
consider
them
reviewed,
just
need
maintainership
review
and
get
them
through,
and
once
we
have
them
through,
we
can
merge
the
mainstay
of
that.
E
Mr
and
time
is
a
factor
on
this
as
well,
because
new
tests
are
being
merged
in
as
time
goes
on
and
we'll
have
to
fix
those
as
well
before
we
merge
the
mainstay
document
so
yeah.
If
you
have
spare
time,
please
take
a
look
at
it
because
it
should
be
like
relatively
little
work
just
to
nurse
it
through
the
review
phase.
E
And
I
have
the
next
item
as
well.
Welcome
to
the
john
show
so
yeah
like
we're,
also
discussing
the
possibility
of
splitting
our
monthly
estimation
by
group
this
time
we've
been
through
this
a
couple
of
times
and
the
feedback
has
always
been
to
keep
it
as
a
stage
and
to
have
well.
We've
always
had
like
one
person
from
each
back-end
group
as
a
dri
before
we
moved
to
continuous
estimation,
now
we're
moving
away
from
continuous
and
back
to
a
monthly
rotation.
E
The
feedback
seems
to
be
that
engineers
would
like
to
actually
split
up
by
group.
If
you
have
a
view
on
this,
I've
linked
the
mr.
Please
take
a
look
at
it
and
weigh
in
otherwise
I'm
going
to
assume
that
all
the
feedback
is.
E
We
want
to
split
it
by
group
and
I'm
going
to
work
with
jake
to
actually
do
that
in
the
hamburg,
if
you're
curious
as
to
why
we
want
to
move
back
to
a
monthly
rotation,
it's
so
that
we
can
get
pm's
issues
weighted
by
the
13th
of
the
month,
so
they
have
a
better
idea
of
what
they
have
in
terms
of
points
to
spend
for
the
next
milestone.
E
It'll
never
be
perfect,
but
it's
an
attempt
to
improve
on
how
things
are
going
at
the
minute.
You
can
check
I've
linked
the
product
timeline
there
as
well.
So
if
we
get
this
to
a
good
place,
we
should
have
issues
by
the
fourth
and
I'll
be
asking
people
on
our
side
of
the
team
to
await
issues
on
the
fourth,
and
we
aim
to
have
them
done
well
before
the
13th.
To
give
pms
a
chance
to.
D
You
go
all
right
now,
so
I'm
gonna
highlight
two
portfolio
management.
You
know
metric
items,
so
we
had
four
and
a
half
percent
growth
and
self-managed
incidence
adoption
from
july
to
august,
which
is
pretty
great.
So
we
passed
the
thousand
self-managed
reporting.
Remember
we
only
get
20
about.
We
only
get
self-managed
data
from
about
27
30
of
the
instances,
so
that
number
is
lower
than
it
is
in
reality.
But
that's
what
we
have
as
a
reporting
number.
Oh
yeah,
not
self-managed
customers.
D
Those
are
self-managed
instances,
apologies,
which
is
a
that's
a
great
milestone
to
pass.
We
also
had
an
all-time
high
for
epic
creation
on
self
manage,
as
well
with
4
800
epics
created
in
july.
So
that's
great
good
work.
D
Well,
customers
can
kind
of
be
conflated
with
users
that
time
and
time
just
instance
is
a
little
just
more
clear
like
an
instance
that
has
the
usage
on
it,
but
yeah
that
makes
sense.
B
Yeah
great
news
from
the
certified
area
as
well.
We
have
181
reporting
self-managed
instances
that
are
utilizing
requirements,
management
in
august,
which
is
up
24
from
july,
which
is
huge
out
of
all
of
the
self-managed
instances.
Reporting
only
around
350
could
use
requirements
management
due
to
what
version
they're
running
so
about
half
of
those
who
could
are
again.
The
reporting
instances
are
a
subset
of
actual
instances,
so
it's
kind
of
hard
to
extrapolate.
B
But
this
is
the
best
we
have
right
now,
there's
also
a
13
increase
in
number
of
requirements
created
by
our
self-managed
customers,
which
is
excellent,
and
then
finally,
we've
seen
a
24
growth
in
the
number
of
projects
created
by
paying
instances
for
service
desk.
B
Now
we
saw
a
large
spike
in
the
number
of
instances
using
service
desk
on
the
whole
when
we
moved
it
down
from
premium
to
starter
or
from
ultimate
to
starter,
but
the
month
after
that
move
we're
still
seeing
a
24
increase,
which
is
fantastic,
so
we're
seeing
a
lot
more
use,
which
is
all
great
news.
So
thank
you,
everyone
for
all
your
hard
work.
It's
been
a
noticed
in
the
metrics,
which
is
great.
C
So
I
will
report
on
what
we
know
now.
We
don't
have
all
the
data
in
yet
because
they're
still
the
last
week
of
august,
it's
getting
processed,
it
should
be
done
in
the
next
seven
to
14
days
or
something
like
that,
but
35
self-managed,
gmail,
improvement
for
and
those
that's
folks.
Creating
issues
at
this
point
I
think
we
have
heinrich,
is
working
on
an
issue
to
add
more
event
tracking
so
that
we
can
switch
to
that
gmail
being
based
on
anyone
who
interacted
with
an
issue
like
comment.
C
Labels
created
one
edited
description,
that
sort
of
thing
and
then
the
paid
gmail
should
be
taken
with
grain
of
salt.
I
continue
to
see
this
really
weird
trend
right
now.
The
day
is
telling
me
that
we
had
a
decrease
at
200
now,
which
would
be
only
like.
You
know,
a
sixth
of
a
percent,
but
the
thing
that
is
interesting
and
like
I'll
show
this
just
so
folks
can
kind
of
reference
where
how
basically,
how
flaky
I
think
these
metrics
are.
C
This
is
like
a
table
that
shows
you
the
total
license
instances
and
then
those
that
have
cust
that
have
usage
being
enabled.
So,
like
there's
been
this
continued
trend,
where,
like
you
know,
I
think
from
six
seven
we've
lost,
we
lost
some
instances
for
whatever
reason
they
just
turned
it
off.
We
don't
know
yet
I'm
still
working
with
data
team
to
figure
out
how
we
can
determine
that
but
and
the
usage
being
like,
grew
just
a
little
bit.
C
But
then,
when
we
look
at
this
month
so
far
we
have
basically
we
agree
the
total
number
of
licensed
instances
by
30,
but
the
overall
pings
enabled
dropped
by
25
down
to
only
28.9
percent.
So
what
this
is
basically
saying
is
you
know,
71.1
percent
of
our
licensed
users
are
not
giving
us
any
data,
so
take
it
with
a
grain
of
salt,
because
all
the
customers
that
I
talk
to
that
use
plan,
don't
have
usage
being
enabled.
So
you
know
it
is
what
it
is.
B
The
other
thing
to
note
for
all
of
our
metrics
that
the
vms
are
presenting
here
is
we
don't
know
it's
not
easy
to
know
which
28
are
reporting.
Are
they
the
large
instances,
the
medium
instances
or
the
small
instances,
so
it
gets
very
conflated
if
you're
trying
to
figure
out
number
of
users.
If
you
know
of
those
28,
none
of
them
are
our
large
enterprise
type
users.
Then
we're
really
only
representing
a
very,
very
small
portion
of
our
users
and
there's
no
easy
way
for
us
to
determine
that.
B
A
Cool
well
thanks
for
showing
those
it's
definitely
even
though
the
data
is
kind
of
hard
to
validate.
I
guess
it's
still
nice
seeing
those
those
numbers
and
those
increases.