►
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
So
this
one
creating
a
new
page
about
controlling
ci
cd
jobs.
So
if
we
look
at
the
documentation
right
now,
sorry
I'm
jumping
around
specifically
the
reference
file.
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
Is
making
me
so
happy
right?
So
so
look
at
how
short
this
is
and
then
the
the
key
to
making
this
work
is
which
one
is
this,
so
this
is
only
changes
in
the
additional
ds.
Sorry
below
that,
we
also
have
related
topics.
Only
changes
and
exec
accept
changes.
Examples.
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
A
So
my
idea
is
to
start
with
only
accept,
because
no
one
is
submitting,
merge
requests
on
this,
so
I'm
not
getting
merged
conflicts
and
then
I'll
be
able
to
put
it
into
and
move
them
all
here
and
then
next
I'll
move
rules
here
and
then
I'll
move
needs
here,
because
those
are
all
about
like
controlling
when
jobs
run,
job
timing
and
then
in
here
it'll.
A
It
won't
be
like
keywords
as
much
in
in
the
list:
it'll
be
like
run
pipelines
when
you
know
variable
changes,
or
you
know
like
so
that
people
when
they
they
can
type
in
to
google
or
any.
B
B
We
have
this
reference
and
the
docs
all
mixing
together,
documentation
for
features
and
keywords,
and
then
kind
of
the
workflows
like
how
do
you
complete
this
specific
job,
because
that's
kind
of
the
mindset
that
a
developer
comes
to
documentation
they're,
not
looking
for
a
feature
they're
looking
for
a
solution
to
the
thing
that
they
need
to
to
create
like
to
do
the
job
that
needs.
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
Yeah
yeah,
it's
a
huge
improvement
for
sure
yeah.
This
is
great.
I've
also
been
thinking
about
the
getting
started
page
or
get
started.
B
It's
it's
yeah,
it's
like
it's,
not
really
bad,
but
it's
just.
A
Like
it
is
so,
what
happened
was
recently
not
concepts.
A
This
one,
that's
actually
good.
This
one
is
suzanne,
actually
redid
this
one
a
couple
months
ago,
so
this
one
is
actually
much
better,
but
it's
the
main
page.
I
think
when
you
click
on
this
one,
I
think
this
one
is.
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
Where
does
that
bring
us
because
people
circle
ci?
Oh.
A
And
so
it
does
bring
us
here
actually
eventually,
once
we
get
to
the
dock,
so
the
idea
is
to
make
the
page
match
what
people
are
searching
for,
yeah,
the
the
bigger
one
that
is.
Actually
I
don't
know
if
you've
noticed,
but
have
you
noticed
this
one.
B
Are
child
pages
under
get
started.
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
We
have
use
ci
cd
variables
in
job
scripts,
so
it
could
also
be
like
how
do
I
use,
but
it's
not
all
the
way
there.
I
kind
of
did
all
of
these,
but
I
think
from
this
point
to
the
bottom.
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
Yeah
but
it
sounds
like
you're
addressing
all
of
the
right
things
like
I
don't
even
have
anything
to
add.
I
feel
like
all
of
my
concerns
and
ideas
I
wanted
to
bring
to
this
call
you're
already
doing
all
of
those
things.
So
it's
amazing.
Thank
you.
So
much.
A
No
problem
yeah,
it's
just
a
matter
of
really
I
get
a
ping
and
then
it's
like
I'm
working
on
a
thousand
lines
or
someone's
got
a
typo
fix.
Yeah.
Let's
work
on
that
because
I
can
say.
B
A
Work,
I
really
appreciate
it.
Let
me
emerge
that
for
you
or
actually
dove
just
sent
me
a
blog
post
that
he
wrote
about
the.
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
Yeah,
that's
a
good
point
and
also
we
can
link
some
of
the
blog
posts
in
documentation
as
well.
If
we
want
to
make
it
more
accessible
like
for
someone
to
expand
on
the
topic.
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
That's
true:
these
do
get
outdated
very
quickly.
I
constantly
stumble
into
stuff
that
is
like
like
six
months
old,
and
you
know
it
passes
like
one
day
for
us,
but
everything
changes
in
six
months.
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
But
what
it
means
is
I'm
being
pulled
into
issues
more,
and
I
told
him
because
when
I
started
was
right,
when
technical
writing
got
moved
into
the
ux
group,
we
used
to
be
like
under
one
group
and
then
moved
to
just
engineering
and
now
under
ux,
and
I
and
I
felt
like
now-
it
really
makes
sense
that
technical
writing
is
in
ux
because
I
told
it
was
like.
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.
A
B
Yeah
yeah,
so
yeah,
I'm
also
very
excited
about
collaborating
more
closely
around
documentation
and
yeah
super
excited
to
see
all
of
the
changes
that
you're
working
on.
It's
like
exactly
what
we
need.