►
From YouTube: GitLab 12.8 Kickoff - Plan:Project Management
Description
12.8 Release kickoff issue for the Plan stage - https://gitlab.com/gitlab-org/plan/issues/53
A
Hey
this
is
Gabe
from
the
planned
project
management
group
with
get
lab,
talked
to
you
about
the
12.8
release,
kickoff
issue
that
we
have
things
we're
going
to
be
focusing
on
until
0.8
within
our
group.
There's
some
problem-
validation,
stuff.
There
are
some
solution,
validation,
stuff
within
problems,
we're
going
to
be
starting
to
understand
better
how
we
can
prevent
the
ability
to
duplicate
labels
across
projects,
groups
which
is
kind
of
noisy.
A
We
originally
started
with
project
level
labels,
and
we
had
a
group
logo
labels
and
the
ability
to
promote
project
to
group
level
labels,
but
you
can
still
prevent
duplicates
and
that's
they
all
filter
down
it's
kind
of
hard
to
tell
which
label
you
should
be
using,
especially
if
they're
all
named
the
same
thing.
So
we
want
to
figure
out
the
best
way
to
solve
for
that.
We're
also
going
to
start
looking
into
how
we
can
automate
the
triaging
of
labeling
of
issues
more
specifically
around.
How
can
we
automate
issue
workflows
where
it
makes
sense?
A
So
this
is
the
early
phases
of
the
validation
cycles
within
solution
we've
been
working
on
understanding
how
we
can
add
more
than
one
tie
box
to
an
issue.
More
specifically,
an
issue
can
belong
to
maybe
sprint,
maybe
a
milestone,
maybe
a
version.
We're
pretty
close.
We've
gone
through
a
lot
of
design
cycles
here,
but
we
need
a
few
more
customer
interviews
so
before
we
get
that
scheduled
for
final
implementation
phases,
we're
going
to
talk
to
some
folks
get
their
feedback.
A
Make
sure
that
the
solution
is
on
point
in
terms
of
design
priorities,
we're
going
to
be
looking
at
how
we
can
provide
first
class
class
support
for
issue,
task,
lists
and
tasks.
This
is
a
we
have
tasks
in
markdown,
but
they're.
Not
really
a
real
data
object
as
far
as
the
product
is
concerned,
and
this
to
enable
us
to
do
things
like
add
weights
to
tasks
and
automatically
roll
them
up
into
issues
as
a
whole,
which
would
be
great
and
then
one
of
highly
requested
feature.
A
Probably
one
of
the
most
highly
requested
features
within
the
project.
Management
group
as
a
whole
is
group
level
description
templates
for
issues
epics
and
merge
requests,
so
we're
gonna
start
designing
that
out
and
seeing
how
complex
we'll
be
using
what
the
simplest
NBC
would
and
hopefully
getting
that
scheduled
in
the
future.
Milestone
specific
features
were
going
to
look
to
deliver
in
12.8.
Burnet
charts
is
one
of
them,
and
this
kind
of
goes
in
line
with
the
theme
of
trying
to
better
a
report
on
scope,
change
in
movement
within
a
milestone.
A
Right
now,
the
burndown
chart
isn't
very
historically
accurate,
as
in,
if
I
were
to
add
a
bunch
of
scope
to
a
given
milestone.
It's
not
very
indicative
that
that's
happening
so
I
could
complete
five
issues
on
one
day
and
I
could
add
five
issues
one
day
to
that
milestone
and
this
line
wouldn't
move
so
the
burnup
chart.
What
it
does
is.
It
will
attract
the
scope
that
is
completed
over
a
given
milestone.
A
It
will
also
track
the
total
scope,
so
you
can
track
both
what
is
at
it
and
was
removed,
and
it's
kind
of
a
more
accurate
way
to
understand
the
narrative
and
a
story
of
how
things
play
out
within
a
given
milestone.
After
this
happens,
we're
gonna
continue
to
show
maybe
like
what
milestone
is
or
what
work
has
been
carried
over
from
previous
milestone
to
understand.
You
know
like
how
well
your
team
is
doing
on
executing
finishing
what
they've
committed
to,
and
this
also
will
lead
to,
naturally,
a
better
report
within
the
Mauston
suit
investigation
around.
A
Why
didn't
we
get
things
done?
How
can
we
reduce
the
friction
of
a
scope
group
during
a
given
sprint?
So
this
is
a
big
thing
that
folks
has
been
asking
for,
would
think
about
and
we're
excited
to
work
on
that
another
feature
we're
gonna
be
working
on.
Is
we
want
to
get
at
least
one
field
in
the
sidebar
any
sidebar,
whether
that's
an
epic
or
an
issue
updating
in
real
time?
A
The
significance
of
this
is
doing
a
proof
of
concept
on
how
we're
going
to
address
more
real
time
features
than
gitlab,
which
has
kind
of
been
a
hot
topic
of
discussion
across
several
different
groups
and
what
we
want
to
do
case
in
point.
If
I
were
to
update
a
label
right
now-
and
somebody
else
is
looking
at
this
issue-
they
would
not
see
that
label
update
and
that's
kind
of
you
know.
A
We
want
people
to
understand
the
issues,
there's
a
single
source
of
truth,
but
also
that
what
they're
looking
at
is
the
most
accurate
reflection
of
the
data
with
an
issue
to
date,
and
the
only
way
to
do
that
is
using
thing
like
WebSockets.
We
currently
use
etag,
caching,
which
kind
of
has
its
drawbacks
and
we're
looking
to
kind
of
level
things
up
with
WebSockets,
an
action
capable
within
rails.
So
goal
is
very
small:
get
one
field
updating
either
assignees
Mouse
own
I'm,
not
sure
what
team
is
going
to
side
here.
A
But
the
goal
is
just
one
small
thing
to
do
concepts
so
that
we
can
continue
to
expand
and
grow.
We
also
would
like
to
address
some
UX
debt
from
not
filtering.
We
released
this
in
12.7,
but
in
order
to
get
it
in
12.7,
we
had
to
make
a
lot
of
concessions
in
terms
of
usability,
and
this
is
following
up
on
that
to
make
sure
that
it's
a
top
notch
experience
so
we'll
be
addressing
this
issue
as
well.
A
There's
lots
of
little
things
that
you
know
nuances
that
will
make
it
a
better
experience
so
going
to
check
this
out
great
I
will
post
a
link
to
this
planning
issue
with
a
YouTube
video
you
check
it
out.
You
can
click
through,
can
read
everything
and
there's
also
a
link
to
some
of
the
more
relevant
epics
that
apply
the
peril
holders
for
the
bigger
picture,
vision
of
why
we're
working
on
these
features
and
would
love
for
you
to
contribute.
If
you
have
any
feedback
Thanks,
you.