►
Description
Brief discussion about potential convergence between the Pages and Static Site Editor features and how it might position GitLab in the headless CMS space.
A
There
we
go
so
I
was
like
a
disclaimer
pages,
is
not
in
the
core
release
management
use
case
or
realm.
They
meet
different
needs
and
expectations
from
like
the
market
and
from
a
persona
release
management,
it's
very
focused
on
coordinating
deployments
and
orchestrating
deployments
at
the
enterprise,
but
also
enabling
a
developer
to
be
empowered
to
release
continuously
and
take
advantage
as
the
full
gitlab
offering
in
CI
CD.
A
So
pages
was
put
inside
of
release
management
as
a
convenience
for
the
ops
section
and
I've
been
helping
support
it
from
an
API
technical
perspective
and
making
sure
that
its
meeting
expectations
of
the
existing
user
base,
since
it's
a
production
product
that
people
absolutely
love
and
increment,
incrementally
improving
the
technical
debt
that
lives
on
it.
Today,
it's
not
like
something
that
I
spend
a
bunch
of
time,
investing
in
direction
or
vision.
I
have
some
popular
issues
and
items
that
I'm
prioritizing
after
we
finish
the
technical
architecture
piece,
but
I
continually
tell
my
team.
A
Since
it's
a
non
revenue
generating
product,
we
aren't
really
competing
from
a
market
share
perspective
with
nullify.
We
are
a
user
share,
competitor
with
nullify,
but
that
means
that
we,
we
could
be
eroding
their
revenue
if
we
build
out
more
capabilities
in
both
the
CDN
and
statics
I
edit,
our
capabilities,
that's
not.
A
This
would
be
a
decision
on
the
new
we'll
need
to
make
that
if
we
want
to
be
a
net
loss,
I
competitor,
then
we
should
invest
further
in
pages
efforts
to
meet
that
expectation
from
a
static
site
engine
which
also
would
intersect
with
with
your
directions.
But
today
my
vision
for
pages
is
is
stops
at
the
popular
most
uploaded
issues.
B
Mean
it
makes
it
makes
a
ton
of
sense
where
I'm
coming
from
here
is
the
styling
editor
as
a
group,
as
we've
discussed
before
when
I
was
running
through
my
understanding,
when
we
chatted
several
months
ago,
is
initially
focused
on
just
providing
a
really
really
intuitive
editing
experience
for
markdown
files
that
eventually
get
hosted
on
static
sites.
We
aren't
necessarily
considering
tying
the
functionality
or
we
hadn't
necessarily
been
considering
kind
of
functionality
to
pages
itself
like
making
it
exclusively
available
to
people
who
host
on
pages
or
anything
like
that.
B
But
given
that
pages
is
where
you
host
static
sites
inside
gitlab,
it's
come
up
many
times
like
how
can
we,
how
can
we
find
a
home
for
the
static
site
editor
and
as
pages
the
right
home
for
that
type
of
functionality?
And
so
recently,
I'd
say
in
the
past
month
or
so
I've
been
thinking
more
about
the
longer-term
direction
because
we're
starting
to
get
some
nice
iterations
and
we're
shipping
in
the
product
now
and
we're
kind
of
approaching,
where
the
handbook
use
case
is
getting
the
end
of
the
tunnel
is
in
sight.
B
So
we
we
had
previously
investigated
a
lot
of
opportunities
where
the
are
options
for
direction
that
that
included
like
a
live
page,
editing
experience.
You
know
maybe
like
a
runtime
JavaScript
like
package
that
runs
on
your
production
site
and
lets
you
edit
in
line
and
then
feeds
through
an
API
back
to
the
data
source.
B
B
B
The
environment
that
we
would
need
to
create
for
somebody
to
get
quick,
previews
and,
like
almost
immediate
previews,
of
their
changes,
it's
just
really
difficult
to
imagine
being
Universal,
so
we
would
have
to
probably
pick
like
two
or
three
static
site
generators
that
we
are.
You
know
we
bless
with
our
our
plug-in
and
we
would
generate
plug-ins
for
those
that
run
in
the
production
environment.
B
Among
the
other
feature,
so
it
doesn't
get
us
any
closer
to
driving
up.
You
know
people
crossing
over
to
a
different
stage
or
even
within
the
same
stage
like
going
over
to
the
web
IDE.
But
if
we,
if
we
were
to
consider
pages
as
the
home
for
static
site
editor,
it
is
fairly
straightforward
to
to
think
of
a
future
where
we
have
some
translation
layer
between
the
static
site
generator
and
the
project
and
a
pages
interface
that
that
presents
a
list
of
all
your
pages.
Maybe
a
nested.
You
know
directory
tree
like
the
web.
B
Id
does,
but
in
a
more
visual
way
lets
you
open
those
up
in
the
static
center
to
initialize
it.
So
that
would
be
the
home
for
the
editor
itself
and
then
we
can
take
it
from
there,
where
we
start
to
investigate
features
that
you
would
normally
see
in
a
headless
CMS
like
asset
management,
or
you
know,
like
shared
files
between
pages
and
things.
Like
that,
it's
a
can
of
worms,
though
I
mean,
as
you
know,
net
will
fly,
is
a
leader
in
that
market
content
full.
B
What
I'm
thinking
about
right
now
is
really
if
we
were
to
go
in
the
direction
of
providing
a
CMS
like
experience
with
four
static
sites
inside
get
lab.
What
does
that
really
look
like,
and
how
close
can
we
get
to
a
headless
CMS
without
actually
having
a
headless
CMS,
if
that
makes
any
sense,
because
one
of
the
things
we've
been
talking
about
recently,
especially
we
just
had
a
conversation
about
this
with
the
marketing
team
who's
investigating
whether
they
should
migrate
content
over
to
a
CMS
for
ease
of
collaboration
and
maintenance
and
stuff
like
that.
B
Most
of
the
CMS
is
the
headless
CMS
since
they
require
a
database,
so
the
the
content
is
brought
into
the
database
where
it
can
be
mutated
and
managed
and
then
surf
it
back
out
and
statics
pages.
So
you
could
be
hosted
on
something
like
pages
or
nullify
or
wherever
our
approach,
and
maybe
this
is
the
wrong
approach.
But
right
now
our
approach
is
still.
We
want
to
read
directly
from
the
project
in
markdown.
B
We
don't
want
to
take
the
data
away
from
the
project
and
put
it
in
a
database
to
be
accessed
by
a
headless
CMS.
We
would
prefer
some
level
of
I
guess
translation
to
occur
on
the
fly
where
the
project
data
can
can
live
in
in
the
same
directory
as
markdown
files
and
in
your
Jekyll
or
Hugo
site
remains
untouched.
B
Then,
when
the
static
site
editor
pulls
the
data
in,
that's
only
do
the
conversion
for
editing,
and
then
we
spit
it
back
out
as
as
markdown
I
think
that
workflow
makes
a
lot
more
sense
for
gitlab,
assuming
it's
inside
to
get
my
product,
because
then
you
can
have
people
editing
the
same
content
from
multiple
parts
of
the
product
like
the
web,
IDE
or
a
local
dev
environment.
You
can
be
editing
from
a
merge
request
and
then
we
maintain
the
single
source
of
truth.
B
B
Thinking
like
we,
we
have
a
ways
to
go
before
we
could
could
really
implement
any
of
this
right
now,
we're
very
focused
on
refining
the
editor
and
then
building
out
workflows
for
like
managing
edits
to
multiple
pages
or
picking
up
draft
edits
and
and
like
making
multiple
commits
to
the
same.
Mr,
from
behind
the
scenes
within
the
editor
I'd
say,
probably
within
like
a
quarter
or
so
maybe.
B
Yeah
four
months
we
might
be
more
realistically
looking
at
creating
new
pages
from
templates
and
now
beginning
between
pages
and
things
like
that.
That
would
require
a
little
more
UI
within
the
gitlab
product
if
that
ends
up
being
our
home,
but
that
naturally
does
raise
questions
about.
Are
you
competing
with
Matloff
I?
How
does
this
interface
with
existing
headless
CMS,
as
if
it
does
at
all?
Do
we
give
people
options
to
use
those
as
data
sources
or
okay
at
lab
project,
and
then
do
we
make
the
editor
available
to
people
who
aren't
hosting
on
pages?
A
B
A
B
What
it
is
it's
it's
specifically
to
address,
personas
that
are
under
under
served
within
the
get
lab
proc
already
so
content
writers,
authors,
copywriters,
product
managers,
executives,
people
aren't
who
aren't
comfortable
interfacing
directly
with
the
markdown
or
navigating
the
project
hierarchy
through
the
web
IDE
people
who
would
like
a
little
more,
you
know
GUI
around
their
content
and
the
editor
in
that
way.
The
single
page
editor
we
have
now
the
WYSIWYG
mode
is
the
is
the
default
and
primary
editing
experience,
although
it
lets
you
switch
back
to
the
raw
markdown.
B
If
you
need
to
that's
just
that's
our
way
of
saying
you
know,
this
is
a
right
now,
a
really
hopefully
solid,
visual,
markdown
editor,
and,
to
that
end
our
home
might
not
be
pages.
It
might
just
be
a
different
mode
of
web
IDE,
where
you
toggle
over,
if
the,
if
the
file
format
supports
it
or
if
it's
been
configured
properly
or
something
like
that,
how.
B
We've
thought
about
that
a
little
bit
if
we
go
in
the
direction
of
having
this
be
something
that
gets
like
embedded
on
a
page
and
lets
you
edit,
live
on
the
page
in
an
environment
similar
to
like,
like
you,
would
edit
a
Squarespace
site
or
something
like
that
or
web
flow.
You
could
potentially
embed
that
in
a
review
app
as
well
and
then
somehow
waving
my
hands
pipe.
Those
changes
back
out
to
the
mr
from
the
review
app
or
something
like
that.
B
As
of
now
I
think
what
we
would
do
is
we
would
probably
do
on
the
fly
builds
for
live
preview
that
don't
include
the
whole
pipeline,
and
then
we
would
just
like
review.
Apps
continue
to
work.
I,
don't
think
the
actual
like
live
preview
feature
would
work
for
us.
I
believe
it
needs
to
be
like
HTML,
essentially
I.
Don't
think
that,
because
it
requires
it
to
get
sent
through
the
static
site
generator,
you
need
to
at
least
build
that
one
page
to
get
the
output
I'm,
not
sure
the
live
preview
feature
like
that.
A
I'm
gonna
send
you
this
MBC
issue
here:
I,
don't
have
access
to
the
agenda,
so
otherwise
I
would
drop
it
in
there.
Oh,
ok,
so
there's
this
visual
review
functionality
that
creates
that
conduit
that
you
can
add
a
comment
in
this
visual
review
application
and
then
it
pumps
it
back
to
the
merge
request
for
feedback.
A
There
might
be
something
to
like
learn
in
abstract
there
on
how
how
the
static
site
editor
can
interplay
with
pages
and
bring
it
back
to
the
merge
request,
because
I
think
that
see
say
that
a
content
editor
is
working
with
a
developer
on
an
e-commerce
website
and
they
are
reviewing
the
pages
for
a
new
transaction
button
and
they
have
to
test
a
couple
of
scenarios
for
error
messages
to
pop
up.
Let's
say
that,
while
they're
wanting
to
edit
in
that
page,
they
can
edit
hey
here's
what
the
copy
should
say.
A
B
Contributor
of
some
kind
visits
the
actual
production
page
and
sees
a
typo
or
wants
to
change
the
marketing
copy
and
wants
to
basically
initiate
that
mr
themselves,
and
so
you
click
edit
and
instead
of
going
to
the
web
IDE
and/or,
you
know
having
to
learn
markdown
or
run
a
local
environment.
You
are
presented
with
the
tools
you
need
to
just
change
the
copy
and
submit
an
mr
I
could
see
that
working.
B
B
Think
if,
if
we
validate
that
pages,
is
a
it's
a
good
place
and
that
users
would
benefit
from
or
the
company
would
benefit
from
having
some
lightweight
content
management
within
a
within
the
get
web
product,
I
won't
use
the
word
CMS,
but
if,
if
that
is
beneficial,
I
could
definitely
see
a
sort
of
co-opting
or
even
owning
the
pages
concept.
We
don't
practically
speaking,
have
engineers
with
spare
cycles
to
like
take
over
maintenance
of
it
right
now,
because
we're
we're
already
spread
across
three
groups
and
only
a
five
engineers.
So
we.
B
A
B
A
About
intersecting
the
static
site,
editor
for
pages
and
I'm
coming
suffixing
it
with
light,
so
that
we're
setting
the
expectation
that
this
isn't
a
head-to-head.
This
is
an
inter
to
help
erode
some
of
the
nullify
users,
but
potentially
strengthen
our
position
for
non
developers
using
pages
until
like
that
would
be
my
my
perception
as
the
pages
owner
on
how
to
play
with
that
yeah.
A
Think
the
other
action
I'm
you
know
I-
should
consider
partnering
on
its
business
case,
of
how
much
of
the
market
is
actually
serviceable
by
pages
and
tonics
I
edit
er
today.
So
if
we
create
a
unified
experience
here,
how
much
of
the
net
lo-fi
market
would
we
we
actually
capture?
So
some
opportunity
here
would
be
looking
at
our
current
customers
where
we
have
net
loss,
I
users,
we
could
potentially
look
at
the
customers
who
are
using
an
elephant's
template
or
have
a
fork
of
it
and
use
that
as
a
proxy
for
the
population.
B
B
A
B
B
We
have
about
two
dozen
monthly
active
users
outside
of
gitlab.
There's
it's
it's
almost
nothing.
We
haven't
done
any
marketing
of
it
per
se
and
people
discover
it
through
our
project
template.
But
it's
not
something
that
we
are.
It's
not
mature
enough,
yet
that
we've
really
figured
out
what
market
to
even
measure.
A
B
There's
definitely
an
opportunity.
We
haven't
measured
the
opportunity
or
to
quantify
that
opportunity
yet
because
we've
been
focused
entirely
on
addressing
our
get
lab
team
with
the
handbook
and
figuring
out
how
we
can
make
it
a
generalized
enough
that
it's
available
in
the
product,
but
without
knowing
yet
you
know
how
exactly
it's
gonna
fit
into
the
product
we
don't
have.
We
don't
have
data
on
on
that.
So
I
think
that
would
be
part
of
this
exercise
as
well
is
quantifying.
A
B
A
B
B
C
B
C
C
Well,
thank
you
for
setting
up
this
quick
touch
base.
I
realize
we
might
need
more
time,
but
I
at
least
wanted
to
kind
of
get
on
the
same
page,
because
I've
been
out
for
a
week
and
I'm
sure
things
have
happened.
Comments
have
happened,
an
issue
and
I
actually
had
a
kind
of
a
long
follow-up
chat,
just
based
on
some
comments
and
that
research
issue
with
James,
and
you
know
he
had
some
interesting
thoughts
and
suggestions.
So
that
was
good.
C
So
here's
where
my
head
is
at
y'all
I
think
in
some
ways
when
it
comes
when
I
think
about
what
we're
trying
to
do.
You
know
it
with
having
product
release,
notes
and
decoupling
ourselves
from
the
marketing
blog
post
I.
My
concerns
are
more
around
are
less
about.
Can
we
put
content
at
issues
because
it
looks
like
we
can
and
it
would
have
a
lot
of
benefits.