►
From YouTube: GitLab Handbook Direction Discussion (2020-04-17)
Description
Discussion with Eric Schurter (Senior Product Manager, Create:Static Site Editor) and Derek Knox (Senior Frontend Engineer, Create:Static Site Editor) and GitLab Field Enablement team
https://about.gitlab.com/direction/create/gitlab_handbook/
A
Thanks
everyone
for
joining
today,
so
this
this
meetings,
gonna
be
just
a
little
bit
different.
Emily
is
on
pto,
so
instead
of
asked
Eric
to
join
and
Derick,
and
so
from
from
their
team
just
to
give
us
an
overview
of
and
what
is
there
Eric
your
team's
roles
and
responsibilities?
I
would
love
just
some
insights
into
as
you
think
about
making
the
handbook
more
consumable
and
usable
like
what
are
some
of
the
things
that
you're
working
on
and
then
hopefully
have
some
time
for
some
Q&A
from
the
team
as
well.
How's.
B
But
I
think
the
the
product,
leadership
and
the
senior
leadership
here
took
a
step
back
and
said:
well,
let's
not
just
fix
it
for
the
handbook,
let's
see
if
we
can
embrace
this
and
and
build
something,
that's
a
little
more
usable
for
all
of
our
customers
and
then
dog
food
and
true
gitlab
nature.
And
so
our
group
is
formed.
We
are
focused
ultimately
on
delivering
a
a
more
friendly,
more
familiar
and
more
accessible
interface
for
editing,
content
on
static
sites
and
so
to
define
static
sites.
B
These
are
sites
that
don't
call
out
to
database
or
have
a
bunch
of
API
calls
that
pull
in
from
different
services.
These
are
files
that
are
served
as
static,
HTML,
Javascript
and
CSS
that
sit
on
a
server
that
can
just
run
similar
to
how
we
have
get
lab
patients.
So
a
handbook
is
a
great
example
and
the
handbook
is
our
primary
source
of
dogfooding
our
feature.
The
handbook
is
generated
through
a
framework
called
middleman
which,
if
you've
edited
the
handbook,
you've
probably
seen
middleman
you've
had
to
startup
middleman.
B
Maybe
middleman
is
a
ruby
based
static
site
generator
and
there
are
dozens,
if
not
maybe
a
hundred
other
ones
out
there.
Middleman
is
not
the
most
popular.
It
is
probably
the
most
popular
ruby
based
one
and
I
think
the
decision
to
choose
middleman
was
based
on
our
our
technical
expertise
in
Ruby.
Back
in
the
day.
B
A
static
site
generator
is
to
take
a
step
back
is
is
helpful
for
an
engineer
who
wants
to
output,
static
sites
from
a
collection
of
content,
and
that
content
would
be
better
served
separated
from
the
the
layout
of
the
page
itself.
So
if
you
could
imagine
somebody
making
a
landing
page
for
a
product,
it's
fine
to
just
write
the
content
in
line
with
the
page
styling,
and
you
just
like
push
out
a
page
and
it
and
it
lives
there.
B
And
so,
when
the
generator
starts
running
on
the
local
development,
on
the
local
development
environment,
on
the
developers
machine
or
in
our
case
on
the
CI
pipeline.
When
the
generator
is
running,
we
are
going
through
and
looping
over
every
page,
that's
marked
as
a
certain
page
type,
pulling
the
content
into
the
template
and
generating
an
output.
That's
a
static,
HTML
file,
and
so
all
that
to
say
is
there's
a
big
compilation
step
and
then
the
output
is
just
a
bunch
of
HTML
pages
that
you
can
put
on
any
server
anywhere
and
host
your
site.
B
B
So
when
you
have
to
import
things
like
diagrams
or
embed
YouTube
links
and
things
like
that,
markdown
can
get
a
little
messy.
So
what
we're
aiming
to
do
and
what
we
have
started
to
do
actually
with
12.10,
is
build
a
feature
that
can
run
on
your
static
site
and
provide
a
link
to
edit
the
content
on
that
page.
That
is
separate
from
a
code
editor
workflow,
so
separate
from
the
idea
of
a
web
IDE
separate
from
building
in
on
your
local
dev
environment
and
checking
out
the
branch
and
and
making
changes
there.
B
Some
of
the
the
largest
I'd
say
sticking
points
or
roadblocks
to
contributing
to
the
handbook,
or
this
extends
beyond
the
handbook.
This
is
anybody
who
wants
to
contribute
to
a
site,
that's
statically,
hosted
or
statically
generated.
Some
of
the
major
roadblocks
are
getting
that
local
dev
environment
set
up,
because
that
is
the
easiest
way
to
contribute.
If
you
have
that,
and
you
have
the
knowledge
of
git
and
you
can
use
the
terminal-
and
you
know
how
to
check
out
a
branch-
it's
it's
quite
straightforward
to
to
make
changes
to
these
projects.
B
But
that's
a
lot
of
overhead
and
even
for
the
smallest
changes,
it
feels
like
you're
spending
more
time
typing
git
commands
than
you
are
making
content
edits.
So
we
want
to
abstract
that
away
and
we
want
to
provide
editing
tools
that
are
more
familiar
more
like
Dropbox
paper
or
confluence,
even
things
that
are
more
like
rich
text,
editing
and
more
visual.
So
you
have
a
formatting
bar
or
you
know,
a
block
editor
of
some
kind
or
something
there.
B
We
are
excited
because
we've
just
shipped
today,
actually
we
finally
merged
our
first
feature.
The
team's
been
working
hard,
this
past
release
and
we
are
officially
in
the
gate
lab
product.
We
started
with
a
template
for
middleman
so
that
we
can
dogfood
our
own
feature
in
the
coming
milestones
and
right
now,
our
MVC,
our
first
NBC,
we'll
put
a
persistent
edit
button
on
all
the
pages
that
support
editing.
B
So
if
you
were
looking,
I
will
take
the
handbook,
for
example,
but
I
want
to
caveat
that
we
haven't
integrated
into
the
handbook,
but
the
the
use
case
we're
trying
to
get
to
is,
if
you're,
looking
at
the
handbook
right
now
on
the
bottom
of
every
page,
we
have
in
the
footer,
like
openness
and
web
IDE.
Imagine
a
link
that
just
says
open
and
static
site,
editor
or
edit.
This
page
and
static
site
editor
or
it
could
just
be
an
icon.
B
C
B
Sounds
it
sounds
pretty
good
right
now,
it's
it's,
it's
pretty.
It
works
and
it
doesn't
work
on
the
handbook,
but
it
works
on
our
template
project.
Our
next
milestones
and
we
focused
on
adding
the
what-you-see-is-what-you-get
a
rich
text,
styling
interface
on
top
of
the
editor
and
then
we're
gonna
be
working
on
a
couple
other
small
things
most
likely
before
we
integrate
it
with
a
handbook.
B
But
my
guess
is
we're
like
I
haven't
cleared
this
with
Derek
and
the
team,
but
my
guess
is
we're
probably
two
to
three
milestones
away
from
from
getting
this
integrated
in
the
handbook,
and
that
will
be
the
real
test.
That's
where
we're
gonna
start
to
be
able
to
get
real
feedback
from
everyone
and
get
laughing
and
those
outside
that
want
to
contribute
to
the
handbook
and
see
how
we
can
continue
to
iterate
on
our
editing,
workflow,
so
I
say
all
that,
and
that
is
our
main
focus
as
a
as
a
group.
B
But
we
do
maintain
the
handbook
as
well.
Technically
speaking
and
well,
we
don't
technically
own
the
visual.
You
know
of
the
handbook,
the
UI
and
UX
I.
Think
you
know
in
the
spirit
of
of
gitlab,
everybody
can
contribute.
We
have
made
changes
to
the
UX
and
will
continue
to
make
changes
to
improve
the
the
reading
and
editing
experience.
B
Some
of
those
examples
on
our
roadmap
are
making
sure
that
we
expose
a
little
more
of
the
sort
of
meta
information
about
a
handbook
page
like
assigning,
maybe
a
similar
to
how
we
have
code
owners
in
the
code
base,
but
like
a
primary
DRI
for
the
page
content,
if
you
needed
to
request
a
review,
that's
who
you
should
sign
it
to
exposing
information
about
the
last
time
it
was
updated
and
edited
and
by
who,
by
whom,
and
then
things
like
making.
We
just
ripped
that
tooltip.
So
is
you
highlight
text
now
in
the
handbook?
B
You
can
click
an
icon
and
it'll
jump
you
right
into
the
web
IDE.
We
want
to
continue
to
expand
on
that
and
be
able
to
link
you
not
just
to
the
web
IDE
but
put
the
cursor
and
the
web
ID
exactly
in
the
point
or
as
close
as
we
can
get
to
where
your
selection
was
imagine
a
long
page.
I
know
sales
has
a
bunch.
Sales
enablement
has
a
bunch
of
long
long
pages.
A
A
B
A
B
B
B
Oh
because
this
is
a
Direction
page,
it's
only
in
handle
like
a
better
example,
we
started
small
in
this
period
of
everything,
iteration
and
NBC's.
We
didn't
include
the
Direction
pages,
because
they're
dynamically
generated
and
handbook
pages
are
a
little
more
one-to-one
with
markdown,
so
inside
the
handbook
domain
we
can
say
if
we
wanted
to
change
this
now
we
added
a
social
sharing
because
there's
you.
A
B
There's
some
some
tip
angles
where
you
want
to
talk
about,
get
lab
on
Twitter,
so
you
can
select
text
and
copy
that
text
into
a
tweet,
but
we'd
always
intended
to
also
make
this
a
utility
for
editing.
So
these
two
icons,
one
takes
you
to
the
file
view
and
the
other
takes
you
directly
into
the
web
IDE
and
so
I
can
go
and
edit
now,
in
this
case,
the
product
handbook
page
is
quite
long
and
so
it'd
be
great.
B
We're
looking
at
an
alternate
project
that
we
could
migrate
to
called
frontman
that
should
hopefully
dramatically
speed
up
our
build
times,
but
until
then
we're
focused
on
a
lot
of
other
improvements,
and
some
of
them
are
closed
out
already.
Some
are
in
flight
and
and
we're
working
on
making
sure
that
you
know
when
you
click
build.
When
you
finally
get
the
merge
request
in
the
pipeline,
it
doesn't
take.
You
know,
35
45
minutes
like
that.
B
B
A
B
Yeah
yep
I
totally
agree
so
I
think
yeah.
So
we
have
sort
of
a
dual
focus
in
that
we
want
to
maintain
the
handbook.
We
want
to
improve
the
performance
of
the
handbook
and
add
features
that
make
the
handbook
easier
to
use.
At
the
same
time,
we're
looking
at
revamping
the
entire
editing
experience
through
our
primary
feature,
and
then
eventually
dogs
believe
that
so
at
a
certain
point,
these
concerns
will
converge,
I
think
and
we'll
have
a
static
site
editor.
That's
that's
feature-rich
enough
that
we
can
start
building
on
that.
B
Instead
of
building
UX
features
on
the
handbook
itself
only
could
be
looking
at
an
editor
that
actually
allows
you
to
import
reused,
reusable
content
and
have
a
media
library
that
you
can
import.
You
know
assets
into
your
page
and
maybe
even
a
block
editor
to
rearrange
content
and
things
like
that.
That's
that's
a
little
bit
down
the
road,
but
we're
we're
headed
in
the
direction.
We're
editing
the
page
in
the
handbook
should
should
really
never
have
to
go
into
our
code
base
directly.
A
E
One
for
me
is
once
you've
made
a
merge
request.
Can
you
go
back
in
and
double-check
what
you've
said?
You've
done
the
merge
request
on
while
it's
in
process
or
do
you
have
to
wait
till
it
actually
post?
So
that's
because
you
know
you're
always
second-guessing
yourself
be
like
maybe
I
should
have
changed
that.
Can
you
go
back
into
that
iteration
that
you
is
basically
in
process
and
modify
it
or
double
check
it
so
I
just.
C
A
C
B
You
as
a
content
country,
would
never
have
to
worry
about
it
again.
Okay
right
now,
though,
once
you
create
a
merge
request,
you
will
get
a
pipeline
that
runs
and
that's
what's
going
on.
The
middleman
project
is
running
and
it's
generating
the
new
files
necessary
and
then
eventually
it'll
start
a
review.
App
and
in
this
little
block
here,
you
can
click
view
app.
You
have
to
wait
for
this
to
run.
B
This
is
where
it
takes
an
uncomfortably
long
time
sometimes,
but
once
you
get
the
merge
request
through
the
pipeline,
you
can
click
view
app
and
that
will
spin
up
a
site.
That's
actually,
you
know
a
preview
of
your
changes,
that's
not
alive,
so
it's
like
a
coconut
environment
and
then
you
can.
You
can
go
in
and
confirm
your
changes
before.
E
A
E
B
C
C
That
still
needs
to
be
done,
and
we
can
all
understand
that
in
a
sense
of
that's
how
there's
visibility
into
change
tracking
right
like
who,
like
that's,
basically
where
that's
all
about,
but
otherwise
that
doesn't
matter
like
assumingly
you're,
just
trying
to
change
some
text
like
it's,
probably
the
majority
of
the
time.
I
could
be
wrong.
We're
just
trying
to
change
some
content.
So
realistically
you
don't
even
need
to
know
you're
in
an
editor.
You
could
just
be
changing.
C
The
text
like
this
is
what
I
personally
see
I,
don't
think
it's
to,
while
they're,
really
in
vision,
there's
just
technical
things
behind
the
scenes
that
we
need
to
help
facilitate
the
get
behind
the
scenes,
but
otherwise
you
can
just
start
changing
the
text,
but
it's
it
doesn't
just
doesn't
get
saved.
So
that's
the
piece
for
weensie
did
that's
where
the
magic
needs
to
happen.
C
E
Probably
now
mostly
text
but
I
think
as
we're
learning
more
we're,
gonna
go
more
graphic
and
more
visual,
so
probably
70%
text,
maybe
30%
visual,
and
then
we
tend
to
do
larger,
bigger
doc.
Sometimes
it's
a
1
small
page
update,
but
then
John
and
I
tend
to
do
bigger
projects
and
my
other
Co
I'm,
teammate,
she's,
bigger,
bigger,
longer
form
documents.
When
so
we
both
kind
of
do
long.
C
A
A
B
I,
usually
kind
of
the
worst
mark
sounds
about
the
best
thing
that
has
ever
happened
and
the
worst
it's
it's
very
basic.
It's
it's
great
and
it's
very
quick
right,
but
given
all
the
differences
across
different
flavors
of
markdown,
as
they
call
them
different
extensions
of
markdown,
it's
very
hard
to
stay
consistent.
So
that's
what
I
think
we're
hoping
to
do
with
our
editor
as
well
is
like
we'll
pull
in
the
markdown
and
we'll
give
you
that
rich
preview.
You
don't
need
to
worry
about
what
your
student
tax
is
like.
A
A
B
Yeah,
the
handbook
slack
channel
is
a
great
place
if
you've
got
questions.
If
there's
an
urgent
escalation,
if
something's
broken,
we
have
handbook
escalation,
there's
a
process
there
where
we're
monitoring
it
within
a
reasonable.
You
know
SLA,
we
get
back
to
you
and
but
most
of
the
time,
if
you
have
general
questions
about
how
something
should
work
or
how
something
should
be
formatted,
the
handbook
slide
channel
is
a
great
place.
B
That's
also.
Where
will
we
you
know
we'll
post
information
about
improvements
and
we'll
make
an
announcement
when
the
statics
I
edit
errs
available
to
be
used
on
the
handbook
as
well,
that
might
that
might
be
a
might
warrant,
a
company-wide
announcement,
but
yeah
we'll
be
sure
to
look
for
it
in
the
handbook
as
well.
C
Any
of
you
run
into
some
kind
of
problem
that,
or
just
have
an
idea
of
like
it'd,
be
so
much
easier
if
I
could
do
X
like.
Please
also
share
that
in
the
handbook
channel.
That's
that's
creating
it.
Whatever
makes
the
most
sense
for
you,
but
just
get
it
written
down
in
some
form
and
feel
free
to
act
me
personally
or
whatever
you
need
to
do,
because
there
are
a
lot
of
things
we
can
do.
We
just
need
to
know.