►
From YouTube: GitLab 14.3 Kickoff - Create:Editor
Description
Overview of what's planned for the Create:Editor group in 14.3
Planning issue: https://gitlab.com/gitlab-com/create-stage/editor/-/issues/17
A
But
I'll
highlight
a
couple
specific
issues
and
high
level
themes
for
you
here
today
now
in
14.3,
14.4
and
probably
into
the
14.5
milestone,
you'll
see
that
we're
shifting
our
focus
a
little
bit
to
improve
the
overall
reliability
and
performance
of
our
core
categories,
and
so,
rather
than
focus
on
individual
specific
new
features.
I
want
to
highlight
a
couple
of
things
we're
doing
on
the
back
end
that
will
serve
that
goal.
So,
starting
with
the
web
ide
we've
been
wanting
to
take
a
fresh
look
at
our
overall
state
management.
A
There's
a
several
issues
on
our
backlog,
related
to
the
the
status
of
a
file
on
the
back
end
falling
out
of
sync.
With
the
web
ide
front
end,
and
so
we
want
to
take
a
fresh
look
and
and
refactor
that
state
management
so
that
we
can
hopefully
provide
a
much
more
resilient,
predictable
and
reliable
web
ide
experience.
A
This
will
also
set
us
up
for
some
further
performance
improvements
on
the
back
end
in
subsequent
milestones,
shifting
gears
to
the
wiki
one
of
the
things
we
want
to
do
for
as
far
as
reliability
and
predictability
is
clean
up
some
work
that
we
didn't
get
to
when
we
introduced
the
group
wiki
feature
several
milestones
ago,
but
the
first
is
to
add
the
ability
to
toggle
off
that
group
wiki
at
the
end
at
the
settings
level,
so
expect
that
in
fourteen
three
and
then
as
we
look
at
overall
reliability
of
the
wiki,
we
have
a
few
opportunities
to
explore
and
we'll
be
doing
some
technical
planning
and
initial
work
there
in
14-3.
A
Remove
our
dependency
on
on
a
back-end
service
that
we
have
dedicated
to
the
wiki
and
and
convert
all
of
that
functionality
over
to
native
giddily
rpcs,
and
so
this
will
help
us
in
a
number
of
ways.
It's
going
to
make
it
a
lot
more
maintainable,
because
we
will
be
able
to
move
away
from
a
third
party
service,
but
it's
also
going
to
have
performance
improvements
and
and
help
just
our
general
ability
to
develop
features
on
the
wiki
in
the
future.
A
So
this
again
won't
have
any
real
impact
to
the
the
feature
set
directly,
but
hopefully
improve
the
performance
and
reliability
of
the
wiki.
A
Another
part
of
the
wiki
performance
is
how
it
handles
loading
very
large,
markdown
files,
and
so
by
that
I
mean,
like
you,
know,
files
that
have
20
000
lines
of
markdown
things
like
that,
where
they
exceed
a
reasonable
amount
of
a
reasonable
size,
but
take
a
large
amount
of
memory
to
and
a
large
amount
of
time
to
render.
A
So
we're
going
to
take
a
cue
from
the
from
the
repository
view
and
offer
some
options
on
the
front
end
on
the
on
the
view
of
the
page
too,
to
handle
those
large
files
in
ways
that
that
might
be
a
little
more
performant
like
the
ability
to
view
the
raw
source
or
clone
the
repository
and
view
it
locally,
rather
than
depend
on
our
backend
service
to
render
it
immediately
on
every
every
page
load.
A
And
the
last
thing
I
want
to
highlight,
with
with
the
wiki
is
a
parallel
track
that
we're
focused
on,
and
I've
talked
about
this
a
lot
in
previous
kickoff
videos.
But
in
140
we
introduced
the
content
editor,
which
is
our
wysiwyg
markdown
editor
in
the
wiki,
and
so
we're
continuing
to
mature
that
by
providing
support
for
all
of
the
gitlab
flavored
markdown
extensions
in
the
content,
editor
and
right
now.
A
What
we
want
to
do
is
make
sure
that
any
page
in
the
wiki
that
has
existing
gitlab
flavored
markdown
content
can
be
loaded
in
the
content
editor
without
corrupting
the
data
or
or
removing
the
intent
of
the
data.
So
what
what
I'm?
What
you'll
find?
Is
that
if
the
content
editor
doesn't
understand
something
like
table
of
contents
link,
for
example,
it'll?
Actually
just
try
and
parse
it
as
plain
text,
and
so
when
you
save
that
page
back
out,
it'll
have
created
a
paragraph
out
of
something
that
you
intended
to
be
a
table
of
contents.
A
So
for
everything
like
that
in
the
gitlab
play
for
brocktown,
we
need
to
just
build
little
extensions
so
that
we
know
how
to
render
and
we
can
interpret
that
content
correctly
and
prevent
any
data
loss
or
data
corruption
and
we're
plugging
away
at
that.
Our
goal
is,
in
the
next
couple
milestones
to
have
a
full
coverage
of
the
gitlab
flavored
markdown
spec,
so
in
14.3
we'll
be
working
on
things
like
table
of
contents,
audio
and
video
content,
and
things
like
that
and
we'll
have
more
in
14
3
and
14
4..
A
We
also
have
a
really
great
new
developer
tutorial
for
providing
extensions
to
the
content
editor.
So
if
you're
interested
in
in
contributing
to
these
extensions,
please
follow
through
here
in
the
issues
and
you'll
see
a
link
to
the
tutorial
and
you
can
help
out.
That's
all
I
wanted
to
highlight
for
today,
and
I
appreciate
your
time
I'll
see
you
next
month
thanks
a
lot.