►
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
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
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
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
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
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
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
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.