►
From YouTube: GitLab Documentation Content Audit
Description
GitLab Technical Writer Manager, Craig Norris, discusses a recent content audit of our documentation site (https://docs.gitlab.com/).
A
Hi,
my
name
is
Craig
Norris
I'm,
a
manager
of
technical
writers
here
at
gitlab,
I,
started
relatively
recently
and
inherited
a
group
of
technical
writers
that
are
responsible
for
the
product
documentation
here,
but
I
wanted
to
know
more
about
the
documentation
itself
and
all
of
the
things
that
we
were
responsible
for.
So
as
part
of
that
onboarding
I,
you
know,
was
responsible
for
doing
a
Content
audit
of
all
of
the
information
that
we
have
and
I
just
wanted
to
share.
A
You
know
what
we
found
and
some
of
the
insights
that
we've
made
into
the
things
that
we
do
so
as
part
of
that
effort,
we
collected
all
of
the
information
that
we
discovered
into
a
spreadsheet
that
allowed
us
to
be
able
to
see.
You
know
here
are
the
markdown
pages
that
we
have.
You
know
here's
where
they're
located
things
about.
You
know
titles
of
those,
but
you
know
also
even
into
when,
were
they
last
updated?
Who
is
the
technical
writer
that's
generally
associated
with
the
content
on
this
page?
How
big
is
the
page?
A
How
complex
is
the
page
and
from
that
we,
you
know,
put
together
some
information
there.
For
example,
we
have
a
little
over
1,600
markdown
pages
that
make
up
the
product
documentation
set.
Most
of
them
happen
to
be
sitting
in
the
yet
lab
repo.
We
do
have
quite
a
few
redirects
that
are
sitting
in
there
as
well,
though,
which
are
just
individual
pages
that
redirect
other
places.
A
Those
are
some
of
the
things
that
we've
identified
that
we'd
like
to
try
to
you
know
cut
down
on
so
that
we
can
have
most
of
our
product
documentation
actually
be
product
documentation
of
that
product
documentation.
We
have
about
1.2
million
words
and
Counting
within
that,
so
it's
relatively
large
well
how
large
about
the
size
of
24
standard
novels
or
also
about
the
same
length
as
two
times
were
in
piece,
and
not
only
is
it
just
that,
but
it's
its
content
that
we
update
on
a
regular
basis.
It's
not
like.
A
We
wrote
it
once
and
then
we're
done.
We
regularly
revisit
the
information.
That's
in
there
as
a
matter
of
fact,
over
half
of
the
content
that
includes
the
pages
and
the
images
were
updated
in
2020
alone.
So
we
have
a
lot
of
content.
We
have
a
lot
of
contents
that
we
update
regularly.
What
else
do
we
know
about
it?
A
Well,
the
average
reading
level
of
our
product
documentation
using
the
flesh,
contains
four
reading
score,
which
is
useful
for
technical
manuals,
but
also
for
product
documentation
rates
as
a
ten
point,
seven,
which
means
that
on
average,
our
product
documentation
would
require
a
u.s.
grade.
11
education
in
order
to
be
able
to
you,
know,
properly
use
the
information.
A
Now
the
average
American
needs
at
about
a
seventh
or
eighth
grade
level,
so
we're
missing
out
on
a
good
percentage
of
the
US
population,
and
you
know
people
that
can
understand
our
product
documentation,
but
by
making
our
product
documentation
easier
to
understand
and
increasing
the
audience
in
America,
we
also
have
a
better
ability
to
be
able
to
connect
with
people
where
English
may
be
their
second
language.
Also
having
a
higher
score
means.
The
pages
are
more
complex,
which
means
that
we
have
you
know
pages
that
can
be
simplified
and
better
used
by
our
readers.
A
So
these
are
just
a
few
of
the
things
that
we've
kind
of
identified
about
our
product
documentation
that
we're
going
to
use
as
we
move
forward
in
some
of
our
development-
and
you
know
you
know,
architecture,
discussions,
we're
looking
at
also
trying
to
make
this
information
or
the
the
collection
of
the
information
a
little
bit
more
automated
and
something
that
we
don't
just
do
periodically.
But
we
can
do
consistently.