►
Description
Daniel and Mike chat about GitLab's value of iteration and how it can guide tech writing for more meaningful and helpful documentation.
A
B
Well,
having
when
I
hear
iteration
and
think
about
it
in
the
context
it
gitlab
in
past
experiences,
I
think
a
scope
creep
and
I
was
frequently
guilty
of
that
I
see
something
is
it
is
the
next
line
above
in
a
documentation,
I
think
I've
got
to
fix
that
and
the
question
with
with
with
that
is
it
it?
Is
it
easier?
Is
it
hardware
but
or
how
far
do
I?
Let
it
go.
B
A
Something
I
kind
of
wanted
to
jump
in.
How
are
you
feeling
about
that?
That
shift
from
previous
experience
to
today,
because
I
can
tell
you
about
my
experience
that
came
from
a
graphic
design,
background
and
I
came
from
old
style
or
old
ways
of
thinking
my
organization's.
They
were
kind
of
either
government
or
large
enterprise,
and
so
it
was
always
not
so
much
iteration,
but
go
ahead
and
plan
out
the
project
and
then
only
deliver
the
final
thing
and
we'll
just
move
with
that.
A
B
A
A
Yeah,
it
sounds
also
applicable
to
a
lot
of
external
things,
for
example
in
tech
writing.
Thinking
about
other
forms
of
writing.
You
know
like
personal
writing
projects
if
you're
writing,
fantasy
or
or
biography
or
whatever.
You
have
this
large
scope
that
you
want
to
talk
about,
but
then
how
do
I
break
it
down
into
design
just
a
little
chapters
exactly
and
how
do
you
work
with
tech
writing
in
an
iterative
capacity
in
gitlab?
For
now,
let's
talk
about
well
good
glad
right.
B
B
We
could
actually
cover
everything,
that's
happening
with
it,
with
sufficient
clarity
and
and
justice,
so
everything
comes
in
and
and
that
every
that
which
comes
in
is
becomes
our
MVC
of
sorts
and
I,
subdivide
that
into
three
categories
category
one
would
be
things
of
the
title
level
which
itself
is
at
MVC.
You
fix
a
typo.
You
know
you've
made
things
better
category
two
or
dark
fixes.
B
Somebody
sees
something,
that's
inaccurate
of
the
docs.
They
go,
go
and
fix
it.
There
is
a
temptation
there
to
go
ahead
and
look
at
other
things
in
on
the
same
page.
Can
you
fix
those
as
well?
Maybe
you
do
if
it's
it?
If
it's
something
that's
easy,
but
does
that
go
beyond
it?
Mvc,
that's
something!
I
still
struggle
with
category
three
would
be
new
stuff.
You
have
a
new
feature.
B
If
that,
if
the
proposed
document
documentation,
the
proposed
new
future
actually
accomplishes
that
past
and
then
great
otherwise,
and
then
we
talked
about
I,
didn't
say:
what's
what's
the
minimal
viable
change?
How
do
we
bid
only
say
hey
here,
here's
the
new
feature,
and
how
do
we
make
it
usable?
You
know.
B
I
mean
I,
see
it
happening,
but
what
the
one
thing
I'd
like
to
see
more
of
is
is
take
the
point
of
view
of
the
customer,
the
person
who's
implementing
our
product,
who
is
taking
the
future
and
put
it
putting
it
in
place.
What
does
that
person
want?
Well,
how
do
we
make
it
easy
for
that
that
implementer
to
actually
make
things
work
for
them
in
a
most
efficient
way,.
B
The
feedback
I'm
seeing
here
at
get
lab
and
and
before
is
that
it
is
the
number
one
request
is
code
samples
code.
Samples
is
sort
of
a
catch-all
for
bits
of
code
that
you
could
put
into
a
get
lab
dot,
RB
file
or
a
rest
call
that
you
could
run
it
at
the
command
line
or
a
command
that
you
could
use
to
activate
or
deactivate
a
specific
feature
or
similar
sorts
of
things
in
the
UI
yeah.
A
I
don't
necessary
with
the
backend
the
code
aspects
so
I'm,
always
on
the
front
end
and
I'm
always
impressed
by
the
the
assistance
of
job
to
provide,
especially
by
that
thought
process
or
that
methodology
kind
of
related.
To
that.
What
advice
would
you
give
a
designer
in
terms
of
planning
for
problem,
solving
or
planning
for
trying
to
a
dress
code
or
text
or
support
documentation?
And
you
mentioned
a
little
bit
about
how
think
of
the
users
perspective?
Think
of
what
a
user
might
be
experiencing
in
that
in
that
encounter.
A
Yeah
I
know,
for
example,
when
I'm
again
going
back
to
writing
a
text
or
documentation.
I
try
to
think
about
that.
This
is
what
you
need
to
get
to
this
end
solution.
This
is
how
it
should
work
and
then
here's
the
text
around
that
and
then
having
it,
be
sculpted
or
twisted
in
a
little
bit
to
try
and
make
a
little
more
sense
for
the
correct
user
persona.
A
Our
profile,
that's
one
of
the
things
I
know
I,
have
experience
or
trouble
with
in
my
experiences,
making
sure
I'm
talking
to
the
right
profile,
because,
again,
where
you
said
somebody
might
want
to
have
the
the
breadth
of
the
depths
of
knowledge
or
expertise
on
a
particular
topic.
You
want
to
make
sure
that
you
can
focus
it
to
that
type
of
person
who
needs
that
extra
push
so
to
speak,
to
try
to
help,
explain
it
or
better
elucidate
the
problem
right
and.
B
Speaking
promptly,
look
to
frankly
that
that
goes
to
a
weakness
in
our
current
documentation
where
there's
a
lot
of
it.
That's
that's,
essentially,
a
dictionary
that
have
been
with
people
who
develop
stuff,
they're,
proud
of
their
work,
and
people
at
good
laugh
should
be
proud
of
what
we've
done.
So
the
temptation
therein
is
to
is
to
brain
dump
things
to
go
from
A
to
Z
or
Zed.
That
and
say
this
is
everything
you
can
do
and
within
that
take
the
purpose
the
person
who's
free
to
get
in
it.
B
A
Yeah
and
so
expanding
on
that
I
think
the
documentation
definitely
can
always
improve,
and
looking
at
that
from
a
tech
writing
team,
how
do
you
normally
deal
with
that
in
terms
of
a
team
solution
or
team
project?
Normally,
my
only
interactions
are
hey.
I
need
this
issue
looked
at.
Can
you
take
a
give
me
some
help
with
this
body
of
text,
rather
than
looking
at
the
totality
of
the
support
documentation,
the
technical
documentation?
Well,.
B
We're
only
starting
to
look
at
it,
in
fact,
as
the
tech
writing
team
has
well
as
of
a
year
ago,
I
think
there
were
four
and
now
we're
11
or
13
to
Pentagon
was
whether
you
include
the
managers
in
that
number
and
what's
the
expanded
numbers,
we're
starting
to
get
questions
like
that?
How
do
we
that
focus
or
refocus
our
documentation
more
the
right
personas
to
actually
solve
our
users,
problems
yeah.
A
That
sounds
really
good.
I
appreciate
that
sort
of
way
of
tackling
the
problem,
I
think
that's
something
that
I
know.
I've
had
experience
with,
with
trying
to
understand,
documentation
and
then
trying
to
see
where
the
documentation
lives
and
then
thinking
how
would
a
user
experience
or
encounter
that
documentation
and
how
would
they
get
to
that
through
this
process?
So
I
definitely
see
the
difficulties
arm
and.
B
With
that,
we
really
do
appreciate
the
idea
that
ok,
documentation
is
another
UI.
What's
the
user
experience
with
documentation
and
people
like
yourself,
saying,
hey,
let's
analyze
the
documentation
from
a
UX
point
of
view
and
see
what
what
persona
X
Y
and
said,
think
good
or
can
do
with
the
documentation.
I
think
that's
great
and
will
help
guide
us
in
creating
a
vector
experience
for
our
users
that.
A
B
Be
prepared
for
a
different
kind
of
discipline,
we
believe
in
continuous
I,
don't
know
if
this
is
the
right
term,
but
we
believe
in
continuous
delivery.
In
other
words,
you've
got
to
say
know
where
it
went
when
to
push
when
to
let
things
go
at
what
what
to
say.
Ok,
it's
not
as
perfect
as
I
want
it
to
be;
let's,
let's
push
it
what's
the
middle
viable
change
that
actually
makes
things
better
well,.
B
When
that,
when
I
got
the
notification
yesterday
for
this,
it
made
me
think
okay,
am
I
practicing
MVC
and
I'm
realizing
in
some
cases?
No,
but
yes,
this
is
a
good
way
to
think
about
MVC
or
or
for
good
opportunity
to
think
about
it
and
think.
Okay,
how
can
I
make
my
own
practices
better
and
with
this
talk
to
help
others
thinking
in
a
similar
fashion,
yeah.