►
From YouTube: GitLab 13.8 Kickoff - Plan:Project Management
Description
13.8 Plan Release Planning Issue - https://gitlab.com/gitlab-org/plan/-/issues/221
A
One
of
the
things
we're
trying
to
get
better
at
just
before
we
get
run
into
things
is
getting
better
about
planning
according
to
our
historical
velocity,
so
our
running
velocity
as
group
is
41
weight.
So
far,
we've
scheduled
46
wait
for
this
upcoming
release
with
eight
of
that
weight
market
to
stretch
goals,
and
some
of
that
is
naturally
going
to
flow
into
13.9
just
due
to
the
size
of
some
of
the
problems
we're
solving.
A
But
the
team
did
a
really
good
job,
collaborating
and
making
trade-off
decisions
and
working
together
to
plan
a
great
release.
So
here
we
go.
We
have
three
themes
for
this
upcoming
release
and
I
think
you'll
probably
see
these
themes
be
the
same
things
for
the
next
six
months.
If
I
were
to
guess,
one
of
them
is
playing
works,
work
with
iterations.
A
A
The
main
problem
around
this
area
is
that
larger
companies
and
organizations
can't
map
gitlab
to
their
business
domain
and
processes,
and
it's
painful,
if
not
like
outright
impossible
for
them
to
change
their
domain
model
to
work
with
the
way
gitlab
is
organized.
So
we
need
to
provide
better
support
there
and
then
the
other
thing
is
going
to
be
usability.
Such
feedback
and
quality
of
life
improvements.
A
So
we're
going
to
kind
of
talk
through
some
high
level,
things
that
we're
going
to
be
doing
there
so
first
with
iterations
in
13.8,
we're
going
to
add
the
ability
to
bulk
edit
iterations
on
issues
within
groups
and
projects,
so
right
now,
iterations
when
we
released
them
in
one
of
the
early
13
dot
releases,
it's
fairly
straightforward,
but
there's
no
way
to
bulk
edit
or
bulk
update
and
move
issues
from
one
iteration
to
the
next.
So
this
is
kind
of
a
minor
thing,
pretty
low
hanging
fruit,
but
we're
going
to
make
it.
A
So,
within
the
issue
list
you
can
book
update
iterations.
The
next
thing:
we've
gotten
a
lot
of
feedback
from
some
of
our
customers,
that
and
in
the
wider
community
as
a
whole,
that
the
there
are
lots
of
different
ways
that
people
use
groups
and
projects
gitlab.
For
example,
we
have
a
bunch
of
teams
that
all
do
issue
tracking
in
a
single
project.
We've
gotten
feedback
internally
from
dog
fooding
iterations
that
it's
difficult
to
share
the
same
cadence
with
a
bunch
of
other
teams.
A
At
the
same
time,
there
are
other
organizations
that
value
that
so
one
of
the
things
that
we're
going
to
be
doing
to
continue
to
evolve.
Iterations
is
laying
the
foundation
for
supporting
what
we
call
iteration
cadences.
A
A
group
may
have
one
or
more
cadences
and
basically
within
each
cadence,
you
can
think
of
it
like
a
set
of
iterations
we're
gonna
work
towards
exposing
the
ability
to
name
it
to
set
a
start
date
for
your
cadence
set,
the
duration
for
how
long
you
want
your
iterations
to
run
in
a
weekly
time
time
frame
and
then
how
many
iterations
of
the
future
you
want
to
automatically
schedule
or
plan
it'll
be
optional.
A
You
can
opt
into
scheduling
automatically
new
iteration
cadences
will
be
by
default,
and
then
we're
going
to
work
towards
automatically
rolling
issues
over.
So
what
this
will?
Let
users
do
is
set
the
cadence
of
how
they
want
to
structure
their
iterations
and
then
gitlab
will
handle
the
management
of
creating
future
iterations
moving
issues
from
one
of
the
next
and
automatically
populating
lists
and
boards
based
on
your
upcoming
iterations.
So
you
don't
have
to
mainly
like
select,
remove
a
list
for
your
previous
iteration.
Add
a
new
list
for
a
new
upcoming
iteration.
A
It
will
sort
of
all
be
automated
and
then
we'll
work
on
extending
the
drop
down
so
that
you
can
assign
issues
to
different
iteration
sets
or
iterations
within
a
given
iteration
cadence
and
then
scope
a
bore
to
a
specific
cadence,
and
that
way
we
know
which
lists
to
automatically
populate
what
this
will.
Let
us
do
eventually
is
have
a
scenario
where
issues
can
be
assigned
to
iterations
in
groups
outside
of
their
hierarchy.
They'll
be
able
to.
A
One
of
the
things
that,
if
you
want
to
read
this
issue,
it's
kind
of
fun,
we
kind
of
like
thought
a
little
bit
into
the
future
about
where
we
were
going
to
end
up.
A
If
we
continue
making
small
nvcs
on
epics
on
issues
on
some
of
the
things
that
we
need
to
do
for
custom
fields
and
the
amount
of
duplication
that
we
end
up
with
is
pretty
astronomical,
so
one
of
the
things
that
we
really
need
to
be
able
to
do
is
support
the
ability
for
customers
to
define
their
own
hierarchy,
that
they
want
name
the
objects
within
the
hierarchy.
What
they
need
to
some
safe
organizations
will
do
the
epic
capability
feature
user
stories.
A
Others
will
have
different
names
that
they
want
to
call
these
using
labels
is
not
a
sufficient
way
to
solve
this.
It's
confusing
it's
poor
usability
and
then
within
each
of
these
different
types
of
issues
and
once
you're
able
to
define
these
relationships,
I
also
have
the
ability
to
kind
of
configure
the
fields
that
you
want
to
use,
and
so
this
is
really
going
to
position
us
for
the
enterprise
to
be
able
to
take
any
data
model.
That
is
any
in
any
competitor's
solution,
whether
that's
jira
version
one.
A
How
organizations
currently
have
their
issues
set
up
with
their
fields
and
and
map
that
one-to-one
into
gitlab,
with
no
data
loss
with
no
anything,
because
we'll
have
a
flexible
enough
field
model
on
issues
to
support
moving
any
structure
over
more
or
less,
and
this
will
also
unlock
the
ability
to
kind
of
look
at
some
additional
small
primitives,
like
customizable
statuses,
we
already
are
going
to
start
customizable
types
in
139
of
relationships
and
then
it's
about
optimizing.
A
So
one
of
the
things
we're
doing
in
13
8
is
we
are
going
to
convert
the
assignees
field
up
here
into
a
standalone
widget,
which
is
more
or
less
the
same
architecture
that
will
be
used
to
kind
of
power,
custom
fields
down
the
road.
The
reason
why
this
is
also
important
is
that
other
plan
teams
or
other
gitlab
teams
have
started
to
use
issue
types
and
issues
to
solve
their
problems.
Test
cases
is
a
good
example
where
it's
it's
actually
an
issue
type
in
an
issue
under
the
hood.
A
Incidents
with
the
health
team
is
another
example,
and
as
these
teams
are
wanting
to
mainta
autonomy
and
push
forward
with
the
road
maps
and
solving
their
their
jobs
to
be
done
for
their
users,
they
need
a
good
reference
architecture
for
how
to
build
widgets
and
fields
and
the
way
that
we
want
to
have
them
when
we
eventually
want
to
roll
out
this
kind
of
level
of
configurability
and
customization.
A
So
it'll
work
similar
like
this,
where
I
will
go
and
I'll
select,
maybe
an
attribute
I
can
select,
is
and
then
you'll
be
able
to
select
instead
of
just
one
one
value
per
key.
You
can
select
more
than
one
and
then,
when
you're
done
with
that,
it
will
basically
populate
out
your
your
filter,
showing
the
or
in
the
middle
and
one
thing
that
we're
still
kind
of
testing
and
figuring
out
is.
If
we
want
to
allow
this
to
be
a
conditional
or
switches,
and
that
could
be
confusing.
A
But
based
on
some
of
the
feedback,
we
got
seeing
that
or
is
a
helpful
because
some
people,
if
it's
just
a
comma
thought
that
it
was
automatically
or
an
implicit
and
instead
of
an
or
so
I
think,
we're
going
to
start
making
this
a
disabled
kind
of
selectable
filter
and
then
expand
to
see
if
it
makes
sense
to
add
in
there.
A
But
what
this
will,
let
you
do
is
do
assignee,
where
you
can
have
multiple
assignees,
that
can
be
ores,
and
then
you
can
and
other
attributes
other
keys
and
kind
of
do
faceted,
search
that
way
so
excited
about
this
excited
to
see
get
some
feedback
from
our
users
when
we
launch
it.
A
Another
small
usability
thing
that
we're
going
to
be
focusing
on
is
the
discoverability
of
quick
actions.
So
nuke
did
a
great
job
of
challenging
me
and
making
me
think
about
the
usability
of
quick
actions.
A
I
kind
of
have
written
them
off
to
a
little
bit,
just
as
being
a
feature
that
it
should
be
geared
towards
more
advanced
power
users,
but
really,
I
think
it's
it's
a
good
thing
to
focus
on
making
them
discoverable
for
all
gitlab
users,
and
so
right
now
one
of
the
problems
that
you
sort
of
have
is
as
we're
down
here
and
we're
looking.
A
If
I
start
typing,
I
only
see
a
maximum
of
five
quick
actions
when
in
reality
we
have
a
whole
lot
of
quick
actions
that
are
out
there
that
are
available
and
they're
just
not
discoverable.
Unless
I
go
click
through
and
read
this
documentation,
so
what
we're
going
to
do-
and
this
very
small
mvc
is
instead
of
eliminating
it
to
five
we're
going
to
populate
all
the
quick
actions
that
are
possible
and
make
it
scrollable.
A
So
you
can
select
one
from
the
option
from
this
list
without
having
to
go,
read
the
documentations
and
get
started
small
things
super
trivial,
but
I'm
hoping
that
it
will
have
a
huge
impact
in
terms
of
usability.
A
Another
thing:
we've
gotten
some
feedback
that
there's
a
security
issue,
while
back
that
more
or
less
was
making
math
rendering
very
expensive
and
it
was
causing
browsers
to
basically
become
exhausted
from
a
resource
standpoint
and
then
brick.
A
So
we
implemented
some
kind
of
strict
measures,
try
to
lock
that
down,
but
we
were
a
little
bit
too
strict
there
and
it's
made
using
math
within
the
markdown
editor,
whether
that's
issue
or
wiki,
pretty
much
unusable,
because
you
have
to
limit
the
character
size
of
your
math
equation
to
a
very
small
fractional
size
of
what
users
typically
do,
and
so
what
we
found
is
there
are
users
who
are
starting
to
now
not
use
issues,
because
they
can't
render
math
properly
or
they're,
not
using
wikis
the
way
that
they
were
before,
and
so
this
affects
all
markdown
rendering
in
gitlab
and
what
we're
going
to
be
doing
is
using
a
similar
approach
that
we've
done
with
other
things,
with
solving
the
same
problem
with
large
mermaid
charts
or
many
memory
charts
within
a
single
issue
or
markdown
editor.
A
We're
going
to
kind
of
be
doing
some
asynchronous
loading
there
and
trying
to
allow
all
math
rendering
to
be
loaded
in
chunks
instead
of
just
completely
breaking
it.
So
excited
about
that
small
and
the
last
big
thing
usability.
This
will
be
running
between
13,
8
and
39,
but
we're
kicking
it
off
at
13.
8
is
group
level
description,
templates
for
issues,
ethics
and
merge
requests.
A
Epics
will
probably
come
after
we
get
the
base
framework
in
for
issues
and
merge
requests
and
instead
of
creating
a
new
ui
or
introducing
new
ui
we're
actually
going
to
extend
the
file
templates,
ui
and
piggyback
off
this
feature
where,
within
the
instance
level
or
the
group,
you
can
set
a
template
repository
where
you
pick
any
repository.
That's
in
your
hierarchy
that
you
want
to
use
as
your
reference
for
templates
that
all
the
rest
of
the
projects
and
groups
can
use,
and
so
we've
already
done.
A
A
poc
alexander
did
a
great
job
actually
showing
me
a
working
version
of
this,
and
we
need
to
get
a
production
writing.
But
what
you'll
be
able
to
do
is
at
the
instance
level
or
at
the
group
level,
specify
repo
where
you
have
your
file
templates,
but
also
your
description
templates
and
that
will
automatically
then
be
populated
down
to
all
of
your
groups
subgroups
and
made
available
so
that
you
can
set
it
once
and
have
it
everywhere.