►
From YouTube: 13.11 Kickoff - Plan Stage
Description
Groups: Project Management, Product Planning and Certify!
A
B
Hi
there
all
right,
so
I'm
going
to
take
everyone
through
what
we're
kicking
off
in
1311..
I'm
just
going
to
share
my
screen
here
and
look
at
our
planning
issue.
While
I
talk
so
on
the
product
planning
team,
we
do
have
a
fairly
small
capacity
for
13
11,
we're
working
with
12
to
17
points,
so
we
want
to
really
make
sure
we
spend
it
in
the
right
spot.
B
Our
focus
is
fully
on
our
epic
boards
rollout.
Last
monday
we
did
a
kickoff
on
our
mvc2
for
epic
boards
and
you
could
see
here.
That's
our
main
focus.
It's
around
10
points
left
that
is
spread
into
from
1310
and
1311,
but
we're
putting
all
of
our
efforts
behind
that
and
continuing
to
drive
that
forward.
B
We
also
have
a
few
other
smaller
issues
that
we're
going
to
look
at.
One
is
our
epic
epic
aggregate
tracking
issue,
which
is
essentially
this
is
going
to
get
us
to
tracking
parity
with
issues.
So
you
can
see.
The
team
has
already
merged
lots
of
mrs
for
all
of
the
different
epic
actions,
and
so
this
will
continue
to
be
a
focus
in
1311
and
hopefully
ship
in
1311.,
and
with
this
data
we'll
be
able
to
make
better
customer
decisions.
We'll
also
be
able
to
see
how
epics
relate
in
comparison
to
issues
in
plan.
B
The
last
two
that
I'm
going
to
mention
are
their
usability
and
dog
fooding
issues
and
one
of
them
we
discovered
on
actually
a
team
call
when
we
did
the
kickoff
for
mvc2,
and
that
is
that
it's
frustrating
when
you
drag
and
drop
in
epics
and
if
you
drag
one
epic
over
another,
it
will
open
up
and
you
won't
be
able
to
just
drag
over
it.
So
there's
no.
Currently
there
isn't
a
delay
on
epics,
and
that
is
what
this
issue
is
going
to
address.
B
I've
also
marked
that
one
dog
fooding,
because
we
did
find
that
as
a
team
and
it's
really
important
and
then
the
last
one
is
this:
improving
the
loading
state
of
boards
when
slip
swim
lanes
are
applied.
So
this
is
another
dog
fooding
issue
that
the
team
found
and
actually
mark-
and
I
found
this
this
morning
on
a
call.
B
But
what
currently
happens
with
boards
is.
If
you
have
a
lot
of
cards,
you
can
be
in
the
loading
state
for
a
long
time
and
you're
you're,
not
knowing
that
that's
happening
so
you're.
Looking
at
your
board,
you
see
all
the
cards
there
and
you
try
to
interact
with
it
or
maybe
click
on
one
of
the
cards
and
then
nothing
happens
and
what's
happening
is
behind
the
scenes.
It's
still
loading,
but
there's
no
indicator
to
you
as
the
user
that
that's
happening.
B
So
what
this
proposal
and
mvc
is
going
to
do
is
add
skeleton
loaders
to
the
boards,
and
you
could
see
here
just
full
screen
kind
of
what
that
looks
like.
Essentially,
it's
going
to
be
a
major
indication
that
it's
still
in
a
loading
state
while
still
giving
the
user
this
feedback
that
they
do
have
columns
and
cards
and
things
like
that
on
the
board
and
then
once
all
the
objects
are
loaded,
it
would
progress
and
you'd
see
them
and
be
able
to
interact
with
them.
A
I
have
a
couple
yeah.
Thank
you,
kristen,
first
of
all,
for
walkies,
so
for
epic
boards.
I
know
this
epic
boards
themselves
aren't
a
category.
Epics
are
category,
but
if
you
were
to
treat
them
as
a
category
for
a
second
from
my
fictitious
example,
when
would
you
say
that
epic
boards
would
be
viable?
Is
that
after
nbc2
would
that
be
after
mvc3.
A
Got
it
okay,
good
question?
My
second
question
is
related
to
that
which
is
at
what
point
do
you
plan
to
make
epic
boards
ga
or
generally
available?
So
I
know,
if
I
understand
correctly
still
for
13.10
you'll
have
to
do
some
config
feature.
Yes,
when
will
that
be
generally
available
for
anyone
who's
running
gitlab.
B
A
Awesome,
that's
great
and
then
last
question
for
me
at
least
skeleton
loaders,
that's
great!
It's
a
great
quality
of
life
improvement.
I
agree
that
it's
just
using
it
this
morning
and
forgot
there's
still
loading
and
I
was
mashing
the
refresh
button
trying
to
figure
out.
Why
and
I
realized
I
was
just
loading
a
giant
board.
Will
there
be
animation
on
the
skeleton
loaders
or
will
it
just
be
the
like
ghosted
frame
of
the
list.
B
Yeah,
so
if
we
look
at
the
issue,
we're
gonna
start
with
the
ghosted
frame.
I
should
have
mentioned
this
so
we'll
start
with
just
solid
which
isn't
as
fun,
but
it
still
gives
the
indication
and
then
future
scope,
we're
gonna
break
off
other
one.
You
can
see
here.
If
I
click
this,
it's
got
a
little
more
animation
to
it.
There's
different
ways
the
team
is
playing,
but
for
our
first
two
pointer
just
get
something
up.
It's
just
going
to
be
the
the
image.
A
C
Some
of
these
things
are
in
kind
of
different
flights,
but
at
a
very
high
level,
we're
we're
working
on
playing
work
with
iterations
again
like
this
is
one
of
the
primary
use
cases
for
the
team
experience
within
gitlab
and
it's
basically
taking
what
would
be
those
epics
and
break
them
down
into
smaller
pieces
user
stories.
Individual
vertical
feature
slices
and
then
sequencing
those
out
across
any
number
of
upcoming
iterations.
So
what
we're
doing
right
now
is
making
progress
and
supporting
multiple
iteration
cadences.
C
So
we're
not
expecting
to
get
this
done
in
13.11.
we,
but
we
are
going
to
just
make
progress
through
each
of
these,
so
they
can
be
their
own,
mrs,
if
they
want
they
could
be
grouped
into
mars.
I
really
have
left
that
up
to
the
engineers
and
how
they
want
to
tackle
this
from
development
standpoint,
but
this
will
also
then
enable
us
to
do
automated,
iteration
cadences,
where
you
can
schedule
basically
enable
automated
scheduling
pick
a
start
date.
C
C
C
This
is
sort
of
makes
it
along
the
lines
of
gitlab
needs
to
be
a
little
bit
more
configurable
with
saying
defaults,
of
course,
so
one
of
the
small
things
we're
going
to
be
doing
in
this
work
stream
is
filtering
issues
by
issue
type
and
issue
boards
and
lists
so
right
now.
This
is
sort
of
a
higher
priority,
because
incidents
are
also
backed
by
a
type
of
issue.
C
More
and
more
feedback
marketing
through
that
channel
is
basically
suggesting
that
there
needs
to
be
better
filtering
and
sorting
of
incidents
that
are
intermingled
with
issues
on
board.
So
you
can
filter
by
just
type
of
incident
and
get
better
visibility
there.
So
we're
going
to
go
ahead
and
do
that
and
then
we're
gonna
take
our
first
step
towards
adding
customizable
issue
types
to
the
product
by
adding
support
for
default
issue
types.
So
these
will
eventually
be
able
to
be
customized
by
the
end
user.
C
They
will
be
able
to
add
more,
but
this
is
basically
the
front
end
small
front
and
change
that
maps
to
the
back
and
work
necessary
to
kind
of
move
the
issue
types
into
its
own
model
and
be
able
to
support
the
future
needs
there.
So
there's
not
a
ton
of
ux,
but
what
will
happen
as
a
result
of
this
is
each
of
these
types
of
issues
will
have
their
own
little
icon?
C
You
can
create
a
new
type
of
issue
from
the
issue
drop
down
currently,
but
these
will
then
become
available
and
then
in
future
iterations
the
end
users
will
be
able
to
customize
those
types
and
add
their
own.
So
that's
that
small
thing
and
then
in
the
last
sort
of
big
work
stream,
I
call
it
quality
of
life
and
that
includes
performance,
refinements
application
limits
for
dev
stuff
security,
usability
based
on
noobs,
announce
announcement
today
that
we
need
to
prioritize
infradev
over
pretty
much
everything
else.
C
All
of
the
open,
infradev
issues
in
plan
have
been
scheduled
for
13.11
and
take
precedence
over
anything
else
that
I
said
previously
in
the
two
work
streams,
but
thankfully
three
out
of
the
four
we
were
already
pretty
far
along
with,
and
that
would
be
improving
performance
of
projects
list
under
api
under
load
into
the
next
tier,
which
is
reference
architectures.
We
can
kind
of
clean
up
some
of
the
performance
there.
I
think
when
we
get
up
into
like
which
tier
is
it
a
lot
of
users?
C
I
can't
remember
the
reference
architecture
we're
trying
to
target,
but
we
basically
need
to
improve
the
the
project
list.
Api
for
that
add
application
limits
for
jira
imports
right
now.
There
is
no
limits
whatsoever,
so
you
basically
can
crash
redis
by
stashing,
much
res
keys
when
you're
doing
a
massive,
massive
import,
and
so
we're
going
to
kind
of
take
an
approach
to
adding
some
limits
there.
Then
this
is
something
we've
been
planning
to
do
for
a
long
time,
so
it
kind
of
fits
nicely
into
new
priorities.
C
C
C
Heinrich
has
been
working
on
this
for
a
while
as
well,
so
hopefully
we'll
get
that
wrapped
up
and
then
there's
a
couple:
small
performance
things
for
the
project's
issues,
controller
and
then
one
bug
for
fixing
incorrect
number
of
issues
and
fixed
burn
down
charts
so
that
there
is
more
accurate
reporting
and
it's
not
wonky.
So
that's
it
for
me.
A
C
So
there's
not
even
front-end
changes
and
that's
going
to
fix
a
number
of
bugs,
and
so
that
would
be
the
one
thing
I
think
it's
might
already
be
done
or
closely
done,
and
then
the
next
thing
that
I
would
like
to
do
is
be
able
to
create
a
new
cadence
and
just
enter
the
name
for
that
cadence
and
not
anything
else
and
then
see
my
iterations
within
that.
So
those
are
the
two
smallest
things
that
I
think
we
can
get
done
this.
This
release
great.
C
Yep,
that
would
be
the
smallest
thing
that
I
want
to
get
done
is
adding
support
for
default
issue
types
doesn't
require
any
additional
additional
front-end
development.
We
already
have
the
drop
down
in
the
issue,
create
form
where
you
can
select,
which
type
it
is
so
I
would
like
to
have
that
the
back
end
basically
table
done
and
then
have
those
default
types
show
up
in
the
drop
down.
That's
it.
So
that's
what
we're
planning
on
doing.
A
Great
last
thing
I
had
here
was
just
a
thank
you
for
prior
for
prioritizing.
I
could
say
that
word
the
in
for
dev
work.
I
know
it's
not
feature
work,
it's
not
glamorous
necessarily,
but
it's
critical
from
a
customer
support
and
and
just
customer
satisfaction
perspective.
It
helps
us
run
gitlab.com
more
efficiently
and
is
good
for
the
business.
So
thanks.
B
C
C
Thanks
I'll
talk
to
and
let's
talk
to,
engineering
managers
and
things
like
this
generally
always
will
fall
to
my
team,
because
if
you
look
at
like
the
features.yaml,
we
have
all
the
random
stray
features
in
the
product.
Basically,
it's
stuffed
under
our
group,
so
they
actually
get
assigned
to
us.
So,
thanks
for
offering
and
I'll
take
you
up
on.
D
D
I
link
the
epic
there
there's
about
five
points
of
weight.
This
release
we
expect
to
send
toward
that,
which
is
the
entirety
of
the
capacity
for
those
keeping
track,
but
this
initiative
should
bring
all
the
benefits
of
issues
to
requirements
we'll
be
able
to
have
labels
in
a
more
consistent
manner,
we'll
be
able
to
look
at
requirements
and
link
them
to
other
things
throughout
gitlab
using
the
existing
construct.
So
that's
really
exciting.
So
there's
two
issues
there.
D
The
first
one
is
to
add
a
new
issue,
type
requirements
and
the
second
is
add
the
model
restrictions
for
requirements,
issue
types,
because
we
don't
want
to
take
everything
from
issues
into
requirements.
So
there's
going
to
be
some
restrictions
on
what
we
do
and
do
not
allow
into
the
issues
or
into
the
requirements
from
issues.
D
D
The
other
is
a
priority,
two
severity,
two
bug
and
bugs
don't
generally
count
toward
our
weight.
In
fact,
they
generally,
the
engineering
team,
has
generally
been
completing
four
to
ten
bugs
per
release
in
addition
to
the
weight
they've
been
doing
so
this
is
the
bug
for
the
quality
management
or
yeah
from
for
the
service
desk
this
month,
as
well
as
there's
one
security
fix.
A
D
We're
looking
to
leverage
that
mechanism-
yes,
since
that's
already
been
built
into
the
issue,
types
there's
no
point
in
reinventing
it
for
requirements
as
it
stands
now
as
a
standalone.
So
what
we're
looking
to
do
is
leverage
that
we
are
not
made
a
final
decision
if
we
will
use
the
actual
related
to
as
we
have
it
today
or
if
we
use
a
field
of
similar
capacity
or
add
to
that
related
field.
But
the
idea
behind
it
is
the
same.
So
yes,
that's
our
plan.
C
One
thing
I
could
add
to
that:
I
just
linked
in
the
agenda
basically
there's
another
issue
that
is
on
our
near
term
roadmap
for
improving
and
evolving
how
relationships
work
basically
right
now
there
are
lots
of
other
teams
that
want
to
relate
things
to
issues,
issues
needed
more
formal
relationship
to
merge
requests.
Threat.
C
D
And
that's
why
we
haven't
committed
to
how
we're
going
to
do
that,
because
we
knew
there
were
some
some
other
initiatives
out
there,
where
we're
trying
to
redefine
that
relationship
a
little
bit.
But
the
idea
is
to
extend
that
into
requirements
in
a
sane
manner.
So
it's
not
overwhelming
to
our
users.
A
Cool
one
last
question:
for
me
at
least
I
was
just
thinking
about
this.
Like
is:
do
we
have
this
mechanism
of
satisfying
our
requirement
right?
Is
there
a
way
that
we
bring
that
functionality
back
into
the
sort
of
primitive
issue
type,
and
could
it
be
reused
in
some
way
across
another
feature
or
another?
Another
issue
type
on
that
longer
term
issue
types
roadmap.
D
There's
no
reason.
We
could
not
expand
that,
though,
to
start
with
that,
I
don't
think
that's
on
the
requirements
team
currently
to
expand
it,
but
I
think
other
teams
could
then
utilize
that
or
leverage
that
so
for,
like
instance,
you
could
have
closed
instance
or
you
could
link
incidents
to
requirements.
I
think
the
goal
long
term,
though
we
need
to
make
sure
the
paradigm
is
clear.
If
an
incident
results
in
a
problem
should
then
that
result
in
a
requirement
update
and
then
you
satisfy
the
requirement
again.