►
From YouTube: Plan stage weekly 2020-08-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).
B
All
right,
let
me
just
share
my
screen
yeah,
so
we've
recently
decided
that
the
the
health
status
of
an
issue
becomes
less
relevant
once
we
close
it,
so
we
shouldn't
really
display
it
in
the
epic
tree
just
to
clear
up
the
the
user
space
and
then
also
disallow
editing
of
the
health
status.
B
So
by
the
way,
thanks,
I'm
felipe
for
doing
the
back
and
work
on
this.
So,
as
you
can
see
this,
there
is
this
closed
issue
right
here
right
now.
We
do
not
allow
editing
it
since
it's
closed,
but
we
re
open
this
one
and
then,
as
we
can
see,
we
can
re-edit
it,
and
then
we
go
back.
B
As
you
can
see,
there's
neither
attention
it's
it's
there
again,
yep.
So
again,
the
masterminds
behind
this
was
keenan
and
alex's.
Thank
you
yeah.
So
that's
the
demo.
C
Yeah,
it
looks
good,
I'm
just
wondering
I
guess
in
the
future,
and
I
think
keenan
and
I
discussed
this
a
bit.
Are
we
thinking
about
rolling
in
kind
of
that
like
locking
or
dropping
status
after
close
to
issues
as
well
gabe?
What
do
you
think.
C
Worry
no
so
like
after
an
issue
is
closed.
Would
you
imagine
at
some
point
some
of
that
that
data
being
locked
or
kind
of
dropping
off
the
issue.
D
Yeah,
I
would
think
some
stuff
would
be
locked,
but
I
guess
it
depends
on
if
you
lock
the
issue
or
not,
I
mean
there's
an
ability
to
lock
it
once
it's
closed,
which
would
prevent
certain
like
non-members
from
editing
it,
but
I
don't
yeah,
there's
been
another
request
too
to
have
the
due
date.
Color
change
when
an
issue
has
been
closed
because
it
still
shows
red,
even
though
it's
closed
like
it's
overdue,
but
it's
not
really
overdue.
D
F
And
all
right,
so
I'm
going
to
demo
what
we
have
so
far
for
iterations
within
projects.
So
here
I
am
and
in
the
get
lab
test
project
and
I
can
go
over
to
issues
and
select
iterations
here,
which
then
takes
me
to
an
iterations
page
within
the
project,
and
here
it's
listing
right
now,
just
all
the
projects,
but
from
what
I
understand.
F
D
I
think
it
looks
great
I
I'm
kind
of
I
asked
the
water
community
what
they
thought
about
the
inheritance
of
iterations,
I'm
still
on
the
fence
of
like.
Should
we
only
show
if
there
are
issues
or
should
we
always
show
it
if
there's
an
inherited
iteration
and
prevent
like
subgroups
from
creating
overlapping
iterations
from
inherited
iterations?
D
If
that
makes
sense,
like
there's
that
weird
thing
where
the
whole
point
of
it
is
to
have
a
single
cadence
time
box,
cadence
for
like
measuring
velocity,
so
I'm
gonna
see
what
how
they
responded
and
what
sort
of
feedback
they
had.
But
what
do
you
all
think
about
how
it
should
behave.
G
Just
curious
so
just
to
clarify
you're,
saying
like
if,
for
example,
on
this,
looking
at
the
screen,
it's
like
iteration
for
august
1st
august
2nd
a
subgroup
wants
to
make
an
iteration
for
that
time
frame.
This
one
already
exists,
but
they
don't
see
it.
They
would
like
hypothetically,
wouldn't
see
it
because
it
didn't
have
issues
in
it.
G
D
I'm
leaning
towards
the
ladder
just
because
it
gives
individual
teams
more
autonomy?
Yes,
but
it
also
is
like
a
usability
concern
of
being
like
well
where's,
the
iteration
in
this
list.
I
don't
see
it
even
though
I
know
to
the
parent
group,
because
there's
not
an
issue
in
it.
Yet.
H
Right,
but
from
a
two
thousand
one
I
think
you're
right,
you
should
give
the
flexibility
in
a
future
mvc.
You
could
create
a
policy
where
a
group
could
say
that
my
subgroups
must
follow
right
of
enforcing
the
iterations,
basically
enforcing
a
cascade.
That's
a
policy
decision.
I
think
that
you
want
to
support,
but
I
think
your
default
out
of
the
box
should
give
peop
give
individual
subgroups
the
flexibility
to
do
their
own
cadence.
H
I
mean
you
were
in
the
conversations
and
marketing
as
to
how
we
kind
of
got
all
wrapped
around
the
axle
around
this
at
some
level.
Yeah
all
right,
yeah,
that's
good
feedback.
So
the
only
other
thing
on
this
view,
it'd
be
really
useful.
To
know
whether
or
not
an
iteration
is
at
the
is
is
from
here
is
from
gitlab
test
or
gitlab.org.
H
D
Yeah,
I
agree.
We
have
a
issue
I
think
scheduled
for
13.4
and
holly's,
not
here
but
she's,
going
to
work
on
some
design
for
it
to
cool,
make
the
issue
list
view
more
actionable
like
so,
including
the
slug
of
where
the
thing
originated
from
and
also
progress,
indicators
and
other
things
like
that.
So
good.
A
All
right
next
point
is
mine:
swim
lanes
iteration
one
for
the
swim
lanes
since
we
put
that
schedule
in
there,
but
in
reality
it's
it'll
be
forget.org
iteration,
two
review,
so
last
week's
objective
was
to
finish
the
graphql
queries
to
allow
for
a
read
only
swimlane
board.
A
E
Yeah
sure
well
jan's
on
the
call.
So
maybe
we
can
get
more
context,
but
basically
the
the
query
itself
will
not
change
the
database.
Query
that
it
performs
in
the
background,
is
at
the
minute
quite
slow.
I
think
also
there
might
be
implications
for
whether
we
show
or
hide
the
open
and
closed
columns
like
those
will
reduce
the
complexity
of
the
query,
but
I'm
not
totally
sure
maybe-
and
maybe
it's
no
better.
I
The
problem
is
that
now,
if
you
create
a
board,
for
example
in
gitlab
work
group
in
open
list,
you
can
technically
see
all
open
issues
from
all
projects
in
gitlab
work.
So
we
need
to
find
all
epics
which
might
be
connected
with
this
issue.
So
we
have
to
join
with
tens
of
thousands
of
issues,
and
this
is
relatively
slow
with
cold
cash
with
one
cash.
Now,
it's
quite
fast,
if
you
get
to
300
milliseconds,
but
with
cold
cash,
it's
30
seconds
or
more.
I
J
Yeah,
so
I
just
want
to
make
sure
to
walk
through
what
I
think
it
should
be
doing
now,
and
you
can
tell
me
if
that's
weird,
but
you
know
we
should
only
be
looking
for
epics
that
are
open
and
then
it
should
be
issues
that
share.
You
know
the
property
of
lists
right.
So
I
think
those
are
the
two
filters
we
started
with
right
or
the
two
parameters
that
were
able
to
filter
down
the
issues
on
sorry.
You
mentioned
issues
that
share.
I
A
property
on
a
list
like
the
list
that
the
board's
made
out
of
here
yeah,
but
the
one
of
the
list,
is
so
backlog,
yeah,
open
issues.
A
So
you
said
it's
30
seconds,
cold
cash
right
now
or
is
that
one
cash.
I
Yeah,
it's
it's
not
clear
to
me.
If
I
I
think
that
they
are
trying
to
make
sure
that
it's
less
than
a
15
seconds
timeout,
because
otherwise
the
user
gets
three
500
error,
because
the
sql
statement
times
out.
I
Yeah,
the
problem
is
that
that's
a
great
point.
The
problem
is
that
on
issue
board,
when
you
fetch
list,
you
do
pagination,
which
is
fine,
but
if
I
want
to
paginate
epics,
I
need
first
to
get
a
list
of
all
possible
epics
and
to
get
all
possible
epics.
I
need
to
get
all
issues,
so
I
cannot
paginate
only
100
issues.
I
Yeah,
so
I
think
that
I
hope
we
will
get
some
conclusion
with
database
team
to
for,
for
example,
go
forward
with
feature
flag
or
figure
out
something
and
see
how
it
behaves
in
production.
I
D
What
if
what
if
we
like
when
querying
issues,
we
basically
query
until
we
find,
I
don't
know,
10
epics
and
then
of
those
10
epics.
We
then
query
all
the
issues
for
each
of
those
epics,
and
that
way
you
can
load
those
immediately
onto
the
board
and
then
do
asynchronous
like
finding
of
the
rest
of
the
epics,
and
then
you
could
do
pagination
that
way,
so
you
wouldn't
have
them
all
at
first.
I
We
would
first
fetch
thousands
of
issues,
try
to
find
epics
for
them
and
if
you
would
have
enough
for
the
page
of
epics,
we
would
use
this
yeah
did
my
work,
I'm
afraid
the
concern
is
that
it
wouldn't
work
for
another
pages
yeah.
So
if
you
would
want
to
get
fifth
page,
you
would
still
have
to
find
enough
issues
for
it.
E
What
if
we
maintained
a
a
project
epics
table,
which
we
updated
with
every
time
an
issue
in
a
project
is
added
to
group
level,
epic,
we
create,
we
add
it
to
that
table
and
then
we
query
that
table.
So
it's
like
a
cache
that
we
keep
updated.
Then
we
don't
have
to
do
a
join
through
issues.
We
would
just
it's
more
like
it's
going
to
it's
going
to
extend
going
to
extend
this
work.
It's
not
something
we
can
do
overnight
like,
but
we
did
this
for
project
authorizations.
I
think
or
group
authorizations.
I
D
This
is
also
one
of
those
things
that
is
like
a
self-inflicted
performance
issue
to
a
certain
degree
because
of
how
flexible
we've
made
everything
and
I'm
wondering
if
we
need
to
like
at
some
point
put
more
constraints
on
the
product
itself
and
how
it
behaves.
So
I
think
part
of
the
problem
is
like
you.
D
You
first
have
to
look
at
what
the
borders
scope
to
and
then
only
look
at
issues
that
have
that
scope
and
then
find
the
epics
and
then
like,
whereas,
like
in
a
traditional
project,
a
project
would
have
epics
and
issues,
and
you
could
only
associate
the
two
and
it
wouldn't
be
like
so
massive.
I'm
just
wondering
if
there's
things
that
we
need
to
change
from
the
product
itself
to
help
improve
performance.
J
K
K
When
you
have
an
epic
swim
lane
on
a
juror
board,
it's
only
showing
recently
modified,
doesn't
tell
you
what
that
is,
but
they
probably
have
a
similar
performance
issue
and
they're
they're
deciding
to
like
lop
off
some
set
of
issues
or
they
maintain
some
flag.
That's
like
recently
updated
or
not,
I'm
not
sure,
but
something
to
consider.
I
K
J
D
J
Because
at
the
same
time,
we're
also
dealing
with
the
the
board
scope
itself
right,
which
should
be
limiting
the
number
of
items
returned
in
that
issues
without
epics
right.
I
E
I
wonder:
could
we
simply
bail
out
in
the
first
iteration
if
the
filters
on
the
board
are
too
permissive
same
way?
We
do
with
its
issue
search
you
can
search
across.
You
can
search
from
the
dashboard
view,
for
example
across
all
issues,
just
by
like
one
label
or
something
because
that
would
search
every
project
every
group,
so
you
have
to
put
in
a
certain
amount
of
criteria,
a
certain
number
of
criteria.
So
maybe
we
could
do
that
as
a
first
iteration.
E
You
can't
simply,
you
simply
can't
load
a
board
that
asks
for
everything
everything
on
gitlab
org,
slash,
gitlab,
that's
labeled,
backend!
You.
B
I
Would
it
be
viable
to
just
return
a
warning,
for
example,
if
your
issue
board
shows
more
than
we
can
easily
check
the
size
of
issues
in
the
issue
world?
So
if
you
do,
for
example,
more
than
500
epics,
we
should
just
return
an
error
or
warning
as
john
suggested.
Your
issue
board
is
too
big.
Please
limit
the
scope,
no.
D
Would
it
help
at
all?
I
don't
know
if
it
would,
if
we
put
in
some
like
scope,
because
this
is
also
the
same
same
thing
for
program
boards
or
epic
boards.
I
think
at
some
point
we're
gonna
have
swim
lanes
there.
If
we
have
some
sort
of
scope,
board
scope
for
epics
as
well
in
the
same
board,
so
you're
only
looking
for
a
subset
of
epics
that
match
a
subset
of
issues
or
would
that
make
it
more
complic
complicated.
D
So,
for
example,
like
the
project
management
group
for
the
project
management
groups,
epics,
we
put
the
same
label
on
the
epics,
and
so
I'm
wondering
if
like
right
now,
you
can
say
I
want
to
find
like
scope,
this
board
to
all
issues
that
have
the
group
project
management
label
right
and
that's
for
issues.
D
I
Yeah
yeah,
maybe
I
will
have
to
do
some
measurements
to
tell
you,
but
perhaps
yes.
J
Yeah,
I
filter
by
back
end
work,
and
I
my
epics
have
front-end
work
in
them
as
well.
Right
like,
I
would
then
be
obfuscating
a
lot
of
the
work
we
even
have
from
the.
I
Boardview
yeah.
So
if,
if
we
limit
scope
on
epic
size,
I'm
not
sure
if
it
helps,
because
we
still
have
to
join
the
issues
with
epics
through
the
epic
issues
table
and
I'm
not
sure
if
there
will
be
significant
difference
in
performance
works.
A
Can
we
just
do
that
for
the
first
iteration
and
then
we'll
come
back
because
options,
then
I
think,
or
the
best
options
are
either
do
that
or
just
put
it
behind
a
future
flag
to
get
that.
Mr
through,
I
think
the
error
is
fine
for
the
first
iteration
and
then
we
can
handle
that
on
the
front
end
with
minimal
work,
and
then
we
can
figure
out
because,
regardless
of
our
solution,
I
think
there's
going
to
be
some
ux
work
that
we
have
to
put
into
it.
A
So
I
don't
want
to,
if
possible,
push
back
getting
getting
the
back
end.
Mr,
if
we
don't
have.
J
J
I
I
I
I,
it
was
just
just
a
quest,
so
I
would
have.
I
will
update
the
query
and
do
the
measurement
on
database
lab,
and
I
will
thank
you
back
with
some
timings.
A
J
J
100
1300
in
the
open
column
and
then
700
in
the
close.
So
this
is
the
inherent
problem
with
the
open,
close
column
and
one
of
the
reasons
we
were
discussing.
How
do
we
move
them
off
the
board
when
selected
by
users
to
help
verify
this
is
because
the
way
open,
the
way
our
open,
often
called
backlog
column?
It's
everything
like
it's,
not
scoped.
The
open
column
is
not
scoped
down
and
the
closed
column's
even
worse.
D
J
Yes,
what's
the
question
like.
J
I
J
Bar
and
then
you
have
the
actual
lists
or
workflow
states
like
we
have
so
you
have
three
layers
of
filtering.
We
use
till
you
get
the
snapshot
of
what
a
board
is
and
the
issues
that
should
be
on
there
that
we
would
then
put
the
epic
swimlane
on.
I
guess
it's
what's
the
order
that
we
do
that,
because
it
seems
I
I
just
don't
understand
much,
because.
I
I
For
backlog
or
for
the
first
open
column,
we
still
have
to
filter
or
get
all
the
issues
which
don't
fit
to
any
of
the
list,
but
it
still
can
still
occur
in
the
open,
open
list
common
so
for
streamlines.
It's
easiest
for
me
to
ignore
any
list.
Filtering
just
select
all
open
epic,
all
open
issues
which
may
occur
in
any
of
the
list,
including
the
backlog.
It's
the
easiest
filter
and
fetch
these
issues
and
then
get
a
picks
for
them.
A
K
J
D
Yeah,
I
don't
see
any
other
anybody
that
I've
seen
use
boards
doesn't
have
as
many
issues
as
we
do
so
like
they
use
the
open
as
the
backlog,
and
I
think
we
that's
why
I
created
a
label
for
myself
that
is
like
or
the
workflow
start
label
as
a
backlog,
so
that
I
can
move
things
into
my
actual
backlog,
and
this
could
be
an
opportunity
for
us
to
create
a
real
backlog.
D
I
I
think
it's
a
problem
and
the
one
the
one
problem
with
the
time
based
approach
is
that
and
unless
there's
a
way
for
me
to
load,
more
than
discoverability
of
things
becomes
limited,
and
I
think
right
now,
discoverability
things
is
limited
from
the
open
calm,
because
you
only
can
see
a
few
things
and
you
have
to
scroll
really
far.
D
So
I
I
know
that
there
have
been
requests
for
better
backlog
management
in
gitlab,
like
the
issue
list
doesn't
work
because
of
pagination,
and
you
can't
manually
drag
things
from
one
page
to
another.
We
can
fix
that
with
infinite
scroll
sort
of
like
we
do
on
boards,
but
then
you're
dragging
things.
J
Yeah,
well,
I
think
we're
closer
to
an
opportunity
to
actually
solve
that
in
a
valuable
way
because
of
iterations
right.
That's
generally,
when
folks
start
running
into
the
backlog
construct
and
wanting
to
use
that
as
a
foundation
for
planning
work,
because
you
actually
then
say
I
have
a
backlog
and
I
have
upcoming
iterations
and
I
want
to
start
dragging
things
in
between
those
and
started
them
right.
So
we're
maybe
on
the
cusp
of
needing
to
do
that
now.
D
Yeah,
that's
where
what
I
how
I
always
worked
in
biblical
tracker
and
not
the
cleanest
way,
but
I
wish
it
worked
this
way
where
I
had
my
epics
and
then
I
could
see
all
my
issues
that
were
in
my
epic
that
weren't
scheduled
to
iteration
and
then
I
could
drag
it
into
the
specific
iteration
right.
So
I
can
see
the
like.
D
I
basically
can
see
all
the
epics,
I'm
working
on
then
easily
schedule
them
different
issues
into
different
iterations
and
then
anything
that's
not
scheduled
like
is
not
there
and
that's
what
we
can
do.
I
think
with
boards
with
swim
lanes
because,
like
we
could
have
iterations
as
lists
and
you
could
have
your
epics
with
all
the
issues
and
you
could
drag
it
like
schedule
in
that
way.
D
So
I
think
there's
lots
of
ways
to
do
it
and
I
would
like
to
explore
that
it's
worth
it
or
whatever
we
can
do
for
better,
better
backlog
management.
I
think
it's
a
problem
with
yourself,
so
yeah.
A
So
sorry,
real
quick,
what
would
happen
if
we
remove
the
open
and
close
or
the
open
column
that
would
kind
of
people
would
create
a
backlog
label?
Right,
probably
that's.
K
What
I
would
do
is
that
are
you
suggesting
zone
that
we,
by
doing
that,
we
we
automatically
encourage
better
board
scoping
yeah.
J
Yes,
yeah
yeah,
so
I
mean
that's
where
this
a
lot
of
this
conversation
started
a
few
weeks
ago
I
was
like
hey
when
you
turn
swim
lane
on
the
open
and
close
column
should
be
hidden.
Then
you
know
you
can't
close
the
you
can't
close
the
closed.
I
can't
hide
the
closed
column,
because
I
need
to
drag
things
there
to
close
them
right.
So
you
need
that
one.
But
the
question
is
like:
does
what
is
the
open
column
actually
doing
that
can't
be
done
better
by
a
scoped
backlog,
column.
D
Well
I'll
also
say
the
about
the
closed
is
the
there
is
an
inherent
problem
and
that
lots
of
teams
their
workflow,
their
done
state
is
not
closed.
D
It's
like
they
might
finish
some
work
and
hand
it
off
to
a
qa
team,
and
then
they
don't
touch
it
again
right,
and
so
they
can't
use
a
lot
of
the
burn
down
stuff
and
milestone
stuff
and
progress
reporting
because
they're,
it's
not
their
done,
is
not
closed.
So
the
reporting
is
accurate.
The
way
that
trello
handles
this,
which
I
think
is
pretty
brilliant,
is
they
have
a
like
an
archive
feature
so
like
in
your
last
list.
D
You
basically
can
say
I'm
going
to
archive
all
these
cards,
which
would
be
closing
it,
and
then
it
takes
them
off
the
board
and
puts
them
in
this
archive
area.
That's
separate
from
the
board,
so
we
could
look
at
having
a
final
list
and
either
like
how
it
works
in
jira.
Is
you
could
say
this
is
like
this
list?
Eight
means
that
it's
done
done,
which
is
separate
from
being
closed,
and
we
could
look
at
doing
that
and
then
it
periodically.
D
A
H
Listen,
I've
been
quietly
listening.
I
apologize
my
videos
screwed
up,
I
gotta
fix
it,
but
I
love
the
idea
of
getting
rid
of
both
open
and
closed
columns
from
boards.
I
think
they're
distracting,
there's
way
too
much
there
and
the
idea
of
then
what
donald
just
suggested
of
having
a
place
to
drag
drag
it
for
closed.
If
you
want
to
close
it,
I
think
it
would
move
make
these
things
much
much
cleaner
and
force
people
to
establish
the
clear
parts
of
it,
because
I
always
collapse
them.
H
J
K
J
One
clarifying
question
on
that
so
is
the
is
the
actual
concern
the
the
big
bucket
at
the
bottom,
which
is
like
issues
without
an
epic?
Is
that
because
that's
the
is
that
the
one
where
we're
worried,
there's
gonna,
be
so
many
or
is
it
really
just
in
general?.
D
C
C
I
J
But
and
then
we're
good
we
need
to.
We
need
to
go
back
to
that.
What
does
that?
Look
like
question
than
alexis,
because
the
problem
was
swim
lanes
or
the
epics
being
displayed
on
the
swim
lane
artifact
being
displayed
to
the
left
side
of
the
board
would
then
need
to
cross
over
a
column
that
it
doesn't
actually
affect
and
like
what
do
we
know.
C
C
Were
under
the
assumption
that
open
import,
enclosed
were
more
important
than
they
were,
maybe
we'll
play
around
with
it.
Keenan.
A
Okay,
so
just
circling
back
the
current
step
first
step
is
to
add
a
limit
to
whatever
yawn
decides,
is
the
appropriate
amount
and
then
we'll
figure
out
the
ux
implications
of
open,
close
and
everything
else.
A
Okay,
so
then,
let's
talk
about
the
next
iteration
because
we
had
planned
to
get
the
read-only
version
out.
I
So
it's
in
in
a
review
process,
so
it
depends
on
how
fast
database
review
will
be
done
and
approved,
and
so
I
had
to
so.
Our
official
limits
are
two
days
for
feedback,
so
so
perhaps
till
the
end
of
this
week,
hopefully.
A
A
Okay,
so
I'm
proposing,
then
we
keep
iteration
to,
as
is
but
of
course,
dependent
on
when
that
gets
in,
because
what's
left
for
iteration
two,
which
is
like,
I
said,
the
read-only
version
of
swim
lanes
is
we
just
need
to
integrate,
so
we
need
to
have
the
back
end.
A
Graphql
queries
merged
in
that's,
going
to
take
at
least
a
few
days
after
it
gets
merged.
A
So
again,
what
I'm
proposing
is
we
keep
it,
as
is
where
we
aim
to
get
that
done
by
iteration
two,
but
let's
acknowledge
that
it
probably
will
move
into
the
next
iteration.
And
then,
when
we
come
back
next
week,
we
can
see
where
we're
at
and
move
the
other
iterations
back,
at
least
in
iteration.
If
need
be,.
E
Can
we
work
off
that
branch
in
the
meantime
because,
like
I
said
the
the
graphql
query
itself,
the
schema
shouldn't
change
just
what
happens
in
the
background.
A
Yes,
I
asked
flori
to
to
confirm,
but
I
think
we
have
been
working
off
of
that
branch.
So
it's
it's
essentially
just
like
the
final
integrations
that
needs
to
happen
that
we
wanted
to
work
off
of
all
of
them
all
the
branches,
all
the
vacuum
branches
be
merged
in
there.
C
I
was
just
looking
at
swim
lanes
and
trying
to
whip
something
up,
but
it's
hard
cool
I'll
talk
about
boards
in
general,
we've
got
a
lot
of
requests
from
users
to
see
epics
on
their
boards
keenan,
and
I
translated
that
into
they
want
like
epic
or
program
boards,
which
is
basically
allowing
them
to
plan
at
a
higher
level,
and
you
know
see
how
epics
work
through
the
workflow
of
a
board,
as
opposed
to
seeing
how
their
issues
go
through
the
workflow
of
the
board
and
you
know,
help,
helps
them
track
and
report
on
initiatives
at
a
higher
level.
C
J
Yeah,
so
it's
kind
of
it
it's
also
our
largest
and
it's
our
largest
or
one
of
the
largest
gaps
we
have
for
being
able
to
onboard
organizations
that
practice
safe.
You
know
we
can
have
our
opinions
on
that,
but
you
know
the
idea
that
I
can
actually
manage
that
fixture
workflow
at
a
higher
level
either
before
they
have
issues
assigned
to
them.
You
know
if
it's
like
an
idea,
backlog
or
a
long-term
work
backlog
where
I
say
hey
these.
J
These
are
the
six
features
I,
as
a
product
manager,
are
gonna
manage
over
the
next
90
days.
I
need
to
get
it
from
ideation
to
validation,
to
design
solution,
to
the
point
where
it's
ready
for
engineering
to
take
a
look
and
help
break
it
out
or
the
idea
of
like
I
have
work
in
flight
epics
are
being
worked
on.
I
need
to
track
those
over
time
at
a
higher
level,
to
report
it
to
my
stakeholders
and
my
or
outside
customers,
to
look
at
it
a
instead
of
showing
a
board
with
a
thousand
issues
on
it.
C
C
Everything's
funny,
I'm
I'm
surprised,
I'm
awake
right
now,
because
I
haven't
had
enough
coffee
yeah.
So
this
is
pretty
rough
I'll,
just
walk
you
all
through
this,
but
for
mvc
we
are
gonna.
Add
a
boards
option
within
the
epics
navigation,
so
users
can
navigate
to
the
boards
within
epics
and
of
course
they
see
epics
because
they
have
that
permission.
C
They
can
create
a
new
board
and
it
all
looks
pretty
familiar
for
mbc.
They
could
hide
the
open
and
closed
list.
They
could
scope
by
label
for
mvc,
create
their
board
and
again
it
looks
pretty
similar.
It's
up
there
seeing
epic
cards
on
the
board
instead
of
issues
and
again
this
is
just
a
rough
prototype.
So
don't
take
take
it
with
a
grain
of
salt,
they
can
add
their
list
and
for
mvc
they
can
add
epic
lists
by
label.
C
So
they
see
that
they
can
still
create
new
epics
within
a
list.
They
can
add
existing
epics.
I'd
assume
this
means,
like
they're,
not
scoped,
to
this
board,
and
you
know
they
could
still
investigate
a
single
epic
and
quickly
edit
it
and
they
can
still
oops
wrong
thing,
set
a
whip
limit
by
epic
and
in
the
future.
C
Well,
you
know,
past
mvc
will
investigate
a
little
bit
more
we're
going
to
loop
in
growth
as
well
to
think
about
first
key
states.
I
think
that
will
also
help
with
some
of
the
scoping
issues.
We're
having
you
know,
having
the
funnel
be
a
little
bit
different
users
come
in
and
they
create
a
new
board
and
they're
encouraged
in
a
better
way
to
scope,
and
they
understand
what
the
implications
of
having
you
know.
C
Huge
boards
that
are
unscoped
means
thinking
about
better
ways
to
basically
display
planning
in
the
navigation
in
general,
and
can
we
do
things
like
just
combine
boards
together?
So
I
go
to
just
a
boards
area,
and
I
see
all
my
different
kinds
of
boards
or
thinking
about
better
ways
to
add
columns.
I
think
simon
was
talking
about
this
as
well.
So
you
know
what
are
different
ways.
We
could
allow
users
to
add
columns.
C
Can
they
just
like
scroll
to
the
end
of
their
list
and
say
I
want
to
add
another
list,
different
ways
to
visualize
the
header
to
support
users
a
little
bit
better
here
and
again.
This
is
all
really
rough.
So
don't
look
at
it
too
much
do
we
have
any
questions
there.
C
Cool-
and
you
know
we're
gonna-
keep
working
on
this,
so
let
me
know
or
just
add
feedback
or
questions
to
that
issue.
I
linked
and
I
was
looking
at
epic
swim
lanes.
Let
me
see
if
I
could
find
it
what
I
meant
about
the
not
showing
swim
lanes
on
open
and
closed.
I
don't
know
if
this
makes
sense
and
I
couldn't
mock
it
up
very
fast,
because
again
I
need
more
coffee
but
basically
see.
C
J
J
First
off
I
threw
that
in
there-
and
I
forgot
to
put
it
at
a
discussion
point
of.
Would
the
group
find
that
valuable?
Isn't
that
something
we
on
the
product
side
could
plan
and
organize
and
share,
and
then,
ironically,
I
forgot
to
do
it.
So
I
can
always
talk
about
my
metrics
as
I
have
them.
I
always
refresh
them
first
thing
in
the
morning,
but
just
from
an
overall
group
perspective
like.
Is
that
something
to
be
interested?
J
What
kind
of
metrics
would
you
like
to
see
we're
trying
to
find
better
ways
to
craft
that
message
for
the
individual
groups?
So
it's
valuable,
but
I
would
actually
really
like
to
have
thoughts
and
opinions
from
the
group
on
what
we
could
do
here
to
help.
E
I
E
Just
from
a
from
an
engineering
point
of
view,
I
think
it'd
be
really
nice
to
just
see
basic
metrics
and,
like
explain
to
me,
like
I'm
five
kind
of
metrics
about
user
ship
of
features
that
we've
released,
maybe
with
say
a
three
month
lag
or
something.
So,
let's
say
we
moved
to
epics
to
premium
three
months
ago,
like
what
did
that
do
for
yeah
usership
of
epics.
E
Maybe
if
we
have
sales
numbers
as
well,
that
would
be
really
interesting,
just
stuff
that
we
don't
see
every
day
when
we're
like
in
the
middle
of
things
like
work.
Working
on
features,
be
really
nice
just
to
see
like
how
those
those
contributions
that
we
made
panned
out
in
the
long
run,
and
you
know
what
was
effective
and
what
customers
care
about
that
kind
of
thing.
Yeah.
J
J
Let
me
know
when
you
can
see
my
screen:
yeah
cool
yeah,
so
actually
I'll
start
with
kind
of
what
we're
doing
from
the
product
business
side
and
explain
it
because
you're
gonna,
if
you
haven't
already
heard
these
terms
a
time,
you're
gonna
hear
them
a
lot
more.
J
But
you
know
we
have
the
idea
of
what
each
group
should
be
tracking,
something
we're
calling
that's
called
gmao
or
group
monthly,
active
users
which
are
active
individual
users
using
part
of
the
product
and
those
then
get
aggregated
up
into
you,
know,
stage
level,
monthly,
active
users
and
then
total
monthly
active
users
for
the
entirety
of
gitlab.
So
we
we
have
our
first
initial
pass
at
that
for
portfolio
management,
which
is
really
just
users,
creating
epics
we're
going
to
expand
that
into
users
interacting,
and
so
these
numbers
will
grow
quite
a
bit.
J
Once
we
have
that
data
in
we're
just
waiting
for
the
data
team
to
help
us
out
on
some
of
it,
but
one
of
the
interesting
things
here
you
can
see
is
this
stretches
back
to
december
of
18.,
so
the
top
one
is
sas
and
self-managed
orange
being
self-managed
sas
being
purple.
J
And
of
course,
when
we
talk
about
self-managed
metrics,
we
have
to
keep
in
mind
that
30
of
our
self-managed
instances
are
providing
this
data,
so
that
number
is
a
subset
of
the
reality,
but
it
is
what
we
have
to
work
off
of
and
you
can
actually
see
you
know
going
from.
You
know
back
to
let's
say
august
of
last
year
you
know
we
only
you're
only
really
reporting
about
56
unique
users
on
sas
and
when
we
launched
one
we
started
improving
epics
we
back
around
august
and
september.
J
We
did
see
an
organic
level
of
growth
start
to
kick
off
like
we
doubled.
You
know
four.
We
actually
4xed
in
about
six
months,
the
number
of
users
on
sas
and
then,
as
soon
as
we
introduced
premium
epics,
which
was
in
the
very
last
couple
weeks
of
february,
we
actually
saw
pretty
huge
growth
on
both
sides,
as
we
had
a
lot
of
a
lot
of
new
accounts
and
adopters
overall,
so
you
can
see
we're
now.
J
You
know
right
getting
close
to
2
000
active
users
creating
epics
every
month
on
the
platform,
which
is
a
substantial
increase
from
we
were
six
months
ago
and
which
is
something
we
should
be
extremely
proud
of
and
at
the
bottom.
This
is
just
this
graph
at
the
bottom
is
really
just
a
aggregation
of
the
number
of
epics
being
created
in
the
two
different
types
of
accounts.
You
know
again,
let's
go
back
to
august
or
well
august
was
a
off
month.
So
let's
say
you
know
here
in
september.
J
You
know
we're
at
1500
a
month
and
now
we're
almost
6
000
a
month
being
created.
So
this
all
just
comes
from
us
consistently
being
part
of
the
release
post
process
and
rolling
out
new
features
and
improving
things
and
adding
those
table
stake
items
that
users
needed
and
expected
for
epics
to
be
viable
and,
as
you
can
see
like
just
just
being
part
of
the
release
process
and
rolling
out
these
new
features
and
marketing
them
has
driven
a
ton
of
usage
and
adoption
over
the
platform
and
what
we're?
J
Also
now,
I'm
working
with
the
data
team
is
now
I'm
trying
to
get
to
the
point
where
we
can
actually
track
a
number
of
issues
assigned
to
epics
over
time.
Actually,
I
think
we're
gonna
have
to
do
some
work
on
that
too.
I
think
tom
and
john
john.
J
I
did
it
again,
I'm
so
sorry,
donald
and
john,
and
I've
been
talking
about
this,
because
then
we
can
actually
show
how
the
adoption
of
epics
over
time
is
actually
driving
more
plan
usage
overall,
because
the
theory
and
belief
is
that
as
you
adopt
epics,
you
actually
start
breaking
work
down
more,
which
means
you're,
actually
using
more
issues
or
mars,
et
cetera,
et
cetera,
so
we're
going
to
get
more
granule
granular
on
how
does
a
feature
increase,
actually
drive
increase
across
the
entire
stage,
which
is
super
exciting.
J
Let's
see
if
there's
another,
so
specific,
yeah
yeah,
the
other
one
I
want
to
talk
about
is
up
here
in
the
top
left.
This
is
the
number
of
active
excuse
me
over
here
on
the
right.
We
already
did
that
this
is
the
number
of
namespaces
we
see
on.com
using
epics,
and
so
again
we
go
back
to
you
know,
september
november
or
like
40
50.
and
as
of
july.
We
were
you
know,
358,
so
that
a
lot
of
that's
starting.
J
You
see
this
big
jump
from
january
to
february,
which
is
when
we
rolled
epics
to
premium
so
huge,
huge
adoption
on
the
dot-com
side
relative
to
where
we
were
before,
and
it's
continuing
to
have
nice
strong,
organic
growth
monthly
month
over
month.
You
know
close
to
10
percent,
with
the
exception
in
june,
which
is
a
little
lower
and
then
down
into
self-managed.
You
know
it's
the
same
data
we
had
across,
but
this
one
here
this
top
one.
J
We
actually
see
a
split
of
number
of
epics
created
month
over
month
across
premium
and
ultimate.
So
one
of
the
concerns
was
that
if
we
move
epics
down
to
premium,
ultimate
adoption
might
suffer
and,
as
we
see
ultimate
absolutely
ultimate
use.
Creation
of
epics
is
still
on
the
rise
and
has
actually
had
a
quite
a
large
uptick
since
march.
So
we
now
we're
we
didn't.
J
We
didn't
hurt
ultimate
adoption
or
usage
overall
and
in
fact,
with
adding
premium,
we've
doubled
the
number
of
epics
we
see
being
created
by
accounts
every
month
top
left
again.
This
is
the
same
view
we
had
on
namespaces,
but
this
is
self-managed
accounts,
and
so
you
go
back
to
september.
Last
year
we
had
433
self-managed
instances
who
are
reporting
data
using
epics,
and
we
are
getting
really
close
to
breaking
a
thousand,
so
doubling
the
the
adopted
self-managed
accounts,
and
so
that's
all
super
exciting.
That's
really
strong
growth
over
time.
J
That
is
consistent,
which
is
what
you
want,
and
it's
also
interesting
to
know.
You
know
we
are
in
a
we're
in
a
unique
position
on
the
portfolio
management
side
that
every
every
user
we
have
is
a
paid
user,
either
in
premium
or
ultimate,
and
so
our
gmail
is
essentially
a
paid
group,
active
monthly,
active
user,
which
is
which
is
pretty
exciting
over
time.
The
other
item
we
I
always
like
to
talk
about
is,
like
john,
you
said
you'd
like
to
see
feature
data
as
we
roll
it
out
over
time.
J
So
this
is
some
high
level
health
status
adoption.
So
you
can
see
this
is
dot
com,
just
the
number
of
health
status
assignments.
You
know
we're.
We
had
a
pretty
high
adoption
in
may,
which
a
lot
of
it.
A
lot
of
this
is
actually
scoped
internal
usage
and
pretty
pretty
still
consistent
usage
over
time
last
couple
months.
J
This
top
graph
here
shows
green
bars,
total
number
of
health,
statuses,
health
status,
changes,
the
orange's,
unique
number
of
users
on
dot
com,
doing
that,
and
then
purple
is
unique,
unique
issues
that
have
health
status.
So
we
are
having
consistent,
consistent
usage
from
about
150
to
180
users
month
over
month,
self-managed
as
well,
we've
seen
720
or
excuse
me,
725
total
issues
with
a
health
status
and
107
instances
using
them
so
that
actually,
if
we're
almost
to
a
thousand
instances
on
using
epochs
and
100
of
them,
are
using
health
status.
J
This
is
why
I'm
excited
to
start
surfacing
health
status
and
other
parts
of
the
products,
especially
like
on
boards,
because
right
now
this
is
really
just
valuable
at
the
epic
tree
level
and
if
we
can
actually
allow
people
to
use
workflows
with
that
data
point,
I
think
we're
going
to
see
some
substantial
increase
in
that
usage
and
then
we
already
because
we
knocked
out
the
confidential
epics
and
we
put
tracking
data
into
it
immediately.
We
have
we
have
date
on
that
right
away,
which
is
great.
You
can
ignore
this
august
data.
J
That's
not
complete,
obviously,
because
the
month's
not
over,
but
in
you
know
what
was
it
in
july
we
had
263
confidential
epics
created
a
lot
of
that
is
internal,
but
is
some
some
external
and
then
on
self-managed
we've.
Actually
we
saw
nine
in
the
few
days
it
was
live
before
we
we
did
a
self-managed
data
upload,
so
I'm
excited
to
see
what
that
looks
like
in
august.
So
that's
those
are
my
highlights
anyway.
J
If
there's
anything
else,
you
want
to
see,
let
me
know,
but
again
great
job
overall,
like
we're
driving
real
usage
and
a
part
of
the
product
that
drives
real
revenue,
and
so
we
should
be
extremely
happy
and
proud
about
that.
E
Awesome
thanks
yeah
that
was
really
interesting.
There
was
one
stat
just
at
the
beginning.
I
was
curious
about.
It
seemed
like
it
seemed
like
very
recently.
We
had
growth
in
self-managed
for
a
feature
I
forgot
which
feature
was.
It
was
epics
creation
of
epics.
It
seemed
like
those,
so
the
orange
bar
only
showed
up
by
february.
I
J
D
I
think
over
time
and
I
want
to
be
respectful,
so
I
dropped
a
link
into
the
dashboard,
the
project
management,
one
and
I'll
walk
through
it
next
week
or
whenever
we
have
our
next
time
together,
if
that's
helpful,
but
I
think
the
most
interesting
if
you
look
at
that,
is
towards
the
bottom,
there's
just
a
weekly
featured
option
by
release
and
I'll
just
share
my
screen.
This
one
thing,
because
I
think
it
is
very
interesting
so.
J
That's
that's
a
fun
one,
but
it
is
hard
to
read
the
first
time
so.
D
Yeah
yeah,
so
what
we're
looking
at
here
is
like
how
many
people
are
adopting
plan,
specifically
issues
per
new
release
and
so
like
over
a
course
of
four
weeks.
You
see
things
start
declining,
because
people
are
upgrading
to
the
next
release.
D
So
that's
like
it's
a
normal
curve
after
the
like
kind
of
four
week
points
since
we
released
on
a
monthly
basis,
but
what's
interesting
about
this
is
like
you
can
kind
of
look
at
12.10.
Only
27
of
people
adopt
a
plan
in
in
the
first
week,
which
means
that
they
upgraded
quickly
and
then
started
using
issues
and
so
for
each
release.
D
This
has
steadily
been
going
up
and
then
for
13.2,
it's
up
to
37,
which
is
the
highest
first
week,
adoption
that
we've
ever
had,
and
so
I
think
it's
like
just
an
interesting,
I'm
still
working
with
the
daily
team
to
figure
out
how
to
plot
this
and
understand
the
story
of
as
we
build
new
things.
Is
it
driving
an
increase
in
adoption
rates
for
our
product
and
for
the
features
that
we're
building
and
then
how's
that
trending
over
time?
D
And
so
like
is
it's
cool
to
see
like
because
we're
iterating
on
things
and
adding
new
things
and
making
things
better?
It's
driving
an
increase
in
adoption,
which
is
what
we
want
to
see
because
adoption
is
like
the
leading
indicator
of
more
or
less
being
able
to
generate
revenue.
So
anyway,
cool
data
point
just
thought:
I'd
share
it,
but
you
can
check
out
the
rest
of
the
chart
or
her
dashboard.
If
you
want,
if
you're
interested,
I
can
walk
through
more
next
week.