►
From YouTube: Plan Stage Weekly - 2020-12-09
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
B
Well,
since
there's
not
a
ton
of
stuff,
would
it
make
sense
at
some
point
like
just
to
talk
through
the
current
13.8
planning
issue
together
on
this
call
just
to
review
it,
or
should
we
just
keep
that
entirely?
Async.
A
I
think
there
would
be
value
in
going
through
that,
okay
down
below
cool.
A
So
this
is
what
was
a
somewhat
small
ux
tweak
that
I
think,
will
provide
a
lot
of
value
because
I
think
it's
I
know
I've
been.
I
had
been
struggling
with
this
where
you
go
to
linked
issues
and
try
to
add
a
related
issue,
and
for
this
you
have
to
typically
hit
pound
first
hashtag
first
and
then
it'll
auto
complete
to
some
of
the
issue
ids.
A
Now
with
this
change,
and
it
is
in
production,
it
is
on
gitlab.com
already
you
just
type
in
the
number
and
it
pre-patents
the
the
hashtag
to
the
id,
and
then
you
get
autocomplete
there.
You
can
do
that
and
then
you
can
do
multiple
ones
and
it'll
always
add.
You
can
still.
B
Will
you
try
to
start
typing
and
like
like
you're,
instead
of
adding
the
hash
to
start
typing
like
you
want
to
match
a
word
or
phrase?
I
don't
think
that
works
yet.
B
So
this
is
where,
if
you,
if
you
do
the
hashtag
first
and
then
you
start
typing,
it
will
auto
complete
in
the
title
so
start
typing
whatever
you
want
like,
and
I
bring
this
up.
I
was
on
a
call
yesterday,
where
we
spent
15
minutes
talking
about
this
for
the
customer
who's
confused
about
how
to
do
this
frustrated.
B
So
I
think
that's
where
like
they,
they
had
no
idea
that
you
could
even
do
this
and
they
also
said
well.
I
was
like
well,
you
can
start
with
the
issue
title
or
the
issue
number
and,
like
we
don't
know
what
the
issue
number
is
like.
We
just
want
to
type
in
the
name
of
the
thing
and
like
have
an
auto,
complete
right,
and
so
we
technically
already
do
that.
B
But
it's
not
like
discoverable
in
any
sort
of
way,
and
so
I'm
wondering
where,
like
if
the
right
way
to
solve
that
is
sort
of
saying,
check
the
first
character
that
gets
entered.
If
it's
a
pound
sign,
then
don't
enter
a
pound
sign.
If
it
is
not
a
pound
sign
then
enter
the
pound
sign
and
that
way
like
people
could
still
start
typing
and
auto
completing
because
otherwise
you're
still
going
to
have
to
remember
to
know
to
add
the
pound
sign
manually
and
then
start
typing.
D
A
Yeah
and
I
think
for
this
first
iteration
not
sure
why
we
kind
of
went
the
other
way
where
we
were
trying
to
essentially
autocomplete
on
the
number,
so
they
weren't
required
to
add
the
hashtag
if
they
were
searching
for
a
issue
number,
but
I
think
you're,
right
gabe
for
the
majority
of
people
they're
going
to
be
searching
by
or
they're
going
to
want
to
search
by
title
as
opposed
to
the
issue.
Number.
B
Should
I
open
up
a
follow
up?
Yes,
because
yeah
that's
what
what
they
that
folks
base
says
they
absolutely
did
not
want
to
ever
have
to
copy
and
paste
urls
anymore,
because
it
was
nightmare
from
usability
standpoint.
I
just
want
to
be
able
to
type
and
and
like
match
things.
Should
I
open
up
a
follow-up
issue
to
basically
say
like
handle
autocomplete
well
without
having
to
type
pound
sign,
or
how
do
we
want
to
tackle
that.
A
Say
what
you
broke
up
for
a
second
or
maybe
I
did
sorry
yeah.
I
think
that
that's
what
we
should
do
just
create
a
follow-up
issue
that
we
can
tackle
and
we
can
take
care
of
in
a
future
iteration.
B
Oh
yeah,
so
I'm
curious
as
I
was
like
part
of
the
simplified
groups
and
project
working
group.
There's
this
whole
idea
of
like
we
want
to
merge
groups
and
projects
together
or
like
migrate
them
to
namespace
or
something
so
we
don't
have
to
duplicate
code.
I
think
manage
is
gonna.
Take
they'll
leave
with
a
little
bit
of
that
and
then
we're
gonna
help
out
kind
of
in
terms
of
thinking
through
it.
B
It's
gonna
be
a
joint
effort
between
our
two
stages,
because
what's
gonna
basically
happen
is
there's
going
to
be
there's
something
called
a
work
workspace
that
gets
created
above
all
top
level
groups.
That
is
the
same
thing
as
a
merged
group
and
project
so
that
we
can
can
roll
things
up
across
top
level
groups
for
self-manage,
because
that's
the
big
disparity
between
selfmanaging.com
is
on.com.
You
already
have
a
top
level
group
and
you
only
have
one
and
everything
rolls
up
there
well,
except
for
us.
B
We
have
two
at
kit
lab
and
so,
like
you
don't
run
the
same
problem,
we're
on
self
manage.
You
have
like
you
know,
10
or
12
or
15
top
level
groups,
or
even
more
and
not.
You
can't
share
data
between
the
two
or
issues
or
epics
or
any
of
that
stuff
and
then
sort
of
thinking
about
this.
A
little
bit
more
there's
a
use
case
where
yeah
like
we
can
roll
everything
up
to
this
top
level
like
workspace,
eventually
to
solve
part
of
the
problem.
B
But
then
it's
also
more
nuanced,
like
how
do
we
get
something
like
an
issue
from
gitlab.org
git
lab
project,
to
link
to
an
epic
and
gitlab.com
group,
which
is
a
top-level
group?
And
in
reading
some
of
the
history
like
it's
there's,
not
a
clear
reason
why
we
made
a
decision
to
disallow
that
so
I'm
curious
to
get
some
feedback,
because
this
not
just
for
issues
and
epics.
B
But
this
also
has
practical
implications
for
things
like
iterations,
where,
if
I
wanted
to
create
an
iteration
in
one
top
level
group
or
iteration
cadence,
and
I
then
could
create
or
associate
issues
from
another
top
level
group
or
child
project
there
to
my
iteration,
which
would
sort
of
like
decouple,
allow
everybody
to
have
their
own
groups
with
their
own
iteration
cadences
and
still
pulling
issues
from
anywhere.
B
E
I
cannot
talk
on
the
engineering
on
the
engineering,
but
I
cannot
talk
on
the
decisions
made
when
we
decided
to
make
it
hierarchical
groups
and
so
on,
because
I
was
not
there
when
it
was
all
implemented,
but
like
I
I
don't.
I
think
we
can
link
groups
in
between.
Just
like
we
link
issues
just
have
some
sort
of
a
reference
from
one
group
to
another
right
and
then
you
look
up
permissions
and
so
on.
So
that
is
not.
E
What
I'm
more
concerned
is,
I
think,
the
ux
around
that,
because
when
you
start
cross-linking
a
lot
of
stuff
in
between
each
other,
then
that
can
get
very
complicated,
very
fast
and
yeah
like
as
with
everything,
the
more
stuff
you
link
in
between
the
more
you
have
to
check
permissions
and
and
everything
else,
and
then
obviously
that
can
have
an
impact
on
performance.
E
If
you
have
cross-linked
like
thousands
or
hundreds
of
thousands
of
groups
or
or
objects
right,
then
you
kind
of
have
a
a
problem
there
as
well.
So
I'm
I'm
not
sure,
like.
I
understand
the
need
of
to
have
to
to
be
able
to
link
one
specific
issue
from
one
specific
group
somewhere
in
one
specific
hierarchy
to
some
other
hierarchy
like
I
understand
that
that
is
is
like
something
that
can
happen.
E
I'm
not
sure
how
big
of
a
use
case
that
is
to
to
have
this
type
of
granularity,
and
I
think,
with
this
we
discussed
some
some
time
ago,
like
I,
I
would
incline
more
I'd,
be
inclined
more
to
think
about
sharing
the
whole
feature
like
sharing
issues
from
one
specific
group
to
a
different
sibling,
specific
group.
That
would
seem
to
me
somewhat
not
easier,
because
the
amount
of
work
is
probably
there,
but
perhaps
on
performance
side.
It
will
be
something
like
easier
to
to
grasp.
I
guess.
B
Yeah,
I
think,
if,
if
you
were
to
like
share
all
the
issues
from
one
project
to
another
group,
for
example,
you
could
still
do
something
like
if
those
were
shared,
you
technically
have
access,
but
you
could
also
so
there's
not
a
ton
of
noise.
You
could
basically
say
like
I'm
only
going
to
show
like
if
you
were
to
have
an
issue
that
gets
assigned
to
a
group
that
already
has
access
to
it.
B
Then
you
could
limit
visibility,
just
the
things
that,
like
are
assigned
to
that
specific
group,
so
without
like
having
to
check
access
for
each
specific
issue,
it's
sort
of
like
a
access
and
visibility
or
two
separate
things.
If
that
makes
sense,.
E
Then
combine
that
with
iterations
and
planning,
I'm
not
sure
how
a
shared
item
or
a
shared
issue
would
behave
in
terms
of
planning
and
so
on
in
a
different
hierarchy
where
you
have
different
iterations
and
different
currencies
and
stuff
like
that.
So
how
do
you
combine
the
two?
Do
you
allow
for
multiple
iterations
then
to
be
set
on
the
same
issue?
E
Do
you
import
all
the
iterations
down
as
well
to
be
able
to
see
that
issue?
In
some
words
so,
like
it
seems
simple,
but
when
you
deep
dive
into
these
small
details,
it
does
get
complicated
fast.
B
Yeah,
I
know
I
know
it
does.
I
think
you
also
mentioned
earlier,
like
what
are
the
use
cases,
and
I
got
I'll
be
frank
and
say
that
some
of
our
customers
that
we've
talked
to
who
are
self-managed
will
not
adopt
plan
until
we
fix
this
problem
because
the
you
can't-
and
it
was
another
customer-
the
same
customer
was
talking
to
yesterday,
which
is
even
a
little
bit
smaller.
B
The
engineer
was
on
the
call
and
he's
like
yeah.
We,
we
organized
all
of
our
groups
and
projects
so
around
how
we
wanted
to
structure
our
code,
and
it
has
nothing
to
do
with
how
the
product
managers
want
to
structure
their
roadmaps
right
and
so
they're,
like
they're
forced
into
either
we're
gonna
optimize.
The
way
we
structure
groups
and
projects
for
our
code
or
we're
going
to
optimize
it
for
the
way
that
we
structure
our
roll-up
reporting
and
it's
never
both
and
right.
B
Now,
like
they're
doing
the
workspaces
in
self-manage
will
solve
part
of
that,
because
you
can
roll
everything
up
to
the
top
level
workspace
across
all
of
your
different
groups
and
projects
and
whatever.
So
you
can't
have
the
same
sort
of
experience
that
you
have
on
gitlab.com,
but
you,
you
also
run
the
problem
where
you
have
smaller
teams.
B
You
just
can't
share
things
across
sibling
groups
right
and
so,
like
I
don't
know
the
best
way
to
solve
this
sid
kind
of
shut
down
the
idea
of
doing
a
a
dag,
but
like
I'm
still,
I'm
still
stuck
trying
to
figure
out
how
we
solve
for,
like
our
customers
and
unblocking
their
constraints,
so
they
can
adopt
plan.
I
think
this
is
like
a
big
one
that
I
would
like
us
to
spend
some
time
as
a
stage
thinking
about.
B
They
you
can't
crosslink,
no,
I
don't
think
so.
You
can
roll
things
up
into
a
portfolio
and
the
way
that
they've
done
it
with
jared
line
now
is
jiro
line
is
a
completely
separate
product,
and
so
there
you
can
basically
specify.
I
want
to
pull
in
issues
from
this.
This
project,
this
project
and
this
project
for
and
like
it
doesn't
matter
because
it's
just
using
an
api
to
basically
pull
all
those
things
in
and
it
doesn't
really
respect
hierarchy.
E
On
top
of
this
as
well,
if
the
more
we
move
into
into
customer
issue
types
and
having
two
separate
hierarchies,
this
hierarchy
defines
their
issue
types
in
one
way
and
then
they
want
to
share
with
it
with
a
hierarchy
that
has
totally
different
issue
types.
So
how
do
you
combine,
though?
How
do
you
show
that
new
issue
type
in
the
list
of
of
totally
different
issue
types
and
so
on?
So
I
I
don't
have
an
answer.
E
B
One
of
the
things
I
was
thinking
about
too,
that
might
help,
is
thinking
about,
instead
of
making
all
that's
like
crazy,
flexible
just
making
it
so
that
you
can
better
associate
issues
to
merge,
requests
in
sibling
groups
and
projects
so
like
right
now.
Sort
of
the
problem
is
that
when
you
go
into
an
issue,
there's
a
button
to
create
a
merge
request,
it
looks
directly
at
your
repo
and
that's
it.
It
does.
B
So
that
way,
you
know
when
you
go
to
like
create
your
merge
request
from
an
issue
like
you
would
pick
from
a
couple
different
of
the
connected
repositories
like
you
could
tackle
it.
That
way
as
well.
So,
instead
of
like
making
issues,
super
flexible,
making
or
decoupling
merge
requests
from
issues
if
that
makes.
E
Sense,
it
makes
sense,
but
it
is
a
slightly
different
thing
now
that
you're
talking
about
the
the
coupling
between
merge
requests
and
issues
versus
doing
the
planning
work
across
multiple
across
different
groups.
So
to
say
right
it
do.
It
does
relate
to
the
major
requests,
but
it's
sort
of
different
as
well,
because,
like
the
management
does
not
look
too
much
into
match,
requests
to
my
understanding
they
would.
E
They
would
rather
want
to
do
these
cross
groups
kind
of
planning
of
the
issues
and
not
bother
with
the
image
requests
at
all
and
then,
as
a
developer,
being
able
to
see
the
issues
within
the
message
request
across
all
of
the
groups.
That's
very
easy
and
and
very
handy
for
the
for
the
engineering
and
development,
and
so
there
are
kind
of
two
different
discussions
with
both
our
upon
the
same
problem,
the
same
issue
of
being
able
to
cross
reference
across
groups.
But
it's
slightly
different.
F
B
F
I
can
imagine
how
it
would
work
if
we
would
allow
cross-referencing
of
resources
across
groups,
because
there,
from
user
point
of
view,
what
would
be
what
would
be
a
reason
for
building
a
structure
of
nested
groups
in
such
case,
if
I
can
use
resources
from
completely
different
or
unrelated
groups
anyway,
so
it
would
basically
break
the
the
rule
of
having
a
structured,
nested,
nested
groups.
I
guess,
but
another
reason
why
I
think
I
can
imagine
this.
F
This
could
be
easy
to
do
is
we
would
have
to
do
all
the
searching
and
reference
checks
and
permission
checks
across
all
groups
or
all
related
groups,
and
the
permission
checking
already
is
difficult,
because
if
you
check
issue
in
one
group
or
project,
you
have
to
check
also
permissions
in
all
nested
all
ancestor
projects,
so
we
will
have
to
do
it
for
unlimited
amount
of
associated
issues.
So
it
would
be
quite
a
big
complication
or
something
to
be
aware
of
when
we
implement
this.
B
We
already
do
this
for
issues
where
you
can
relate
issue
from
any
group,
any
project,
any
project
regardless
of
hierarchy
right.
Well,
you.
B
Basically
that,
then
you
can
assign
issues
to
from
any
group
or
a
roadmap
or
some
if,
if
we
don't
figure
out
how
to
solve
it,
like
I
don't
know
how
we're
gonna
scale
effectively.
F
E
Will
not
be
easy,
because
you'll
have
to
now
check
two
higher
well
the
permissions
but
yeah,
but
you
have
to
open
it
already
in
a
way,
I'm
not
sure
if
it's
totally
doing
the
same
thing
that
we
want.
I
mean
I'm
not
sure
if
it's
checking
permissions
through
the
hierarchy
and
all
that
stuff,
but
we
sort
of
have
something
like
that.
F
B
B
If
we
want
to
be
successful,
so
I
think
I'll
ping,
some
of
the
engineers
john,
I
think
I
already
pinged
you
and
alexa
andrew
I've
pinged
you
on
an
issue
where
we're
collaborating
with
mitch
on
merging
the
two
things
so
I'll
include
y'all
and
stuff,
and
we
can
keep
figuring
out
how
to
think
about
solving
the
problem
so
kristin.
I
think
you
have
the
next
item.
G
Oh
yes,
so
this
one's
also
an
fyi
my
team
tom
just
merged
an
update
which
is
in
the
comment
here
on
our
design
management
usage
pane
for
the
gmail.
So
since
designs
have
moved
over
to
product
planning,
I
just
want
the
team
here
to
look
at
that
and
make
sure
that
it's
okay
tom
is
a
front-end
engineer,
I'm
not
for
sure
that
back-end
has
looked
at
it.
Yet
we
do
want
all
of
designs
being
viewed
edited
or
created
deduped
into
monthly
active
users
on
that
on
the
chart
the
existing
chart.
B
It's
also
worth
adding
we
added
some
trackers
for
not
views,
but
I
added
a
few
trackers
for
design
management
things.
So
I
will
pull
up
the
mrs
for
that
too,
and
kind
of
show
you,
but
it
was
part
of
the
work
we
did
for
issue,
tracking
and
tracking
all
the
interactions
on
an
issue.
G
Oh
nice,
that
makes
sense
yeah.
We
should
probably
have
a
I'll
move,
the
knowledge
dashboards
over,
so
we
have
them
under
plan
too.
Just
so
we
start
looking
at
it.
There
there's
a
really
huge
uplift
and
spike,
which
I
don't
believe
it
went
up
to
like
80
000
in
a
month
which
doesn't
make
any
sense,
so
I
don't
trust
their
math
on
on
that
chart
that
I
linked
there.
G
Okay,
john,
it
looks
like
you've
got.
C
Yeah
out
of
the
comments
ears
as
well,
I
wonder:
did
you
want
to
talk
to
the
priority
of
that
epic
user
events
issue
as
well
like
which
do
you
want?
Are
we
looking
to
do
both
of
these
within
a
certain
period
of
time,
or
do
you
have
them
both
in
mind
for
13
8,
or
you
want
to
spread
them
out
like?
What's
the
urgency.
G
Issue
counts,
isn't
that
are
these
ones?
Do
you
mean
epic,
the
epic
ones
we
were
talking
about.
G
G
I
think
that
the
sooner
like
design
management
is
like
second
priority
kind
of
right
now,
so
we
have,
we
do
have
our
main
gmail,
so
they
are
competing
priorities
if
it's
one
release
on
the
issue
counts
and
then
one
on
design
management
that
works.
If
we
do,
the
issue
counts.
First,
from
my
perspective,.
C
Okay,
cool
thanks,
yeah,
okay.
I
have
the
next
item,
so
yeah
there's
an
opportunity
here
to
get
a
really
quite
straightforward
performance
win
across
multiple
pages
yeah.
So
let
me
just
ask
quickly:
like:
does
anyone
have
a
strong
opinion
for
or
against
counts,
in
the
sidebar
being
truncated
and
rounded
at
the
minute?
For
example,
we
have
a
bug
where,
if
you
look
at
the
number
of
issues
in
gitlab
org
on
the
sidebar,
it
says
something
like,
let's
say
forty
five
thousand
nine
hundred
and
ninety
something.
C
And
then,
if
you
look
in
the
issue
list,
it's
like
forty,
nine
thousand
nine
hundred
and
eight
or
something
right
so
like
there's
a
tiny
discrepancy.
Anyway,
this
kind
in
the
sidebar
is
costing
us
sometimes
north
of
350
milliseconds
on
the
initial
page
load,
which
means
350
milliseconds
off
the
bottom
line.
Right
because
we
don't
load
anything
on
the
page
until
we've
loaded
the
initial
page
load.
So
taking
that
away
would
save
us
like
350
milliseconds
and
it's
quite
an
easy
win.
C
The
downside,
if
you
can
call
it
a
downside,
is
that
we'd
have
to
run
some
numbers
because
we
can't
guarantee
at
any.
Given
time
the
numbers
are
exactly
accurate
in
the
sidebar,
so
if
you
feel
strongly
that
we
shouldn't
do
that,
I'd
like
to
hear
your
opinion
now
otherwise
like
why
shouldn't
we
do
this.
If
there
are
any
other
reasons.
A
C
Yeah,
so
the
way
the
code
would
work
would
be
that
it
would
check
the
cache
anyway,
every
time
like
because
it
because
it
doesn't
know
in
the
code
path
like
that.
There's
only
20
issues
in
this
group
that
you're
looking
at,
like
it
checks
the
cache
first
for
an
entry
and
if
it
doesn't
find
anything,
it
goes
to
the
database
so
we'll
check
it
anyway.
So
there's
no
reason
not
to
cache
it
anyway.
C
As
regards
the
running,
we'll
cache
the
exact
number,
but
because
the
cache
will
go
stale
at
some
point,
possibly
during
the
time
period
like
over,
which
will
expire
the
key,
we
can't
guarantee
that
it'll
be
the
exact
kind.
The
user
will
see
so
raining.
It
solves
that
problem.
We
also
have
to
like
think
about
certain
events
which
might
cause
us
to
bust
the
cache,
so
large
imports
bulk
operations
like
deletions
and
so
on,
but
for
most
operations
in
a
group
really
like
we
should
be
able
to
set
it
for
like
a
day.
C
You
know,
and
then
it's
it's
set.
So
only
the
first
visitor
will
warm
the
cache.
We
won't
do
any
pre-warming
of
the
cache,
we'll
just
let
the
first
visitor
experience
the
current
the
current
load
time
of
whatever
it
is,
and
then
every
visitor
thereafter
to
that
group
it'll
just
be
drawn
from
the
cache.
It's
such
an
easy
win
and
it
gets
us
so
much
in
return
and
then,
if
anyone
does
really
care
about
the
exact
number
of
issues
they
have,
they
can
still
go
to
the
issue
lists.
G
G
C
The
issue
sidebar
like
okay,
would
be
a
candidate
for
this
as
well.
Like
the
sorry,
the
project
sidebar,
I
believe,
which
draws
another
kind
that
draws
the
kind
of
issues
and
projects
not
in
the
group,
but
the
group
sidebar
joins
all
the
projects
onto
that
group
grabs
the
issues
and
that
query
is
and
then
checks
permissions
for
the
user,
so
that
query
is
quite
quite
yeah,
slow,
especially
on
larger
projects,
so
yeah
they
could
go
to
the
issue
list.
C
G
D
D
D
D
I
agree
with
that.
I
think
the
sidebar
it's
irrelevant
for
me
at
least
on
the
way
I
use
gitlab.
I
think
when
you're
filtering
it
makes
sense,
but
even
filtering.
I
would
argue
that
we
could
do
something
like
500,
plus
or
just
come
back
and
say
yeah.
You
have
500
plus
issues,
because
again
the
purpose
of
most
filtering
is
to
be
like:
hey
either
I'm
trying
to
get
down
to
see
a
specific
set
of
issues,
in
which
case
I'm
looking
for
20
to
30
that
meet
my
criteria
or
I'm
trying
to
get
a
rough
estimate.
D
B
I
I
don't
mind
removing
it
entirely
like
I
don't
at
least
from
the
sidebar,
the
other
thing
that
I've
been
thinking
about
a
little
bit
more.
Just
in
situations
like
this
is
like
I've
noticed
and
I
think
jake.
You
brought
it
up
like
a
lot
of
times.
B
We've
made
sort
of
these
engineering
decisions
based
on
the
idea
that
we
need
to
hide
certain
things
due
to
authorizations
or
if
there's
a
confidential
issue
in
a
project
that
we
shouldn't
disclose
that
that
even
exists
anywhere,
and
I,
like
we've
sort
of
already
breached
that
ground,
where
we're
showing
weight
from
confidential
issues
rolling
up
into
epics
and
on
to
like
burn
down
and
burn
up
charts
on
milestones
and
iterations,
like
that's,
not
a
security
risk
to
say
that
there
is
something
that
exists
because
you're
not
disclosing
any
information
about
it,
and
so
like.
B
I
wonder
if
there's
an
opportunity
to
like
switch
towards
using
things
like
postgres
events
and
event,
listeners
to
keep
tables
across
groups
and
projects
updated
when
new
events
or
when
new
issues
or
whatever
do
change.
So
that
way,
we're
not
like
having
to
query
it
every
single
time
and
it
will
always
be
updated
correctly
on
the
table
whenever
we
requested
the
page.
That's
the
other
thing.
B
If
we
wanted
to
keep
it
and
have
it
be
more
performant,
taking
an
approach
like
that,
but
just
two
thoughts,
but
I
think
if
we
want
to,
if
we
want
to
experiment
with
getting
rid
of
it,
just
put
in
we're
doing,
we
did
this
with
the
add
issue
side
or
button
on
a
board.
We
just
put
it
behind
a
feature
flag
in
the
ui
and
disabled
it
and
we're
waiting
to
see
if
anybody
complains
there's
nobody.
Nobody
complains
that
we're
just
going
to
like
delete
together.
So
we
can
do
the
same
thing
with
this.
A
A
There
were
issues
with
the
sidebar
count
for
test
cases
and
not
to
say
that
it's
a
bad
idea
to
remove
it
from
the
sidebar
for
issue
count,
but
it
just
kind
of
signals
that
people
do
use
that
count,
and
then
the
thing
I
also
worry
about
is
for
for
non-gitlab
projects
like
we're
kind
of
looking
at
it
at
the.
What
do
we
have
35
000
issue?
Count
where
that
count
has
no
value
for
smaller
projects
for
smaller
organizations.
A
H
There
yeah,
I
think,
there's
definitely
about
like
when
you
have
10
issues.
If
you're
running
a
small
like
open
source
project,
you
have
10
issues
like
okay.
I
have
10
things
to
do.
That's
like
a
very
valuable,
like
signal
that
said,
the
performance
impact
of
the
accounts
isn't
bad
at
that
at
that
scale,
either
so
they're
like
fine
to
keep
like
they're,
not
costing
anything
so
having
having
it
on
a
like.
H
A
group
level
feature
flag
that
we
could
have
counts
off
for
gitlab
org
and
have
them
on,
for
you
know
some
small
open
source
project
or
whatever,
but
I
also
am
in
favor
of
doing
like
the
non-granular
estimates,
because
I
think
that
kind
of
get
the
best
of
best
of
both
worlds,
where
we
have
at
least
some
signal
there
of
like
how
much
how
many
issues
there
are.
But
it's
super
fast.
D
D
C
Gabe
mentioned
storing
the
kind
on
the
table
itself.
Just
the
sake
of
completeness.
There
is
a
feature
in
rails
called
counter
cache
which,
as
long
as
you
do
everything
the
rails
way,
will
automatically
update
the
kind
on
the
parent
object.
So
in
this
case
anytime,
anyone
interacts
with
an
issue
that
has
a
group
id
it.
C
Would
you
know
increment
or
decrement
the
counter
on
the
group
automatically
and
there's
no
reason
why
you
kind
of
have
a
second
counter
cache,
which
is
confidential,
counter
cache,
and
then
it's
just
a
case
of
summing
the
two
or
leaving
out
the
confidential
one.
If
the
user
can't
access
it,
but
it's
just
that.
C
That's
a
bigger
job
and
it
also
means
we
have
to
go
through
all
our
services,
all
our
the
ways
that
we
can
create
and
import
issues
and
make
sure
that
they're
compliant
with
the
real
way
of
doing
things
which,
like
spoiler
alert,
they
won't
be
like.
So
it's
a
bigger
job,
whereas
this
is
like
kind
of
an
easy
win
and
if
we're
cool
with
it
like
like,
if
we're
cool
with
this
rounding
of
the
numbers,
then
it's
something
we
could
do
in
a
milestone.
F
I
was
the
using
caching,
I
mean
outside
of
database,
might
be
a
simpler
or
better
solution,
because
if
we
keep
counters
for
each
table
or
project,
we
would
still
have
to
go
through
the
structure
of
the
group
and
we
wouldn't
get
rid
of
the
relatively
expensive
query
to
get
all
the
descendants
of
the
of
the
group.
So
and
we
wouldn't
gather
it.
We
wouldn't
get
rid
of
the
major
issue
with
caching,
which
is
invalidation
of
the
cache.
G
G
I
don't
want
to
mess
up
flows
that
are
already
happening
on
the
team,
but
I
want
to
show
potentially
a
more
consistent
way
to
visualize
the
whole
of
the
release
and
just
see
where
things
are
at
so
I'm
gonna
I'm
going
widescreen
and
sharing
my
screen
here,
because
it
does
take
up
a
fair
amount
of
real
estate
and
I
do
have
a
gitlab
better
boards
plug-in
installed,
which
is
these
lines
across
the
top
which
are
filters.
So
I
am
cheating
the
system
a
little
bit
with
this.
G
G
So
what
I've
got
here
is
basically
everything
on
our
plate
under
product
planning
in
one
board.
What
I'm
noticing
is,
as
we
look
at
like
13
7.
So
if
I
just
scope
down
to
that
label.
G
G
What
I've
done
on
other
teams
is
only
really
use
the
milestones
for
things
that
we're
going
to
ship
anything
that
ems
and
the
engineers
commit
to
that
is
in
ready
for
development,
would
have
the
label
on
it
and
then,
when
we're
rolling,
when
we're
in
the
release
and
building
in
the
build
track,
it
would
really
always
be
these
last
columns
that
we're
looking
at
and
everything
else
gets
their
milestone,
label
removed
or
gets
punted
like
for
a
lot
of
these.
They
would
punt
over
to
thirteen
eight
or
thirteen
nine
immediately.
G
Just
so
I
clean
out
the
junk
drawer.
We
also
when
I
look
at
this
scope
or
grouped
by
epic.
I
was
able
to
see
if
we
just
let
this
spin
for
a
sec,
that
there
are
a
lot
of
these
issues
down
below,
which
is
just
like
a
flag
to
me
that
are
not
in
epics
way
down.
G
Issues
with
no
epic
assigns.
Some
of
these
may
have
been
created
by
engineers
on
the
fly
added
in
extra
weights,
getting
a
process
around
this,
where,
if
a
new
issue
is
created,
we
that
we
have
discussion,
we
move
it
quickly
to
the
next
release
or
we
bring
it
on
the
board
immediately
and
it
goes
into
ready
for
for
development
or
the
blocked
column,
and
we
know
that
we
just
added
like
two
points
to
that
capacity.
G
B
Yeah,
you
might
need
to
just
do
some
since
you're
kind
of
taking
over
do
some
house
cleaning.
I
had
to
do
this
for
a
couple
of
releases
in
a
row
where
I
basically
had
to
move
everything
out
and
so
like.
B
I
got
to
the
point
now
where,
thanks
to
like
donald
and
jake,
and
a
lot
of
the
engineers
and
ux
folks
contributing
to
clean
stuff
up
we're
at
a
point
where
it's
just
sort
of
like
what
you're
talking
about
where
we
don't
put
milestones
on
anything
until
it
gets
into
planning
breakdown.
I
even
deleted
the
scheduling
list,
because
it's
just
one
more
queue
that
yeah
I
mean
is
annoying
to
a
certain
degree.
G
D
G
A
lot
of
this
in
1307,
I
think,
like
I,
the
thing
I'm
not
sure
about
those
just
we
don't
have
for
like
community
contributions
for
engineer
added
items.
We
don't
have
a
flow
yet
of
what
happens
to
them
so
like
we'll
just
have
to
talk
about
that
more.
G
G
That's
the
conversation
that
we'll
have
to
have,
I
guess
in
the
last
week
of
this
release
week
or
two,
but
I'm
going
to
start
doing
the
release
posts
on
all
of
them.
Just
wanted
to
mention
that.
D
G
G
We
would
in
knowledge
we
would
pair
with
an
engineer,
would
kind
of
oversee
or
at
least
be
on
the
community
contribution,
and
it
would
be
on
the
board
like
everything
else,
so
it
was
integrated
with
the
team.
C
Because
we've
had
an
uptick
in
community
contributions
on
the
back
end
and
just
mostly
lee,
but
a
couple
other
people
as
well.
We
have
on
the
billboard
a
separate
queue
for
community
contributions
and
they
all
go
in
there.
The
simple
reason
that
we
can't
in
the
way
that
we
can,
with
our
own
internal
team
members
like
we,
can't
guarantee
a
schedule
when
we
have
contribution
from
a
community.
A
D
G
D
A
Like
john
said,
I
think
what
we
have
been
doing
is
on
the
billboard.
We
just
have
a
separate
label
and
essentially
treat
it
like
its
own
workflow
label
and
that's
where
we
keep
track
of
of
community
contributions
and
how
we
need
to
guide
them
or
help
them
through
those
yeah.
G
C
I
find
actually
sometimes
contributors
at
labels
or
milestones
themselves
and
yeah
like
it's
it's
hard
to
make
the
argument
that
like
if,
if
they're
volunteering
their
time
and
they
want
to
track
in
a
particular
way,
I've
always
feel
bad,
telling
them
or
removing
a
label
when
they've
added
it
or
removing
a
milestone
when
they've
added
it,
especially
if
they
do
feel
like
they
can
get
it
done
in
that
time.
C
Oh,
it
might
have
been
me
as
well,
I'm
not
sure
because
that's
a
whole
stream
of
work
add
multiple
participants
to
service
desk
issues
has
about
five
four
or
five
different
issues
involved
in
it
and
he's
assigned
to
all
of
them,
so
he's
actually
delivering
that
entire
stream
of
work
himself
so
yeah
it
could.
It
could
have
been
him
on
some
issues
and
myself
and
the
others
I
probably
just
wanted
to
keep
them
consistent
to
be
honest,
rather
than
have
some
in
a
workflow
state.
C
So
I'm
not
some
in
the
milestones.
I'm
not.
D
I
D
G
F
I
believe
there
were
some,
mrs
from
from
the
recently
related
to
service
desk
participants.
D
No,
we
would
just
take
them
right
off
and
backlog
them
right
now.
Service
desk
is
completely
on
hold
for
us
as
long
as
it's
not
a
bug
fix,
so
the
only
life
being
breathed
into
service
times
right
now
is
lee,
which
is
why
I'm
even
more
reluctant
to
discourage
that,
because
you
know
if
it's
not
a
bug
or
it's
not
impacting
people
we're
not
really.
G
Yeah,
okay:
we
can
talk
about
this
more
later.
I
understand,
what's
going
on
now
with
it,
I
think
we're
at
time.
I
wanted
to
go
through
planning
breakdown,
but
I
don't
want
to
go
over
time
here.
G
I've
got
a
list
here.
This
can
be
read
only.
This
is
a
comment
from
alexis
supporting
the
susan
initiative.
So
we
have
this
push
within
product
where
we're
all
signing
up
to
do
specific
fixes
to
try
to
fix
the
sus
survey.
So
these
are
the
suggestions
from
her
feel
free
to
also
comment
on
this
or,
if
you
know
of
one
that
would
help
with
that
ux
score.
G
And
then
this
is
an
open
question
that
can
go
async,
we're
discussing
settings
of
like
the
the
filter
on
the
swim
lanes
and
whether
or
not
it
would
be
a
user
setting
or
a
board
setting
or
global.
G
So
I
was
just
more
asking:
is
there
a
chart
somewhere
a
table,
something
architecture-wise
where
maybe
we're
logging
every
type
of
setting
around
boards
and
issues
and
road
maps
and
which
ones
are
persistent?
Which
ones
are
users
which
ones
are
board
settings?
So
we
can
just
sort
of
get
clear
on
that
and
see
the
big
picture.
So
we
make
consistent.
G
F
That's
a
good
question.
I
don't
think
we
are
super
consistent
in
this.
I
know
we
have
couple
of
boards
related
user
preferences,
both
boards
preferences
and
board
user
preferences
tables,
where
we
store
server-side
user
data
or
settings
per
port,
but
I
know
there
are
also
some
use
cases
when
we
use
client-side
caching.
F
G
A
Yeah
boards
are
a
little
bit
different,
like
I
think,
the
only
thing
we
cache
on
the
user
side
and
when
I
say
user,
it's
not
really,
oh.
Actually,
there
is
so.
I
think
we
do
have
user
settings
and
then
we
have
local
storage.
I
was
going
to
say
the
only
thing
we
store
in
local
storage,
so
that
would
essentially
be
browser
state
is
the
labels
I'm
hiding
and
showing
everything
else
is
stored
on
the
back
end.
G
G
B
We
love
input,
things
that
at
least
at
least
for
my
group
that
I
haven't
listed-
that
we
should
consider-
and
I
also
wanted
to
ask
everyone
to
help
weighing
some
of
those
issues
that
haven't
been
weighted
yet
or
breaking
them
down
just
because
I'm
gonna
try
really
hard
not
to
put
too
much
weight
into
this
milestone,
and
I'd
like
to
do
like
eighty
percent
of
what
our
velocity
has
been,
or
maybe
even
seventy
percent.
So
I
just
need
to
know
what
things
I
have
to
kick
out
from
a
prioritization
standpoint.
B
If
we
need
to
make
that
decision
or
if
there's
like
other
things
that
we
should
do
before
some
things
are
listed,
raise
that
stuff
just
so,
we
can
all
stay
on
the
same
page,
but
I'd
like
to
get
this
figured
out
by
the
early
next
week,
so
that
we
can
get
that
the
planning
issue
cleaned
up
before
we
do
the
kickoff
video
I'm
trying
to
follow
the
release
timeline
a
little
bit
more
structured
way.
So
it
doesn't
feel
like
a
rush.
So
love
y'all's
help
with
that.