►
From YouTube: Create:Editor Wiki Content Editor MVC Iteration Planning
Description
Sync discussion about the scope of the MVC for the Content Editor in Wiki. Related to: https://gitlab.com/groups/gitlab-org/-/epics/5403
A
All
right,
let's
just
dive
in
this-
is
the
mvc
iteration
planning
for
the
content
editor
in
the
wiki,
so
I'll
just
dive
right
in
I
think
a
good
place
to
start
would
be
to
address
some
of
the
questions
that
you
had
put
in
slack
and
then
made
its
way
into
the
issue
every
day.
So
I
don't
know
if
you
want
to
kick
it
off
that
way
or
if
you
had
another
anything
else,
you
wanted
to
start
with.
B
B
A
Yeah-
and
I
think
that
that
was
extremely
helpful
and
was
what
I
was
hoping
to
do
in
preparation
for
this
meeting
and
you
beat
me
to
it.
So
I
appreciate
that
very
much.
I
think
I've
thought
about
this
a
lot
since
I
wrote
my
answer
in
slack
and
I
think
it's
still
accurate,
which
is
that
in
an
ideal
state.
Yes,
we
want
everybody
to
be
able
to
access
the
new
editor.
A
But
I
thought
about
it
over
the
past
couple
of
days
and
given
the
scope
that
you've
outlined,
I
think
this
could
be
a
vector
for
our
mvc
to
to
get
out
there
faster
start
getting
feedback
and
deliver
value
sooner
in
an
organic
and
elegant
way.
As
long
as
we're
not,
I
think
my
fear
is
that
we
would
end
up
building
so
many.
A
Safeguards
and
divergent
editing
experiences
like
that,
the
user.
Would
you
know
that
the
the
author
of
the
content
would
be
unsure
which
editing
experience
they're
going
to
get
and
that
we
might
end
up
with
code
that
doesn't
need
to
exist
for
very
long?
That's
checking
like
whether
or
not
this
content
was
created
with
the
new
editor
or
not,
and
whether
we
should
display
a
certain
button
or
not
or
which
one
should
be
the
default
or
not
that
logic,
I'm
I'm,
maybe
over
complicating
it
in
my
head
that
logic
may
be
fine.
A
C
One
question
I
had
is,
I
don't
think
I
don't
think
the
determiner
is
like
whether
it
was
created
with
the
new
editor
or
not,
because
they
could
create
something
with
a
content
editor
and
then
go
edit
it
in
the
product
like
in
the
existing
wiki
editor,
unless
we
restrict
them
from
that.
Somehow,
and
I
don't
know
how
we
would
we'd
have
to
like
set
a
flag
per
document
and
then
add
something-
that's
not
supported
and
then
go
back
and
try
to
edit
it
with
the
content.
C
A
D
B
At
the
end,
the
problem
is
not
content
that
was
produced
by
the
content.
Editor
is
content
by
its
markdown
that
was
produced
by
the
user
and
uses
those
content
type
that
the
content
types
that
the
content
data
doesn't
support.
Yet
so
the
only
path
where
we
can
fully
protect
the
user
from
having
that
kind
of
bad
experience
is
by
just
allowing
them
to
produce
new
content
with
the
editor.
A
C
A
A
B
A
C
A
A
A
A
But
I
think
one
of
the
one
of
the
goals
we
will
have
is
to
address
the
problem
that
the
static
site
editor
currently
has,
which
is
that
it
reformats
the
entire
document.
Every
time
it's
opened
and
one
of
the
one
of
the
promising
things
we
talked
about
with
pros,
mirror
and
tip
tap
was
that
we
could.
A
I
would
say
if
we
can
solve
that,
then
we
can
do
a
lot
less
for
the
nbc,
because
now
the
existing
documents
have
far
less
chance
of
being
corrupted
and
we
would
be
able
to
say,
like
you
know,
we
fully
support
common
mark
if
you
wrote
your
stuff
and
comma
common
mark
you're
good,
but
if
you're
using
any
of
these
git
lamp
flavor
markdown
extensions,
you
know
just
wait
a
minute
and
we'll
get
to
it
eventually,
but
yeah.
So
anyway,
I'm
making
a
lot
of
assumptions
there.
That
may
not
be
possible
this
early.
B
B
B
B
B
D
A
C
C
The
client
turns
that
html
into
a
pros
mirror
internal
representation,
and
then
we
turn
that
back
into
markdown.
Do
we
end
up
with
exactly
the
same
markdown
that
we
started
originally
with
on
the
server
and
for
everything
in
that
table?
The
plan
is
we're
going
to
have
a
test
of
the
search
that,
yes,
we
do
end
up
with
that,
and
anything
we
don't
do
like
we're
going
to
have
to
do.
Work
is
essentially
throw
away
in
the
end,
to
like,
say
all
right.
C
A
C
I
don't
see
one
I
think
we
have
with
the
test
framework.
We
have
a
pretty
good
way
to
ensure
we
don't
introduce
corruption
or
at
least
as
corruption
is
found,
to
put
a
very
strong
regression
test
around
that.
So
once
we
fix
it
that
never
occurs
again,
but
as
far
as
like
not
doing
it
all
at
once,
I'm
not
seeing
an
easy
way
forward.
A
Comment
in
this
issue
enrique
this
stuff
about
diagrams
and
html
tags-
I'd
like
to
dig
in
deeper
to
that
later,
but
I
think
the
what
I'm
hearing
is
the
gist
of
it
is
like
we
just
need
to
build.
This
is
how
this
is,
what
it's
going
to
take
to
support
the
different
content
types
in
get
lab
flavored
markdown,
and
that
may
put
us
at
risk
unless
we
can
find
a
way
to
accelerate,
may
put
us
at
risk
for
rolling
out
an
nvc
in
14
now,
which
is
fine.
This
was
an
ambitious
goal.
To
begin
with.
C
B
That's
right
like
if
we
want
to
get
feedback
about
the
eighth
or
usage,
we're
gonna
at
least
restrict
the
the
scope
of
the
rollout
and
that's
the
reason
that
I
was
thinking
about
the
opening
or
opt-out
about
indicator
like
if
you
see
that
this
hater
is
corrupting
work.
That
is
important
for
you.
You
can
just
hop
out
of
it.
A
C
E
E
C
D
C
B
There
is
a
an
interesting
idea
that
was
shared
by
I
by
brett.
I
I
never
remember
his
last
name,
but
he
works
in
the
in
the
plan
group.
It
was
about
how
atlassian,
when
they
first,
I
think
they
designed
a
confluence.
They
just
ditched
markdown
and
they
decided
to
store
directly
the
prosmero
document
format.
B
B
D
I
think
that
that's
a
great
idea,
because
gitlab
flavored
markdown
doesn't
work
anyway
with
the
other
formats
like
hard
dock
and
sk
dock.
It
doesn't
work
with
them
and
it
would
be
expected
that
this
new
format
would
not
work
with
key
classified
markdown
either
I
mean
something
that
is
gitlab
flavored,
so
I
think
it
makes
sense,
and
eventually
we
can
iteratively,
add
gitlab
flavored
maximum
support
to
the
content
editor
and
like
make
a
bad
back
and
forth
transition.
D
Whatever
this
one
would
just
have
an
extension
of,
let's
say
json,
and
if
you
check
out
the
source,
you
would
get
a
like
a
json
representation
of
what
the
structure
of
the
document
in
closed
mirror
is,
and
you
can
go
ahead
and
change
that
if
you
know
the
syntax,
it
would
be
similar
to
changing
like
at
last
in
a
document
format
but
yeah.
We
wouldn't
recommend
doing
that.
A
I've
heard
specific
feedback
that
people
want
wysiwyg
editing,
but
if
you
take
away
the
ability
to
drop
back
into
markdown,
I
mean
we've
had
this
internally
from
our
discussions
with
static
site
editor.
This
feedback
came
up.
If
you
take
away
the
ability
to,
let
me
like
view
the
raw
source,
I'm
not
going
to
use
it
paraphrasing,
but
that's
that's
a
really
big
hurdle,
and
I
understand
why
that's
maybe
easier
or
more.
We
can
more
iteratively
work
in
that
way
by
creating
a
new
document
format,
but.
A
A
Based
on
the
feedback,
I've
heard
about
atlassian's
document
format
and
the
frustrations,
people
have
working
with
confluence
and
how
they're
trapped
to
the
confluence
editor
and
they
would
prefer
to
work
in
their
local
environment
or
they
would
prefer
to
write
in
raw
markdown.
Even
if
we
iterate
towards
a
really
delightful
content,
editor
experience
where
you
can
type
markdown
or
even
type
ascii
doc
into
the
document
format.
There
are
going
to
be
those
users
that
want
to
check
it
out
locally
and
use
their
local
markdown
editors.
A
D
A
Forcing
a
a
new
file
format
into
that
is
not
going
to
make
is
not
going
to
realize
our
our
vision
for
using
this
to
edit
static
sites.
Even
if
we
just
picked
one
static
site
generator,
we
would
then
need
to
like
have
our
own
fork
of
it.
That
understands
this
format,
and
I
think
it
would
be
a
limiting
elimi,
a
limiting
factor
in
how
far
we
can
spread
the
content
editor
throughout
gitlab.
C
One
of
those
users
that
wouldn't
use
it-
and
it
also
brings
up
like
migration
issues
if
this
wouldn't
be
a
permanent
thing.
We
have
to
like
it's
sort
of
viral
like
if
they
edit
it.
If
we
allow
them
to
edit
existing
content,
it's
going
to
get
converted
to
this
new
content,
and
then
they
they
can't
get
their
markdown
back
and
that
would
upset
people
or
if
we
only
allow
it
for
new
content.
C
It's
it's
really
going
to
be
people
that
are
com.
They
only
want
that
the
wysiwyg
experience
which,
like
I
get
really
annoyed
at
that,
because
I'm
so
much
more
efficient
in
markdown
and,
I
think,
an
engineer,
heavy
audience
more.
People
that
are
familiar
with
markdown,
at
least
are
not
going
to
be
happy
with
the
solution
like
that.
A
There's
also
incremental,
like
complexity,
when
we
start
thinking
about
this
as
something
that
we
could
edit
our
handbook
with
like
there's
a
lot
of
data-driven.
You
know
helper
files
that
are
in
our
handbook
that
are
written
using
ruby
when
we
start
trying
to
solve.
For
that
case
like
it
becomes,
I
should
say
the
the
the
complexity
is
all
on
the
shoulders
of
the
wysiwyg
editor.
Where,
in
the
future
we
may
rely
on
a
strategy.
A
That's
that's
more
like
what
I
described,
which
is
like
we
identify
a
content
type
and
that
just
gets
edited
as
source
and
like
we
don't
need
to
build
custom
ui
for
writing,
queries
against
a
random
data
helper
or
something
like
that.
It's
it's
worth,
considering.
Still
I'm
not
trying
to
put
my
foot
down
or
anything,
but
the
guiding
principle
has
for
me
has
been
that
markdown
needs
to
remain
our
source
of
truth.
I
am
intrigued
by
the
idea.
A
Like
you
created
a
new
wiki,
say:
hey,
you
want
to
try
out
a
new
editor
by
the
way,
like
don't
use
these
extensions,
because
it's
just
not
going
to
work
right,
like
then
progressively
add
to
that
and
eventually
make
it
available
to
existing
wikis.
We
still
would
have
the
problem,
and
so
I
guess
my
I
was
going
to
ask
the
question
like
what
happens
in
the
editor.
If
we
do
corrupt
the
file
like
how
aware
of
that
can
we
be?
C
I
think
that
the
easiest
way
around
that
might
be
to
just
expose
some
like
history,
ui
say:
did
your
dot
get
completely
corrupted?
Here's
your
last.
You
know
here's
how
to
check
it
out
and
get
and
revert
it
like.
It
could
just
be
pointers
to
some
dots
of
how
to
get
back
to
the
version
before
so
they're,
not
completely
lost.
B
A
related
problem.
Well,
I
think
that
this
is
like
there
is
a
aside
to
this,
like
that
is
the
what
is
the
expectation
of
the
user
when
the
whistle
hater
modifies
existing
markdown-
and
this
is
a
problem
that
we
had
in
the
statistic
as
well,
and
I
think
that
we've
been
working
on
their
the
assumption
that
the
we
squeak
eight
will
protect
every
markdown
preference
that
the
user
put
in
their
existing
markdown
content
in
the
source
and
that's
impossible.
B
This
is
like
the
the
most
important
way
of
putting
it,
but
you
don't
care
that
much
about
the
source
or
the
structure
that
that
is
following,
and
I
feel
like
that
will
be
some
that
will
be
a
resistance
that
we
will
that
we
will
meet
once
we
share
the
cont
we
will.
We
publish
the
content
later
like.
How
do
we
deal
with
that
and
we
create
the
assumption
that
the
continuator
is
like
you
know.
It
really
takes
away
the
control
over
the
source
from
the
user.
C
A
Yeah,
I
think
that's
accurate
and
I
and
I
think
for
the
for
the
vast
majority
of
people
who
are
going
to
use
the
content
editor
as
their
primary
experience.
That's
actually
a
benefit
right.
I
mean,
I
think,
back
to
my
early
days
using
dreamweaver
and
learning
web
design.
Right,
like
I
didn't,
have
an
opinion
yet
about
how
it
was
writing
out
the
structure
of
my
html
tables.
A
I
just
wanted
to
see
the
right
columns
and
cells,
and
you
know
they
got
better
at
formatting
the
automatically
generated
source
over
time,
and
I
got
better
at
writing
it
from
scratch
and
eventually
switched
over
to
writing
it
myself.
But
it's
it's
a
it's
an
abstraction
and
it's
a
visualization
of
existing
content.
A
A
I
don't
know,
I
think
we
just
still
need
to
keep
in
mind
the
problem
that
we're
running
into
with
the
static
site
editor
where
we're
reading
rewriting
the
whole
document.
So,
for
example,
if
I
have
a
bulleted
list-
and
I
open
it
up
in
the
content
editor
and
I
change
an
item
on
a
list-
I
don't
care
if
you've
written
that
and
reformatted
it
to
hyphens
instead
of
asterisks.
A
A
I
lost
the
train
of
thought
where
I
was
trying
to
summarize
what
what
you
were
saying:
chad
but
the,
but
the
the
the
general
idea
that
entering
has
to
be
the
same
yeah
that
the
that
the
rendering
is
consistent
and
that
we
can
render
everything,
because
if
we
don't
render
something
or
we
render
it
incorrectly
right
like
if
we
pick
up
I'm
trying
to
think
of
a
gitlab
flavor.
Let
me
look
back
at
the
table
I'll
get
like
flavored
markdown
extensions,
so
like
if
we,
if
we
pull
in
a
math
equation.
A
That
seems
like
something,
that's
probably
pretty
important,
as
somebody
who
wrote
intentionally
wrote
some
math
in
in
into
a
wiki
document
right
and
then
we
just
write
that
out
and
it's
completely
different
or
it's
wrong
or
it's
just
not
formatted.
It's
just
like
some
random
string
of
text
now
in
the
document.
That's
not
okay,.
E
E
Right,
it's
a
negligible
kind
of
aspect
of
this
whole
thing
or
so
because,
like
the
majority
of
things
where
we
do
it,
so
people
never
see
the
diff.
You
don't
see
it
on
wikis.
You
don't
see
it
on
comments.
You
only
see
always
the
result
right.
So
you
never
have
like
this
weird
thing
with.
Oh
it
reformatted
things.
C
B
E
E
C
A
B
A
E
So
I
think
like
in
in
this
case,
like
for
the
14-0
release
and
for
the
next
steps
I
think
for
us.
It's
really
really
important
here
to
be
like
to
be
ambitious
because,
like
the
the
problem
is,
if
we
say
oh
no,
it
will
take
us
like
five
six
months
or
so
till
it's
like
ready
where
we
say
now,
we
feel
ready
to
implement
it,
or
so
this
is
like
five
six
months
or
so
that
we
cannot
use
to
kind
of
like
push
a
certain
narrative
forward
in
the
company
about
like
hey.
E
E
That
is
totally
fine.
We
do
it
this
way
and
it's
like
very
narrow,
but
at
least
it
gives
us
like
a
playground
where
people
can
feedback
it.
We
can
self
like
use
it
constantly,
and
we
can
push
this
narrative
forward
and
kind
of
share
the
vision,
because,
ideally
other
teams
are
starting
to
be
like
interested
in
this
as
well
saying
hey,
we
want
to
adopt
this
as
well.
C
A
Yeah,
I
think
I
think
you're
right
on
chad
with
back
to
the
original
question,
which
is:
should
this
be
opt
in
or
opt
out
like?
I
think
for
now,
until
we
are
super
confident
that
we're
not
corrupting
files
and
that
we
have
extensions
like
nailed
down
for
editing
and
rendering
everything
and
get
lab
flavored
markdown.
We
should.
A
This
should
be
an
explicit
user
opt-in
and
we
should
have
an
interstitial.
That's
like
please,
look
at
the
documentation
and
understand
the
limitations
very
clearly
like
the
only
these
types
of
pages
can
work,
and
we
won't
know
you
won't
know
until
after
you
write
the
changes,
whether
you've
messed
up
your
page.
A
We
should
move
forward
with
that,
and
then
we
can
talk
about
at
what
point.
We're
ready
to
expose
that
opt-in
to
people
outside
of
gitlab
and
in
what
context
there,
but
it
sounds
like
opting
in
for
any
wiki,
is
the
same
risk
as
opting
in
for
new
wikis
because
we're,
if
we're
not
limiting
their
editing
options
for
local
editing.
Well,
actually,
let's,
let's
revisit
that
logic.
So
if
we,
if
we
give
this
option
only
for
new
wikis
and
then
that's
when
you
opted,
then
we
could
take
away
the
button
for
cloning.
A
A
I'm
thinking
back
to
how
confluence
did
this.
So
when
we
at
my
last
job,
we
were
moving
from
dropbox
paper,
which
was
a
fairly
delightful
editing
experience
by
the
way
to
confluence,
and
they
were
in
the
middle
of
transitioning
from
their
standard
editor
to
their
newer,
like
block
type
editor,
and
it's
with
the
new
document
format
that
they
were
creating
to
get
to
it.
You
had
to
create
a
new
page
and
choose
the
meeting,
notes,
template
and
specifically
use
a
new
editor
in
it,
and
you
couldn't
switch
between
editors
on
purpose.
A
Sometimes
it
would
accidentally
load
it
with
the
old
editor,
and
that
was
a
bug
that
we
want
to
avoid,
but,
and
eventually
they
rolled
that
editor
out
to
all
template
types
and
I'm
sure
they
had
document
conversion
and
stuff
like
that.
But
this
seems
like
a
similar
path
in
a
good
way.
I'm
I'm
trying
to
highlight
that
this
is
like
a
a
potential
good
strategy.
A
It
seems
like
a
a
potential
path
for
us
to
introduce
it
with
more
confidence
early
and
let
people
make
the
decision
on
whether
it's
the
right
fit
for
them
in
the
chat
hamanta.
Your
your
discussion
about
how
we
are,
we
are
using
an
intermediate
intermediate
format
and
whether
or
not
we
expose
it
to
the
user,
it
might
be
that
that's
something
we
could
explore
like
if
you
maybe.
A
A
Gitlab
wiki
doc
type
like
you
no
longer
have
access
to
the
source
and
the
file
is
saved
with
an
extension
after
the
markdown
file
so
that
it
can't
accidentally
be
opened
or
I
what
I
would.
What
I
would
suggest
is
that
we
don't
intentionally
write
out
the
prose,
mirror
document
format
like
if
we
could
keep
that
markdown
but
add
an
extension
on
it.
That
just
like
makes
it
not
mark
down.
If
that
makes
sense.
So
if
we're
writing
markdown,
that's
great,
but
we
want
to.
D
Oh
yes,
in
in
the
in
the
drop
down,
if
you
select
any
of
the
other
formats
like
ascii
doc
and
anything
else,
so
extension
saved
is
like
our
dock
or
st.
It's
not
markdown,
but
we
still
show
you
a
markdown
editor
and
it
you
can
still
see
a
markdown
preview,
although
it
does
not
make
sense,
it
doesn't
even
work.
D
C
D
A
Okay,
so
I'm
I'm
intrigued
by
this.
Let
me
just
think
through,
like
an
iteration
plan
for
it,
so
for
mvc
you
create
a
new
page
in
any
wiki
and
you
choose
the
new,
get
lab
markdown
format
and
you're
editing
your
editing
experience
now
changes
to
use
the
content,
editor,
there's
no
there's
no
visible
source
yet,
and
we
have
a
big
warning,
that's
like
by
the
way.
A
Please
keep
this
limited
to
like
headers
and
lists
and
common
marks
back
otherwise
you're
in
trouble.
Now
you
you
save
that
doc.
It
gets
written
to
the
repository,
it's
technically
a
markdown
file,
but
it's
got
maybe
an
extension
or
something
like
that
to
just
segment
it
away
and
then
eric
yeah.
It
wouldn't
be
a
a.
A
A
C
That
prosemirror
supports,
like
the
benefit
of
himanshu's
approach,
is
like
we
can
iterate
on
the
content.
Editor
like
let
them
do
whatever
they
want,
but
they
won't
be
able
to
edit
ever
work
with
them
raw
markdown.
It
won't
even
exist
in
the
repo,
so
that
lets
them
have
the
full
access
to
the
editing
experience
but
not
markdown.
The
other
mvp
approach
is
like
okay,
they
have
their
markdown,
but
it's
a
very
limited
and
incrementally
developed
markdown
experience.
C
A
Like
two
approaches,
so
let
me
be
more
more
specific.
I
don't
want
to
write
an
intermediate
format
to
the
repo
if
we
exposed
through
to
the
user's
perspective.
This
is
a
different
format,
but
use
that
as
the
flag
to
say.
I
want
to
use
the
content
editor
and
only
ever
right
now
want
to
use
the
content
editor.
B
D
D
A
D
A
A
C
Yeah,
I
think
your
comments
earlier
like
got
pointed
that
what
what
user
segments
are
we
concerned
about
keeping
happy
and,
at
the
same
time,
the
people
who
want
a
onesie,
wig,
editing,
experience
or
people
who,
like
maybe
just
want
to
look
at
it
real,
quick,
but
also
it's
really
important.
They
can
still
edit
the
markdown
source,
like
how
big
are
those
two
cohorts
comparatively.
A
Yeah
we
can
write
raw,
markdown
and
preview.
It
quickly,
like
the
source.
Editor
can
do
that.
We
have
a
proof
of
concept.
This
is
the
opposite.
This
is
you
want
to
write
visually.
You
want
to
see
the
headers
big.
You
want
to
write
using
markdown
shortcuts,
I'm
fully
comfortable
with
not
providing
the
entirety
of
gitlab
flavor
markdown
for
our
mvc
as
long
as
we're
not
risking
our
reputation,
the
reputation
of
the
editor
by
exposing
that
too
soon.