►
From YouTube: GitLab 14.4 Kickoff - Create:Editor
Description
Overview of what's planned for the Create:Editor group in 14.4
Planning issue: https://gitlab.com/gitlab-com/create-stage/editor/-/issues/26
A
Hi
everyone,
my
name,
is
eric
schroeder
and
I'm
the
product
manager
for
the
editor
group,
which
is
part
of
the
create
stage
of
the
devops
lifecycle
here
at
gitlab,
and
I'm
excited
to
share
with
you
what
we
have
planned
for
the
14.4
milestone
as
usual
I'll
link
to
our
planning
issue
in
the
video
description,
and
you
can
click
through
and
see
all
the
issues
that
are
scheduled
for
the
milestone.
But
I'll
highlight
a
few
for
you
today.
A
Overall,
as
a
company
as
a
product,
gitlab
is
focused
this
quarter
on
improving
reliability,
scalability
and
security,
and
the
editor
group's
no
exception.
We
have
our
back
end
team,
actually
working
on
some
larger
reliability
initiatives,
and
so
our
our
planning
for
this
milestone
is
very
front.
End
heavy,
but
we're
hoping
to
pitch
in
on
that
theme
by
focusing
on
two
main
categories:
the
web
id
and
the
wiki-
and
I
want
to
highlight
what
we're
working
on
there
for
the
web.
A
A
This
is
improving
how
we
handle
changes
to
the
state,
the
file
state
as
it
gets
displayed
in
the
web
ide
and
and
handling
some
instances
where
it
wouldn't
be
accurately
displayed.
So
overall,
this
is
really
not
gonna
offer
a
lot
of
new
features
and
functionality,
but
it
should
offer
improvements
in
reliability,
more
maintainable
code
base
and
some
performance
boost
in
the
end.
So
we're
really
excited
to
to
continue
working
on
this
area.
A
One
thing
we
want
to
squeeze
in
it's
a
small
improvement,
but
one
one
feature
we
want
to
introduce
in
the
web
ide
in
14.4
is
the
ability
to
quickly
open
up
any
file
that
you're
viewing
in
the
repository
view
inside
the
web
ide.
This
is
a
pattern
that
some
of
our
competitors
have
started
to
adopt
using
the
period
key
as
a
keyboard
shortcut
to
quickly
open
up
the
file
in
an
ide
to
start
editing.
So
we
want
to
adopt
the
same
pattern.
A
It's
a
fairly
straightforward
shortcut.
We
already
have
the
web
id
available
through
a
button
on
the
on
any
view
like
that,
so
this
is
just
a
quick
ux
improvement
to,
hopefully
improve
discoverability
and
awareness
of
the
web
ide
shifting
over
to
the
wiki.
I
think
I
mentioned
this
before,
but
carrying
this
over
into
14.4.
A
In
the
worst
case,
it
can
result
in
500
errors
or
502
errors
and
fail
to
load
the
page.
So
we
want
to
optimize
the
way
the
wiki
pages
are
loaded
all
together
and
asynchronously
load,
the
bulk
of
that
markdown
content
by
displaying
the
rest
of
the
wiki
page
first
and
then
progressively
loading
that
content
in
later.
A
This
should
help
reduce
our
overall
error
budget
and
and
generally
make
the
wiki
more
responsive,
but
ultimately
just
serve
to
be
a
better
user
experience,
because
you'll
have
a
little
more
understanding
of
what's
loading
on
the
page
and,
what's
taking
so
long
and
sort
of
a
as
a
separate
track,
we're
going
to
continue
working
on
our
content,
editor
implementation.
So
I've
talked
about
this
a
lot,
but
this
is
our
wysiwyg
markdown
editor.
A
We
made
huge
progress
in
14-3,
so
we
should
be
able
to
wrap
this
up
and
meet
our
quarterly
goal.
The
other
part
that
we
want
to
focus
on
for
the
content.
Editor
is
feedback
that
we've
received
frequently
related
to
the
wysiwyg
editor,
and
that's
not.
Everybody
wants
to
use
a
wysiwyg
mode
to
edit
markdown.