►
From YouTube: Plan Stage Weekly 2020-08-12
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
Password,
it's
really
strong
cool.
We
can.
We
can
get
started
for
posterity.
This
is
august
12th,
apac
plan
weekly.
D
D
D
Like
these,
these
two
shared,
like
the
same
logic
at
the
at
the
parent
component
and
the
same
behavior,
that
we
saw
on
the
on
the
regular
board
like
this
one
and
it
looks
empty,
but
we
are
keep.
We
keep
working
on
adding
more
items
this
week
like
the
labels,
for
example,
and
yeah.
That's
it
it's
a
quick
one.
D
No,
no
is,
it
is
a
new
one.
In
fact,
as
you
can
see,
we
don't
actually
have
we.
We
still
need
to
connect
it
with
the
actual
issue.
We
don't
have
like
the
issue
title
or
the.
G
E
It
does
that's
super
exciting,
so
we're
thinking
as
far
as
at
least
the
presentational
side
of
it
of
going
with
the
annex.
We
talked
about
this
earlier,
I'm
going
with
labels
next
gabe.
I
think
you
recently
maybe
today
on
trying
to
get
the
close
button
that's
available
in
get
lab
ui
done
on
the
sidebar,
so
that
should
be
a
simple
thing
just
to
replace
it,
but
we
don't
use
the.
E
C
Hold
off
do
we
have
a
definitive
list
of
all
the
places
where
we
need
to
refactor
over
to
pajamas.
E
Well,
we
have
issues,
I
don't
know
if
we
have
it
all
listed
in
one
place,
but
I
will
add
that
to
my
list
to
do.
C
Cool,
I
can
help
too.
I
don't
really
know
where
all
the
places
are,
but
I
can
you
know,
look
at
like
files
in
our
repo
and
try
to
figure
it
out
if
that's
helpful,
but
I
do
think
consistency
should
be
our
first
goal
for
the
user
experience,
and
that
means
that
we
have
to
delay
that
for
that
open
to
opinions,
if
others
disagree,
but
that's
my
take.
E
Yeah-
and
we
can
probably
I
mean
it's
just
passing
a
prop
down
a
view-
only
prop
down
to
the
gitlab
ui
component,
so
once
we
once
we
get
every
component
or
every
sidebar
component
to
use
the
gitlab
ui
labels,
then
it'd
be
super
easy
to
turn
it
on
everywhere.
C
Cool
that'd
be
awesome
yeah
I
know.
Sometimes
when
I
was
like
selecting
a
label
from
the
drop
down
or
something
it
was
a
scope
label.
It
wasn't
styled
the
same
way,
so
that
was
even
jarring.
So
I'm
all
for
optimizing.
Like
consistency.
First
cool.
E
Okay,
I
have
the
next
demo
for
kushal
and
eugenia.
E
All
right
so
on
this
is
local.
The
component,
the
gitlab
ui
component
here,
is
still
behind
a
feature
flag
because,
as
we
said
last
week,
I
believe
there
are
still
some
some
issues
that
we
need
to
fix
before
we
can
turn
this
on
in
production
so
locally.
We
have
milestone
here.
E
Cool
and
then
we're
able
to
filter
by
milestone.
We
also
get
this
with
the
epics
list
view,
which
would
be
good.
So
my
question
on
here
is
so
this
is
behind
the
feature
flag
for
the
gitlab
ui
component,
which
we're
not
going
to
be
able
to
get
for
at
least
a
couple
weeks.
E
It's
a
fairly
easy
fix
to
add
this
to
the
old
hamel
filter
bar.
The
only
problem
is
we
don't
support,
not
filtering
on
a
milestone
yet,
and
it
is
extremely
difficult
in
the
old
hammel
filter
search
to
say:
don't
give
me
not
filtering
just
for
milestone,
so
users
would
have
the
option
to
not
filter
a
milestone.
It
just
wouldn't
work.
E
So
again,
my
question
is:
are
we
okay
with
that?
Or
do
we
hold
off
on
adding
milestones
until
we
get
this
get
my
ui
component
done.
E
C
Hey
sorry,
I
was
trying
to
add
something
to
jin
at
the
same
time,
you're
doing
that.
Are
you
saying
that
there's
not
hold
off
until
what
happens
again.
E
So
we
can,
we
can
add,
milestones
to
the
old
version
where,
because
not
filtering
is
not
supported
on
the
back
end
yet,
but
in
order
to
add
the
ability
to
not
so
many
knots
in
order
to
add
the
ability
to
to
have
it
like
we
have
it
here
where
it
just
shows
the
equal
and
doesn't
even
give
you
the
option
to
not
filter
it's
it's
really
hard
to
do
on
the
on
the
haml
version
of
this.
E
A
Yeah,
let
me
I
can
track
down
the
issue,
but
there's
there
are,
there
are
filter
bars
where
you
can
select,
not
equals,
and
then
it
has,
for
example,
milestones,
but
you
can't
like
when
you
do
it,
it
just
does
nothing
and
then
we
so
that
is
to
say,
like
there
are
places
where
that
problem
exists.
Now
this
would
be
one
additional
place
where
that
problem
exists,
but
I'll
leave
it
to
the
I'll
leave
to
gabe
to
make
a
judgment
call
on
which
of
those
is
worse
or
better.
C
I
I
think
I
I'm
not
really
sure
like
how
everything's
implemented,
but
I
would
ask
the
question
of
like
is
this:
does
it
not
work
because
we
haven't
implemented
a
graphql
query
or
some
parameter
to
pass
through
or
something
in
the
rest,
but
I
gotta
expect
everywhere
across
the
product
the
filter
bar
to
work
exactly
the
same
and
always
work
so
yeah
I,
if
it
doesn't
now,
we
should
like
write
out
an
issue
why
it
doesn't
and
all
the
place
the
things
that
need
to
be
fixed
and
figure
out
how
like,
when
we
do
implement
it.
C
It
works
well,
so
I
wouldn't
add
on
to
it.
That's
all.
B
Yeah
I
we
should
keenan's
the
dri
for
this
feature
right,
so
we
should
let
him
weigh
in
tomorrow
when
he's
online.
My
vote
is
option
b,
which
is
like,
let's
not
add
the
debt.
Now,
if
we,
if
we
know
we're
going
to
implement
it
and
fix
it
or
make
it
work,
then,
and
that's
like
in
the
near
term,
then
let's
just
wait,
but
we
can
let
keenan
weigh
in
and
then
I
agree
with
gabe.
E
Okay,
I
have
the
next
two,
but
I
need
to
switch
to
master.
So
I'm
going
to
let
simon
jump
up
and
demo
his
stuff
while
I
switch
over
please.
Let's
do
it.
F
E
F
E
F
F
C
F
C
C
Two
somebody
reported
this
is
like
an
issue
early
on
that
they
didn't
like
and
in
the
next
release
we
will
have
a
fix
for
it
directly,
which
is
great
turnaround
time
on
feedback,
and
I
do
think
it's
like
sort
of
you
know
it's
one
of
those
like
quality
of
life
things.
It's
pretty
it's
like
a
small
detail,
but
it
adds
the
overall
like
experience,
which
is
great,
I'm
excited
for
it.
F
E
Well,
let's
just
talk
through
it,
then,
because
yeah,
it's
essentially
just
iterations
view
within
a
project.
There
is
some
conversation
in
the
issue
that
I
think
gave
your
following
and
providing
feedback
on.
I
don't
know
what
the
latest
on
that
was,
but
what
we're
still
still
trying
to
figure
out,
because
it's
confusing,
because
a
little
bit
different
than
how
we
do
project
inheritance
in
other
places,
because
we're
essentially
saying
it's
still
a
group
iteration
just
scoped
to
issues
within
a
project.
C
Is
that
correct
yep?
So
it's
like
the
reverse
of
how
things
roll
up
things
roll
down.
So
the
reason
why
is
like
in
a
lot
of
use
cases
there
will
be
some
consultant
or
some
part
of
the
team
who's
only
given
permission
to
a
project,
and
so
if
they
want
to
be
able
to
see
their
report
view
and
they
don't
have
access
to
the
group,
there'd
be
no
way
for
them
to
ever,
see
that
so
it's
kind
of
like
the
inverse
of
like
like.
C
I
think
this
is
the
more
accurate
way
to
inherit
things
from
a
top
level
group
down
into
your
project.
So
you
can
see
it
scope.
Just
to
your
thing,
it's
the
same
problem
where
we
have
where
labels
in
your
project
that
are
group
labels
from
you
know,
two
groups
up
don't
show
up
in
your
project,
even
though
you
can
add
them
to
your
issues
in
your
project
or
milestones.
C
You
can
add
to
your
issue:
don't
show
up
in
your
milestone
list,
and
so
it's
just
like
a
weird
thing,
where
you're
always
having
context
switch
into
a
different
group
or
a
parent
group
in
order
to
see
progress,
scope
to
just
a
given
project.
So
the
group
by
is
so,
you
can
see
things
at
a
rolled
up
view,
and
then
this
is
so.
You
can
see
things
like
within
that
specific
project
without
leaving
it.
If
that
helps.
E
Cool
yeah,
that
makes
sense.
I
don't
know
what,
where
we
were
at
as
far
as
that.
So
I
don't
know
if
we
have
any
questions
any
further
questions
on
that,
but
we
can
just
look
through
the
the
issue
and
see
if
there
are.
C
Yeah,
I
think,
though,
the
last
comment
I
made
was
just
clarifying
the
goal
because
I
think
at
one
point
there
there
was
a
suggestion
or
proposal
to
just
like
add
a
link
to
the
group
iteration
report
view
with
some
like,
like
already
pre-selected,
to
just
show
the
project
information
there,
but
that
doesn't
solve
the
use
case
of
I
don't
have
access
to
that
group.
So
how
can
I
see
the
report
so
I'll
check
back
in
I'm
about
178
to
do's
behind
but
yeah?
I
think
we'll
figure
it
out.
F
I
did
have
one
question
on
the
inheritance
thing:
if
we're
for
subgroups,
if
in
the
iterations
list
we
see
the
iterations
from
the
parent
group,
but
then
clicking
them
goes
to
the
actual
parent
group
iteration.
C
Yeah,
so
it's
all
one
iteration,
it's
the
same
one,
but
it's
like
the
you
can't
edit
it
unless
you're
in
the
top
level
group
or
in
the
group
where
the
iteration
belongs
to
and
subgroups
should
also
behave,
the
same
way
as
projects
in
a
perfect
world.
So
if
I'm
looking
at
it
within
a
subgroup-
and
I
inherited
the
iteration
from
parent
group-
I
shouldn't
be
able
to
edit
with
it
within
the
subgroup.
But
I
still
should
be
able
to
look
at
the
report
there.
So,
okay,
it's
okay!
F
B
E
F
E
E
Okay,
so
we
previously
had
the
ability
to
mark
an
epic
as
confidential
when
creating
an
epic,
but
once
it
was
confidential,
you
were
stuck
with
it
being
confidential
because
we
didn't
have
a
way
to
update
it,
which
we
do
now,
I'm
on
master,
so
it
is
merge
in
a
master,
should
be
in
production
in
just
a
day
or
two
a
couple
days.
Hopefully,
okay,
so
I'm
in
an
epic.
Now,
as
you
can
see,
our
normal
epic
sidebar
now
has
confidentiality
I
want
to
edit
it
turn
on
confidential.
E
E
And
then
we'll
try
to
again
the
error
works
too,
because
we
cannot
make
a
cop
or
make
an
epic
confidential
if
it
has
public
issues.
If
we
were
to
go
into
here,
make
this.
G
C
No,
I'm
not,
but
it's
a
discussion
which
point
number
three
is
issue
specific
discussion
and
demos.
So,
but
I
we
had
our
real-time
working
group
synchronous
call
this
morning
and
we
now
support
websockets
and
real-time
assignees
for
single
instances.
I
think
in
13.4
we
will.
C
The
infrastructure
team
will
be
able
to
get
websockets
working
in
kubernetes,
which
means
that
we
can
use
it
on.com
and
so
we're
kind
of
servicing
we're
at
the
point
now
where
we
can
start
making
all
the
fields
in
the
sidebar
real
time
which
I
haven't
raised
the
issues.
Yet
today
I
will
do
it
tomorrow,
but
I
just
wanted
to
surface
it.
C
That
it'll
probably
require
some
front-end
refactoring,
because
I
think
right
now
the
way
that
we
implement
implemented
the
science
field
is
it
does
some
conditional
checking
if
websockets
is
active
and
then
it
uses
a
different
component
and
I'm
not
sure.
But
the
like
query
for
the
websockets
connection
is
just
on
the
the
assignee
field,
but
we
might
want
to
move
it
out
towards
the
sidebar
container
and
or
even
theoretically,
the
entire
issue.
C
If
we
can,
because
I
think
each
issue
will
be
its
own
channel-
that
you
can
connect
to
to
get
broadcast
when
things
change,
so
I
more
or
less
just
wanted
to
say
like
it's
awesome.
Heinrich's
done
amazing
work
to
get
us
this.
This
far
and
scott
did
great
work
on
the
first
front,
end
feature
for
real
time
and
I
think
we're
at
the
point
we're
ready
to
start
scaling
it
out
to
more
fields.
So
for
how
that
impacts,
things
going
on
on
issue
boards
and
all
these
other
places.
C
B
That's
awesome.
I'm
super
impressed
because
I
know
that
that's
really
challenging,
and
especially
within
our
application.
It
was
a
long,
long
road
to
get
us
to
where
we
are
now.
But
I'm
super
excited
we're
here
and
excited
that
we
can
start
to
raise
the
issues
around
where
else
to
make
things
real
time,
which
is
going
to
be
great.
C
Yeah
we
saw
some
work
around
with
quality
engineering
and
just
to
make
make
sure
that
it's
performing
at
scale
and
that's
so.
I
think
we
might
have
to
like
balance
some
things
and
slowly
scale
it
out.
But
what
is
also
nice
is
like
two,
I
think
two
or
three
months
ago
they
had
a
broadcast
to
the
graphql
ruby
gem
so
like.
That
is
what
lets
you
broadcast:
a
single
change
to
many
connected
clients,
which
will
be
a
huge
performance
gain.
C
So
you
wouldn't
have
to
do
like
a
separate
transaction
for
every
single,
like
request
for
new
data,
so
we're
exploring
that
too
and
yeah
it's
it's
exciting.
I
like.
I
would
like
to
keep
it
slow
and
just
like
just
do
the
sidebar
and
get
that
on
issues
and
get
that
on.com
production
and
then
take
some
performance,
measurements
and
memory
measurements
to
make
sure
that
we're
within
acceptable
ranges.
Then
I
think
after
we
get
that
stabilized,
it
will
be
off
to
the
races,
for
I
think
any
group
that
wants
to
use
websockets,
real-time
stuff.
B
B
I
have
the
next
one:
it's
mostly
an
fyi,
so
I'm
I'm
just
using
this
time
to
tell
you
about
it
and
to
encourage
you
to
contribute,
but
I
opened
an
issue
yesterday,
after
talking
with
the
rest
of
the
pms
and
engineering
managers,
to
do
an
rca
around
some
of
our
recent
challenges,
around
sort
of
being
over
capacity
over
committed
and
and
generally
just
slipping
on
things,
and
so
we
don't
have
to
use
now
to
discuss,
but
I'd
love
for
you
all
to
read
through
it
and
if
you
have
sort
of
context
or
input
or
information
or
just
perspective,
that
you
can
contribute.
B
We've
started
the
discussion
and
some
threads
on
the
issue,
but
please
jump
in
there
and
and
add
your
point
of
view.
This
will
help
us
as
we
discuss
potential
solutions
and
things
we
can
do
to
mitigate
this.
So
I
love
your
input.
We'll
take
the
next
couple
of
weeks,
probably
to
get
this
issue
full
in
terms
of
of
information
and
and
breakdown
of
the
challenge
and
then
have
discussions
later
on
on
what
outcomes
we
want
to
reach
for.
B
And
then
to
bring
us
home
unless
people
have
other
things.
I
shared
a
couple
things
that
I
thought
were
interesting,
that
I'm
not
sure
if
the
rest
of
the
team
have
seen.
I
know
gabe
shared
this
one
actually
gabe's
here,
so
we
can
probably
talk
about
the
first
one.
He
shared
it
in
the
in
the
feature
room
for
this,
but
I
thought
it
was
cool
to
share
with
the
rest
of
the
team
and
look
at
some
of
that
data.
B
B
Right
so
I
was
prepared
to
do
it
anyway
and
you,
your
presence,
is
a
surprise,
a
pleasant
surprise,
so
yeah
so
gabe
pulled
this
data
together
and,
and
we
shipped
the
importer
in
someone
remind
me
1210
or
130
right
and
over
the
last
just
few
months.
B
It's
just
been
tremendous
growth
and
the
the
chart
was
updated
recently,
so
it
is
across
two
scales
instead
of
one,
because
the
total
count
of
issues
is
obviously
massive
imported
issues,
but
I
think
it's
just
impressive
that
a
feature
in
such
a
short
amount
of
time
has
grown
sort
of
10,
no
3xed,
ish
and
really
most
interesting
is
the
the
projects
projects
with
issue.
B
Imports
number
is
the
most
interesting
to
me
because
a
lot
of
a
lot
of
projects,
a
lot
of
name
spaces-
could
choose
to
like
play
with
the
importer
multiple
times
which
will
boost
the
other
metrics,
but
distinct
projects
with
issue
imports
is
really
interesting.
So
I
think
that's
good
context.
B
What
it
tells
me
as
a
narrative
is
that
there
are
a
lot
of
customers
interested
in
importing
away
from
jira
to
use
gitlab
plan
and
so
we're
kind
of
in
an
interesting
spot
with
the
atlassian
integration,
and
with
this,
where
we
kind
of
have
two
options
for
customers
and
a
pretty
clear
path
to
say
like
hey,
if
you're
you
know
a
hardened
jira
customer,
but
you
want
to
use
like
source
code
management
and
ci
cd,
gitlab's,
a
great
solution
and
then
down
the
road.
B
We
have
this
really
great
importing
utility,
that's
going
to
enable
you
to
move
permanently
your
data
from
jira
into
gitlab
and
start
using
gitlab
plan.
So
I
thought
this
growth
was
great.
It
was
something
I
wasn't
paying
that
close
of
attention
to
and
then
gabe
surfaced
this
data,
and
I
thought
it
was
super
cool
and
worth
sharing.
C
I'll
also
add
that
I'm
going
to
talk
with
patrick
dooley
and
ecosystem,
but
I
think,
there's
a
fairly
clear
path
to
merge
the
importer
with
the
integration
and
have
like,
because,
right
now
our
integration
is
just
api.
Only
so
we
don't
pull
the
jr
data
in.
So
you
can't
use
our
other
features
like
value
stream
management,
but
that's
been
a
huge
request
from
customers,
and
so
I
think
there
is
a
huge
opportunity
to
do
a
data
first
integration
to
where
we
have
the
data
as
well.
C
There
have
been
a
lot
of
customers
who
I've
personally
spoken
to
have
said
that
they
would
love
to
use
jira
issues
with
our
portfolio
management
features,
for
example,
which
would
only
really
work
well.
If
we
had
the
data,
you
could
do
some
hackie
or
anything,
but
anyway,
we'll
keep
moving
forward
there.
But
I
think
there
is
a
cool
thing
on
the
horizon,
where
those
two
things
can
merge.
B
Your
a
customer
could
basically
just
choose
to
stop
using
jira
one
day
if
they
want
to,
instead
of
having
to
go
through
an
import
process
right.
If
we
did
that
so
yep
yep,
that's
great
cool
and
the
last
thing
I
put
on
there's
another
fyi.
But
this
is
the
performance
indicators
for
the
dev
section
and
I'm
actually
working
on
mr
to
create
a
plan
stage
once
it's
just
a
little
bit
easier
for
us
to
look
at
the
pis.
B
But
for
those
of
you
who
don't
know,
the
product
team
has
been
working
with
the
data
team
and
with
many
of
you
have
had
to
implement
some
of
the
usage
ping
and
other
metrics
to
track
a
single
or
in
some
cases
a
couple
sort
of
key
performance
indicators
per
stage
and
per
group,
and
so
on.
B
This
page
is
the
all
the
dev
section,
but
I
that
link
is
directly
to
the
plan
section
or
plan
stage
pis
and
our
focus
is
mao
or
or
xmao
so
smaug
stage,
monthly,
active
users
or
gmail
group
monthly,
active
users,
and
so
that's
a
breakdown
of
each
group
and
then
obviously
like
the
roll
up
for
the
stage.
So
we're
going
to
use
this
as
sort
of
a
a
beacon
going
forward
as
our
primary
metric
for
the
stage
and
our
primary
metric
for
each
group.
B
B
B
C
Just
going
to
say,
the
charts
aren't
right,
but
the
at
least
in
the
group
level
numbers
I
for
project
manager
tried
to
include
the
actuals
so
part
of
why
there's
a
disparity
is
because
we
were
experimenting
on
sas
if
we
could
like
what
the
mao
would
be
if
we
tracked
unique
users
who
interacted
with
issues
whether
that
was
commenting,
editing,
adding
a
label
et
cetera,
whereas
for
usage
ping,
the
only
metric
that
the
only
counter
we
have
is
for
a
unique
user's,
creating
issues.
C
F
So
the
monthly
active
users
is,
if
they
interact
with
it
one
time
in
a
month.
Correct
is
that
okay
so
and
we
we
don't
have
like
a
bot
that
just
adds
a
label
to
every
single
issue
on.com,
so
that
people
then
go
and
remove
it,
because
it's
great
for
our
stats,
because
I'll
do
it.
B
Every
every
metric
that
you
pick
will
have
some
way
you
can
game
it.
Hopefully
this
one.
I
think
this
one
is
despite
those
potential
things,
is
the
most
reflective
of
the
type
of
growth
we
want
right.
It's
like
you,
use
interacting
with
issues,
and
if
we
get
some
bots
in
there,
we
can.
We
can
close
our
eyes
just.
F
Now
this
this
seems
good
since
you're
going
for
yeah.
It
isn't
just
like
you
couldn't
just
game
this
with
a
bot
by
saying
a
million
issues
have
been
updated,
since
you'd
still
need
people
to
then
go
on.
D
G
B
C
I
also
think
it's
worth
highlighting.
I
don't
know
if
you
saw
the.
I
think
we
maybe
talked
about
last
week,
but
the
leadership
is
using.
The
numbers
is
like
one
of
the
weights
that
they
put
on
r
d
investment
allocations,
and
so
I
think
that's
like
they're
trying
to
standardize
on
that.
So,
if
we're
showing
forward
progress
like,
I
think
the
range
is
that
we're
at
right
now
is
like
a
four
out
of
five.
C
Once
we
get
above
200
000
unique
users,
then
that
bumps
up
to
a
five
which
then
impacts
like
is
another
like
indicator.
It's
just
like
hey.
They
should
probably
we
should
think
about
giving
them
some
more
team
members
to
grow
so
fingers
crossed.
I'm.
F
C
They're
they're
based
on
historical
growth
rates,
and
so
I
think
this
is
where,
like
we
set
a
quarterly
target,
and
I
think
we
set
that,
based
on
what
our
historical
growth
rate
has
been
justin,
I
think
you
actually
picked
the
target
so
feel
free
to
speak
to
that.
B
No,
you
you
hit
the
nail
on
the
head,
it's
it's
an
hour!
Well
gabe!
You
helped
me
with
this
math,
but
it's
an
average
from
the
last
four
or
five
months,
growth
rate
and
then
modeled
that
out
for
the
next
three
months.
So
it's
a
quarterly
target,
so
yeah
196k
is
that
is
that
average
and
we
can
share.
I
can
go
find
the
napkin
math
gabe
and
I
did.
C
But
also,
if
you
want
to
game
it,
you
could
help
heinrich
work
on
implementing
the
usage
ping
counters,
because
what
we
found
when
we
switched
to
just
like.com,
having
measuring
just
now,
based
on
unique
users,
creating
issues
to
any
unique
user,
interacting
with
an
issue
in
a
meaningful
way
in
a
given
month,
boosted
our
numbers
by
30
for
com,
and
we
haven't
seen
that
reflected
in
our
self-managed
accounts.
Yet
so,
assuming
we
do
the
same
thing
self-managed,
we
should
see
30
increase
there,
yeah,
which
would
push
over
the
200k,
which
would
be.
B
And
you
could
help
there's
there's
an
issue
somewhere
too
for
epics
for
portfolio
management.
Same
thing:
it's
right!
Now,
it's
it's
users,
unique
users,
creating
epics.
We
want
to
move
it
to
unique
users,
interacting
with
epics,
which
could
be
like
assigning
an
issue
to
an
epic
commenting
all
the
same
things
that
gabe's
tracking
for
issues.