►
Description
Walkthrough current state of maturity for the team's categories, what needs done to advance them and the current timelines to do that within.
Maturity Page: https://about.gitlab.com/direction/maturity/#verify
Category maturity Scorecard info: https://about.gitlab.com/handbook/engineering/ux/category-maturity-scorecards/
CI Direction Page: https://about.gitlab.com/direction/verify/continuous_integration/
MT Direction Page: https://about.gitlab.com/direction/verify/merge_trains/
A
Hey
dean,
I
wanted
to
do
a
quick
walkthrough
of
our
maturity
of
the
existing
categories.
Excuse
me
and
our
plan,
for
how
we're
going
to
mature
those
just
do
a
do.
A
quick
update
of
that
and
start
doing
these
quarterly
so
with
the
new
quarter
kicking
off.
I
wanted
to
get
this
recorded
because
I
am
going
to
put
this
out
on
one
filtered
didn't
want
to
put
the
caveat
in
there
of
this,
contains
information
related
to
upcoming
products,
features
and
functionality.
A
It's
important
to
note
that
it's
not
presented
for
it
or
it
is
presented
for
information
purposes,
only
don't
rely
on
this
for
purchasing
or
any
planning
purposes.
Anything
linked
or
mentioned
here,
subject
to
change
or
delay,
as
we
know
so
overview
today,
of
where
we're
at
the
screenshot's
a
couple
of
weeks
old,
but
nothing
has
changed
where
we're
at
is
ci
scaling,
which
is
a
non-marketing
category,
so
it
doesn't
appear
on
our
maturity
is
in
a
currently
available
state.
Ci
is
a
complete.
A
We're
working
with
ux,
though
on
kind
of
setting
some
thresholds
for
how
we
think
about
load
at
scale
and
also
then
doing
some
interviews
and
creating
a
score
card
of
sorts
of
how
we
think
about
really
large
users
on
gitlab.com
and
the
experience
that
they
would
have
with
a
lot
of
users
taking
a
certain
action
or
onboarding
a
lot
of
users
to
the
ci
platform
and
how
that
should
influence
our
our
maturity
level.
And
so
that
is
ongoing
research
right
now.
A
And
so
I'm
not
going
to
talk
through
what
it's
going
to
take
necessarily
to
get
us
to
that
next
state.
In
this
video
for
viable.
It
should
have
significant
use
at
gitlab
as
a
company.
An
internal
maturity
scorecard
score
of
3.14
for
our
main
job
to
be
done
with
those
internal
users
and
there's
no
assessment
for
the
related
jobs
to
be
done.
A
Complete
does
do
that
assessment
externally,
there's
at
least
100
users
using
it
has
that
scorecard
of
3.63
for
the
identified
jobs
to
be
done
when
tested
with
external
users
and
then
lovable
get
us
up
to
a
score
of
3.95
for
the
related
for
the
job,
maybe
not
in
the
related
jobs
to
be
done.
So
we
have
some
scorecard
testing
that
we'll
need
to
do
as
part
of
this
excuse
me.
A
So
I
do
have
here
moving
cs
scaling
from
available
to
minimal
we're
going
to
step
over
that,
because
we're
still
working
through
the
research
part
of
it,
but
ci
continuous
integration
to
move
from
complete
to
lovable
right
now.
Our
target
for
that
is
january,
and
so
some
of
the
to
do's
that
we
need
to
do
to
get
there
is
that
scorecard
of
this
isn't
3.63
right
edit.
This
on
the
fly.
A
A
A
A
I
don't
know
that
we
have
enough
capacity
and
that's
enough
time
to
close
the
gap
in
that,
so
we
may
result
in
a
maturity
target
change
from
complete
to
lovable
to
further
out
from
january,
because
the
scorecard
takes
a
while
to
score
it's
not
going
to
take
the
full
three
months.
That's
reflected
here
november
december
january.
A
A
So
the
things
that
we
still
need
to
do
are
significant
use
at
gitlab
and
really
that
means
enabling
it
for
the
main
gitlab
project.
Merge
strains
is
not
turned
on
there
and
we
know
what
we
need
to
do
for
that.
There's
some
dog
fooding
items
that
we
want
to
address
the
big
ones
are
some
api
work
to
be
able
to
add
support
for
when
the
pipeline
succeeds
and
emerge
to
invest,
merge,
train
visualization.
A
So
in
this
case
it
would
be
merge
results,
pipeline,
merge,
merge
pipelines
for
merge,
requests,
merge,
request,
pipelines
or
just
what
we're
doing
today
of
you
know.
Putting
things
merge
when
pipeline
succeeds,
so
we'll
need
to
complete
then
additional
research,
and
we
would
do
a
cm
scorecard
identified
3.63
to
get
to
complete
so
we're
a
little
bit
ahead
here
with
viable
because
we're
not
using
it
internally
exclusively.
So
we
want
to
validate
that.
It
really
really
is
viable
and
then
move
it
into
complete.
A
I
think
that
the
timeline
there
in
15
months
makes
sense.
We
have
time
to
do
the
work
that
needs
to
get
done
and
as
of
course,
pending
other
things
that
you
know
push
in
and
are
more
important
for
us
to
merge
trades
at
the
time.
So
the
rough
timeline
for
that
is
again
working
through
the
jobs
to
begin
review,
validating
the
internal
usage
gaps,
we'll
be
working
on
that
in
q3
fiscal
year,
23.
So
that's
august,
through
october
of
22
and
then
november
through
january.
A
We'll
do
the
additional
research
to
make
sure
the
additional
jobs
to
be
done
are
well
understood
and
we
can
start
to
build
to
close
those
gaps.
It
looks
like
I
had
those
two
things
closed
or
pretty
much
duplicated.
Additional
strategy
done
research,
but
then
coming
may
is
when
we
would
may
have
23
about
a
year
from
now
is
when
we
start
that
research
into
the
external
user
jobs
to
be
done,
validation
and
do
the
scorecard
rather
and
get
that
score
up
there
and
you
know
be
able
to
move
that
category
to
complete.
A
So
that's
a
quick
walkthrough
of
where
we're
at
with
the
maturity
today
and
where
we
want
to
go
some
of
the
things
that
we
need
to
do
to
get
there,
and
so
I'll
continue
to
post
these
updates
quarterly
or
whenever
I'm
making
a
maturity,
change
or
a
date
in
a
maturity
change
so
that
we're
all
keeping
up
to
date
on
where
we
want
to
go
and
how
we're
going
to
get
there.
Thanks.