►
From YouTube: Exciting improvements to GitLab CI/CD docs!
Description
Marcel Amirault, Technical Writer at GitLab, Verify meets with Nadia Sotnikova, Product Designer at Verify:Pipeline Authoring to discuss the upcoming improvements to CI/CD documentation.
- What are the problems with GitLab CI/CD documentation
- What improvements are we making
- How Technical Writing and UX collaborate to make GitLab CI/CD magic
Learn more about GitLab CI/CD: https://docs.gitlab.com/ee/ci/
A
All
right,
so
what
am
I
up
to?
I
guess
so
here
let
me
share
my
screen,
so
I
to
be
honest.
I
I
feel
like
this
week,
I've
kind
of
caught
up
kind
of
starting
just
before
my
vacation
that
last
week
I
basically
got
to
to
do
zero
and
then
I
was
able
to
start
looking
into
the
long
term
plans,
but
there's
one
thing
that
I've
been
tinkering
with
and
I
probably
could
have
gotten
emerged,
but
I
still
feel
like.
A
A
If
you
look
at
the
sidebar
like
you
can
see
how
things
kind
of
jump
around-
and
you
have
like
keywords-
a
lot,
but
then
you
have
things
that
don't
really
match
exactly
a
good
example
is
rules
are
also
only
except
we've
got
only
except
basic.
We've
got
regular
expressions
and
supported
syntax
and
all
this
stuff,
but
it
would
be
a
lot
better
if
all
we
did
was
list
keywords.
A
A
That's
at
the
bottom.
Actually
I
think
yeah
for
some
reason
I'll
have
to
fix
that,
but
we
have
a
very,
very
dry
like
page
that
lists
one
topic,
an
example,
a
response,
and
then
we
have
same
thing
again:
we've
got
the
endpoint
details.
The
call
a
table,
the
response
and
it
kind
of
repeats
again
and
again
and
again
like
that,
so
that
when
people
are
looking
at
one
of
the
bigger
ones,
maybe
like
user
is
a
massive
one.
A
You
can
see
how
many
are
on
the
side,
but
at
the
same
time
it's
really
obvious
list.
Ssh
keys.
I
know
exactly
what
I'm
going
to
get
when
I
go
there
single
ssh
key,
add
ssh
key
like
when
I
go
there
and
I
know
exactly
what
I'm
going
to
get,
because
this
looks
exactly
like
this
looks
like
this
looks
like
this.
They
all
look
the
same.
So
that's
my
idea
to
to
do.
The
same
thing
here
is
to
have
all
of
these
listed
with
a
standard
template,
and
where
is
that's.
B
A
A
A
Ready
yet,
but
so,
for
example,
if
we
look
at
how
rules
looks
like
in
the
old
one,
but
now
look
at
the
new,
only
except
it's
just
really
dry,
and
so
we've
got
only
except
four
keys
here,
you
go.
If
you
want
to
go
to
refs,
and
then
we
have
a
keyword
type,
it's
a
job
keyword.
You
can
only
use
it
as
part
of
a
job.
A
What
are
the
inputs
that
it
accepts
much
like
the
table
in
an
api
reference?
Here's
one
single
example:
here's
additional
details
in
case
you
know
I
want
a
little
bit
of
flexibility,
so
maybe
an
additional
detail
section.
If,
if
you
really
have
to
put
some
extra
information,
put
it
in
additional
details
and
then
the
same
thing
only
keyword
type,
it's
a
job
keyword,
the
inputs
variables.
A
A
What
this
does
is
it
gives
developers
and
contributors
a
place
to
just
say:
I'm
using
only
changes
for
this
use
case
and
then
just
list
all
the
use
cases
on
this
page
outside
of
the
reference,
because
people
don't
really
need
to
see
that
in
the
reference.
But
if
they're
like
using
only
changes
or
something
they'll,
be
able
to
come
here
and
look
for
specific
examples
that
match
their
use,
cases
for
people
who
know
what
they're
doing
they
can
just
go
here
and
say:
what
does
it
need?
Oh,
it
needs
an
array.
A
B
A
A
A
Yeah,
it's
just
been
a
matter
of
finding
time
to
work
on
it
because
yeah,
like
I
said,
I'm
like
oh,
should
I
bold
this
or
not,
or
should
I
make
this
a
list
or
should
it
be
paragraphs
and
it's
all
just
been
kind
of
tinkering
with
it
from
time
to
time,
but
I
I
actually
like
you
can
see
where
was
it
suzanne
was
just
somewhere.
She
was
like
want
me
to
merge
like
she's,
ready
like
let's
merge
it,
let's
go
she.
She
doesn't
wanna
he's
like
it's.
A
B
A
A
A
We're
kind
of
slowly
rolling
out
a
new
process
called
we're,
we're
calling
it
ctrt,
which
is
concept,
task,
reference
tutorial,
slash,
troubleshooting
or
maybe
troubleshooting
as
a
special
case,
and
the
main
thing
is
we're
trying
to
group
pages
as
much
as
we
can,
but
at
least
sections
such
that
it's
only
doing
explaining
a
concept
or
it's
only
explaining
a
task
or
it's
a
reference.
So
the
the
new
this
one
control
when
jobs
run,
would
be
like
a
list
of
tasks.
A
I
want
to
run
a
job
when
something
I
want
to
run
a
job
with
something,
and
this
should
be
the
concept
page
and
you
can
see
it
says
concepts
right
now,
but
like
we
don't
need
overview,
we
don't
need
getting
started
really
and
it
would
just
be
explained
the
concepts
of
getland
cicd.
So
it's
I
have
an
issue
open
about
this
one
and
it's
just
a
matter
of
buckling
down
and
working
on
it.
Instead
of
tinkering
with
the
other
stuff,
that's
more
fun.
B
Yeah,
so
so
here,
basically,
what
you're
suggesting
is
that
for
the
this
parent's
icd
page,
we
will
have
just
just
explain
what
gitlab
cicd
is
and
what
it
does
yeah
roughly
and
then
in
get
started
page.
This
is
this
is
the
one
page
that
you
need
to
get
started.
Basically,
that's
kind
of
how
I
see
it
ideally
like.
What's
the
flow
you
you've
never
heard
of
gitlab
scarcity
or,
like
you
heard
of
it
once
and
now,
you're
coming
to
the
docs.
B
B
Some
more
advanced
features,
and
maybe
getting
started,
should
focus
on
like
the
way
I
see
it.
It
should
be
really
like
a
workflow
based
page
so
step
by
step,
taking
you
through
the
process
of
getting
started,
making
it
possible
to
kind
of
go
into
different
directions
if
you,
if
you
need
to,
if
you
want
like
more
complex
configuration
right
away
or
something
like
that,.
A
Yeah
yeah,
yeah
and
so
like
for
this
one
gets
it.
I
think
the
idea
here
is
like
how
do
I
get
started
with
git
labs?
I
I've
never
done
this.
I'm
gonna
we're
gonna,
see
what
it
what
it
says
so
like
it,
you
know
if
it
brought
us
there
and
that's
kind
of
the
whole
idea
is
like
what
would
people
actually
type
and
it
it
and
it's
bringing
us
here-
it's
not
bringing
us
to
like
the
main
one.
So
that's
a
good
question:
what
is
git
lab
ci
cd?
A
A
Yeah,
so
this
one
was
created
in
the
past
when
people
were
like,
I
don't
even
understand
what
cicd
is,
let
alone
gitlab
ci
cd.
So
there
is
the
idea
that
we
should
create
it.
This
was
before
I
joined,
but
we
should
create
a
page
that
tells
people
what
does
continuous
integration
mean?
What
does
continuous
delivery
mean
and
give
like
a
definition
of
terms
and
and
of
kind
of
related
to
gitlab
cicd?
A
B
Yeah
yeah,
it
makes
a
little
sense.
I
agree,
I
think
it's
the
way
you
framed
it
thinking
about
those
two
questions
or
like
queries
that
someone
would
be
searching
for
get
started
with
csd
or
what
is
gitlab
cicd.
So
these
are
kind
of
the
two
main
questions
that
we
want
to
answer
initially,
when,
when
someone
is
on
boarding
onto
gitlab
ci.
A
Yeah,
there's
also
a
lot
of
work
happening
about
the
information
architecture
of
the
page
like
how
we
set
up
things
on
the
sidebar
as
well
and
and
so
there's.
Sometimes
our
managers
are
saying:
oh
well,
you
know
hold
off
on
that
reorganization
or
hold
off
on
that
revamp
because
we're
not
sure
how
we're
going
to
structure
things,
but
this
type
of
change
we're
actually
getting
strong
encouragement
from
management
to
go
ahead.
With
this
make
sure
the
pages
have
headers
that
people
will
actually
search
for
to
not
not
have.
A
So
here's
kind
of
a
mix
I
rewrote
this
one.
This
is
what
I
was
working
on
heavily
like
last
month.
It's,
for
example,
like
how
do
I
use
an
instant
cicd
variable?
It
doesn't
say
that
it's
just
like
a
a
title,
so
this
is
more
of
a
concept
to
teach
people,
so
you
we
could
conceptually
we
could
put
like
what
is
an
instance
the
icd
variable,
but
if
we're
introducing
things
we
can
we
can
just
do
it
like
that.
But
you
can
see
here.
A
A
Like
they're
pa,
the
pages
are
big
and
it's
it's
hard
to
make
small
iterations
when
you
want
to
just
like.
I
would
just
want
to
take
all
of
this,
and
I
want
to
rename
everything-
and
I
do
want
to
do
all
this,
but
it's
actually
a
thousand
lines
and
then
you
know
you're
going
through
and
going
through
it.
It
takes
a
long
time
for
for
some
of
these
big
pages.
If
it's
a
little
page,
you
get
that
instant
gratification,
but
for
these
big
ones
it's
it's
a
long
slog
to
get
through
them
all.
B
A
B
A
A
A
It's
like
we
need
more
of
these,
so
so
he's
actually
doing
the
opposite,
like
the
other
way
around,
because
in
the
reference
we're
just
saying,
here's
the
keywords:
here's
the
thing
you
know:
here's
how
he
hears
the
the
acceptable
inputs
and
stuff
like
that,
but
we
don't
really
have
a
way
to
advertise
and
we
don't
really
want
kind
of
like
that
blog
style,
but
I
actually
replied
in
so
I
copied
it
with
him
and
I
replied.
It
was
like
we
need
more
of
these.
A
This
is
exactly
what
we
need
like
when
we're
when
we're
making
breaking
changes
or
making
some
new
ideas.
Like
not
everyone,
looks
at
the
the
release
post
and
and
it's
not
necessarily
clear
in
a
little
blurb,
and
I
think
that
blog
post
is
going
to
have
a
much
bigger
effect
and
we
should
probably
write
more
of
those.
B
A
You
take
it
out
of
the
dock,
so
we
kind
of
just
like
yeah:
let's
not
link
them
at
all,
but
we
then
we
do
lose
the
current
the
benefit
of
it
right
now.
So
there
there's
a
same
thing
with
youtube
videos:
people
put
youtube
videos
into
the
docs
and
we're
we're
always
a
little
bit
like
aha,
it's
okay
now,
but
will
it
be
okay
in
the
future?
B
A
A
Well,
another
thing,
just
just
if
you
have
a
time
I
just
wanted
to,
let
you
know
I
I
had
my
one-on-one
with
my
manager
yesterday
and
I
said
it's
strange
because
my
like
the
number
of
mrs
that
I've
had
to
review,
has
gone
down
a
little
bit,
but
I
still
feel
busy,
but
not
in
a
bad
way.
You
know,
just
just
let's
say
active,
I'm
not
I'm
not
sitting
here
doing
rubik's,
cube
or
something
passing
the
time
I
always
have
stuff
to
do.
A
I
have
two
designers,
I've
got
nadia
and
vitika
who
are
designing
the
interface
and
and
they're
asking
me
about
the
text
in
the
interface
and
we're
working
together
on
these
proposals
and
we
can
and
then
together.
We
can
both
think
about
how
people
are
going
to
use
it,
and
then
we
we
end
up
with
a
great
proposal
that
then
goes
off
to
the
engineers
and
it's
like
yeah,
I
am
in
ux.
You
know
I
might
like.
A
I
am
helping
out
with
the
design
and
stuff
like
that,
and
I've
just
been
enjoying
that
part,
because
in
the
first
year
and
a
half
in
in
verify,
it's
been
just
docks:
stock
stock
stock
stock
stocks,
occasional
pings
for
ui
text
or
error
messages
and
stuff
like
that,
but
over,
like
the
last
six
months,
it's
really
swung
over
to
helping
out
with
the
design
phase,
and
it's
just
been
really
really
nice
to
work
with
you
and
vitica
on
the
designs
and
yeah.
I
I
really
like
that.
B
That's
great,
I'm
really
glad
to
hear.
I
also
really
enjoy
working
with
you
and
I
see
technical
writing
as
a
critical
part
of
ux,
like
the
way
I
see
documentation
is
that
it's
part
of
our
product
like
there's,
really
no
difference,
especially
you
know,
for
products
like
gitlab
documentation
is
extension
of
the
ui.
Basically,
like
it's
just
so
complex,
you
need
to
rely
on
documentation
and
in
our
research
for
pipeline
authoring.
We
see
that
the
communication
is
used
more
than
gitlab
ui
for
cicd
authoring,
so
especially
imaginable.
B
Yeah,
like
the
only
the
only
part
of
pipeline
authoring
tools
that
we
offer
it's
cic
documentation,
that's
what
they
access
like.
If
they
don't
try
out
pipeline
editor
and
what
we
often
see
is
someone
uses
documentation
and
the
standalone
linter,
for
instance,
and
then
they
use
github
ui
to
like
navigate
to
the
pipeline
and
view
the
logs
but
yeah.
So.