►
Description
Sync meeting with members of the Editor group to kick off work on the upcoming Rich Text Editor MVC and map out our iteration plans.
Agenda doc (GitLab Internal): https://docs.google.com/document/d/19Z11Vw0DPNMSZA-4kLuicH3q3zh1m4u8EAQeGh-RUoQ/edit?usp=sharing
More info about the rich text editor: https://gitlab.com/groups/gitlab-org/-/epics/4630
A
B
It's
also
incentivizing
the
community
contributions.
So
I
think
that
perhaps
what
we
have
to
do
first
is
lay
out
that
fundamental
structure
of
how
the
editor
will
be
organized,
how
each
picture
has
to
be
implemented,
set
up
the
the
package
dependencies
and
then
create
let's
say
some
patterns,
how
we
can
test
this.
Each
picture
write
the
documentation
start
a
development
guideline
that
not
only
you
know
the
not
only
the
editor
team
can
follow,
but
also
other
things.
B
And
finally,
I
think
that
that
we
should
right
now
we
have
a
free
text
either
component,
that
is
only
used
by
the
start,
excitator
that
is
based
on
toast
ui
and
is
the
one
that
we
have
to
deprecate
and
we
want
to
deprecate.
So
I
I
think
that
we
could
do
some
clean
up
in
that
in
there
and
take
that
toast
ui
base
editor
and
move
it
inside
the
starting
site.
Editor
application,
because
it's
not
it's
not.
C
B
A
Or
yeah,
I
think
that
that
makes
a
lot
of
sense
and
yeah
just
to
agree
yeah.
We
don't
want
to
have
to
make
this
dependent
on
reaching
feature
parity
with
the
static
site
editor
for
our
mvc.
So
I
think
starting
a
fresh
component
makes
the
most
sense
here
and
I
just
added
a
section
in
the
agenda
just
for
my
own
note,
taking
about
like
epics
or
issues
that
need
to
be
created
just
to
track.
A
Some
of
this
work
so
feel
free
to
continue
to
add
to
that,
but
a
couple
things
that
we
might
want
to
create
now
but
track
much
later,
like
an
official
deprecation
of
toast
ui
when
we
do
get
to
feature
parity
and
we
want
to
remove
it
from
the
code
base,
there
may
be
people
out
there
that,
for
some
reason,
have
worked
or
have
a
dependency
or
are
used
to
working
on.
That
will
probably
need
a
formal
deprecation,
even
though
it's
not
an
api.
B
D
I
mean
like
what
one
intercepting
questions
are
for
you
like.
If
you
we
talk
about
rich
text
at
a
time,
if
I
look
at
the
mvc
points
like
bold
and
italic
and
this
kind
of
stuff
regarding
vision
like
what
do
we
talk
about
here?
Do
we
kind
of
envision
something
like
I
mark
it
and
click
a
button
and
highlight
it
or
so,
or
do
we
actually
kind
of
really
look
for
kind
of
like
this?
This
notion,
like
experience,
because
I'm
still.
B
D
B
So
I
I
touched
that
that
point
here
so
when
we
implement
a
feature
like
as
simple
as
setting
text
as
gold,
we
can
allow
the
user
to
introduce
both
text
in
several
ways.
So
one
of
the
ways
is
setting
an
input
row
that
would
be
like
you
started
like
using
your
markdown
syntax
in
the
fridge
text
editor,
and
then
it
compared
that
piece
of
text
involved.
B
So
I'm
thinking
that
we
could
organize
shipping
those
pictures
like
in
that
way
like
we
don't
we
don't
see
it
in
isolation
as
okay.
We
we
added
a
a
bold
button
in
the
toolbar
that
allows
you
to
set
the
texas
fault
that
we
treat
both
as
if
we
are
implementing
both.
We
have
to
take
care
of
configuring
and
configuring
an
in
control
that
allows
you
to
have
that
notion.
B
This
is
something
that
that
tiptap
and
prosmitter
already
provides
a
lot
of
help
with,
like
all
of
these
features,
are
already
set
up
and
tipped
up
for
for
the
bold
style
but
yeah.
I
think
that
you
know
from
the
ground
up.
We
have
to
think
in
which
kind
of
experience
we
want
to
provide
and
and
read,
and
try
to
implement
each
of
the
pictures
in
later,
like
you
know,
considering
considering
all
of
those
aspects.
C
So
I
I
have
some
I'm
confused
about
exactly
what
it
is
going
to
entail
technically
and
we
don't
have
to
get
off
into
the
weeds
here,
but
like
the
previous
approach
and
what
we
talked
about
with
tip
top
proposed
mirror
is
like
it's
client-side,
rendering
markdown
right.
So
it's
it's
live.
So
when
you
say
we're
still,
gonna
rely
on
server-side
parsing.
How
do
those
two
fit
together?
Are
we
only
gonna
like
ship
out
parts
of
it
like
the
mr
links
or
what.
B
C
B
B
So
we
only
have
to
set
up
trolls
meter
to
take
this
html
that
is
produced
by
the
server
and
parse
it
and
convert
it
into
a
prosperous
document.
We
shouldn't
be
very
complicated
because
we
only
have
to
to
account
for
the
differences
that
prosmero
is
expecting
in
the
way
that
we
represent
voltex
or
a
link
or
or
a
task
list,
our
task
list,
etc.
C
C
B
We
are
not
going
back
to
a
server
with
every
time
that
the
user
introduced
some
new
content.
So
when
the
user
is
introducing
content
in
data,
we
are
producing
the
like
the
html
in
the
client
and
then
when
we
go
back
to
the
to
the
right
mode,
let's
say,
and
we
want
to
display
the
markdown
based
on
the
content
in
the
bridge
text
editor.
We
have
to
generate
that
marker
in
the
client
as
well.
B
B
Side
dependent,
so
this
is
the
way
that
they
auto
complete.
The
suggestions
function.
Working
the
in
data
is
that
there
is
a
drop
down
component
that
makes
an
api
call
to
get
all
of
the
suggestions
from
the
server,
but
the
part
of
generating
the
link
in
the
client
is
is
only
the
client.
It's
not
only
the
server.
C
Okay,
maybe
that's
a
bad
example,
but
I
assume
there's
something
that
is
dependent
upon
the
server
rendering
or
we
don't
have
to
get
into
it,
but
it
seems
like
they're,
I'm
still
confused
about
some.
Why
would
we
have
to
have
the
server
render
anything
if
we
have
all
of
the
logic
on
the
client
and
if
we
don't
have
all
of
the
logic
on
the
client?
How
are
we
going
to
render
everything
live.
A
Let's
follow
up,
I
think
it
is
important
to
to
specify
and
underline
that
we
are
for
our
nbc.
We
will
be
relying
on
server-side
rendering
of
the
markdown
and
not
fully
like
building
that
architecture
that
we
had
been
proposing
before,
where
we
had
a
client-side,
markdown,
parsing
and
part
of
that
is
because
we
already
have
an
existing
server-side
markdown
parser
that
handles
all
of
gitlab
flavor
markdown
already,
and
there's
no
reason
to
completely
rewrite
that,
for
our
abc.
B
E
Comment
a
little
bit
about
how
prose
mirror
can
handle
these
things
like,
for
example,
you're
working
on
something
some
document
that
is
not
marked
down
in
on
the
front
end,
and
then
you
send
it
over
to
the
server
side
and
server
side.
Sends
you
a
different
markdown
and
then
you
convert
that
back
to
html
and
pros
mirror
can
actually
do
a
diff
of
what
has
changed
so
that
it
can,
for
example,
come
convert
a
a
short
code
of
a
merge
request
or
an
issue
into
a
into
an
actual
link.
E
E
E
B
B
I
was
wondering
if
we
could
ship
a
nator
with
all
of
these
features,
except
tables,
because
it's
complicated
to
to
implement
and
then
provide
that
editing
experience
as
an
optional
one
in
the
wiki,
and
the
only
downside
that
I
that
I
see
with
that
approach
is
that
if
the
user
tries
to
open
a
document,
a
wiki
page,
that
is
using
pictures
that
are
not.
You
know.
B
That
is
not
one
of
them
or
one
of
these,
then
the
data
will
be
capable
of
of
opening
the
or
of
eight
in
the
page.
So
perhaps
what
we
can
do
is
like
not
allowing
to
enable
that
editing
experience
if
they,
if
we
detect
that
kind
of
those
of
unsupported
content
in
in
the
page
that
the
user
wants
to
edit.
A
A
The
ability
for
users
to
try
out
and
be
successful
with
our
mvc
and
how
long
we
would
put
that
off
for
like
if,
if
it
meant
one
release,
and
then
we
just
focus
on
tables
like
well,
we
could
probably
talk
about
that.
But
maybe
we
could
talk
a
little
more
about
what
is
com,
what
makes
tables
more
complex
and
how
we
would
address
that,
even
if
it's
not
in
the
nbc.
B
B
A
It
makes
a
lot
of
sense.
Would
we
be
able
to
render
tables
that
this
is
to
your
second
point?
Would
we
be
able
to
render
tables
and
allow
the
text
inside
a
table
to
be
edited
without
providing
the
formatting
for
adding
new
rows
and
removing
rows,
and
things
like
that?
Maybe
we
could
still
display
the
content
in
the
editor.
A
A
A
But
clearly
it's
a
it's
a
separate
effort.
I
mean
it's
a
it's
an
it's
a
feature
that
can
be
implemented
in
isolation,
so
we
can.
We
can
talk
more
about
whether
or
not
that
makes
it
into
our
first
release
or
at
what
point
we
make
it
available
to
everybody.
But
that's
it's
an
important
thing
to
for
me
to
remember
the
complexity
of
of
tables
as
far
as
including
in
the.
D
It
would
work
right,
they're,
just
like
we
don't
do
anything
with
it
like
we
don't
do
any
special
rules
like
if
there's
like
just
in
the
rich
text
area,
if,
like
somebody,
writes
a
markdown
style
table
okay,
then
you
see
it
like
as
plain
text
or
so
only
kind
of
in
the
full
rendered
version.
So
if,
like
we
submit
anything,
that's
where
you
see
it
would
that
be
possible
because
at
least
then
we
don't
kind
of
lose
the
support
for
tables.
B
E
B
E
So
if
your
backend,
if
your
document
contains
those
tags
so
like
it
can
it
can
render
it
properly,
even
though
like
you
might
not
be
able
to
edit
those,
but
you
can
at
least
display
those.
I
think
it
should
be
possible,
but
I'm
not
sure
so
I
think
there's
got
it
sorry.
I
have
used
rosemary
to
display
tables
in
the
past,
but
that
was
like
three
or
four
years
ago.
C
So
the
general
case
is
just
like:
we
had
for
the
static
site
editor
for
things.
We
don't
support.
You
have
to
do
something
with
that
in
the
rich
text
editor,
so
you
either,
which
means
you
have
to
somehow
fence
it
off
and
either
it's
like
a
rendered,
but
not
editable
version
that
you
can't
touch
or
you
just
don't
show
it,
but
some
way
you
have
to
to
fence-
and
that's
going
to
be
true
of
sorted
to
my
previous
point
of
every
feature.
C
A
The
idea,
if
we
can't
render
the
table
without
making
it
editable,
then
I
would
probably
prefer,
from
an
experience
standpoint,
to
have
some
kind
of
call
out
that
just
says.
Like
there's
content
on
the
page,
we
don't
understand
and
click
here
to
edit
the
source
or
something
like
that
and
like
maybe.
We
can
even
know
that
it's
a
table
and
say,
like
tables,
aren't
supported
in
this
version.
A
Like
click
on
this
issue,
to
follow
our
progress
right,
we
we
can
be
very
transparent
about
what
we
support
and
what
we
don't
support
for
the
mvc,
especially
when
it
comes
to
things
that
we
know
we
don't
support
right,
like
there's
the
wiki.
The
reason
we're
choosing
it
is
because
there's
a
fairly
well
defined
set
of
things
that
you
can
type
in
there.
The
statics
like
editor,
would
would
have
a
lot
more
of
these
edge
cases.
B
Yeah,
so
I
think
that
we
should
explore
himanshu's
idea
about
just
creating
a
pros,
mirror
schema.
That
knows
how
to
interpret
all
of
the
features
supported
by
the
gitlab
flavor
markdown.
Even
though
we
don't
provide
tools
to
eat
it.
Perhaps
we
can
teach
pros,
mirror
how
to
read
it
and
display
it,
and
I
think
that
it
should
be
really
easy,
because
it's
just
defining
a
personal
function
that
tells
you
hey
this
html
picks
those
attributes
and
and
display
it
in
in
a
specific
way.
A
So,
just
to
replay
just
to
make
sure
I
fully
understand
which
this
is.
This
is
great,
and
this
is
what
we
need
to
be
talking
about.
The
year
there
we
could
separate
the
concerns
for
our
mvc.
We
can
build
a
schema
that
interprets
everything
that's
available
in
gitlab
flavor
markdown,
everything
that
could
potentially
be
put
into
a
wiki
or
in
an
existing
wiki
page,
so
that
at
least
we
understand
the
content
coming
in
and
then
the
editor
as
we
build
out
individual
features,
can
make
those
those
components
in
the
schema
editable.
A
So,
for
example,
if
we
decide
that
the
mvc
in
order
to
get
it
out
as
soon
as
possible,
doesn't
support
editing
tables
and
can't,
like
you,
can't
type
ahead
labels
or
something
like
that
like
we
can.
We
can
find
this
list
of
of
things
to
make
the
cutoff,
but
at
least
then
the
content
is
rendered
and
we
may
be
even
able
to
direct
the
user
to
like
switch
over
to
the
raw
markdown
source
to
to
make
their
edits.
B
B
No,
it's
a
it's
going
to
be
possible
to
edit
the
text
notes
within
a
an
element
that
is
not
supported.
For
example,
you
have
this
element
stream,
this
hierarchy
of
comp
of
nodes,
where
a
table
cell
content
contains
a
text
node,
so
you
can
edit
the
text
node
within
the
table,
but
you
cannot
make
any
special.
A
Okay,
I
mean
that
that
seems
like
a
good
compromise
to
me
for
an
mvc,
which
is
that
an
existing
table
in
a
wiki
gets
translated
appropriately
and
displayed
and
previewed,
and
if
I
need
to
change
the
content
of
the
cell,
then
I'm
good.
If
I
want
to
change
the
format
of
the
table,
we
say:
look
sorry
it's
coming
later
right,
we'll
indicate
to
the
user
that
we're
working
on
that
and
we'll
be.
A
A
So
yeah
I
mean
I've
been
taking
notes.
I
think
what
we
want
to
do.
We
need
to
define
the
experience
and
obviously
this
comes
with
pros
mirror,
but
I
think,
as
we
or
with
tip
tap
as
we
move
towards
it,
what
we
want
to
do
is
use
the
the
floating
medium
style,
formatting
bar.
So
that's
the
experience
we're
going
for.
I
believe,
though,
I'm
saying
that
and
michael's
mock-ups
for
what
it
looks
like
in
wiki
had
a
top
floating.
A
I
mean
a
top
toolbar,
so
I
want
to
chat
with
him
about
whether
or
not
he
was
doing
that
because
he
just
felt
like
it
would
be
less
disruptive
or
if
he
thinks
that's
the
best
experience
I
know
in
tip
tap.
You
can
have
either
one
so
we'll
we'll
just
decide
on
a
direction
we
don't
want
to
have
both
or
like
make
that
some
kind
of
user
setting.
B
A
Okay,
well,
oh
we'll
get
clarity
on
that.
Obviously,
before
we
start
building,
then
where
did
my
notes
go?
I
was
trying
to
write
that
tonight.
Here
we
go.
We
want
to
build
in
a
mechanism
to
opt
in
to
this
mvc
and
opt
back
out.
That's
part
of
the
mvc
right.
We
need
to
have
a
way
for
the
user
to
try
this
out
we're
going
to
build
all
the
basic
text.
Formatting
features,
but
maybe
not
editing
every
aspect
of
get
lab,
flavored,
markdown
and
we'll
come
up
with
that
final
list.
A
If
you
think
about
the
wiki
editing
view,
we
have
that
content
box
if
opting
into
the
new
editor,
simply
adds
a
new
tab
up
there,
and
it's
now
called
rich
text
and
you
can
switch
between
source
and
preview
and
rich
text
or
whatever.
Maybe
we
hide
preview?
That's
one
approach
would
this
be?
It
would
be
too
much
for
the
mvc
to
introduce
that
source.
A
E
C
So
I
want
to
point
out
that
michael's
mock-ups
of
what
the
opt-in
look
like
are,
if,
if
you
click
through
to
the
issue
that
he
linked
that
one
yeah
and
then
if
you
click
yeah,
go
down
to
the
highlighted
yeah,
so
there's
no
multiple
tabs.
It's
like
the
rich
text.
Editing
is
the
only
experience
you
have
so
this
the
incremental
approach.
We
were
just
discussing
where
some
things
just
don't
work,
isn't
really
compatible
with
with
that,
at
least
not
until
we
have
full
feature.
Parity.
A
Yeah
yeah,
I
think
that
that's
the
two
points
of
feedback
I
have
on
this,
and
you
know
we
just
opened
this
up
as
the
meeting
was
starting
so
there's
time
to
refine
this.
But
the
two
points
of
feedback
I
have
for
him
are:
we
need
to
have
a
way
to
drop
back
into
the
raw
source,
and
we
want
to
make
sure
that
the
top
toolbar
is
the
direction
we
want
to
head
in.
I
was
under
the
assumption
we
were
going
to
go
with
the
sort
of
floating
on
every
line.
Kind
of
medium,
like
editing,.
B
B
B
E
B
C
C
And
I'm
I'm
getting
to
understand
it
now,
but
so
the
part
that
concerns
me
is
that
inverse
operation
when
you
convert
it
back
to
markdown
like
if
the,
if
our
rich
text
editor
does
not
have
like
100
percent
parity
with
rendering
exactly
the
same
as
the
gitlab
flavored
marked
down
on
the
back
end,
they
have
to
be
in
sync.
Otherwise
what
they
saw
in
the
rich
text.
Editor
is
not
what
they're
going
to
see
when
they
act
when
they
save
it
or
when
they
look
at
it
somewhere
else.
B
Writes
some
markdown
in
the
remote
and
then
we
allow
the
server
to
to
generate
html
for
that.
And
then
we,
when
the
user
switches
from
reach
text
to
raw
markdown,
we
are
we're
going
to
be
generating
markdown.
That
is
potentially
different
from
what
the
user
growth
in
the
first
place.
Is
that,
like
a
similar
product
to
what
we
have
in
in
toast
ui.
C
Yeah,
so
that's
the
edge
cases
that
that
really
worry
me
like
and
especially
like
they
write
something
that
is
not
well
formatted
like.
Presumably,
that
should
be
impossible
in
the
rich
text
editor
but
like
they.
They
write,
something
that
it
just
doesn't
understand
and
it
happens
to
render
differently
or
get
saved
differently.
B
C
C
B
C
Yes,
but
the
server
is
rendering
it
renders
marked
down,
but
pros
mirror
whatever
it
does
to
render
html
as
they
type
it
live.
That
html
has
to
exactly
match
what
would
be
rendered
by
that
yeah
like
if
you
take
the
inverse
operation
of
the
html
from
the
rich
text,
editor
and
then
rerun
it
through
the
get
lab
flavored
markdown.
E
That
is
right;
no
it
they
cannot
really
be
identical,
always
because,
like
like,
obviously,
you
would
like,
for
example,
tag
some
user
and
it
converts
into
a
link.
So
what
like?
What
tip
tap
or
the
collaborative
editing
thing
can
do
here-
is
that
if
there
is
a
difference,
it
applies.
The
server
side
changes
to
your
document
that
calculates
a
diff
and
then
applies
it
to
a
document
we
can.
We
will
need
to
do
a
little
bit
more
research,
but
I
think
it.
C
C
E
C
B
B
Okay,
next
point
is:
can
anything
anything
be
done
in
parallel?
I
think
that
this
is
a
a
picture
that
we
can
really
develop
in
parallel,
because
I
know
that
perhaps
like
well.
It's
like
bringing
one
example
is
that,
in
the
case
of
the
schema,
we
have
to
develop
a
schema
that
supports
two
features
of
of
gitlab
flavor
markdown.
B
E
A
E
C
B
B
C
E
It's
it's
actually
quite
similar
to
snippets
just
a
little
bit
lesser.
Maybe
but
yeah
there's
a
lot
of
stuff
going
around
and
wikis
like
you
can
there's
wiki
pages,
there's
a
list
of
pages
and
you
can
there's
a
wiki
display
page
and
then
you
can
edit.
The
wiki
page
like
there
are
like
four
or
five
different
pages.
E
D
So
imagine
like
I
would
not
aim
for
like
any
kind
of
else.
Besides
the
wiki
edit
experience
for
the
mvc,
like,
I
think
that's
all
we
need
is
always
say
you
still
like
create
a
page.
You
click
edit
and
you
come
into
specific,
like
edit
page.
I
don't
think
we
need
to
refactor
all
of
like
wiki
for
just
like.
E
Also,
I
had
a
question
like,
for
example,
like,
like
chad,
mentioned
that
you
for
ex
for
an
example
where
you
put
an
issue
number
and
then
there's
a
drop
down.
That
appears.
Let's
say
I
don't
select
anything
in
the
drop
down
and
I
just
enter
an
issue
number
and
I
hit
space
bar
in
the
disk
text.
Editor
what's
going
to
happen
next,
like
will
will
a
request
to
the
server
be
sent
here
and
to
to
convert
that
thing
into
let's
say:
link.
B
What
transfer
would
do
is
like
to
interpret
that
as
a
specific
node
that
that
we
teach
pros
mirror
how
to
recognize
like
we,
you
see
these
two
characters
together.
That
represents
a
reference
to
an
issue
and
then,
based
on
that,
you
know
some
logic
outside
of
the
display
logic
of
transmitter
can
take
that
note,
and
you
know,
file
for
that
reference
in
the
in
the
server.
E
C
C
B
So
in
in
relation
to
to
vacant
support,
I
feel
at
the
front
for
the
nbc.
We
don't
need
a
bucket
involvement,
but
that's
my
that's
an
estimation.
I
I
I
can't
say,
like
I'm
100,
confident
of
that,
but
I
think
that
back-end
involvement
will
be
required
when
we
start
like
displaying
advanced
features
like
pds
files
and
diagrams,
because
if
you
like
have
a
pdf
attachment,
you
probably
want
to
tell
the
you
want
to
teach
the
martin
endpoint
to
represent
that
pdf
pdf
attachment
as
a
special
note
with
metadata.
B
C
B
A
I
think
that
there's
three
like
there's
three
phases
to
this:
there's
we
have
a
component,
it's
live,
but
it's
behind
a
feature
flag,
and
maybe
we
only
turn
it
on
for
us,
then
there's
a
default,
visible,
toggle
to
opt
in,
and
then
there's
default
on
that
this
is
the
the
default
experience
for
editing,
wiki
text
right
so
defining
those
milestones
and
what
needs
to
go
into
place
to
to
set
those
up.
Obviously
we
need
to
create
the
feature
flag
for
it.
A
Probably
you
know
later
this
year,
I'm
I'm
not
too
concerned
about
that
strategy.
Right
now,
the
I
think
it's
important
probably
to
talk
about
the
strategy,
also
in
the
context
of
what's
not
on
the
nbc,
which
I
made
a
note-
and
we
haven't
really
talked
about
this,
but
since
the
wiki
allows
you
to
write
in
other
formats,
other
than
markdown
or
mvc
should
be
formatted.
I
mean
specifically
for
markdown
formatted
pages.
A
We
can
work
towards
ascii
doc,
support,
rdoc
support
and
things
like
that,
and
I
know,
there's
a
lot
of
issues
in
the
backlog
and
a
lot
more
context
that
I
still
catching
up
on.
As
far
as
like
a
strategy
for
making
ascii
dock
a
little
more
first
class
and
and
having
it
be
a
little
more
native
feature
in
an
ideal
world.
A
This
is
just
for
markdown
pages
and
for
those
that
do
support
it,
making
it
very
easy
to
switch
over
and
try
out
the
new
editor
so
in
in
relation
to
michael's
concepts.
I
actually
really
like
the
idea
of
getting
rid
of
that
markdown
is
supported
link
and
instead
using
that
area
to
switch
and
toggle
between
the
editors.
The
only
thing
that's
missing,
as
we
already
talked
about,
is
the
way
to
get
back
to
the
source
view
and
since.
A
I
mean
I
think
it
could
be
as
simple
as
when
you
toggle
that
switch
and
opt
into
the
new
editor.
You
now
have
two
tabs.
Instead
of
write
and
preview,
it's
like
source
and
rich
text,
or
something
like
that
and
source
is
the
same
content
as
right.
We
just
maybe
change
the
name
of
the
button
or
something
like
that
to
make
it
more
clear
and
the
rich
text
editor
becomes
a
replacement
for
the
preview
link.
A
C
Yeah,
I
just
put
an
update
on
it.
I
I
don't
think
this
is
really
relevant.
I
wrote
this
when
I
was
I
was
thinking
we
were
going
to
continue
iterating
on
the
existing
static
side.
Editor
rich
text
editor,
but
it's
not
relevant
to
this
meeting,
but
it's
still
a
thing
like:
if
we're
are
we
killing
the
editor
or
the
whole
static
site
product
or
what's
what's
the
long-term
plans
for
that?
Maybe
it's
a
discussion
for
another
day,
probably
we're
already
running
late
here.
A
Yeah
I
mean
we,
we
should
have
that
discussion
there.
There
are
no
plans
to
completely
you
know,
abandon
that
category.
So,
if
anything,
I
think
we're
building
a
stronger
case
for
it
by
working
on
this
rich
text
editor
and
hopefully
make
it
a
better
product
or
better
category
in
the
long
term,
but
in
the
near
future
yeah
it
is
it's
not
something
we're.
B
A
A
A
So
if
you,
if
you
looked
at
the
wiki
edit
page
right
now,
we
have
the
title,
the
content
type,
I
believe,
and
then
the
yeah,
the
format
so
markdown
and
then
the
content
editor
itself
and
then
there's
like
a
commit
message
and
a
save
button
on
the
bottom
rnvc
is
specifically
constrained.
I
think
to
that
content.
A
You
know
metadata
on
the
page
things
like
that,
so
as
a
as
an
aspirational
goal,
this
is
fantastic
and
I
think
that
it's
it's
very
close
to
what
we're
looking
at.
I
am
curious
and
I
want
to
talk
to
him,
we'll
probably
I
have
a
we
have
our
design,
ux
sync
I'll,
put
it
as
an
agenda
item
to
talk
through
this
top
toolbar
versus
like
inline
formatting,
whether
or
not
he
thought
this
might
be
easier
or
if
he
actually
thinks
this
is
like
a
preferred
experience.
So
we'll
talk
through
that
and
otherwise.
A
It
won't
behave
quite
the
same
as
something
like
medium,
which
is
that,
like
in
the
wiki
view
and
in
issue
view
here,
the
idea
being
that
you
toggle
between
an
edit
mode
and
read
mode
right.
So
what
I'm
getting
at
is
I
I
don't
see
a
near
future
where
we're
removing
the
need
for
an
edit
mode.
We're
not
ever
gonna
have
like
live
editing,
because,
ultimately
it
needs
to
result
in
a
commit.
A
A
The
closer
those
start
to
look
the
the
more
I
expect
the
desire
will
be
to
like
remove
that
barrier
and
just
be
able
to
like
click
into
the
description
and
start
writing
and
then
click
out
of
it,
and
it
saves
that's
not
something
that
we
need
to
explore
now.
It
may
be
something
that's
technically
never
possible
because
of
the
get
operation
that
needs
to
happen,
but
that's
something
that
came
up
in
an
issue
that
I
saw
yesterday.
A
I
think
around
the
wiki
and
trying
to
remember
the
context,
but
it
was
effectively
the
the
same
concern
which
is
like
a
going
into
edit
mode
and
creating
the
the
right
operation
versus
editing
in
the
live
sort
of
read
mode
and
I'll,
try
and
find
that
issue
and
link
it.
I
think,
yeah.
I
think
what
we're
what
we're
getting
at
is
until
we.
A
A
It
was
check
boxes.
We
should
talk
about
check
boxes
at
some
point
and
how
they
weren't
interactive,
because
every
time
you
click
one,
it
becomes
a
right
operation.
It's
a
it's
a
commit
so
I'll,
just
wrap
it
up
to
say
that
interactive
checkboxes
in
the
read
view
of
wiki
is
not
part
of
the
mvc.
We
don't
need
to
solve
for
that
in
our
mvc
and
we
can
talk
about
it
later.