►
From YouTube: Plan Stage Weekly 2020-04-14
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
She
even
noticed
she's
not
going
to
be
here,
so
it's
read
only,
but
it
looks
like
some
praise
for
this
kr:
improving
visibility
of
system
status
and
system
performance.
A
Cool,
does
anyone
have
visibility
over?
This
could
speak
a
bit
about
it.
C
I'm
not
familiar
with
her
specific
changes,
but
I've
been
working
on
similar
changes
and
I
would
echo
the
sentiment
that
everyone
has
been
really
attentive
and
jumping
on
these
as
we've
been
flagging
them
because
it's
a
uxkr.
So
thank
you
all
so
much
for
being
attended
to
this.
B
Sure
yeah,
just
in
case
you
haven't
seen
it
the
the
sad
news
is
that
we're
loaning
heinrich
over
to
the
db
team,
for
I
have
the
issue
link
here.
B
The
next
three
releases,
they're
kind
of
splitting
the
database
team
into
two
teams,
one
to
focus
on
sharding,
which
is
like
a
massive
effort
which
I
think
they're
still
kind
of
like
in
the
figuring
out
phase
of
determining
how
that
will,
how
that
will
work
and
how
that
will
help
and
how
to
even
approach
that
so
some
of
the
sort
of
more
experienced
database
engineers
are
moving
over
to
work
on
that.
And
then
we
are
they're
kind
of
backfilling
temporarily.
The
the
database
team
with
folks
from
other
teams,
including
heinrich.
B
So
it's
unfortunate
for
us,
but
it's
also
really
important
stuff
for
gitlab
to
you,
know,
succeed
and
get
past
some
of
these
trickier
trickier
database
scalability
issues
that
we've
been
running
into
so
with
regards
to
the
real-time
subscription
work
that
heinrich's
been
working
on
recently.
B
The
goal
is
to
get
that
into
get
that
through
through
review
and
merged
here
in
the
next
week,
or
so
so
that
we
can
kind
of
at
least
have
that
ongoing
piece
at
a
point
where
it
makes
sense
before
he's
sort
of
off
the
team
for
for
several
months
and
similarly
with
the
smtp
connection
pooling
stuff.
That
he's
worked
on
he's
that's
on
production,
but
there's
some
omnibus
and
a
couple
other
things
to
like
config
changes
to
wrap
up
before
that's
closed
out.
B
B
Yeah,
I
mean
it's
full-time
he's
still
reporting
to
me,
so
we'll
still
talk
and
like
he's
generally
everywhere,
like
he
generally
tends
to
weigh
in
on
on
stuff
like
this,
so
I
wouldn't
hesitate
to
to
ping
him.
You
know
things
like
the
relative
positioning
stuff
that
you're
working
on
he'll
still
be
around
to
talk
through
and,
and
you
know,
we're
not
gonna.
I
I
in
some
ways
other
than
like
the
specific
work
that
comes
out
of
plan.
B
I'm
sure
the
the
you
know,
social
and
collaborative
aspect
of
having
him
on
the
team
won't
change
too
much,
because
he'll
still
be
paying
attention
to
this
stuff.
A
D
Know
if
that's
feasible,
like
shots
like
I
don't
have
a
very
dependent
setting
but
highly
is
like
very
hard
to
communicate
between
shards.
I
think
it's
like
somewhat
expensive
sort
of
thing.
So
when
you
shot
something
is
more
like
you
treated
more
of
a
like
a
separate,
at
least
as
a
separate
table,
if
not
as
a
separate
context
of
here,
maybe
like
a
database
or
something
like
that-
not
100
sure
of
that.
E
I
I
mean
there
might
be
a
couple
that
we
don't,
but
when
you
think
about
custom
issue
types
like
right
now,
we
only
have
like
three,
but
in
the
future
there
might
be
15
right
because
the
customer
might
make
their
own
and
so
for
those
you're
going
to
want
to
show
them
all
in
the
same
list
and
also
I
I
haven't
gotten
any
feedback
that
folks
don't
want
things
in
boards
as
well
like
they
want
incidents
and
boards.
They
want
requirements
and
boards.
E
It's
just
because
it's
a
way
to
visualize
work
right,
and
so
that's.
Why,
like
I,
I
don't
know
if
sharding
would
work
for
issue
types,
but
I
I've
not
my
call.
A
E
About
it,
what
if
you
want
to
what?
If
you
want
a
group
like
right
now,
we
have
swim
lanes
for
epics,
but
I
could
see
it
valid
being
having
swim
lanes
for
requirements.
E
So
you
can
see
all
the
issues
that
are
implementing
a
requirement,
for
example,
or
you
might
want
to
have
just
you
might
want
to
have
just
requirements
on
your
board,
but
you're
you're,
going
to
maybe
want
to
expose
like
a
bit
thinking
long-term,
maybe
and
mars,
that
are
related
to
it
or
something
like
that
that
are
going
through
different
workflow
stages.
E
So
requirements
is
the
only
one
where
it
may
not
make
the
most
sense,
but
I
know
test
cases.
People
are
using
issues
for
that
right
now,
we'll
import
a
bunch
of
stuff
create
a
board
for
a
specific
release,
put
out
dump
all
their
test
cases
in
there
and
then
move
issues
through
different
lists.
Basically,
so.
E
A
Yeah
it's
interesting
yeah,
so
I
wonder
if
this
new
sharing
team
will
take
input
from
us
or
whether
they'll
analyze
the
databases
and
queries
going
to
the
database
that
we
already
make
and
make
decisions
on
where
to
shard
from
that,
because
we're
in
the
middle
of
bringing
in
issue
types.
So
things
could
look
very
different
in
12
months.
D
Like
a
good
shouting
might
be
separating
closed
or
done
issues
from
open
issues
or
something
so
it's
more
of
like
moving
the
archived
one
that
you
don't
you're,
not
really
interested
into
out
of
the
out
of
the
querying
sort
of
space.
So
you
kind
of
query
less
issues
than
then
then
you
have
to
play
with
otherwise,
perhaps.
E
I
was
also
going
to
say
I
do
think
the
sharding
team
from
the
conversation
brief
one
that
I
have
with
christopher
holtz,
is
taking
into
account
where
we
want
to
go,
not
where
we're
at
today.
E
So
he
asked
me,
I
guess
it
was
march
25th
he's
like
where,
like
what,
what
what's
the
architecture
frozen,
move
towards
for
product
planning
or
like
for
a
plan
as
a
whole,
and
they
said
like
hey,
we
want
to
like
consult
everything
down
in
types
of
issues,
we're
going
to
eventually
consolidate
a
group
of
projects
in
the
same
entity.
That's
possible
and,
like
kind
of
you
know,
he
didn't
say
anything
back
to
that,
but
he
asked
so.
I
told.
F
F
I
would
expect
that
for
our
purposes
it
would
make
more
sense
to
do
sharding
per
top
level
groups,
because,
most
typically,
we
list
resources
by
group
or
any
descendant
groups
or
epics.
So
we
are
almost
always
limited
by
the
group.
We
are
working
in
not
sure
if
it
will
be
reflected
for
sharding,
but
I
can
imagine
that
this
would
make
most
sense.
A
F
Mean
sharing
across
charts
should
be
still
possible.
It
might
not
be
just
so
performant
because
we
already
link
resources
across
different
groups
like
if
you
link
labels
from
completely
different
group,
it's
still
possible
or
issues
but
yeah.
It
would
perhaps
it
wouldn't
be
just
so
performant,
but
it
still
must
be
supported.
B
I
think
I
think
it
will
well.
I
saw
under
issue
specific
discussions
and
demos
beyond
this
point,
so
we
can
get
to
that,
but
it'll
be
interesting
to
see
how
all
of
these
databases
change,
like
we're.
B
There's
significant
plans
for
the
database
to
change
architecturally
like
over
the
course
of
the
next
several
months,
and
those
things
may
make
it's
a
frightening
scenario
to
have
like
these
massive
changes
to
the
database
architecture
happening
while
we're
also
trying
to
make
significant
change
to
the
application
like
whether
it's
consolidating
groups
and
projects,
so
I'm
just,
I
guess,
more
eager
to
see
what
their
plans
are
for
the
sharding
stuff
and
how
that
will
work,
which
it
sounds
like
gabe
had
some
of
that
conversation
before
so
we'll
we'll
see
but
yeah,
it's
gonna
be
something
just
stay
on
top
of,
I
guess
for
us,
and
every
team,
probably
we'll
we'll
suffer
some
pain
from
it.
D
I
don't
think
we're
yet
at
the
point
where
we
have
to
shark
issues.
I
think
that's
more
of
a
issue
with
the
ci
deals
as
long
as
they
have
so
much
more
data
there
that
and
there's
a
lot
of
it
is
also
like
coming
obsolete,
very,
very
fast
right.
You
run
a
bill
then,
like
next
day,
you
mostly
don't
need
it
or
something
like
that.
So
that's
more
of
an
issue
there,
but
not
so
much
for
the
for
the
issues.
A
Just
on
that,
like
the
it's
not
typical,
probably
for
most
customers,
but
if
you
view
the
gitlab
org
issue
list
and
you
order
it
by
anything,
I
think
other
than
created
that
well,
I
ordered
it
by
popularity.
The
sql
query
takes
10
seconds
to
return,
and
that
happens
in
the
initial
page
load.
So
yeah,
it's
like,
I
said,
not
indicative
as
we're
probably
the
largest
user
of
gitlab.com,
but
we're
definitely
getting
to
the
point.
I
think
where
we
we
need
to
look
at
the
issues
table.
E
Yeah
I
wanted
to
start
the
conversation
now
I
I
know
I
scheduled
a
meeting
I
think
next
week
to
talk
with
some
of
the
designers
and
at
least
the
ems.
In
my
stage,
john
you're
welcome
to
join
if
you
want
as
well,
but
just
about
14.1.
E
I
know,
for
my
team
at
least,
and
I
think
kristin
and
mark
are
largely
on
board,
as
well
kind
of
looking
at
pausing
sort
of
new
feature
development
from
like
a
capability
standpoint
and
spending
several
releases,
refactoring,
paying
down
technical
debt,
paying
down
product
debt
and
then
laying
like
the
proper
groundwork
for
converting
plan
objects
to
issue
types
and
extensible
issues
like
we
sort
of
need
to
get
the.
E
And
so
it's
not
just
like
the
goal
is
not
just
to
do
that
work,
but
also
it's
like
really.
We
have
recruit.
You
know
not
just
performance
problems
but
technical
debt
and
that's
not
a
bad
term.
E
It's
like
we've
made
decisions
to
move
faster
over
a
more
complete
code
or
whatever
we
want
to
do,
and
I
think
it's
caught
up
with
a
little
bit
and
I've
noticed
and
heard
from
the
engineers
that
it's
taken
it's
taking
longer
to
make
changes,
which
is
also
a
good
sign,
that
we
need
to
slow
down
and
go
back
and
fix
some
of
that
stuff.
So
all
that
said,
I
wanted
to
start
asking
the
engineers
for
input
on
what
what
areas
of
the
product
that
is
our
surface
area.
E
Do
we
need
to
focus
on
paying
down
technical
debt
refactoring
certain
things
making
it
so
future
changes
are
easier
and
just
start
thinking
about
if
we
are
to
take
this
like
period
of
time
and
pause
like
our
sort
of
like
our
feature
roadmap,
like
you
know,
I
want
to
do
velocity
for
iterations
like
pushing
that
stuff
out
into
the
future,
so
that
we
can
get
the
right
foundation
in
place.
E
What
would
that
look
like,
and
what
would
you
all
like
to
focus
on
because
I
wanted
to
be
like
everyone
provide
input,
so
there's
some
other
things
too,
like
you
know
for
proposing
a
new
issue
view
largely
because
we
also
want
to
build
a
single
view
app
for
the
issue
view,
and
I
think
that
will
help
with
performance
and
other
things.
E
But
if
we're
going
to
have
to
refactor
that
whole
view,
we
might
as
well
like
take
the
time
to
make
any
ux
changes
that
we
want
to
make,
among
other
things,
so
there's
a
lot
of
things
moving
forward.
Nothing
has
been
sequenced
or
like
decided
on
I'm
more
or
less
trying
to
collect
a
bucket
of
all
the
things
that
we
want
to
accomplish
during
that
period
and
then
work
with
engineers
and
ux
to
figure
out
the
optimal
way
to
sequence
them
into
different
themes
and
like
share
the
workload
over
a
couple
releases.
E
So
that's
just
like
a
general
announcement.
I'll
drop
an
issue
to
a
specific
epic
and
plan
later
today.
Once
I
create
it,
I'd
like
to
just
start,
collaborating
there
and
invite
everyone
to
provide
feedback
and
to
list
out
the
things
that
you
notice.
That
really
need
to
be
improved
upon
or
cleaned
up.
G
Thanks
gabe,
I
am
added
here
a
link
to
a
spreadsheet
that
might
help
you
visualize
the
convergence
between
all
of
the
different
plan
objects.
There's
we
do
have
a
lot
more
going
on
around
extending
issues
as
well
as
the
design
of
them,
but
this
can
help
us
sort
of
look
at
the
metadata.
That's
there.
I
know
I've.
I've
mentioned
this
spreadsheet
before
I
think
also
gabe,
I'm
not
sure.
G
If
you
mentioned
this,
but
we're
talking
about,
I
think
you
touched
on
it,
but
a
design
focus
for
four
to
six
weeks,
working
ahead
of
engineering
to
try
to
figure
out
not
only
the
design
of
the
app,
but
also
just
what.
If
we
look
at
the
spreadsheet
like
what
are
the
required
fields
essentially
for
each
issue
type
and
which
view
will
be
the
first
one
we
work
on
whether
it's
gabe,
I
think
you
mentioned
the
the
view
on
a
board
like.
G
A
sidebar
and
then
port
that
over
to
the
actual
issue,
page
or
epic,
epic
page
or
if
we
start
on
something
like
epics
or
start
on
requirements,.
E
Yeah,
I
think
we
can
sort
that
out
and
that's
why
I
invited
engineers
to
come
to
like
the
the
design
phase
as
well
and
participate
in
that,
so
they
can
give
us
guidance.
E
E
E
D
Yeah
to
the
least
the
issue
to
the
least
of
what
needs
to
be
refactored
or
worked
on
sort
of
on
my
technical
catching
up.
I
was
just
like
it's
something
that
is
on
my
mind
for
the
last
few
weeks
with
the
relative
position,
so
I
was
just
throwing
that
out
there,
but
nothing
specific,
really
just
mentioning.
F
Out
of
curiosity,
as
we
are
talking
about
relative
positioning,
how
realistic
would
it
be
to
switch
to
pair
board
position
for
issues
in
any
near
term,
because
I
expect
we
would
have
to
do
this
if
we
want
to.
D
D
F
So
yeah,
the
idea
was
that
for
epic
boards
it
was
explicitly
requested
to
have
it
per
board,
and
if
you
would
make
a
big
issue
type,
it
would
mean
that
it's
just
another
issue.
So
then
there
would
be
some
inconsistency
between
these
types,
so
we
will
have
to
decide
whether
we
want
to
switch
to
global
positioning
for
epics
or
to
purport
positioning
for
issues
unless
we
want
to
keep
different
positions
for
different
types.
But
perhaps
this
is
something
to
figure
out
later.
E
I'll
I'll
say
my
two
cents,
I
think
it's
something
that
we
should
think
about,
especially
as
we're
refactoring
some
stuff
and
maybe
even
like
spend
some
good
design
time
solving
for
like
right.
Now,
I'm
struggling
with
the
fact
that
epic
epic
boards
have
their
own
position,
because
when
I
have
like
when
I've
looked
at
an
epic
board-
and
I
see
like
you
know,
items
that
are
on
there
in
a
certain
order,
like
maybe
I
have
things
epics
that
are
like
workflow
like
in
development,
are
happening.
E
And
then
I
go
to
the
my
issue
board
and
I
turn
on
swim
lanes
nothing's
in
that
same
order
and
it's
like
sort
of
jarring,
and
I
can't
like
flow
through,
like
basically
zooming
in
and
out
of
planning
artifacts
in
a
way
that
keeps
things
in
a
sane
like
organization
structure
and
then
also
I
do
switch
between
four
different
board
views,
which
is
like
a
list
that
has
our
team
lists.
It
has
like
iteration
lists.
E
One
board
has
milestone
lists
and
another
board
is
like
our
workflow
board,
but
I
do
think
there's
an
opportunity
to
figure
out
how
to
save
ordering
across.
Like
a
number
of
views
without
being
global,
if
that
makes
sense
like
to
to
everything
in
the
group
so
like,
if
there
was
a
way
where
we
had
a
a
board
that
you
could
like
have
these
different
save
views
with
these
different
lists
like
technically
they're
they're,
individual
boards
right
now,
but
really
they're.
E
What
are
now
separate
views
could
solve
the
problem
because
the
ordering
would
be
still
localized
to
whatever
those
sets
of
views
that
I'm
looking
at
are
so
that
could
be
an
opportunity
or
way
to
solve
it.
I
don't
know
how,
but
I
think
we
should
also
consider
that
from
a
product
standpoint,
because
it
does
make
sense.
F
Yeah,
that's
a
good
plan.
Would
you
mind
to
create
an
issue
or
suggestion
for
this
bot,
local
or
semi-local
positioning?
So
we
can
think
about
it.
I
I
know
jaraka
is
working
on
positioning
for
very
epic
boards,
so
ios
we
will
think
about
it
later,
but
perhaps
something
to
be
aware
of
because
there
are
also
some
complications
with
parabola
positioning
so.
G
This
is
a
much.
This
is
a
different
idea
entirely,
but
I
do
think
we're
seeing
more
and
more
where
you
might
want
to
have
a
really
specific
query
or
a
specific
sort
order
and
then
view
it
as
roadmap
view
it
as
board
view
it
as
list,
and
I
think
where
we
need
to
be
more
flexible
with
boards.
G
E
All
right
I'll
open
up
the
issue,
and
then
we
can
all
start
kind
of
talking
there.
I
don't
have.
I
don't
know
what
the
solution
is
in
my
head.
Sometimes
I
I
do,
but
that's
where
I
think
it's
really
going
to
be
a
team
effort
and
largely
ux
driven.
E
I
mean
we
can
kind
of
come
up
with
some
requirements,
but
it's
like
a
it's
a
different
way
to
think
about
our
product,
but
I
do
think
the
constraint
of
like
how
can
we
make?
How
can
we
get
rid
of
global
relative
positions,
but
maybe
have
like
a
smaller
version
of
that?
It's
like
unsafe
is
a
very
viable
path
to
look
at
so
we'll.
E
You
do
that
too,
but
there's
also
problems
with
that,
like
that's
where,
when
I
when
I
joined
gitlab,
I
was
super
frustrated
because
it
was
like.
I
had
my.
I
didn't
know
about
that
at
the
time
and
I
like
organized
the
board
and
then
I
went
and
looked
at
a
day
later,
and
everything
was
like
all
over
the
place
and
I
was
like
hey:
did
somebody
touch
the
board
they're
like
no?
I
was
like
well
what
happened
they're
like
oh,
it's
like
global
ordering.
E
F
Supposing
that
the
goal
is
to
just
have
one
container
entity
in
future
instead
of
having
both
projects
and
groups.
So
there
doesn't
seem
to
be
a
some
clear
solution
for
this
and
so
far
it
rather
seems
that
we
would
keep
maintaining
bots
so
it
so.
F
This
will
have
impact
on
many
upcoming
features
or
proposals
specifically
to
issue
types
to
resource
sharing,
and
perhaps
some
others.
So
if
you
have
some
the
main
problem
for
not
doing
this,
consolidation
is
that
this
will
be
quite
difficult
and
it
means
to
introduce
a
big
technical
debt
for
a
long
time,
because
the
deprecation
can
happen
only
in
six
months
or
more,
and
during
this
time
we
would
have
to
maintain
hex
or
workarounds
in
our
code,
and
there
is
quite
a
resistance
to
go
down
this
path.
F
E
I'm
going
to
say
out
of
the
technical
decision
for
that
one.
So
I
kind
of
left
a
note
there
about
my
standpoint
from
like
a
philosophical,
slash,
proc
position
longer
run
well,
I
think
we
need
to
consolidate
it,
but
if
we
don't
end
up
doing
that,
we
do
some
sort
of
other
like
abstraction.
E
It
is
what
it
is,
but
I
did
surface
this
with
david
de
santo,
along
with
the
workspace
stuff
just
saying
like
hey.
This
is
something
that
we
wanted
to
invest
in
an
fy
22.
from
proc
standpoint.
It's
not
moving
very
quickly.
I
don't
think
there's
a
clear
path
forward
like
we
either
need
to
decide
to
do
it
or
not.
E
Do
it
and
tim
zalman
said
that
he
is
supportive
of
the
goals
and
and
like
is
going
to
commit
to
like
helping
push
it
forward
and
figuring
out
what
that
looks
like
from
the
engineering
side.
So
I
don't
know
what
all
that
means.
We
basically
just
can't
jeopardize
the
the
database
work
that
we're
doing,
but
both
can
be
done
in
parallel,
and
I
think
there
might
even
be
some
benefits
to
the
database
stuff
in
the
long
run.
E
F
Cool
yeah,
I
think
that's
yeah
if
it
means
convincing
some
other
in
yeah.
This
way
might
be.
Another
approach
might
be
to
just
breaking
some
rules
which
were
settled
in
the
discussion
so
far,
so
we
don't
want
to
introduce
other
naming
or
other
entity
like
workspace.
We
don't
want
to
introduce
some
long-term
technical
debt.
So
if
we
can
break
some
of
this
rule,
then
yeah
it
would
be
a
way
forward
too.
E
Yeah,
the
other
thing
I
was
going
to
add
is
like
I
think
the
the
fear
is
just
the
long-running
technical
debt
that
and
we'll
like
have
to
stop
in
the
middle,
and
I
think
that
what
I'm
trying
to
do,
at
least
from
like
my
angle
of
things
is,
is
helping
alleviate
this
by,
like
ensuring
the
whole
organization,
is
behind
the
effort
and
committed
to
doing
their
part
when,
when,
when
the
time
comes
so
that
way
like
if
we
do
choose
to
take
on
some
of
this
type
of
that,
we
have
confidence
that
we're
gonna
see
it
through,
and
we
have
backing
of
like
our
entire
leadership
level.
E
That's
part
of
the
reason
why
I
started
is
the
working
group
and
and
like
went
up
in
that
hit,
presented
the
system
and
said
hey
like?
Is
it
okay?
If
we
consolidate
these
down
like
do
we
have
your
approval,
because
I
definitely
could
be
the
dri
for
that
and
he
was
supportive
of
it,
but
I
think
now
we're
sort
of
getting
the
point
where
we
are
starting
to
do
the
work
and
we
need
to
get
like
get.
E
F
Yeah,
at
least
there
is
no
yeah,
I'm
not
aware
of
of
not
technical
that
approach
we
could
use.
F
Introducing
a
new
new
entity
to
which
we
would
slowly
migrate
would
be
would
be
less
technical
depth,
because
this
new
entity
would
be
basically
the
end
state.
We
want
to
reach
here
so,
but
the
problem
is
that
there
was
pushback
against
introducing
new
entities
instead
of
the
existing
ones.
F
Oh,
you
mean
on
backhand
side
yeah.
Basically,
namespace
is
namespace
system
for
both
personal
link,
spaces,
which
are
namespaces
and
groups
which
inherit
from
blank
space.
D
So
when
a
user
creates
projects
in
like
that
are
his
personal,
they
go
to
a
sort
of
a
personal
group
that
is
called
a
namespace,
and
then
you
have
the
group
entity
as
as
it
is
so
like
on
the
back
end,
it's
pretty
much
the
same
thing
with
the
slide.
It's
just
the
difference
in
type,
but
it's
backed
by
the
same
database
table.
E
Yeah
it
does
it
there's
also
some
weird
behavior
in
personal
name,
spaces
and
group
name
spaces,
especially
from
like
a
billing
perspective
that
I
think
I
was
talking
to
jeremy
before
he
left
and
he
said
affect
the
way
of
magic
wand.
I
would
make
every
personal
name
space,
be
a
group
basically
so
behaved
the
same
way
and
I'm
wondering
if
there's
like
a
way
that
we
could
more
or
less
make
make
a
project
a
name
space
and
then
move
everything
into
the
name,
space
level
and
out
of
the
group
in
the
project
level.
D
D
Do
we
have
some
sort
of
a
direct
relationship
between
groups
and
subscriptions
where
how
do
you
account
for
that
and
then,
if
you
make
a
username
space
into
a
group,
how
does
that
fit
into
the
into
the
whole
building
structure
right,
but,
like
other
than
that,
making
the
names
the
username
spaces
b
groups
is
not
a
big
issue
whatsoever
is
just
really.
How
does
that
play
out
with
the
building?
How
do
we
separate
those
from
not
being
built
that
we're
backwards
compatibility
and
so
on.
E
G
Yeah,
so
I
just
linked
to
our
march
update
for
the
epics
and
if
everyone
wanted
to
see
it,
I
noticed
that
we
passed
100,
000
epics
created
cumulative
cumulatively
on.com,
which
is
really
cool,
and
also
we
had
two
significant
months
of
growth
40
month
over
month
on
just
epic
creation,
the
link
to
there's
a
link
from
the
chart
actually
or
from
that
handbook
page
that
shows
to
sizes,
but
also
the
100k
cumulative
epics,
which
is
pretty
cool.
G
A
G
G
But
it's
exciting
and
it'll
be
interesting
to
set
the
next
targets
for
the
team,
because
also
this
data.
If
you
look
at
the
chart,
this
is
just
on
epic
creation,
not
on
all
of
the
aggregates.
So
like
this
all
the
work
that
we
just
did
to
have
all
the
event
tracking
added
we're
gonna
augment
this
chart
and
it
should
go
up
even
more
so
we'll
have
anytime.
Someone
interacts
with
an
epic
will
influence
this
gmail
number
as.
E
E
D
Okay,
I
was
just
wondering
if
we
know
if
this
growth
in
epic
creation
is
more
of
like
the
same
users,
creating
more
epics
or
more
more
of
more
users,
creating
epics
overall.
G
D
G
G
E
I'm
just
gonna
add
that
I'm
gonna
use
epic
boards
exclusively
once
they're
ready.
That's
also
where
I'm
keenly
like
interested
in
solving
the
problem
of
switching
between
an
epic
board
and
my
issue
board
with
swim
lanes
with
epics.
So
you
can
like
visualize
like
your
epics
and
where
they're
at
then
you
can
like
transition
into
like
the
workflow
for
each
thing,
but
I
also
wanted
to
I
don't
know.
If
you
all
saw,
I
can't
remember
who
posted
slack.
E
If
you
did,
you
can
take
credit
for
it,
because
I
just
read
somebody
else's
great
observation
that
epics
the
nbc
for
boards
was
the
most
clicked
item
in
the
last
release.
I
think,
out
of
every
other
feature
that
we
shipped,
then
that
releases
a
company.
So
it
is
very
much
highly
anticipated.
E
One,
lastly,
I
don't
need
to
spend
a
ton
of
time
on
this,
but
I
did
drop
in
a
link
to
the
project
management,
pi
updates.
We
are
on
track
to
hit
our
free
and
paid
targets.
We've
already
hit
our
free
targets.
E
I
think
we're
about
5
000
miles
short
for
our
paid
targets
with
one
reporting
period
left,
which,
if
monthly
growth
of,
is
any
indication,
we
should
barely
hit
our
paid
target,
but
part
of
the
reason
why
I,
like
our
usage
being,
is
down
a
little
bit
like
there
was
a
seven
seven
point
drop.
E
I
think
there
was
thirty
nine
percent
of
instances,
reporting
usage
being
the
previous
release
or
the
previous
reporting
period,
and
this
time
there
was
only
thirty
six
percent
and
then
also
the
end
of
life
for
starter,
like
basically
that
was
one
of
our
kind
of
big
growth
tiers.
It's
basically
that
growth
is
stalled
out
and
even
declined
on
sas,
and
we
haven't
seen
that
same,
like
all
those
users
haven't
transitioned,
basically
over
to
premium
right
now,
and
so
we'll
adjust
our
targets
for
next
month
to
take
that
into
consideration.
A
D
Yeah,
I
was
just
fun
to
give
more
of
a
heads
up.
I'm
I'm
suspicious
that
1311
will
be
lighter
in
futures
just
because
of
the
focus
on
the
performance
stuff,
but
I
was
really
hoping
to
get
iteration
currencies
and
automation
out
in
this
release.
But
it
doesn't.
D
So
yeah,
that's
one
item
on
my
list
that
I
want
to
get
to,
but
it's
really
behind
more
of
a
more
work
on
relative
positions
and
and
some
but
fixing
there
and
hopefully
get
the
rebalancing
in
a
state
where
we
can.
We
can
use
it
that
will
take
some
some
some
extra
time
from.
E
Yeah
I'll,
I
totally
understand
I'm
supportive
of
the
shift
focus.
I
haven't
called
it
out
on
the
pa
page
that
we're
going
to
probably
pause
some
of
the
feature
work
when
we
can.
I
talked
to
jake
and
donald,
and
I
think
I'd
love
to
at
least
get
it
to
a
good
stopping
point
by
the
end
of
14-0
before
we
stop
start
like
the
feature
freeze.
E
So
even
if
we
can
get
not
the
automatic
part
bit,
but
just
like
the
iteration
cadences,
where
you
can
create
manual
iterations
within
each
cadence,
that
would
solve
a
lot
of
the
customer
problems
that
they're
having
right
now
and
if
we
can
get
that
right
into
14.00,
that'd
be
great,
so
yeah,
I'm
supportive
of
the
shifter
parties.
D
A
I
think
one
benefit
of
the
shift
in
in
focus
has
been
at
least
that
we've
had
more
eyeballs
from
around
the
engineering
department
as
a
whole
on
you
know:
less
performant
areas
of
plan,
the
one
that
comes
to
mind
I'll
I'll
paste
it
into
the
agenda.
After
all,
the
exclamation
points
that
gabe's
just
made
is
the
milestones
page,
which
had
a
lot
of
like
I
think
I
n,
plus
one
and
counts
of
mrs
that
so
for
every
milestone.
That
was
loaded
in
the
list.
A
We
did
a
kind
of
mrs
for
that
milestone
like
horribly
slow
and
we
had
valeria
come
in
and
fix
that
one,
so
we're
collecting
some
input
from
other
parts
of
the
organization
as
well.
So
it's
disruptive
to
what
we
planned
for
the
milestone,
but
it
also
has
some
side
benefits
that
we're
collecting
engineering
input
from
around
the
organization.
B
Also
has
the
added
benefit
of
shining
a
light
on
everything
that
we
have
within
plan
like
the
a
lot
of
the
plan
plan
functionality,
you
know
we're
always
sort
of
like
battling
against
where
revenue
is
generated
for
kind
of
arguing
for
investment,
and
things
like
that.
But
most
of
plan
is
core
functionality
for
gitlab,
like
issues
and
labels
of
milestones.
Things
like
that.
So
it's
it's
kind
of
a
good.
You
know
as
painful
as
it
can
be,
to
sort
of
have
these
rapid
priority
changes
and
trying
to
investigate.
You
know
obscure
performance
issues.
B
It
is
a
good
kind
of
spotlight
on
just
how
much
just
how
much
of
what
we
work
on
is
core
to
the
entire
application,
so
cool
and
cool
in
some
ways.