►
From YouTube: GitLab 12.8 Kickoff - Plan:Certify
Description
GitLab 12.8 Kickoff for the Plan:Certify group.
Release planning issue can be found here: https://gitlab.com/gitlab-org/plan/issues/53
A
A
So
the
certified
group
for
12.8
has
some
pretty
ambitious
goals
as
far
as
designing
ahead
we're
trying
to
catch
up
and
get
ahead
with
our
designing
work
as
such.
These
design
priorities
that
are
listed
here
are
really
issues
that
will
be
designed
throughout
the
12.8
milestone
for
implementation
in
12.9
or
future
issue,
or
a
future
milestones,
so
I'll
kind
of
go
through
these.
A
So
you
can
get
a
feel
for
where
we're
heading
the
first
one
is
the
ability
to
sort
issues
in
list
view
by
the
number
of
items
they're
blocking
with
the
introduction
of
blocking
issues.
One
of
the
key
metrics
that
people
would
like
to
see
is
how
many
issues
have
issues
that
are
being
locked
and
of
the
blocking
issues
which
one
has
the
most
things
it's
blocking.
A
In
that
sense,
we
want
to
be
able
to
prioritize
our
work
to
unblock
the
most
issues
at
a
time
and
therefore
prioritize
those
issues,
potentially
that
have
the
most
blocked
issues.
So
in
doing
so,
we
now
are
hoping
to
add
this
ability
to
the
existing
sort
drop-down,
something
along
the
lines
of
blocking
or
is
blocked
and
it'll
enable
people
to
see
which
issues
are
blocking
the
most
issues
and
help
with
prioritization.
So
we're
pretty
excited
about
that.
A
The
next
item
that
is
currently
being
designed
for
the
future
work
after
12.8
is
the
ability
to
view
the
audit
trail
on
the
full
audit
trail
of
a
description
history.
So,
as
we've
added
the
ability
to
view
the
history
of
description,
changes
and
issues,
one
of
the
items
that
we
had
to
do
was
enable
those
histories
to
be
deleted,
in
a
sense
that,
if
somebody
put
sensitive
information
into
a
description
history,
we
wanted
to
tune
in
to
a
description.
The
history
would
show
that
sensitive
information,
which
wasn't
a
good
thing.
A
A
Currently,
when
a
service
desk
issue
is
created
via
an
email
coming
in
from
an
end
user,
the
issue
is
automatically
more
confidential
and
in
most
situations
that
make
sense,
you
don't
want
other
customers
being
able
to
see
customer
data
that
potentially
could
be
within
an
issue.
However,
the
service
desk
is
not
designed
for
only
external
use,
sometimes
it's
nice
to
have
a
service
desk
for
internal
issues
such
as
the
high
IT
Help
Desk.
In
that
case,
you
don't
want
the
issues
necessarily
to
be
marked
confidential.
A
You
would
like
other
internal
users
to
be
able
to
see
resolution
to
issues
and
search
those
issues
in
order
to
better
serve
themselves
before
having
to
submit
a
new
issue
of
their
own,
we're
going
to
be
designing
a
way
for
you
to
default
all
incoming
service
desk
issues
to
confidential
or
not
confidential,
and
that
will
allow
the
flexibility
afforded
to
users
who
don't
necessarily
want
confidentiality
step
going
back
to
our
planning.
We
are
planning
to
catch
up
with
some
of
the
slippage.
A
A
The
first
thing
we
want
to
implement
here
is
to
raise
a
warning
when
closing
an
issue
with
open
blockers.
If
blocking
issues
have
been
utilized
correctly,
you
shouldn't
be
able
to
close
an
issue
that
is
blocked
until
the
blocking
issue
is
also
closed.
We
don't
want
to
prohibit
people
from
doing
that
if
there
are
use
cases
for
that,
but
we
do
want
to
raise
a
warning
to
alert
them
that
there
may
be
an
issue
with
their
dependencies,
so
this
implementation
of
this
issue
will
allow
for
that.
A
We're
also
hoping
to
allow
private
comments
on
service
desk
issues.
This
has
been
a
much
requested
feature.
It's
very
popular
within
the
community.
If
you're
using
the
service
desk,
do
you
interact
with
your
customers
as
well
as
interact
with
other
people
on
your
team?
It
sometimes
is
beneficial
and
required
to
be
able
to
interact
with
those
team
members
without
posting
updates
to
the
customer
like
to
discuss
their
issue
internally,
potentially
discuss
possible
security
issues
that
this
issue
is
brought
up
and
those
things
are
not
things
you
necessarily
want
emailed
to
the
end-user
every
time.
A
A
Currently,
we
don't
have
an
API
for
adding
related
issues
in
graph
QL
and
it
would
be
great
to
add
that
support
to
bring
our
API
into
a
wor
mature
state.
So
that
is
one
item.
We're
hoping
to
do.
The
other
item
we're
hoping
to
resolve,
which
is
more
tech,
death
and
refactoring,
is
currently
weird,
acting
all
quick
actions
on
incoming
Service
Desk
emails
when
we
implemented
the
template
izing
of
the
incoming
issues.
A
One
of
the
things
we
wanted
to
accomplish
through
those
templates
was
the
ability
to
use
our
quick
actions
to
assign
incoming
issues
to
specific
user
Institute
as
specific
labels
I.
In
order
to
do
that,
we
were
forced
to
kind
of
remove
the
quick
actions
from
incoming
emails
now,
I'm,
not
sure
the
expanded
use
of
this
I'm
not
sure
how
many
people
will
be
using
this,
but
it
is
nice
to
be
able
to
within
email
sent
to
the
Service
Desk,
specify
quick
actions,
so
we're
hoping
to
sort
of
bring
that
feature
back
through
this
issue.