►
From YouTube: GitLab 14.9 Kickoff - Create:Editor
Description
Overview of what's planned for the Create:Editor group in 14.9
Planning issue: https://gitlab.com/gitlab-com/create-stage/editor/-/issues/53
A
Hi
everyone,
my
name-
is
eric
schroeder
and
I'm
the
product
manager
for
the
editor
group
and
I'm
excited
to
share
with
you
a
couple
things
that
we
have
planned
for
the
14.9
milestone
as
usual,
I'll
link
to
our
planning
issue
in
the
video
description.
So
you
can
see
the
entire
list
of
issues
we
have
planned,
as
well
as
our
milestone
planning
board,
but
we
have
a
lot
going
on.
A
A
We
have
been
doing
some
deep
dive
investigation
on
the
future
direction
for
that
editor
component,
and
so
we
are
going
to
be
picking
up
some
work
to
update
the
the
view
application
so
that
there
is
a
more
standard
component
that
can
access
all
the
functionality
of
that
core
editor
object
from
the
view
application,
that's
going
to
set
us
up
nicely
for
a
future
investigation
for
using
the
source
editor
as
to
power
comments
or
to
to
spread
across
gitlab,
as
well
as
just
streamlining
the
way
we
interface
with
it.
On
the
editor
group.
A
Moving
on
to
wiki,
we
have
a
couple
backhand
related
issues
that
we
are
working
on
in
this
milestone.
Now
that
we
have
some
some
increased
back-end
bandwidth,
so
the
first
being
adding
a
group
level
toggle
to
disable
the
wiki
group,
wikis
being
a
premium
and
up
feature,
don't
actually
have
a
full
parity
with
project
level
wikis
and
in
one
regard
they
can't
be
disabled
entirely.
A
There's
no
toggle
to
turn
it
off,
so
we're
going
to
introduce
that
in
the
at
the
group
level
so
that,
if
you
don't
use
the
wiki,
you
can
turn
it
off
and
as
a
I've
talked
about
this
before,
but
the
wiki
when
you're
writing
a
markdown
can
be
very
long.
It
relies
on
our
back
end
markdown
service
to
render
the
markdown
content
at
the
time.
The
page
is
loading.
A
Speaking
of
markdown,
our
content
editor
the
wysiwyg
markdown
editor
that
we
have
on
the
wiki
and
we
hope
to
bring
elsewhere
around
gitlab.
There's
one
little
ux
improvement
that
we're
going
to
pick
up
in
14.9
where
right
now
the
content
editor.
If
you
paste
some
markdown
content
as
into
the
editor,
you
will
paste
it
in
generally
as
plain
text,
so
it
won't
get.
A
It
just
comes
in
as
plain
text,
so
we
have
an
approach
now
that
we
will
be
able
to
to
parse
that
markdown,
that's
pasted
on
from
the
clipboard
and
put
it
in
a
rich
preview
and
last
thing
to
highlight
again
with
the
content
editor.
We
have
a
larger
body
of
work
that
we've
been
investigating
right
now
in
14,
9
we're
going
to
be
taking
the
the
technical
document
that
we've
created
an
approach
to
preserve
unchanged
markdown
in
the
document
and
we're
going
to
build
out
an
iteration
plan.
It'll
probably
take
us
three.
A
This
is
a
problem
we
ran
into
with
the
static
site,
editor
that
ended
up,
resulting
in
really
noisy
and
hard
to
parse
merge
requests
where
you
would
have,
for
example,
like
this
screenshot
here
on
the
left.
Your
you've
got
a
couple
extra
lines
and
you're
using
a
certain
numbering
format,
but
the
expected
format
when
you're
outputting
is
different.
So,
even
though
you
didn't
intentionally
change
that
list
format,
you're
going
to
get
that
show
up,
that's
going
to
show
up
in
there
diff
the
approach
that
we
have
now.
A
As
I
said,
is
going
to
take
a
few
milestones
to
execute
on,
but
we
will
essentially
be
only
updating
the
the
nodes,
the
specific
elements
within
the
markdown
page,
that
you
have
edited
intentionally
and
leave
the
rest
alone.
So
that
means
a
lot
more
streamlined.
Merge
requests.
It
also
unblocks
us
for
a
load
of
new
improvements
down
the
road
where
we
can
bring
the
content
editor
into
issue
descriptions
or
into
the
web
ide,
and
and
have
it
produce
more
clean
and
more
helpful
changes.