►
From YouTube: Verify:Testing 14.1 Milestone Refinement Kickoff
Description
Walkthrough of the 14.1 planning issue focusing on the theme of the milestone and some issues that need attention during the refinement phase: https://gitlab.com/gitlab-org/ci-cd/testing-group/-/issues/58
A
Hey
team,
just
a
quick
walkthrough
of
the
14.1
milestone
to
kick
off
our
refinement
of
this.
So
in
14.1-
and
this
is
the
milestone
kicking
off
in
june-
completing
in
july
kind
of
the
theme
of
this
milestone
is
delivering
some
critical
functionality
for
code
quality,
which
is
a
category
that
we're
handing
off,
but
that'll
help
bridge
the
functionality
for
premium
and
ultimate
users
to
do
some
things
that
they
can't
do
today,
really
until
static
analysis,
can
pick
it
up
and
continue
working
on
the
category.
A
So
those
things
are
somewhere
top
deliverables.
One
is
our
mvc
around
a
scan
that
is
not
used
code
climate.
This
does
a
couple
of
things
for
us
one.
It
gets
us
just
a
faster
scan.
It
helps
people
narrow
down
to
just
run
the
scans
that
they
want
and
it
gets
us
away
from
docker
and
docker.
So
the
mvc
here
is
to
be
able
to
run
a
scan
for
ruby.
A
We
might
change
this
to
run
a
scan
for
ruby
and
javascript
so
that
we
can
dog
food
this
internally
and
get
those
reports
into
all
of
the
code.
Quality
features
so
into
the
merge
request.
Widget
into
the
full
code
quality
report
and
into
the
mr
diff,
that's
going
to
require
the
second
issue
here,
of
adding
support
for
multiple
code
quality
reports,
and
that
is
just
for
the
full
code,
quality
scan
or
the
full
code
quality
report,
rather
being
able
to
take
the
reports
from
multiple
jobs
and
put
them
all
into
that
spot.
A
And
then
the
last
thing
here
is
contributing
to
one
of
our
quarterly
okay,
ours
around
the
error
budget.
This
is
an
audit
of
the
existing
dashboard.
That's
out
there
to
see
what
we're
missing,
what
we
shouldn't
have
in
there
when
it
comes
to
monitoring
endpoints
and
how
they're
doing
the
other
thing
I
wanted
to
call
out
was
a
couple
of
the
user
experience
things
we're
going
to
be
working
on.
One
is
targeted
at
increasing
engagement
with
the
paid
feature
and
increasing
usage
of
a
paid
feature.
A
That's
in
our
group
test
coverage
dashboard
showing
some
projects
when
you
get
there.
If
you
haven't
selected
any
projects,
there's
no
data
to
display
which
isn't
a
great
experience,
so
we're
just
going
to
pick
some
data
for
the
user
and
show
that
there,
so
they
can
see
the
graph
and
they
can
see
the
projects
and
click
into
them.
A
So
they
can
really
dig
in
and
understand
and
value
that
feature
and
then
the
other
is
a
benefit
for
a
static
analysis
team
as
we're
handing
it
off
adding
a
link
to
the
full
code
quality
report
on
the
code.
Quality
merge,
request,
widget:
where
do
you
do
this
on
test
summary?
We
already
do
it
on
license
compliance
or
static,
does
or
secure
does,
rather
and
in
the
user
interviews
that
I've
done
lately.
A
Customers
just
don't
know
how
to
get
there,
and
that
includes
internal
gitlab
users,
so
giving
them
that
button
from
code
quality
will
give
them
access
into
that
full
report,
which
again,
is
a
paid
feature.
So
we
should
see
increased
pg
amount
from
that
and
then
last
there's
a
couple
of
bugs
here
that
we're
working
on
one
test
report
api
is
inconsistent
with
junit
ui
and
then
the
code
quality
mr
widget,
trying
to
really
get
to
resolution
on
when
a
report
isn't
there
why
and
displaying
that
information
better.
A
So
clicking
then
into
our
milestone
board.
You
can
see
we
already
have
some
things
with
a
weight
on
them
and
in
ready
for
development
and
there's
only
nine
issues
in
the
planning
breakdown
list
today.
So
go
ahead
and
jump
in
there
start
looking
poking
me
asking
questions
clarifying
things
so
that
we
can
get
this
milestone,
refined
and
into
ship
shop
sheet.
Thanks
cheers.