►
From YouTube: GitLab 13.10 Kickoff - Plan
Description
Jump straight to a specific product group within Plan:
Product Planning -- https://youtu.be/VuP-IkvcL7E?t=45 (00:45)
Project Management -- https://youtu.be/VuP-IkvcL7E?t=412 (6:52)
Certify -- https://youtu.be/VuP-IkvcL7E?t=1052 (17:32)
Public planning issue: https://gitlab.com/gitlab-org/plan/-/issues/264
A
All
right,
hey
everyone.
My
name
is
justin,
I'm
the
interim
group
manager
for
the
plan
stage,
I'm
here
with
the
rest
of
the
planned
team.
I
don't
know
if
y'all
want
to
introduce
yourself
quickly.
B
Sure
I'm
kristin,
I
am,
I
have
the
product
planning
team,
so
we
work
on
epics
and
boards
and
roadmaps.
D
I'm
mark
working
on
the
requirements,
quality
management,
areas
of
certify.
A
Awesome
so
we're
going
to
spend
a
few
minutes
today,
walking
through
our
kickoff
what
we
have
planned
for
13.10,
so
chris
and
I'll
hand
it
over
to
you
to
kick
us
off
with
product
planning.
B
So
for
1310
we
have
a
few
items
scheduled
here,
I'm
just
going
to
jump
over
to
my
issue.
We
have
been
working
on
epic
boards
for
a
while
now
and
we
have
mvc
one.
That's
in
flight,
we're
going
to
keep
working
on
that
in
mvc
one
we
had
hoped
to
get
it
in
139,
but
it's
going
to
be
in
1310
and
in
terms
of
the
overall
mvc
breakdown
for
epic
boards.
I'm
just
going
to
open
up
the
parent
epic
here.
B
We
are
looking
at
right
now
this
might
change,
but
we're
looking
at
delivering
the
entirety
of
epic
boards
in
the
14.0
release.
So
you
can
see
that
when
we
go
out
with
mvc1
it
will
be
just
creating
and
viewing
the
boards,
then
we'll
add
reordering
and
adding
and
creating
creating
epics
within
the
boards
and
then
by
14.0
or
maybe
14.1
no
promises,
but
we're
tracking
to
that.
We'll
have
the
entirety
of
parity
with
issue
boards.
So
that's
the
goal
so
for
this
release,
though
13.10
it
will
be
mvc1
and
part
of
nbc2.
B
We
also
achieved
our
3900
active
users
for
epic
creation
in
this
last
release,
which
was
a
big
success.
So
we
are
retooling
to
track
all
epic
interactions.
So
that's
another
focus
of
this
next
release
and
making
sure
that
we're
getting
all
of
the
user
interactions,
whether
they're
editing,
epics
commenting
on
them
all
of
those
good
things
into
our
main
gmail
statistics.
B
A
Awesome
thanks
kristin.
We
have
a
couple
questions
I'll
start
with
the
first
one.
So
I'm
curious
so
for
mvc1,
which
you
said
looks
like
you're
targeting
1310.
How
will
customers
be
able
to
to
try
it
out
once
it's
available.
B
Yeah,
so
we're
actually
going
to
release
it
in
the
release
post
with
instructions
for
how
they
can
enable
the
feature
flag
and
some
of
or
remove
the
feature
flag,
so
they'll
be
able
to
get
it
so
some
and
also
we'll
be
testing
it
on
com
for
get
lab
and
we'll
be
reaching
out
to
some
of
our
customers
who
have
high
interest
in
that
right
now
and
want
to
view
their
epics
on
a
board.
So
we'll
be
doing
a
little
bit
of
outreach
and
not
getting
beta
feedback
from
them.
B
It
won't
be
that
useful
you'll
really
just
be
seeing
them
there
so
like
for
right.
Now
we
really
want
to
set
that
expectation
as
well
that
it's
not
going
to
have
parity
with
what
they're
expecting
from
from
using
issue
boards.
B
C
Yeah,
I
was
just
curious
how,
because
I
honestly
haven't
looked
into
this,
yet
how
we're
handling
the
higher
hierarchical
nature
of
epics,
like?
Are
we
just
showing
epics,
have
issues
associated
like
how
are
we
gonna
visualize
that,
on
a
board
view.
B
Yeah,
so
alexis
is
working
on
that,
but
for
right
now
we've
got
we're
just
going
to
have
them
as
cards
initially
when
we
roll
out
and
then
we'll
tackle
the
hierarchy
later,
because
it's
going
to
be
important
to
show
that
I'm
not
exactly
sure
yet
how
we
will
when
we
have
the
sub
epics
on
there,
along
with
their
parents
for
right
now,
they'll
just
be
top
level
objects
like
an
issue.
C
Cool
yeah,
I
think
when
we
were
talking
about
the
defining
relationship
between
types
of
issues,
that's
one
way
that
would
provide
a
kind
of
clear
ui
for
traversing
down
your
your
tears
and
hierarchy.
So
that's
exciting
to
explore
that
further
yeah.
A
Cool
thanks
gabe
looks
like
I
have
the
last
question
for
product
planning.
First
off:
congratulations
on
hitting
the
target
the
gmail
target
super
awesome.
Thank
you.
I
was
curious,
so
you're
mentioning
tracking
all
types
of
interactions
on
epics
I'm.
I
know
that
we
don't
necessarily
use
each
interaction
on
epics
that
to
show
up
on
your
contribution,
graphs,
I'm
curious.
These
may
be
unrelated.
It's
totally
okay,
but
I'm
curious
if
you've
considered
adding
those
interactions
as
contributions
on
a
user's
profile.
In
addition
to
tracking.
B
Analytics
that's
a
good
idea.
I
have
not,
but
we
I
should
go
through
the
list.
It's
quite
a
long
list
like
editing,
dates,
editing
labels,
so
we
would
have
to
figure
out
if
it
meets
the
definition
for
a
contribution,
because
I
know
right
now.
I
think,
like
issues
and
mrs
there's
a
there's
like
a
bar,
you
have
to
reach,
but
that's
a
really
good
call
out
there
that
we
should
actually
just
track
down
and
make
sure
that
all
of
them
are
tracking
over
to
the
user
activity.
C
No,
no
I'm
just
gonna,
say
I
think
there
was
an
issue
in
stock
somewhere
that
we
could
try
to
dig
up,
but
I
think
one
of
the
challenges
of
that
is,
I'm
not
sure
how
complex
it's
going
to
be
to
add,
like
basically,
we
have
events
model,
that's
used
for
issues
and
merge
requests,
which
makes
it
easy
to
show
events
or
activities
on
your
profile,
but
that
doesn't
exist
for
epics,
and
so
I'm
curious
like
if
there
is
some
overlap
there
anyway,.
C
A
discussion
that's
really
relevant
to
that
in
slack
yesterday,
the
day
before.
A
This
also
might
be
a
good
segue
into
extensible
issues
right,
gabe
mm-hmm,
but
thanks
kristin
yeah.
Definitely
nothing
we're
planning
on
actioning
on
in
this
milestone,
but
I
was
just
curious
now
that
you're
gonna
be
able
to
track
them,
be
curious
to
see
how
many
interactions
on
the
different
types
of
things
you
can
do
on
an
epic
exist
right
now,
we've
only,
we
only
know
we're
only
tracking
creation,
so
excited.
A
Awesome:
okay,
cool!
Thank
you.
If
there's
any
other
questions
on
this
one,
let's
toss
it
over
to
gabe
for
project
management.
C
Sounds
good
here's
my
section
for
the
13.10
release.
I
think
one
of
the
key
themes
that
we're
trying
to
focus
on
as
an
organization
is
usability.
So
a
lot
of
the
the
three
themes
that
I
have
all
linked
directly
to
sus
feedback,
as
well
as
to
opportunities
for
improving
mao
and
also
directly
to
customer
arr.
So
it's
kind
of
interesting
how
they
all
correspond.
But
the
first
major
theme
that
we're
going
to
continue
working
on
is
planning
work
with
iterations.
C
We
made
progress
refactoring,
how
we
add
lists
to
boards
in
this
previous
milestone
and
next
we're
going
to
be
able
to
add
an
iteration
via
the
new
list,
edition
ui,
which
is
going
to
look
similar
to
this.
I'm
so
excited
about
that.
It
will
be
a
huge
win
for
people
that
are
using
iterations
because
they
can
more
easily
schedule
and
sequence
work
out
across
many
iterations,
complemented
well
with
epic
swim
lanes
and
some
of
the
things
that
are
out
there.
C
It's
going
to
be
a
pretty
awesome
enhancement,
along
with
iterations,
were
kind
of.
The
problem
is
that
there
are
lots
of
times
where
a
group
will
be
shared
with
multiple
teams
gitlab's.
C
They
kind
of
flow
down
to
subgroups
and
then
once
that's
sort
of
in
place
and
the
backend
work,
I
think,
is
pretty
much
done
for
this,
extending
that
to
enable
so
that
you
can
automatically
schedule
it
and
select
the
start
date.
The
duration
for
your
iterations,
selecting
automatically
relation
issues
over
from
one
completed
iteration
to
the
next
and
then
how
many
future
iterations
of
schedule.
C
So,
basically,
with
all
these
things
enabled
it
will
allow
us
to
more
or
less
automate
the
management
of
iteration
lists
within
boards
and
all
sorts
of
other
fun
things,
and
then
once
this
is
in
play,
we'll
move
on
to
integrating
velocity
into
iterations
and
into
boards
as
well,
so
that
we
can
plan
more
effectively.
C
The
next
kind
of
major
theme
is
sort
of
around
the
extensible
issues.
Some
of
the
things
that
we're
doing
right
now
and
our
plan
4
and
13.10
is
filtering
issue
by
issue
type
and
boards
and
issue
lists.
So
we
already
have
a
type
column
in
our
issue
model
and
it's
being
shared
basically
with
incidents
right
now
and
then,
in
order
for
incidents
to
not
rely
on
the
incident
label
anymore,
so
they'll
show
up
on
boards
properly.
C
We
need
to
actually
be
able
to
support
by
type
within
boards,
so
you
can
have
a
board.
That's
scoped
a
specific
type
of
issue,
whether
that's
an
incident
or
a
normal
issue
now
or
in
the
future,
an
epic
or
requirement
or
a
test
case,
whatever
the
the
use
case
may
be,
but
this
is
sort
of
getting
ahead
of
what
we
know.
C
We
have
to
do
anyways
by
also
supporting
another
team
and
unblocking
them,
and
then
we're
going
to
be
starting
work
on
customizable
issue
types,
so
the
end
user
will
be
able
to
more
or
less
create
different
types
of
issues
that
they
want
and
right
now
it's
going
to
be
pretty
simple.
Just
like
basic.
I
want
to
create
a
feature:
we're
not
customizing
fields
on
it,
doing
anything
like
that.
C
Very
small,
more
or
less
have
different
types
assign
that
type
to
different
issues
and
that's
the
kind
of
first
base
step
that
is
going
to
unblock
a
lot
of
these
interesting
things.
I
think
the
first
mvc
we're
not
going
to
go
with
customized
icons,
but
eventually
we're
going
to
support
being
able
to
select
different
icons
that
relate
to
different
issue
types
that
will
show
up
in
the
ui.
C
I
think
the
let's
see
here
we're
also
going
to
be
doing
some
back
and
spikes
on
converting
other
objects
like
epics
and
requirements
into
a
type
of
issue.
In
terms
of
our
last
major
theme,
we
have
usability
and
for
performance
plus
feedback,
quality
of
life,
improvements,
sort
of
a
big
bucket
of
all
the
things
that
we
need
to
make
better
the
product
that
exists.
C
One
of
those
things
that
we're
going
to
be
working
on
is
the
or
filter
this
is
pretty
far
along,
but
it's
going
to
behave,
sort
of
like
this
on
the
filters.
If
you
want
to
use
signees,
you
can
say
is,
and
then
you
can
have
a
multi-select
option
in
your
list,
so
that
way
it
will
pop
it
in
and
treat
it
as
an
or
filter.
So
again,
the
backend
piece,
I
think,
is
just
about
done
where
we're
actually
able
to
sort,
by
or
in
a
query
parameter
in
the
url.
C
C
C
Epics
will
be
in
a
future
iteration,
but
this
will
more
or
less
enable
you
to
there's
a
couple
of
things
when
you
show
them
set
at
the
instance
level,
where
you
want
your
templates
to
be
drawn
from
which
will
propagate
all
the
way
down
your
hierarchy
or
you
can
override
that
at
the
group
level,
if
you
want-
and
so
this
will
enable
people
who
have
hundreds
of
projects
within
a
group
to
set
one
basically
repository
where
their
templates
are
and
that
be
available
to
all
their
groups
when
they're
create
or
all
their
projects
when
creating
issues.
C
And
then
the
last
thing
that
we're
going
to
be
doing
is
iterating
on
our
delay
deletion
of
projects.
Right
now,
it's
super
expensive.
If
something
gets
accidentally
deleted.
One
of
the
I
think
promises
that
we
make
to
customers
in
our
contracts
is
that
if
you're
a
premium
up
and
something
actually
against
the
lead,
we
will
help.
C
You
restore
your
data
as
best
to
our
ability,
which
is
super
expensive
for
infra,
and
so
one
of
the
things
that
we're
going
to
be
doing
to
support
this
is
is
basically
making
it
so
that
when
you
delay
delete
a
project,
you
can
immediately
reuse
the
path
name
of
the
the
project,
that's
being
scheduled
for
deletion,
better,
supporting
the
ability
to
override
that
and
automatically
basically
delete
a
project
that
is
scheduled
for
delay,
deletion,
there's
compliance
reasons,
and
then
the
other
thing
is
making
it
so
that
groups
can
properly
inherit
the
and
set
the
interval
for
when
they
want
things
to
be
delayed
and
like
basically
from
when
you
schedule
an
issue
for
a
project
for
delay
deletion
until
when
it
actually
happens
and
kind
of
giving
more
control
of
the
end
user.
C
Because
right
now
it
is
an
instance
level
setting
and
it's
available
at
groups.
But
we
can't
default
it
on
at
the
instance
level.
To
protect
basically
add
that
layer
of
protection
for
gitlab.com,
because
there's
not
enough
configurability
at
the
group
level,
so
we
need
to
kind
of
provide
that
level
of
configurability
so
that
customers
that
do
want
to
use
the
legislation
can
customers
that
don't
don't
have
to,
and
it's
sort
of
I
think
this
would
also
fit
into
the
bucket
of
parity
between
gitlab.com
and
self-managed.
A
B
C
I
defer
to
engineering
engineering
hasn't
indicated
specifically
which
object
they
would
want
to
start
with.
I
think
the
requirements
might
make
sense.
The
thing
that
we'd
have
to
obstruct
there
is
a
relationship
between
a
requirement
and
how
that
works.
When
you
basically
tie
it
to
an
actual
test
in
the
code
base
and
making
sure
that
all
that
stuff
works
well
but
again,
like
I
completely
defer
to
the
engineering
approach
and
how
they
want
to
do
this,
and
that's
where
I've
sort
of
asked
them
in
this
release.
C
Like
can
you
come
up
with
an
architecture
blueprint
so
that
we're
all
on
the
same
page?
We
know
how
we
want
to
tackle
this,
and
basically
the
technical
risk
is
reduced
quite
a
bit.
So
that's
the
next
step.
A
Cool
thanks
gabe.
I
the
next
question
on
multiple
iteration
cadences.
If
I
was
a
customer,
how
would
I
sort
of
name
you
mentioned?
Oh
each
team
could
have
their
own
cadence,
which
is
great,
I
think,
that's
a
great
improvement.
A
C
It's
just
a
naming
scheme,
so
I,
like
I'll,
show
you
my
screen
real
quick
right
now
you
can
name
every
single
iteration.
What
we're
gonna
move
to
in
this
kind
of
new
model.
Is
you
name
your
your
kind
of
set
of
iterations
your
cadence
and
then
the
the
iteration
itself
is
going
to
be
identifiable
by
the
date
range
and
by
a
number,
so
the
sequence
of
iterations?
It
is
so
that
way
like
you
can
name
it.
C
Yep
and
then
eventually
we're
integrating
sorry
holly's
working
out
some
of
this
stuff
right
now,
but
basically
a
way
to
scope
a
board
directly
to
an
iteration
cadence.
So
that
way
like
you
can
basically
have
the
board
represent
just
one
cadence
of
iterations.
So
that's
how
we're
going
to
tackle
that.
B
C
Yeah
they're
super
excited
about
it,
because
usually
teams
will
track
against.
You
know
a
milestone
of
some
thing:
that's
in
the
distant
future,
a
kind
of
longer
term
type
thing,
and
then
an
iteration
is
more
of
like
hey
here's,
a
a
specific
time
box.
C
We
might
get
this
done
in
so
now,
they're
able
to
tie
an
issue
both
to
their
playing
cadence,
as
well
as
to
like
some
sort
of
important
business
function,
which
technically
is
what
a
milestone
is
supposed
to
be
in
the
future
milestones
right
now,
don't
have
to
have
dates,
can't
have
dates.
A
Cool
gabe,
I
think
you
actually
answered
my
fourth
question.
I
was
gonna
ask
what
do
you
think
the
team
will
accomplish
in
regards
to
successful
issues
for
the
milestone?
I
think
you
answered
that
it
looks
like
the
plan
is
for
them
to
spike
into
it
and
start
to
come
up
with
some
designs
and
architecture
and
kind
of
start
to
think
about
which
issue
they
want
to
bring
or
which,
which
issue
will
they
want
to
bring
over?
C
You're
right,
there's
two
things:
there's
there's
a
spike
for
actually
converting
things
like
epics
and
requirements
to
a
type
of
issue
and
then
there's
the
ability
for
end
users
we're.
I
don't
know
if
we'll
be
able
to
finish
it
in
13.10,
but
we're
starting
in
earnest
on
the
engineering
for
end
users
to
be
able
to
create
their
own
customizable
tests
right.
Okay,
so
that's
sort
of
like
you
sort
of
have
to
have
both,
I
think.
A
C
A
Mark
you're
up
next
bring
us
home
with
with
certify.
D
Sounds
good,
you
know
throughout
the
release
here
the
the
teams
worked
really
hard
doing
a
spike
into.
You
know
the
next
steps
for
requirements,
management
and
it
kind
of
dovetails
into
what
gabe
was
saying
with
the
idea
of
converting
to
an
issue
type.
So
that's
sort
of
on
the
radar
for
the
certified
team
to
convert
requirements
to
an
issue
type
we're
still
trying
to
determine
how
that's
going
to
work
as
game
mentioned
with
linking
to
other
things.
D
So,
while
we
complete
that
spike,
the
team
really
wanted
to
have
a
bug
fix
release,
and
this
is
actually
a
really
good
thing.
It
shows
that
a
lot
of
people
are
using
the
certified
features
right
now
and
they're
coming
up
and
finding
some
of
these
little
bugs
that
have
kind
of
been
plaguing
it
for
a
while.
D
So
you
can
see
there's
a
list
of
them
here
within
the
issue
where
we're
really
hoping
to
kind
of
knock
out
a
bunch
of
these
bugs
there's
also
going
to
be
a
documentation
update,
and
this
is
really
important-
there's
some
reviewer
guidance
that
was
missing
around
community
contributions,
so
we're
actually
going
to
go
ahead
and
update
that
for
everybody
at
gitlab,
just
to
understand
how
these
reviews
should
take
place
for
community
contributions
and
for
database
review
just
to
ensure
that
we're
not
we're
not
sort
of
not
using
those
community
contributions
to
the
best
of
our
ability-
and
this
was
kind
of
a
problem
we
ran
into-
and
we
just
want
to
fix
it
for
everybody,
so
made
sure
to
schedule
that
as
well.
D
D
So
what
we're
looking
to
do
is
add
a
linked
email
that
they
receive
that
allows
them
to
opt
out
of
future
updates
from
that
issue,
there's
also
a
situation
we
ran
into
where
the
service
desk
email
send
and
receive
feature
wasn't
working
for
a
few
days,
and
nobody
really
noticed
it.
So
we
want
to
implement
some
service
level
indicators
here
for
that
just
to
make
sure
that
we're
maintaining
a
quality
of
service
for
our
our
customers.
So
those
are
the
two
things
we're
going
to
tackle
this
month.
D
While
we
complete
the
spike
into
how
to
handle
requirements,
management
and
linking
requirements
to
test
cases.
A
Awesome
thanks
mark
the
first
question.
I
noticed
a
bug
fix
or
a
small,
maybe
quality
life
improvement
tool,
tips
on
import
and
export
buttons
made
me
think.
Do
you
have
any
data
or
any
sort
of
anecdotal
evidence
on
how
how
much
usage
the
import
export
requirements
feature
is
getting.
D
The
import
export
actually,
while
we're
not
tracking
it
formally
just
yet
we're
working
to
do
that,
there's
some
issues
we
want
to
get
it
into
redis
counter,
so
we're
not
tracking
only
on.com
or
only
in
self-managed,
so
we're
kind
of
looking
at
doing
that.
But
right
now
I
have
received
a
lot
of
anecdotal
evidence
from
a
couple
of
our
customers,
they're
really
enjoying
that
feature,
especially
the
export.
This
is
really
critical.
D
A
C
Yeah,
I
was
just
thinking
about
one
of
the
things
that
I
like
that
you've
done
with
requirements
today
was
the.
When
you
create
a
new
requirement,
it
basically
slides
out
a
little
window
instead
of
taking
you
a
whole
page
and
then
reloading
and
all
this
other
stuff,
I'm
wondering
if
we
should
explore
making
that
like
the
status
quo
for
issues
of
all
kinds.
Just
because
it
is
nice-
and
I
know
that
there's
also,
basically,
the
creation
form
is
duplicated
in
lots
of
places.
So
it's
an
effort
to
also
pay
down
technical
debt.
C
D
Yeah,
I
mean
that's
something
we
actually
talked
about
briefly,
and
I
think
that's
something
that's
really
important
when
we
went
ahead
and
did
that
we
were
trying
to
avoid
that
typical
form
based
entry,
where
you
can't
really
see.
What's
there
on
the
screen,
you
have
to
go
to
a
whole
new
screen
enter
your
requirement.
D
I
would
love
to
see
that
incorporated
all
over
the
place.
I
do
recognize
that
some
users,
when
they
enter
like
larger
issues,
may
want
to
have
a
full
screen
view.
I
don't
think
it
would
be
too
difficult
to
add
a
button
on
there,
something
that
says
you
know
open
a
new
window
or
something
like
that
where
they
can
get
that
experience.
If
that's
what
they're
looking
for,
but
the
slide
out
is
super
convenient
for
requirements
and
any
other
sort
of
quick
entry.
C
Yeah,
I
think
that
could
solve
a
lot
of
problems,
not
just
in
the
list
view,
but
also
like
in
a
board
view,
because
when
you
have
those
quick
create
like
things,
it
doesn't
let
you
set
any
metadata.
So
you
have
to
open
that
issue
or
whatever
it
is
already
to
like,
add
all
the
things
that
you
want
and
you
don't
even
can't
even
use
quick
actions
because
there's
no
description
field
so
it'd
be
cool
to
have
that
be
like
a
standard
experience
for
viewing
and
also
creating,
is
the
sort
of
like
slide-out
mechanics.
B
C
B
B
D
No,
this
was
actually
one
of
the
back
end
services
at
on.com
went
down.
This
was
our
email
before
that
went
down
and
there's
issues
don't
really
have
the
same
sort
of
situation
where
they're
not
receiving
issues
over
email.
So
it
was
one
of
those
things
where
it
went
down
for
a
couple
days
and
we
were
alerted
to
it
by
a
customer
which
was
fantastic.
We
were
able
to
bring
it
back
online
very
easily,
but
it
made
us
realize
that
we
should
have
some
sort
of
monitoring
place.
D
Just
because
it's
a
feature
that's
a
little
bit
harder
to
track.
You
have
to
actually
like
send
an
email
and
verify
it
create
an
issue.
There's
that
linkage
there's
where
it
went
down
the
email
server
was
fine,
email
was
working,
fine
issue
creation
was
working
fine,
but
that
thing
that
ties
them
together
is
where
we
were
seeing
problems.
So
it's
a
very
specific
use
case
tied
mainly
to
the
service
desk,
but
it
is
something
we're
we're
trying
to
fix.
D
A
Yeah
cool,
that's
the
end,
thank
you,
everyone
for
watching
and
look
forward
to
seeing
everything
that
we
can
get
done.
This
milestone.