►
From YouTube: Create:Editor. Source-to-Content switch discussion
Description
Discussing the ultimate goal of introducing the WYSIWYG functionality in parallel with code editing for simple markdown files and Static Site Editor replacement
A
Right
that
was
shared.
I
I
have
I'm
confusing
all
the
all
these
discussions
we
had,
I
know
so.
We
we
had
a
presentation
where
we
looked
into
two
possible
ways
of
implementing
the
source,
the
content
editors
switch
after
that
we
had
a
discussion
with
enrique
and
with
the
staff
engineers
and,
after
all,
we've
got
the
what
what
seems
to
be
to
me
like
the
solution
we
have
to
pursue,
namely
to
introduce
the
shared
data
data
layer
which
will
manage
requests
to
the
to
different
apis.
A
A
So
that's
that's
what
I
would
like
to
talk
about
today,
whether
we
have
any
any
ideas
how
we
will
we
are
gonna
build
this.
Do
we
have
any
examples
of
how
we
will
build
this
and
whether
we,
whether
there
is
anything
we
should
keep
in
mind
and
be
aware
of
before
we
do
that
or
maybe
maybe
somebody
gave
another
thought
to
this
problem,
and
maybe
we
have
to
pursue
some
other
path.
A
No
okay
seems
like
we
are
all
in
agreement,
and
that's
that's
how
we
are
gonna
gonna
get
to
this.
So
technically,
if
this
is
the
case,
I
I
I
think
we
might
approach
the
whole.
The
whole
thing
of
the
source
to
content
editor
switch
in
parallel,
namely
enrique,
has
started
the
work
of
preserving
the
unchanged
markdown
in
the
files,
and
this
is
this
is
the
main
blocker
for
us
technically,
but
this
effort
of
shared
data
layer
can
be.
A
B
A
A
If
we,
if
we
target
only
one
application,
because
all
three
applications
we
have
now
like
web
ids
single
file,
letters,
direct
api
and
snippets
is
graphql,
so
the
best
would
be
indeed
to
take
just
one
application
and
hence
start
writing
this
proxy
layer,
so
that
we
we
connect
to
just
one
data
real
data
data
storage.
Underneath
the
question
is
whether
it
should
be
single
source,
editor,
web
id
or
snippets.
When
I
mentioned
some
snippets
on
slack
last
time,
so
technically.
A
A
Without
any
data
layer,
without
any
shared
data
layer,
we
can
start
doing
this.
We
can
start
implementing
this
switch
and
snippets
right
away
because
we
we
have
content
editor
as
a
view
component.
We
have
source
editors
view
component
and
there
is
no
need
to
update
for
for
the
snippets
use
case.
There
is
no
need
to
update
the
view
component
for
source
editor
to
to
work
with
extensions
and
things
like
this.
So
technically
we
can
start
doing
this
without
any
shared
data
layer.
But
technically
what
this
means
is
just
we.
A
We
postpone
the
solution
to
this
problem
to
later
and
since
we
because
again
why
we
can
do
it
now,
because
in
snippets
we
do
not
care
about
preserving
the
unchanged
markdown.
It's
it.
We
don't
care
about
divs
in
in
the
snippets.
So
snippets
is
a
good
candidate
for
starting
this
and
we
can.
We
can
implement
it
and
we
can
start
gathering
some
statistical
data
if
we
are
interested
in
that.
A
But,
as
eric
mentioned
in
slack,
snippets
won't
really
give
us
any
sensible
statistical
data,
because
it's
not
very
much
used,
especially
for
the
markdown,
especially
for
wheezyweek
functionality
in
markdown
in
in
the
snippets.
Apparently.
So
this
technically
means
that
we
will
just
spend
time,
probably
for
nothing
like
we'll
gain
some
experience,
but
this
experience
will
inevitably
be
moved
away
and
we
will
have
to
get
back
to
to
proper
implementation.
So
I
think
we
have
to
start
in
this
case.
We
have
to
start
with
the
single
file
editor.
A
My
my
idea
is
that
we
have
to
initialize
view
application
on
the
the
problem
is
that
in
order
to
do
this
in
the
single
file
editor,
we
have
to
update
the
view
component
for
for
source
editor,
because
source
editor
in
single
file,
editor
does
use
extensions
and
use
them.
Use
extension
uses
extensions
extensively.
Let's
put
it
this
way,
so
this
is
one
more
friction
point
not
a
big
one
like
we
I've
already.
I
think
david
correct
me
if
I'm
wrong,
I
think
I've
put
this
for
49
the
view
component
yeah.
A
So
technically.
This
means
that
it
won't
happen
this
milestone.
But
if
we
can
approach
that
in
the
beginning
of
14
9,
then
we
will
be
able
to
to
start
looking
into
the
shared
data
layer
in
14.9
as
well,
because
my
plan
would
be
to
to
to
do
it
correct
right
from
the
start,
so
we,
instead
of
just
using
the
sword
the
raw
source
editor
on
the
single
file
letter.
A
We
will
use
the
view
component
to
to
be
on
the
same
page
with
the
content
editor
and
but
for
that
we
will
sort
of
initialize
the
view
application
just
for
the
editor
part,
and
then
we
will
have
to
use
a
source
editor
view
component
with
full
support
for
extensions
and
other
features
that
are
not
supported.
Yet.
A
B
That
makes
sense,
I
know
that
that
will
probably
increase
the
cost
of
inverting
the
continuator,
the
single
pilot
or
because
apparently
there
is
a
view,
migration
or
not-
maybe
a
no,
no,
not
view
migration.
I
think
that
we
could
like
instantiate
a
view
application
and
just
and
like
put
in
there
the
view
version
of
the
source
editor
right
there,
the
source
editor
that
is
like
wrapped
in
the
you
know
your
component
yeah.
Is
that
what
you.
A
Mean
yes,
I
I
mean
like
we,
we
do
have
the
source
editor
view
component
at
the
moment
it
is
the
sort
of
the
abstraction
for
the
for
the
full
size
source
editor
and
technically
we
can.
It
will
be
us
who
decides
how
far
far
we
go
in
this
process,
because
even
if
you
are
using
the
source
header
view
component,
you
can
still
get
access
to
the
raw
source
editor
in
this
component
and
technically
and
that's,
I
think,
that's
what
we
do
for
the
I
don't
confuse.
A
If
for
for
the
pipeline
editor,
we
use
the
view
component.
However,
we
access
directly
td
to
the
editor
underneath
it
in
order
to
install
the
in
order
to
use
the
the
extension.
So
we
can
do
do
it
that
way
without
actually
updating
the
view
component,
but
we
will
still
have
to
set
up
a
proper
communication
between,
like
from
the
source,
editor
and
listen
to
the
things
getting
into
the
source
area
in
order
to
to
to
make
source
editor
and
quantitator
to
speak
to
each
other.
A
When
it
comes
to
the
view
migration,
I
think
we
can
we.
We
can
identify
the
bare
minimum
that
we
have
to
convert
in
the
view,
and
this
probably
would
be
just
this
editor
part.
That
is
that
that
contains
the
editor.
So
we
will
convert
this
into
the
view.
Application
with
the
template
containing
source
header
view
component
and
content,
editor
view
component
or
content
content
editor
component.
A
Another
approach
would
be
to
wrap
both
the
editor
and
the
toolbar
with
the
with
the
view
application.
So
do
this
sort
of
migration.
That
would
be
the
correct
path
to
do
this,
but
this
would
mean
that
we
will
also
have
to
refactor
the
the
toolbar.
The
toolbar
for
the
source.
Editor
is
in
the
nbc
state
at
the
moment
like
in
the
mvc
of
mvc.
Let's
put
it
this
way,
it's
not
even
pushed
yet.
So
that's,
that's!
That's
another
approach
and
himanshu
do.
Do
you
mind
describing
what
you're,
what
you're
writing.
C
It's
a
bit
noisy
here,
but
I
can
describe
it
a
bit
briefly
so
so
right
now,
continuity
does
not
really
support
rendering
of
dynamic
content
or
any
kind
of
content.
That
content
editor,
like
other
renderers
support,
potentially
like
outside
of
gta
fm
and
underneath,
would
actually
render
it
as
plain
text,
which
means
that
any
paragraph
like
content,
you
have
that
would.
A
C
C
B
C
Yeah
yeah
we
can,
we
can
do
that,
but
since
you
can
right
now
you
can
open
those
files
and
content
later
sorry
in
static
site
editor,
and
if
you
want
to
like
deprecate,
study,
excited
editor
and
provide
a
sort
of
one-to-one
replacement
for
it.
Then
you
need
to
be
able
to
open
those
erb
files.
Then
content
editor
as
well.
C
D
C
A
This
is,
this
is
absolutely
correct
and
eric
was
explicit
in
saying
that
he,
since
we
duplicate
the
static
side
later,
he
wants
to
direct
people
to
something
that
they
can
use
as
the
replacement
for
static
site
editor
and
preferably
it's
either
static,
a
single
violator
or
web
ide
with
with
the
wysiwyg
functionality,
and
if
we
do
not
deliver
the
same
functionality
that
they
got
used
to
in
the
static
site,
editor
that
might
be
seen
as
an
as
an
issue.
Is
there
any
like.
A
Yeah,
but
we
cannot,
we
cannot
expect
people
who
were
visually
editing
the
the
pages
to
exp.
We
cannot
expect
them
to
start
all
of
a
sudden
start
editing
markdown
as
the
code
right
and
if
we
do
not
provide
them
with
full
functionality
they
got
used
to
instead
excited
they
won't
be
able
to
get
the
same
results.
D
C
D
D
A
D
A
D
D
That
is
not
used
very
much
light
snippets
and
not
even
try
to
implement
the
translation
layer
just
go
ahead
and
implement
both
of
the
view
components
in
the
way
that
we
want
and
see
what
similarities
there
are,
because
you
know
one
of
the
rules
of
of
architecture.
Is
you
know
you?
Don't
you
don't
dry
things
up
on
the
first
one
you
duplicate
it
once
hold
your
nose
duplicate.
It
twice
hold
your
nose.
D
Maybe
the
third
time
is
where
you
dry
it
up,
because
then
you
can
see
what
the
similarities
and
the
patterns
are
and
have
a
good
feel
for
what
the
abstraction
in
the
interface
needs
to
be,
whereas
if
you
try
to
prematurely
implement
that,
you
can
often
get
it
wrong
before
you.
Actually,
if
you
try
to
do
it
before,
you
actually
know
what
it
needs
to
do.
D
Well,
so
I'm
being
very
hand-wavy
of
this,
but
as
generally
how
I
envisioned
a
problem,
there's
a
source
editor
in
the
content
editor.
They
both
have
to
communicate
via
view
to
something
underneath
them
right.
Presumably
they
will
have
different
requirements
and
this
translation
layer
will
have
to
support
the
superset,
the
combination
of
both
those
requirements.
D
A
Yeah,
I
think
so,
but
just
just
to
make
100
sure
that
I
understand
this,
so
the
suggestion
is
to
implement
this
as
two
separate
view:
components
without
any
any
data
layer.
Abstraction
just
see
how
these
two
things
can
communicate
with
each
other
and
use
this
as
the
basic
sort
of
model
of
how
these
things
communicate.
D
Right
and
do
it
in
a
low
traffic,
low
risk,
low
requirements
area
starting
first
like
snippets
and
then
maybe
you
know
we'll
get
an
idea
there
and
then,
as
we
move
to
more
complex
areas,
maybe
more
requirements
but
we'll
have
a
better
idea
for
the
basis
that
we
need
to
build
and
iterate
on.
By
that
point,.
A
Yeah
like
since
snippets
is
the,
as
I
said
like
implementing
snippets,
is,
is
trivial
like
to
a
certain
extent,
of
course
like,
but
we
don't
need
any
abstraction
layer
for
snippets
at
the
moment,
because
source
editor
source
editor
doesn't
need
to
be
the
view
component
doesn't
need
to
be
updated.
We
don't
need
the
shared
shared
data
layer,
so
we
can
do
it
in
snippets
right
away.
A
The
problem
is,
though,
is
that
I
don't
understand
I
or
I
don't
know
how
this
would
give
us
any
sort
of
any
pattern
that
we
can,
that
we
could
identify
like
you're
you're,
saying
yourself
like
we
have
to
implement
it
two
three
times
in
order
to
see
the
pattern
and
that's
exactly
when
how
many
times
we're
gonna
implement
this
like
we're,
we
have
only
three
three
applications
to
implement
this
in
and
it's
clear
like
it.
Okay,
it's
not
100
clear,
but
we
do
have,
because
of
because
we
have
in
all
three
applications.
A
We
have
three
different
storages.
We
still
have
to
make
sure
that
we
connect
to
all
of
them
from
both
editors
source.
Editor
does
have
connections
to
all
of
those
three.
We
need.
We
have
to
make
sure
that
content
editor
is
being
is
able
to
connect
those
three,
so
we
can
technically
if
we
say
that
we
will
not.
A
A
A
But
then,
if
we
go
to
the
snippets
example,
we
have,
we
can
have
up
to
10
snippets
on
the
same
page
like
when
you
edit
it.
How
does
contemplator
work
with
like
with
with
in
the
in
that
scenario?
I
I
honestly
don't
know
so
enrique
might
might
tell
us
about
that,
but
snippets
is
not
as
straightforward
as
it
might
sound
technically.
A
A
So
we
will
see
how,
like
all
of
a
sudden,
we
have
a
playground
where
we
can
have
up
to
10
instances
of
both
editors.
At
the
same
time,
considering
all
10
files
are
marked
down,
and
then
we
will
be
able
to
measure
performance,
we
will
may
be
able
to
check
the
technical
requirements.
We
will
be
able
to
measure
all
sorts
of
things
so
that
that's,
even
though
this
might
not
reach
the
goal
of
replacement
for
static
site
or
like
it
won't
reach
the
point
of
replacing
the
static
citator
it
will.
A
B
One
is
obviously
delete
that,
like
using
this
experiment
to
deliver
value
immediately
and
provide
this,
we
see
week
8
or
for
markdown
in
one
of
the
applications
that
we
were
discussing
and
the
other
one
is
the
the
learning
part
that
chad
was
talking
about
like.
How
can
we
learn?
What
are
the
architectural
requirements
to
implement
this
layer?
That
is,
gonna
should
be
shared
across
all
of
the
applications.
B
Perhaps
a
way
in
which
we
can
start
is
by
like,
following
this
iterative
architecture
approach
that
chad
was
talking
about.
We
just
like
create
this
experiment
in
the
same
way
that
we
could
that
we
were
creating
proof
of
concepts
for
comparing
approaches
last
week
and
we
say:
hey,
let's,
let's
see
what
synchronizing
both
ethers
looks
like
in
the
single
violator.
B
B
We
can
reduce
the
learning
process
to
just
implementing
that
experiment
in
one
of
them
and
then
we
decide
based
on
that
learning
we
refactor
and
we
create
that
that
data
layer-
and
it's
probably
going
to
be
a
very
similar
requirement
to
what
you
will
see
in
the
web.
Ide
and,
as
you
say,
snippets
is
very
complex.
A
snippet.
The
the
difference
with
snippets
is
that
we
have
multiple
files
open.
At
the
same
time,
I
don't
know
how
you
are
handling
that
in
the
source.
Editor,
probably
that's.
B
You
are
like
handling
all
of
the
editor
instances
through
some
mechanisms
that
that
you
created
in
the
associated
api
right.
So
that's
gonna,
be
that's.
That
may
be
a
problem
because,
like
we
want
that
mechanism
as
well
detach
and
decouple
from
the
source
editor
if
we're
gonna,
have
multiple
editors
for
every
file
available.
So
maybe
we
don't.
We
don't
want
to
deal
with
that
right
now.
We
want
to
focus,
really
focus
and
reduce
the
scope
of
this
work
to
the
data.
Major
that
is
gonna
be
reusable
in
snippets,
but
it's
not
just
like
we're.
B
So
from
that
point
of
view,
I
think
that
the
scene,
the
the
simplest
path
here,
considering
that
we
can
instantiate
every
application
in
the
single
violator
and
create
and
use
the
view
version
of
the
source
editor
and
the
container
we
can
just
like
focus
on
experimenting
on
how
we
can
make
them
talk.
In
that
context,
you
just
use
all
of
that
knowledge
to
be
the
data
layer
solve
that
problem
and
then
focus
on
the
snippets.
A
D
I
respond
to
that
real
quick
so
like
if
the
single
file
editor.
The
reason
I
said
snippets
is
because
I
was
under
the
impression
there
was
maybe
of
equal
complexity,
a
single
file
editor,
but
also
because
it
was
less
used,
so
it
was
less
risk.
But
if
the
single
file
editor
is
much
simpler,
even
though
it's
more
used-
and
therefore
you
know-
maybe
less
risk
of
trying
to
do
too
much
at
once-
then
maybe
that's
a
better
choice
to
start
with.
A
There
is
like
what
we
are
discussing
so
far
inevitably
should
involve
product
no
matter
what
like,
we
have
to
understand
why
we
have
to
build
this.
What
for
and
and
humanity
has
a
as
point
like?
What
is
the
problem
we
are
trying
to
solve
here?
If,
if
it's,
because
that's
that's
a
very
good
point-
that
if
we
are
trying
to
replace
the
static
site
editor,
this
is
this
is
one
set
of
requirements.
A
If
we
try
to
say
okay,
we
just
deliver,
we
say
we
can
pick
capabilities
for
people
working
with
markdown
so
that
they
could
pick
whether
they
edit
as
busy
week
or
code.
This
is
another
set
of
rules
or
a
set
of
requirements
and
without
having
a
clear
understanding.
What
is
the,
what
is
the
end
goal,
or
at
least
what
are
the
goals
on
the
path
of
our
ultimate
goal?
B
B
A
A
D
I
just
want
to
verbalize
something
that
enrique
had
put
in
the
chat,
which
I
think
is
really
important
for
for
what
it's
worth
opening
these
types
of
dynamic
files
you
know,
embedded
erb
or
whatever
in
the
static
site.
Editor
is
currently
buggy
and
unreliable
so
like.
If
that
is
actually
going
to
be
a
requirement.
D
A
A
This
doesn't
mean
that
on
the
way
to
that
go
like
we
are
talking
really,
we
are
talking
about
source
to
content
switch
for
markdown
files,
and
if
we
can,
we
can
talk
about
supporting
dynamic
files
for
as
long
as
we
want,
but
if
we
fail
supporting
the
very
basic
operation
of
providing
users
who
are
working
with
simple
marginal
files,
if
we,
if
we
don't
support
that
case,
we
won't
reach
our
end
goal.
So
we
start
with
just
supporting
the
basic
markdown
editing
as
the
as
the
starting
point.
A
This
again
doing,
this
supporting
the
switch
between
code
and
content
for
simple
markdown
files
will
again
put
us
one
step
closer
to
our
end
goal,
so
we
we
can
approach
this
from.
Let's,
let's
say
we
have
two
ways
for
now.
We
have
static,
we
have
a
single
file
editor
and
we
have
snippets
so
with
snippets.
A
A
And
I
think
snippets
this
is
one
more
interesting
one.
One
interesting
point
to
add
is
that
in
snippets
we
will
be
practicing
the
the
best
practices
technically,
because
snippets
are
on
graphql
and
ultimately
we
have
to
move
our
applications
to
graphql,
and
this
will
be
the
question
when
we
might,
when
we
refactor
a
single
file
editor,
we
will
inevitably
might
refactor
it
with
graphql
in
mind.
So
doing
this
in
snippets
will
give
us
this
experience
and
this
basis,
and
we
will
know
how
to
connect
things
to
to
graphql.
A
There
are
issues
with
with
snippets,
as
we
said,
we
do
not
know
how
it
will
scale
for
multi-file
snippets,
because
we
just
we
just
don't
know
we
we
haven't
tried
this.
This
is
first
point.
The
second
point
is
observability.
It
won't
be
observed
by
enough
users
to
give
us
any
sensible
feedback
or
even
provide
us
with
any
significant
statistical
data
for
us
to
make
this
decision.
Okay,
like
do
people
need
this
feature.
Do
people
use
this
feature
so
snippet?
A
I
would,
I
would
think
about,
starting
with
snippets
as
sort
of
a
sandbox
approach,
where
we,
where
the
cost
of
failure
is
not
that
high,
because,
because
of
the
feature
itself
being
not
widely
used,
another
solution
is
to
start
with
a
single
file.
Editor
single
file
editor.
What
are
the
pros
of
starting
there?
We
will
deliver
value,
and
I,
by
value
I
mean
anything,
we
do
to
provide
with
weak
capabilities
for
editing.
A
A
We
provide
this
in
the
in
the
application
that
is
highly
visible,
so
we
can
start
gathering
really
significant
statistical
data
and
now,
when
users
switch
to
whether
users
switch
to
wiziwik,
whether
they
switch
back
to
code,
what
they're
doing
technically,
whatever
we
want
to
to
to
measure
in
in
this
application,
so
static
single
file
later,
will
provide
us
with
much
better,
statistically
reliable
data.
However,
there
are
technical
issues
with
with
starting
with
static
with
single
file.
A
A
It
does
match
the
idea
of
the
toolbar
mvc
for
static
files
for
source
editor.
However,
we're
not
there
yet
it's
not.
We
cannot
just
take
and
migrate
the
toolbar
right
away.
Third
point
is:
we
have
to
actually
introduce
the
view
application
there?
This
is,
this
is
pretty
minor
if
we
all
have
all
the
view
components
in
place,
initializing
view
application
is
not
a
big
thing.
A
However,
the
biggest
thing
is
that
if
we
start
with
single
file
letter,
we
do
have
to
have
the
shared
data
layer,
because
in
this
case
it
doesn't
really
make
sense
to
to
just
well
okay,
I'm
I'm
pulling
this
one
back.
We
can
start
without
the
shared
data
layer.
We
just
connect
both
editors
straight
to
api,
and
that's
that's
how
we
can
roll
so
okay,
we
can
do
that.
A
We
will
have
to
introduce
the
shared
data
layer
on
the
second
step
when
we
implement
the
same
feature
for
any
other
application.
Should
it
be
snippets
should
it
be
web
id.
We
will
have
to
get
back
and
revisit
this
idea
of
shared
data
layer,
but
at
the
first
ration
we
don't
technically
need
that
we
can
go
straight
to
to
api
and
be
done
with
that.
A
I
still
like
the
idea
of
snippets,
because,
because
it's
just
in
single
file
later
there
are
too
many
unknowns
like
how
fast
will
be.
We
will
update
the
view
compound
and
how
fast
we
will
migrate,
the
markdown,
the
using
the
toolbar
for
yeah.
We
still
have
to
connect
this
toolbar
to
to
the
source
editor.
A
So
whatever
we
do
like,
we
can
reuse
any
any
any
view
component.
It
still
has
to
talk
to
source
editor
right.
So
and
that's
that's
the
that's
the
thing
so
at
the
moment,
source
editor
in
this
single
file
letter
is
connected
to
all
those
bars
on
the
toolbar
or
to
all
those
buttons
on
the
toolbar
through
just
a
simple
javascript.
A
A
D
So
I
just
had
another
thought,
so
I
think
one
of
the
reasons
I'm
confused
about
the
static
site,
editor
like
being
the
dynamic
files
needed
to
be
replaced,
is
because
eric
just
prioritized
the
issue
for
me
to
implement
the
redirects
from
the
static
site
editor
to
the
web.
Ide
he's
already
committed
the
changes
to
remove
it
from
the
docs
and
everything
so
like
that's
why?
D
A
D
C
A
A
Yes,
but
from
from
from
the
implementation
point
of
view,
what
do
you
think
about
what
solution
do
you
think
would
make
more
like?
Let's
assume
again,
the
ultimate
goal
is
replacement
for
the
static
site.
Editor,
that's
the
ultimate
goal.
We
will
get
there.
Eventually,
we
won't
support
the
dynamic
pages
right
now.
B
B
A
This
is
this,
is
both
points
are
very
good
ones
about.
I
will
start
with
the
second
one
about
the
estimations
first
of
all,
as
you
may,
as
you
have
mentioned,
we
are
in
the
middle
of
one
spike.
The
spike
comes
in
addition
to
the
deliverables
and
to
our
like
technical
assigned
work
asking
people
to
respite
in
yet
another
spike
in
this
milestone
is
a
bit
too
to
like
stretching
the
things
a
bit.
This
is
the
first
thing.
The
second
one
is.
A
How,
in
your
opinion,
a
new
spike
would
allow
us
to
estimate
the
things
I.
I
really
believe
that
spike
in
these
regards
would
mean
we
just
jump
straight
into
the
implementation,
and
we
will
know
how
we'll
know
the
estimations
when
we
are
done
with
the
work
so
like
retrospectively.
Estimating
the
work
isn't
is
not
really
the
way
to
estimate
the
things
here,
especially
considering
that
spikes
like
in
the
in
this
particular
case
spike
would
go
in
parallel
with
the
with
the
main
work.
A
So
this
is
something
for
david
to
decide
how
to
how
to
manage
this.
It's
not
me
who's,
who's,
gonna,
sort
of
say
what
is
right
or
what
is
wrong
here.
But
that's
that's
my
personal
opinion,
but
when
it
comes
to
the
quality
and
you've
mentioned
a
really
really
good
thing,
that
makes
me
even
more
worrisome
about
single
file
later
unless
we
have
solved
the
problem
of
preserved,
unchanged
markdown.
A
A
A
A
B
A
I
start
editing
this
I
switch
to
wizzyweek
editor
and
then
all
of
a
sudden
in
my
when
I,
when
I'm
done
with
edits,
I
check
the
change
log
nice
or,
like
the
diff
of
my
last
command.
I
see
all
sorts
of
edits
that
I
haven't
made,
so
it's
not
about
static
site
data
at
the
moment.
It's
just
about
regular
markdown
editing.
A
D
D
C
D
A
Yeah,
that's
that
again.
That
puts
us
back
that
we
have
to
clear
to
have
the
clear
answer
from
the
product,
and
this
just
highlights
like
to
to
to
mention
once
again
the
thing
that
yes,
the
ultimate
goal
might
might
or
is
to
replace
the
static
site
editor.
But
if,
on
the
way
there,
we
will
screw
up
the
basic
markdown
editing
with
with
the,
as
I
said,
with
the
example
that
I
that
I
talked
about
when
we,
when
people
just
edit
a
simple
markdown
file
and
they
get
unwanted
changes.
A
A
E
A
Great
thanks
david,
so
yeah,
so
we
I
will
post
the
the
update
the
from
the
technical
side
of
things
in
in
slack,
so
that
everybody
can
read
through
and
comment
on
that.
But
the
main
thing
we
we
have
to
know
is
where
what
is
the?
What
is
the
purpose
of
this
move
like
what
is
the
end
goal,
and
where
can
this
would
help
as
well?
Where
can
we
cut
the
corners
like
what
product
expects
us
to
deliver
100,
and
where
can
we
say?
A
A
Because,
like
saying
that,
we
have
to
provide
all
like
big
this
big
picture
of
the
license
for
the
static
citator.
That's
that's
not
gonna
happen
right
now.
So,
okay,
thank
you
very
much
for
for
this
meeting.
If,
if
we
have
nothing
to
to
add
here,
I
think
we
have
to
wrap
up
okay,
cool.
Thank
you
very
much
for
jumping
in
this
call.
That
was
super
productive.
I
think,
and
I'm
really
looking
forward
to
hear
what
eric
thinks
about
this.