►
From YouTube: GitLab 13.6 Kickoff - Create:Static Site Editor
Description
GitLab 13.6 Kickoff video for the Static Site Editor group.
All issues planned for 13.6 can be found in our planning issue here: https://gitlab.com/gitlab-org/create-stage/-/issues/12756
A
I
want
to
talk
to
you
today
a
little
bit
about
what
we
have
planned
for
the
13.6
milestone
and
the
the
full
list
of
what
we
will
be
working
on
in
136
is
in
this
issue,
which
I'll
link
in
the
in
the
description
of
the
video
feel
free
to
click
through
and
open
up
these
issues
to
get
more
detail,
read
all
the
details
on
the
proposal,
as
well
as
provide
any
feedback
or
ask
any
questions.
I'd
love
to
hear
from
you
in
those
issues.
A
I
do
want
to
highlight
just
a
few
of
them,
though,
in
this
kickoff
and
the
first
of
which
is
isn't
something
I've
highlighted
in
a
few
kickoffs
before,
but
we're
looking
to
deliver
in
13.6
the
ability
to
upload
an
image
using
the
static
site
editor.
So
this
means
that
as
you're
editing
content,
you
can
click
a
button
upload,
an
image
from
your
computer.
A
It
will
be
inserted
into
the
content
and
then
the
asset
itself
included
in
the
merge
request
that
gets
created
when
you're
done
editing.
Now
we
were
working
on
this
before
and
we
had
to
pause
because
we
uncovered
the
the
requirement
for
a
configuration
file
in
the
static
site
editor.
There
was
no
universal
place
where
we
can
be
sure
that
we
wanted
to
store
this
this
asset
and
we
didn't
want
to
have
to
make
users
choose
every
time
they
uploaded
an
image
which
directory
they
wanted
to
store
it.
A
So
in
13,
4
and
13
5,
we
have
been
doing
exactly
that.
We've
introduced
a
configuration
file
for
the
static
site,
editor
and
we've
been
adding
values
into
that
configuration
file,
support
for
values
and
including
the
one
for
the
image
upload
path,
so
in
13.6
we'll
be
picking
up
the
work
again
to
upload
an
image
as
well
as
delivering
the
ability
to
customize
that
destination
path
in
the
configuration
file.
A
Now
in
13
6.
We
want
to
extend
this
even
further
and
pre-populate.
This
description
text
field
with
the
the
default
merge
request
template
if
there
is
one
assigned
to
the
project
and
if
there
are
multiple
merge
request
templates,
we
want
to
be
able
to
expose
the
select
box
so
that
users
can
switch
between
merge,
request
templates.
Within
that
same
view.
That
way,
when
you
submit
your
merge
request,
it's
in
a
much
more
consistent,
much
more
informative
manner,
and
you
can
provide
the
context
necessary
for
review
without
having
to
edit
your
merge
request
afterwards.
A
Speaking
of
feedback,
the
other
major
point
of
feedback
we
got
from
our
from
our
initial
rollout
to
the
gitlab
handbook
was
that
the
resulting
merge
requests
can
be
rather
noisy
and
make
it
difficult
to
look
at
the
file
diffs,
because
the
the
content
that
goes
into
the
static
site
editor
in
markdown
may
be
rather
loose
in
its
interpretation
and
markdown
syntax.
There
are
multiple
ways
to
do:
lots
of
different
things
in
markdown,
markdown
parsers
can
be
fairly
forgiving
about
spacing
indentation
line
breaks
and
things
like
that
and
still
render
out
perfectly
legitimate
and
valid
html.
A
However,
when
the
wysiwyg
editor
writes
that
back
out
to
markdown,
it
needs
to
adhere
to
a
very
strict
markdown
syntax,
a
set
of
rules
that
are
defined
in
the
editor
itself.
So
when
you
pass
loose
content
into
the
static
site,
editor
then
export
a
very
strict,
markdown
syntax.
Then
what
you
end
up
with
is
a
whole
bunch
of
formatting
changes
to
the
file
and
that
kind
of
obscure
the
the
user's
changes
in
the
diff
view,
and
sometimes
if
the
diff
is
large
enough,
make
it
so
that
our
merge
request
tiff
view
is
actually
unusable.
A
So
we
may
not
have
a
solution
for
this
in
136,
but
I
want
to
bring
it
up
because
it'll
be
a
research
and
development
effort
in
13
6.
we're
going
to
be
defining
an
mvc
one
idea.
We've
had
is
to
take
that
first
initial
reformatting
of
the
markdown
and
just
pre-commit
that
as
a
single
commit
and
then
any
subsequent
changes
from
the
user
are
are
additional
commits.
So
at
least
then
they
can
be
isolated
and
reviewed
separately
in
the
merge
request.
A
And
so
the
re-architecture
is
a
project.
We've
been
working
on
for
a
few
months
now,
and
we've
been
sort
of
questioning
whether
our
our
current
architecture
is
is
sufficient
to
take
us
into
the
next
phase
of
our
our
products.
Maturity,
our
futures
maturity
and
the
gist
of
it
is.
The
research
has
indicated
that
no,
we
need
something,
a
little
more
flexible,
a
little
more
extensible
and
that
has
had
us
evaluating
alternative
editors
and
working
on
a
new
architecture.
A
There'll
be
more
on
that
later
and
there's
lots
of
videos
on
our
on
our
static
site.
Editor
playlist,
where
we've
been
discussing
this
architecture,
if
you're
interested
but
the
the
gist
of
it,
is
that
we
will
be
replacing
our
all-in-one
editor,
which
is
based
on
toast
ui,
with
a
combination
of
a
new
html
wysiwyg
editor,
a
different
markdown
parser
and
using
editor
light
for
our
source
code.
Editing.
A
A
So
we're
going
to
be
dipping
our
toes
into
that
part
of
the
code
base
and
working
on
a
few
issues
that
are
really
geared
towards
adding
some
consistency
to
that
experience,
so
the
first
of
which
is
a
small
annoyance
potentially
where,
as
you
are
navigating
around
git
lab-
and
you
have
recently
visited
projects
and
groups
that
data
is
actually
stored
in
local
browser
storage.
So
if
I
were
to
switch
to
another
browser
open
an
incognito
window
or
even
switch
to
another
machine
or
a
mobile
device,
this
list
could
be
very
different.
A
There's
also
a
pattern
on
the
left
hand,
navigation
where,
if
there
are
features
here
that
you
simply
don't
use
or
you
don't
want
to
use
or
are
not
potentially
able
to
be
configured
for
your
project,
you
can
turn
them
off
in
the
settings,
but
that's
not
actually
applicable
to
all
items
on
the
left-hand
nav
where
that
would
be
relevant.
So
we're
going
to
be
consistent,
we're
going
to
apply
that
pattern
to
the
other
features
so
that
if
there
are
features
you
don't
use,
you
can
simply
turn
them
off.