►
From YouTube: Introduction to the WYSIWYG Editor
Description
In this video, the Editor team talks about the current status of the WYSIWYG editor as used in the Static Site Editor product. They discuss the challenges involved in implementing a WYSIWYG editing experience that fits all usage scenarios in GitLab.
B
A
Only
talking
about
the
that
we
see
with
editor
itself
we're
actually
sharing
the
story
of
the
study
site,
editor
team.
Why
we
implemented,
we
see
we
cater
in
the
product
and
what
challenges
we've
faced
so
far
over
time
and
what
we
are
trying
to
solve
with
this
new
re-architecture
proposal.
I
think
this
is
the
the
best
way
of
developing
empathy
with
the
problem
that
the
problems
that
we
are
trying
to
solve.
A
A
A
A
A
Is
to
first
to
present
the
markdown,
as
the
user
would
see
it
in
the
webpage
and
allowing
to
to
edit
it
in
that
we
see
wiki
style.
What
you
see
is
what
you
get
so
this
is
a
like.
We
see
locator
all
this
blog
here
and
we
are
using
a
a
library
where
I
could
say
that
a
library
is
the
best
the
best
way
of
calling
it
called
toast
ui.
A
The
idea
is
that
you
can
make
any
any
change,
let's
say,
removing
a
dot.
The
every
page
in
a
static
site
generator
has
metadata
to
specify
the
title
of
the
page
or
the
layout,
and
you
can
go
here
and
edit
that
that
metadata,
that's
usually
specified
in
the
source
file
as
a
front
matter,
and
then
you
can
submit
the
changes
from
right
from
here
like
creating
the
the
site.
A
So
what
is
what
what
source
ui
provides
for
us?
So,
let's
throw
it
a
bit.
We
have
two
tabs
here.
The
first
one
is
say:
we
see
weak
mode.
The
second
is
the
second
one
is
a
is
a
markdown
mode.
Basically,
the
first
step
is
the
actual
visibility
that
is
rendering
the
markdown
and
allowing
the
user
to
edit
the
the
render
version
of
the
source,
and
then
the
second
tab
is
a
is
the
raw
markdown
source.
A
A
A
In
the
case
of
that,
we
see
we
cater.
There
is
a
more
complex
process
going
on
the
first
we
render
the
source
file
in
the
case
of
of
markdown.
The
initial
rendering
target
is
html.
Perhaps
there
is
other
targets,
and
then
there
is
a
nato
that
displays
that
render
content
and
allows
the
user
to
edit
it
and
after
that,
after
the
user
has
made
all
of
the
of
the
changes
that
they
want.
A
A
It
is
like
they
are
very,
very
equivalent,
so
the
process
of
editing
content
in
the
in
the
markdown
mode
in
total
is
very
simple.
There
is
no
transformation,
it
is
just
a
a
cultivator,
so
the
other
part
is
displaying.
Is
a
we
see
with
mode
and
toss
ui
uses
another
component
that
is
called
squire
by
the
way
here.
My
speaker
notes.
If
you
open
the
the
presentation,
you
will
see
that
I
have
links
for
everything
that
all
of
the
components
that
I'm
making
preferences
here.
D
A
D
A
B
Of
makes
sense
that
it
doesn't
work,
because
the
use
case
is
different,
like
because
this
is
for
a
specific
project.
That's
going
to
probably
be
deployed
to
another
site
or
something
we're
not
leaving
comments
that
would
even
live
in
the
gitlab
instance.
This
is
probably
going
to
live
outside
the
gitlab
instance.
A
That
is
completely
right,
so
there
are
many
flavors
of
markdown
and
there
are
many
scenarios
where
we
went
where
we
use
it.
For
example,
in
the
case
of
you
mentioned
paul,
tosia
wasn't
created
to
be
used
within
the
the
issue,
a
description
editor
or
to
be
embedded
in
in
the
comment
section,
so
they
don't
need
to
implement
support
for
any
of
those
features
in
the
same
way.
In
the
static
site
editor,
there
are
many.
B
And
but
also
to
add
another
point
and
to
also
what
fraud
was
saying,
I
think
we
have
an
issue
too
for
this,
but
users
have
wanted
whizzy
wig
comments,
editing,
wysiwyg
description,
editing
and
gitlab
for
a
while
too.
So
it
is
good
to
know
that
what's
happening
here
will
be
really
hard
to
reuse.
For
that
use
case,
that's
interesting.
A
A
A
A
So,
for
example,
in
the
case
of
a
static
citator,
we
have
three
use
cases
that
we
have
to
support
for
supporting
18
pages
for
the
middleman
statistic
generator
in
the
first
place.
A
common
case
in
the
handbook
is
that
we
have
to
render
partials
that
are
embedded
in
the
in
the
in
the
handbook
pages.
For
example,
one
common
a
common
case
is
rendering
the
the
the
team
jam
or
file
that
is
like
a
database
for
all
the
people
working
in
kit
lab.
A
A
A
For
example,
one
of
the
problems
of
those
ui
is
that
it
is
translating
html
back
to
markdown
and
that's
a
very
buggy
process,
because
html
is
a
very
flexible
way
of
structuring
content
and
there
are
many
use
cases
that
are
causing
problems.
So
that's
those
are
basically
the
reasons
for
for
that.
You
know
that
we
decided
to
start
evaluating
and
investigating
other
options
by
the
way
there
is
a
well
there
are.
I
there
is
a
in
the
presentation.
A
A
A
A
A
Because
we
actually
created
a
requirements
table
that
has
a
very
long
evaluation
criteria.
That
is
not
limited
to
right
to
the
points
that
I
that
I
made,
but
those
are
probably
the
most
important
ones.
So
if
you
want
to
actually
read
a
little
bit
more
about
it
about
the
ux
technical,
the
ux
requirements
and
the
technical
ones,
I
recommend
you
to
go
to
this
issue
and
read
about
it.
A
So,
let's
jump
here,
okay,
so
we
have
a
good
evolution
criteria,
criteria
table
and
after
a
lot
of
investigation,
we
ended
up
about
the
different.
We
see
weak
platforms
that
are
available
out
there.
We
ended
up
with
two
options:
the
first
one
is
a
ck805
mark
as
a
markdown
parser
and
the
other
one
is
postmeter
and
picked
up
plus
mark
down
it
as
a
alternative,
markdown
parser.
A
Many
aspects
of
alternatives:
again
there
are
some
links
in
there
where
you
can
see
the
results
of
that
of
that
investigation.
But
you
know,
after
a
while,
we
determined
that
prosmeter
prostipta,
a
marked
down
at
not
march,
is
the
best
option
and
why?
Well,
first,
the
alternative
has
a
smaller
bundle
size
footprint
than
ck8r.
A
It
is
easier
to
integrate
with
pyjamas,
because
prospero
and
tiptop
does
not
provide
a
visual
user
interface.
They
provide
a
series
of
renderers
components
that
we
have
to
provide
the
the
styles
and
that
also
influence
the
bundle
size
because,
instead
of
implement
of
having
to
include
a
lot
more
css,
a
lot
more
javascript
we're
just
going
to
use
gitlab,
ui
components
and
utility
classes
to
define
those
visual
components.
A
So,
first,
first
of
all,
we
don't
want
to
create
a
nato
that
fits
all
of
all
of
the
use
cases
in
gitlab.
First,
when
we
were
thinking
about
for
implementing
the
reservator,
we
were
limiting
the
scope
of
to
the
to
the
requirements
of
the
of
the
study
site
theater,
but
actually,
as
paul
mentioned
before,
this
is
a
long
requested
picture.
Having
a
we
see
week,
18
experience
across
fixtures
in
youth
lab
and
in
fact
there
are
people
that
have
tried
and
attempted
to
do
that
before.
A
This
toolkit
will
have
a
basic
support
for
common
mark
and
gfm.
That's
the
the
common
requirement,
the
common
use
case
across
all
of
the
editors
in
github
I'll,
often
support
common
mark.
That
is
a
specification
that
tries
to
well
to
be
like
that
they
found
that
they
follow
the
standard
specification
for
markdown
and
all
of
them
support
gfm.
A
Actually,
this
is
not
the
lab
for
marek
martin.
This
is
github
for
married
martin
features
like
tables
and
strikethrough.
All
of
them
are
supported
by
by
editors
in
gitlab,
so
we
want
to
provide
all
of
that
by
default
and
then
it
has
to
be
fully
extensible
and
modular.
So
I'm
gonna,
let's
expand
a
little
bit
more
on.
B
A
We
have
a
parser
that
allows
rendering
the
markdown
into
a
into
a
format
that
transmitter
prosmeter
understands
and
then,
after
making
some
edits
in
the
document
we
we
convert,
but
the
the
pros
mirror
document
to
a
to
a
marginal
source.
So
what
is
the
difference
with
toast
ui?
So
each
of
these
components
we
will
be
able
to
extend
them.
A
So
one
is
like
when
you
are
using
the
data
toolkit
in
day
in
the
weekend,
you
will
have
the
basics
of
supporting
the
the
the
common
market
functionality,
but
if
you
want
to,
if
you
want
to
implement
these
features,
you
have
to
implement
them
within
the
wiki.
So
we
have
that
that
separation
of
concerns
and
and
each
picture
is
implementing
support
for
for
what
exactly
they
they
need
so
yeah.
That's
that's,
basically,
the
the
architecture.
A
B
D
B
B
B
C
C
You
pass
it
to
the
middle
man
in
this
particular
case
to
bronze,
mirror
it
converts
it
to
the
html
and
you
dump
it
as
full
chunk
to
the
html
or
the
other
way
around.
You
take
the
html
dump
it
fully
to
pros
mirror
and
it
spits
out
the
whole
markdown
document.
This
is
one
approach.
Another
approach
is
more
like
sort
of
like
differing
the
things,
so
you
have
like
reactivity
in
any
like
modern
framework
right,
so
you
do
not
update
the
full
document,
but
you
update
just
just
a
tiny
bit
of
the
document.
C
B
B
A
So
we,
when
we
are
loading,
the
the
magnum
page
in
the
in
the
in
data
we
want
to,
since
this
is
a
reciprocating
experience,
we
want
to
display
the
entire
content
converted.
So
how?
If
you
see
it
from
that
point
of
view,
we
have
to
convert
the
entire
thing.
So
what
would
be
an
alternative
to
that?
If
that's
a
that's
a
user
requirement.
B
C
It
was
out,
I
think,
the
the
the
the
answer
to
this
question.
Paul
is
pretty
like
pretty
simple
in
terms
of
the
burden
of
deciding
how
to
update
the
things
still
on
the
middleman
or
like
pros
mirror
in
this
particular
case.
It's
not
something
we
control
from
the
from
the
editor's
site.
This
is
the
way
middleman
processes
this
for
us,
and
then
it's
just
a
matter
of
how
we
update
this.
Obviously,
but
if
it
speeds
the
whole
document
to
us,
it
doesn't
really
matter.
A
So
they
are
not.
We
are
not
loading
the
render
content
from
middleman
the
the
step
of
loading,
a
markdown
source
and
displaying
it
as
a
with
in
the
whizzy
week
that
conversion
from
from
markdown
to
html,
that
is
not
html.
Actually
transmitter
provides
a
a
middle
layer,
a
document
model
that
is
a
a
better
way
of
structuring
content
for
anything.
You
know
we
see
with
design,
but
that's
a
that's
another
concern.
We
are
not
loading
the
defender
content
from
that
middleman
generates.
A
A
B
B
B
If
you
look
at
vs
code,
when
you
have
like
the
markdown
editor
and
the
preview
side,
there's
actually
traceability
between
the
line
generated
and
the
line
that
generated
it,
and
so
that's-
and
I
don't
know
what
pros
me
or
does
what
any
of
this
does,
but
that
would
be
really
sweet
if
we
had
some
sort
of
editing
capability
where
we
could,
whatever
is
rendered,
keeps
that
traceability
of
what
was
the
line
that
rendered
this.
So
we
don't
have
to
know
about
anything
else
above
it
or
below
it.
B
That
might
we
might
not
know
about
yet
and
and
that's
the
concern
is
if
we
have
to
reimplement
gf
g,
the
get
lab,
flavor,
markdown
or
any
other
kind
of
flavor
markdown.
We
don't
want
to
re-implement
those
it'd
be
nice
to
just
if
it's
metadata
and
we
don't
know
how
to
present
it.
We
just
don't
present
it
and
we
keep
it
intact.
One
way
of
doing
that
is
this
in
place.
A
A
B
A
B
And
I
think
for
presentational
stuff
we
we
will,
but
if
something's
not
presentable
the
less,
we
have
to
know
the
better
and
that's
and
then
so
I
think,
and
what's
nice
about.
That
too,
is.
If
we
don't
know
it,
we
get
some
resiliency
and
rather
than
just
freaking
out
and
blowing
up
and
erasing
things
we
just
don't
present
it
so
you're
right
yeah.
If
we're
gonna
present
something
we
need
to
know
how
it's
presented,
but
by
default.
B
E
Paul
what
you're
saying
is
like
if
somebody
like
you
used
to
with
you
without
your
and
they
like,
add
a
gitlab
thing,
where
they
add
paul,
for
example,
as
a
reference
that
we
just
would
in
even
in
the
kind
of
rendered
version
just
render
it
like
at
paul
and
not
try
to
kind
of
like
pull
in
any
kind
of
components.
But
even
if
it's
like
rendered
them
through
middleman,
we
might
be
able
like
to
to
show
it.
B
B
One
solution
to
this
is,
rather
than
taking
a
whole
document,
transforming
the
whole
document,
transforming
the
whole
document.
Is
we
whatever
changed?
We
just
know
how
to
write
it
back
to
that
bit
and
that's
like
what
vs
and
and
dennis
linked
this
issue
like
this
is
how
vps
code
solves
like
scrolling
between
the
preview
of
markdown
and
the
editing
version
of
markdown
is
there's
that
traceability?
A
B
Yeah
and
there
might-
and
there
might
be
other
approaches
to
it-
I
think
that's,
I
think
the
main
developer,
experience
or
use
case
we
want
to
take
away
from
it
is
to
be
really
nice.
If,
if
we
didn't,
if
something
we
didn't
know
about,
we
didn't
blow
up
and
we
were
able
to
preserve,
even
if
we
just
kept
going
back
and
forth
like
that's,
that's
the
bit
that
I'd
be
really
concerned
about,
because
keeping
track
and
maintaining
all
the
different
syntaxes
is
gonna
would
definitely
be
a
headache
of
because
I
can
see
that
growing.
A
Let's
say
again
in
the
case
of
a
diagram,
maybe
we
can
send
a
request
to
render
that
proportion
back
to
a
server
and
just
display
it,
and
if
we
want
to
have
an
advanced
use
case
where
we
can
edit
that,
then
we
have
to
actually
implement
the
support
for
it.
So
it's
like
having
an
mpp
where
we
delegate
rendering
to
a
third
party
and
then
once
we
want
to
provide
a
more
advanced
experience.
We
have
to
implement
all
of
the
18
tools
in
the
clients.
B
Yeah
it
would,
it
would
be
interesting
to
see
if
we
could
solve
the
use
case
of
a
markdown
with
html
comments
in
it
and
if
we
can
preserve
those
comments
like
that,
that's
the
kind
of
thing
I
think
it
would
be
would
be
interesting
to
see
if
we
can
preserve
that.
Thanks
for
letting
me
derail
the
conversation
a
little
bit,
but
I
I
think
it's
definitely
a
huge
win.
E
A
Follow
so
is
there
any
other
comment
or
or
question?
I,
I
really
recommend
to
explore
the
the
prospector
guide.
There
is
a.
There
are
some
links
like
the
the
concept
that
I
implemented,
and
I
think
that
is
very
good
to
familiarize
with
the
with
the
problem
that
we
are
solving
that
way.
We
can
see
how
how
it
fits.
A
I
know
that,
for
example,
we
have
concerns
about
having
to
maintain
activators,
probably
a
good
way
of
or
starting
a
conversation
of
that
is
getting
familiarized
with
the
with
the
use
case
of
the
and
seeing
how
we
can.
We
are
solving
it
and
perhaps
trying
to
solve
a
similar
thing
with
the
with
monitor,
perhaps
or
or
something
like
that.
I
think
it's
a
way
of
collecting
data
that
we
don't
have
right
now
and
it's
good
to
make
a
decision.
C
C
Where
does
this
come
from
and
what
problems
this
is
supposed
to
solve,
however,
not
being
accused
in
promoting
the
things
we
already
have
so
technically,
like
jokes
aside,
I
I
clearly
see
that
the
only
thing
that
we
don't
have
at
the
moment
in
the
editor
is
the
wizard
week
part.
That's
the
only
thing
that
we
don't
have
right.
We
have
the
markdown
editor.
We
have
the
markdown
editor
that
works.
C
B
C
B
C
Anything
so,
let's
call
it
monaco,
we
use
monaco
for
editing
for
anything
marked
down,
and
since
the
extensibility
is
in
the
editor,
you've
you've
been
talking
about
now.
Editor
light
has
has
the
same
approach
right,
you've
been
to
the
to
the
deep
dive
of
editor
light,
and
you
know
that
it's
purely
extensibility,
that
that
is
the
selling
point
of
the
fairy
light
this.
This
tells
me
that
the
wizardry
part
can
easily
be
the
extension
of
the
existing
editor,
where
we
just
do
the
things
I've.
C
We
like
I've,
pushed
the
draft
of
the
emergency
quest
where
we
have
the
live
preview
of
markdown.
At
the
moment,
I
don't
see
any
at
the
moment.
The
live
preview
goes
through
this
server.
This
is
this
is
horrible,
because
this
is
how
we
do
the
markdown
preview
at
the
moment
right,
but
this
this
doesn't
mean
that
we
cannot
use
market
and
pros
mirror
markdown
to
serve
as
the
middleman
and
do
the
things
on
the
client
without
sending
things
back
and
forth
to
the
client.
C
This
only
tells
me
that,
yes,
we
can
use
the
core
of
the
existing
editor
here,
introduce
the
missing
parts
for
cl.
For
more
client-side
oriented
manipulations,
like
market
and
pros,
mirror
and
then
build
this
wysiwy
on
top
of
the
existing
editor.
This
will
this.
This
architecture
would
will
solve
us
a
lot
of
headache,
because
we
will
still
have
one
source
of
truth
to
to
we'll
have
one
editor
to
maintain.
C
We'll
have
one
editor
with
with
the
box
that
we
know
where,
because
like
up
until
now,
the
editor
group
was
up
up
until
we
got
completely
got
three
of
a's
when
anybody
complained
that
something
doesn't
work,
everything
related
in
the
product.
The
first
question:
we
were
asking
what
editor
it
is
like.
Where
do
you
editing
the
things,
because
we
had
three
editors,
we
had
a's,
we
had
a
now,
it's
a
bit
better,
like
at
least
we
should
like.
C
Definitely
if
we
let's
say
if
we
take
the
if
we
can
take
market,
if
we
can
take
pros,
mirror
mark
down,
add
them
as
the
extensions
again
as
the
extensions,
like
speaking
of
modular
modularity
right
as
extensions
to
edit
the
light
and
then
build
the
wiz
week
on
top
of
that
as
well.
So
what
is
the
benefit
of
bringing
one
one
more
editor.
C
C
The
only
part
that
is
missing
is
when
you
click
the
mark
down
button.
That's
the
part
that
has
to
be
built,
but
since
the
editing
light
is
extensible
and
we
can
build
the
extensions
like
live
preview
that
I
can
link
to
to
the
demo
a
live
preview
that
I
built
for
data
light.
It
is
an
extension
and
it
is
being
loaded
only
when
you're
on
the
markdown
file,
for
example.
C
B
B
Like
so
using
editor
light
as
the
entry
point
yeah,
but
because
knowing
a
little
bit
about
the
way
that
web
wizzy
wigs
work
like
with
content
editable
and
like
it's,
it's
a
it's,
a
wild
implementation.
To
get
that
that
feel,
I
would
be
really
surprised
if
monaco,
which
has
a
very
different
approach
to
editing,
was
able
to
do
it.
But
maybe
they
can't.
I
don't
know.
C
C
C
C
C
Okay,
like
in
this
particular
case,
we
will
have
two
middlemen,
like
one
mark
market,
that
converts
from
mark
down
to
html.
If
I
don't
confuse
the
things
and
the
pros
mirror,
markdown
like
and
not
to
the
html,
but
to
this
like
pros,
mirror
thing
right
and
then
pros
pros
it
markdown
converts
from
this
pros,
whatever
back
to
markdown,
so
we
okay,
it
is
one
way,
so
we.
C
E
C
C
We
are
not
sort
of
coupled
to
this
thing
the
same
thing
about
the
editor.
We
can
throw
it
in
the
future,
but
we
much
better.
No,
don't
do
that.
We
can.
We
can
do
the
same
thing
with
any
extension.
So
that's
that's
the
beauty
of
extensibility,
but
the
the
middle
man
that
is
not
the
product
or
technology.
This
is
just
the
paradigm.
C
B
B
Different
right,
you're,
not
you're,
not
talking
about
the
specific
technologies
that
enrique
has
researched
to
figure
out.
This
is
the
best
way
for
us
to
implement.
This
is
the
best
way
for
us
to
implement.
Wysiwyg
editing
is
using
pros,
mirror
whatever
what
what
I'm
kind
of
getting
from
you
is
is
that
could
live
under
editor
light
because
utter
light
is
very
modular,
and
we
have
just
one
entry
point
to
here's.
Our
editor
and.
C
C
B
B
A
Yeah,
I
think
that's
a
it's
a
great
idea
to
have
a
single
entry
point,
and
I
think
that
that
can
simplify
the
api.
What
I
don't
understand,
let's
say
that
we
load
a
markdown
file
into
into
monaco
and
we
display
that
source
file
in
our
render
version.
That's
exactly
what
how
we
simulator
is
right.
We
just
take
the
spread
or
something,
and
then
we
can
edit
that
render
stuff
and
that
render
and
that
18
that
18,
that
render
render
content
happens
in
a
contain
a
table
in
the
browser.
A
C
That's
a
wonderful
question-
and
this
is
this-
is
reason
this
resonates
with
what
paul
was
asking
so
again
we,
the
beauty,
is
that
we
do
not
need
to
implement
anything
into
edit
light.
The
content
editable
can
be
a
completely
separate
component.
We
and
we
can
lay
it
lay
the
editor,
nothing
component,
but
just
completely
separate
each
element,
so
everyone
else
believe
the
element.
The
main
thing
is
that
we
set
up
the
communication
between
this.
So,
frankly,
what
it
allows
us
is.
It
notifies
us
about
any
changes
in
the
markdown.
C
So
whenever
you
edit
the
markdown
it
notifies
any
subscriber
so
content,
we
can
wrap
the
content
editable
into
the
es6
module
or
extension.
That's
that's
what
it's
called
in
the
edit
line,
so
we
wrap
it
in
the
extension
that
listens
to
those
changes
in
the
editor
and
trans
com
communicates
the
changes
to
this
quantity.
Edible
the
same
way
when
content
editable
gets
updated.
We
change
the
text
with
with
wysiwyg
part
it
can.
A
A
A
A
I
implemented
a
proof
of
concept
that
is
very
simple
that
uses
that
reflects
all
of
the
architecture
that
I
am
proposing.
Perhaps
you
can
find
a
way
of
taking
that
proof
of
concept
and
embedding
that
within
either
light
and
see
if
it
can
work
as
an
extension.
So
what
do
you
think
dennis?
If
you
could
you
help
with
that
like
we
could
go,
we
can
work
together
and
see
if
we
can
take
out
of
that
process
and
put
it
in.
C
A
E
Cool,
so
one
thing
I
want
to
keep
everybody
in
mind.
We
need
to
be
also
like
pretty
swift,
with
everything
that
we're
building
right
now.
So,
like
there's,
currently
a
piece
working
and
if
we
end
up
saying
oh
like
we
could
potentially
achieve
it
in
a
july,
but
it's
kind
of
taking
us
like
probably
six
months
to
get
like
to
on
par
what
we
have
right
now,
then
we
need
to
strategically
make
the
right
decisions
right.
E
E
We
need
to
look
herself
the
use
cases
where
we
want
to
build
it
right
now,
in
this
case
like
if
we
can
implement
the
poc
and
approve
what
we
have
right
now
like
as
a
big
kind
of
drawback
for
our
users,
that
kind
of
probably
makes
sense
to
kind
of
at
least
take
this
step.
If
it's
kind
of
useful
and
then
what
is
the
next
step,
we
kind
of
say,
okay,
how
can
we
like
merge
it?
E
I
think
it's
important
to
figure
out
what
are
the
actual
wysiwyg
aspects
of
the
current
technical
solution
that
we
could
either
kind
of
reuse
for
a
kind
of,
like
extension,
for
it
light.
So
we
I
don't
want
us
to
end
up
in
a
solution
or
in
a
position,
so
we
have
to
reinvent
a
lot
of
things
at
once,
because
that
will
kind
of
throw
us
back
right.
E
But
that
means
I
will
trust
like
you,
denise
and
enrique
and
paul
feel
free
to
join
or
everybody
who
wants
to
join
us
so
to
meet
with
the
poc
kind
of
look
at
it
in
more
detail
to
have
like
a
really
solid
understanding
that
we
kind
of
understand
the
moving
parts
there
and
then
we
can
make
the
next
judgment
calls
and
define.
The
next
steps
sounds
good
with
everyone
absolutely
cool,
then
thank
you
enrique
for
the
enlightening
and
kind
of
like
presenting
for
everything
that
you
did.
That's
super
exciting
and
yeah.