►
Description
A sync up covering our:
- 13.4 release plan for enabling front matter editing in WYSIWYG mode of the Static Site Editor
- 13.5 iteration plan for improving front matter editing (metadata, custom controls, etc.)
A
A
Everyone,
this
is
derek
chad
and
enrique
with
the
static
side,
editor
team,
it's
monday
august
24th.
I
believe-
and
we're
going
to
be
just
doing
a
quick
sync
on
a
planning
dock
for
the
front.
Editing
front
matter
feature
within
the
static
site,
editor.
So
that's
what
this
is
about.
We
might
have
some
other
people
join
as
well,
but
I
know
a
few
aren't
going
to
be
able
to
make
it
so
we'll
just
kind
of
jump
right
in
so
at
a
high
level.
A
Kind
of
the
goal
of
this
is
twofold
or
basically
single
fold.
I
guess
the
goal
is
to
be
able
to
edit
front
matter
not
just
in
raw
markdown
but
in
actual
dedicated
controls
in
wysiwyg
mode.
So
again,
the
kind
of
the
overarching
goal
is
to
since
we're
leaning
more
towards
whizzing
wysiwyg
mode,
as
opposed
to
markdown
mode
being
able
to
edit
what
the
front
matter
settings
actually
are.
A
A
B
I
I
made
that
question.
I
asked
a
question
in
the
the
first
point
of
the
madison
goals,
because
I
I
don't
know
what
is
the
the
ux
decision
towards
that?
Also,
I
asked
a
follow-up
question.
That
is
what
would
be
the
pay
influence
on
the
technical
decisions
of
not
showing
the
role
from
matter
in
the
markdown
mode.
B
B
A
Yeah,
I'm
with
you
on
that,
so
at
a
high
level.
I
think
I'll
just
make
the
call
and
say
we'll
stick
with
that,
because
if,
if
we
are
going
to
have
both
modes
raw
should
be
everything
there's
no
real
reason
that
I
see
at
the
moment
and
again.
If
we
get
contributions
from
others
that
it
does
make
sense
to
somehow
make
raw
also
exclude
front
matter,
then
we
can
obviously
entertain
that
idea,
but
yeah.
A
I
think
we
should
have
kind
of
an
all
or
nothing
mode
which
is
raw,
and
then
we
have
kind
of
the
the
core
goal
of
the
whole
editor
is
to
have
kind
of
a
nice
first-hand
controls
type
of
experience
right.
So
so
with
that,
I
think
I'll
I'll
move
past
that
one
and
talk
about
the
second
piece,
which
is
the.
A
I
agree,
and
one
of
the
comments
I
had
related
to
this
too
right
is,
for
example,
even
in
iteration
our
first
hand,
controls
could
be
lacking
and
then
now,
all
of
a
sudden,
you
can't
even
edit
anymore
and
you're
completely
removed
from
it.
Another
comment,
I'll
add
to
that
chat,
is
yeah
again
longer
vision.
If
we're,
if
it's
so
good,
that
we
can
remove
raw
raw,
would
then
be
web
ide
or
another.
You
know
another
avenue,
it
wouldn't
be
the
static
site,
editor's
responsibility
to
edit
raw.
A
B
A
A
But
that's
a
great
that's
a
great
question.
I
mean
the
kind
of
the
the
simple
solution
is
that
we
don't
have
validation
just
like
anyone
can
edit
a
raw
file.
There's
nothing.
You
know,
I
don't
know
that
might
be
the
easier
solution,
but
longer
term.
That
would
be
great
to
have
some
validation
for
sure,
especially
when
we,
which
is
further
down
here
in
the
talk
about
when
we
actually
have
a
configuration,
for
example,
that's
something
we
would
actually
be
able
to
do.
Some
of
that
validation
against
this
actually.
B
Yeah-
and
I
noticed
in
the
same
mockups
that
we
are
planning
to
to
provide
some
custom
form
controls
like
instead
of
having
an
open
text
field,
it
is
a
drop
down
with
some
available
options
or
a
toggle
that
lets
you
switch
between
true
or
false.
So
it
is
like
inherently
a
constraint,
the
values
that
you
can,
that
you
can
choose
for
those
fields,
yeah.
A
That's
a
great
point-
and
this
is
michael,
updated
the
link
to
the
design
mockups
just
a
little
bit
before
this
meeting.
So
here's
one
example,
and
so
that
exactly
is
to
your
point-
and
I
comment
within
this
in
terms
of
the
13.4
order-
we
would
basically
just
do
input
fields
to
start
right
from
an
iteration
perspective
and
then
in
13.5
plus
we
could
actually
that's
when
we
would
introduce
configuration
and
we'd
also
introduce
first-hand
controls
based
off
of
the
types
right.
A
So
naturally,
if
it's
boolean,
we
could
provide
a
first-hand
control
of
a
checkbox,
for
example,
a
more
unique
one.
That's
actually
doesn't
throw
a
wrench
into
it,
but
requires
us
to
really
understand
the
the
minimum
and
maximum
of
what
types
of
edits
can
occur
like
an
image,
at
least
in
in
michael's,
mock-up
right,
adding
an
image
is
possible,
so
that
kind
of
there's
a
lot
that's
kind
of
packed
within
that.
A
If
we're
going
to
actually
enable
that
so
from
an
iteration
perspective,
just
to
reiterate,
13.4
will
essentially
be
just
having
a
kind
of
a
a
placeholder
ui.
That's
just
going
to
be
input
text,
and
I
think
I
talked
about
it
right
here-
actually
just
labels
and
input
fields
and
then
in
iteration
right.
We
could
tackle
by
type
improving
those.
So
I
see
that
a
very
it
just
naturally
flows
into
an
iterative
process
which
is
which
is
nice.
C
They
really
want
the
wysiwyg,
but
they
don't
care
about
this
form
based
mode,
or
at
least
they
don't
want
to
have
to
be
required
to
edit
the
configuration
file
just
to
add
a
new
arbitrary
front
matter
field
they
may
be
like
I
just
I
know
what
my
front
matter
is.
I
will
manage
it
myself,
don't
make
me
manage
this
configuration
file
just
to
be
able
to
use
the
swizzy
wig
editor.
C
In
terms
of,
if,
like
you
had
to
add
an
entry
in
there
in
order
for
a
new
entry
to
be
valid
like
if
we
say
parsed
it
before,
we
allowed
it
to
be
saved
and
said
hey,
this
is
a
new
keyword
that
we
don't
know
about.
You
have
to
go.
Add
it
to
your
configuration
file
before
you
can
save
this
in
the
static
text
editor.
Some
people
may
not
like
that.
A
Sure
and
that's
something
we'd,
so
this
is
so
that
actually
reminds
me
of
why
we're
actually
even
doing
this
on
the
front
end
is
because
that
was
the
argument
I
initially
made
with
jean,
and
then
I
missed
last
week.
Obviously
it
sounds
like
y'all
had
another
meeting
kind
of
that
talked
a
little
bit
about
this,
but
the
why
reason
we're
doing
on
the
front
is
because
you
could
totally
add
a
whole
new
fro.
A
You
know
front
matter
field
and
then
now
what
kind
of
thing
so
to
your
point,
chad,
my
gut,
would
be
and
again
we'd
have
to
figure
this
all
out.
Is
that
maybe
in
raw
mode
you
get
you
know
it's
wild
west.
You
can
do
whatever
edits
you
need,
but
then,
when
you're
in
wysiwyg
mode,
maybe
there's
we
actually
do
this
validation
constraint
step,
because
you
really
got
to
know
what
you're
doing
and
if
you
really
know
what
you're
doing
you
can
just
do
it
raw.
Maybe
I
don't
know.
C
Right
so
the
question
there
is,
and
again
I
was
all
out
all
last
week
I
may
have
missed
some
discussions
that
I
haven't
caught
up
on
yet
is,
if
you're
allowed
to
save
something
invalid,
what
happens
the
next
time
it's
loaded
like?
Are
you
required
to
go
fix
that
via
some
other
mechanism,
you
know
manually
before
you
can
load
it
in
the
sure,
static
site,
editor
or
what.
A
Then
so
yeah
this
has
been
a
great
discussion,
already.
Definitely
uncovering
some
some
interesting
pieces
we'll
have
to
dig
into
a
little
bit
more,
but
in
terms
of
the
high
level
goal,
which
is
essentially
to
have
controls
which
again
michael's
kind
of
done
a
mock-up
here,
how
it
actually
will
manifest
whether
it's
a
sidebar
above
the
content
or
whatever
was
kind
of
tbd.
It
doesn't
really
matter
for
us
so
much
in
the
in
the
near
term.
A
Obviously,
once
we
actually
iterate
on
it,
it
will
be
important
where
we
put
it,
but
we
can
very
simply
have
a
component
and
we
can
rearrange
where
we
put
that
component
and
style
it
like
locationally
spatially.
So
I'm
not
concerned
with
that.
Enrique.
Let
me
know
if
you,
if
you're
concerned
with
that,
but
I
I
don't
think
that's
going
to
be
much
of
an
issue
and
again
yeah.
So
that's
the
main
goals.
How
do
we
handle
this
in
wysiwyg
mode?
A
So
with
that,
I
kind
of
have
three
core
bullets
for
milestone:
13.4,
which
is
what
we're
currently
in
and
then
some
longer
term,
which
is
13.5
plus
so
I'll
just
go
through
those
real
quickly
and
then,
if
people
have
thoughts,
please
please
add
so.
The
first
one
is
kind
of
a
front-end
focused
one.
I
already
kind
of
mentioned
that
with
the
main
underpinning
that,
if
someone
wants
to
actually
add
something
new
or
remove
something
from
the
front
matter
more
ad,
I
guess
you'd
have
to
do
it
on
the
front
end
anyway.
A
So
that's
kind
of
where
that
origin
of
the
this
avenue
has
kind
of
guided
us,
so
that
first
kind
of
and
let
me
take
a
step-
I
think
each
bullet
is
essentially
at
least
one.
Mr
obviously,
within
these
there
could
be
more,
mrs,
but
that's
kind
of
also
what
I
have
to
expect
about
this.
So
one,
mr,
would
be
front
end
related
where
we
parse
out
the
front
matter
from
the
source
markdown
file.
There's
some
additional
bullets
you
can
read
here.
A
We
technically
already
have
this
working,
but
it's
not
robust
in
essence
that
it
doesn't
handle
different
types
of
front
matter
right
now.
It's
essentially
hard-coded.
So
that's
something
we'll
have
to
expand
on
to
to
enable
that
that
proper
parsing.
So
I
see
that
as
one
mr
then,
the
second
one
is,
then
we
need
to
feed,
so
the
output
of
that,
mr
would
essentially
be.
A
We
now
have
an
object
that
represents
the
key
value
pairs
of
what
formatter
actually
is
and
that
object
is
then
going
to
be
fed
into
likely
as
props
into
a
custom
component
and
that's
the
front,
that's
kind
of
what
I
dubbed
the
it's
here
somewhere.
I
guess
it's
not
super
important
front
matter
controls
here.
A
It
is
front
mounted
controls
component
and
so
that's
going
to
consume
that
object,
that
that
represents
what
the
front
matter
key
value
pairs
are
and
then,
with
that
it'll
dynamically
generate
the
controls
and
then
the
third,
mr
excuse
me,
is
kind
of
the
ui
itself.
What
does
it
actually
look
like
right
and
again
so
we
can
just
and
enrique
you
just
mentioned
a
few
minutes
ago
that
you
don't
see
an
issue
here.
You
know
neither
do
I.
We
can
just
have
kind
of
a
a
dummy.
A
Component
that'll,
essentially
just
you
know,
v4
over
all
the
key
value
pairs
and
just
do
a
set
of
input,
input,
text,
fields
for
iteration
one
and
then
later
we
can
expand
on
that
and
do
by
type
and
and
do
validation
that
type
of
thing.
So
at
a
high
level,
I
see
kind
of
three
and
michael's
working
on
this
currently
again
he
kind
of
linked
to
this
file.
So
we
can
add
some
some
comments
to
the
design
itself.
A
If
you
guys
see
any
anything,
interesting,
definitely
check
that
out,
but
other
than
that,
I
see
this
again,
there's
always
a
little
bit
more
difficult
than
than
it
seems.
But
I
guess
my
question
would
be
to
you
enrique.
Do
you
see?
Am
I
missing
anything?
Am
I
over
simplifying
kind
of
the
the
steps
to
get
kind
of
a
13.4
iteration
in
of
this
feature,.
B
Well,
I
we
already
even
before
going
through
those
points.
This
goes
like
the
questions
that
I
had
that
were
basically
about.
What
do
we
do
with
the
to
sync,
the
the
raw
markdown
mode,
with
the
form
controls
that
we're
gonna
build,
and
you
know
we
already
have
even
more
follow-up
questions
that
we
can
well
that
I
actually
have
a
decision.
We
are
going
to
show
the
the
mark
the
fro
matter
in
in
both
modes.
B
I
have
two
more
questions
about
the
second
point
that
is,
you
know,
displaying
the
or
generating
the
form
controls
based
on
the
form
of
matter.
So
the
first
one
is
that
we
have
like
some
related
metadata
to
display
those
fields
in
the
in
the
sidebar.
Let's
say
that
that
we
want
to
generate
those
form
fields
based
on
the
on
the
front
matter
that
that
the
component
receives,
but
we
have
to
display
labels.
Maybe
we
want
to
display
label
text
a
help
text
to
further
describe
the
those
fields.
A
A
A
I
don't
think
that
solves
your
problem
all
the
way,
but
that's
like
option,
one
that
I
wasn't
actually
aware
about
until
recently,
so
we
could
at
least
have
helper
text
that
way
or
metadata
in
that
sense,
and
we
could
parse
that
we
could
have
a
convention
or
something,
but
we
could
figure
that
out.
The
other
one
would
be
kind
of
the
13
5
plus,
where
we
actually
have
this
config
file
somehow
enables
enables
that
it
kind
of
has
those
defaults
because
otherwise
yeah,
I
don't
know
where
that
data
comes
from.
B
But
then
doesn't
mean
that
we
are
going
to
provide
different
help
text
for
for
every
website,
or
do
we
want
to
provide
the
same
ui
user
interface
for
everyone,
because
I
I
imagine
that
the
help
text,
for
example,
or
the
title
of
the
for
a
title
field
that
we
set
in
the
in
the
layout
of
a
page.
It
will
be
the
help,
the
same
help
text
for
everyone.
So
I
don't
know
if
we
are
gonna
force,
the
user
to
define
that
kind
of
element
in
every
application.
B
A
Excuse
me,
I
don't
have
the
answer
just
spitballing,
my
gut
would
be
that
we'd
somehow
have
if
it
is
really
fed
from
the
configuration.
Then
again,
that's
part
of
what
this
is
right.
It's
unsolved.
We
need
to
design
what
that,
actually,
that
configuration
is
and
then
how
the
how
the
front
end
consumes
it,
but
my
gut
would
be
it
would
be
kind
of
like
a
two-stage
thing.
A
Right,
we'd
have
our
default
and
then
we'd
essentially
have
maybe
an
overrideable
file,
and
then
that
takes
precedence
for
any
matches
or
something
that
would
be
my
guess.
But
yeah.
That's
definitely
that's
a
great
question.
That's
something
that
I've
conveniently
shoveled
to
thirty.
You
know
the
next
thing
to
think
about,
but
I
don't
think
it's.
I
don't
think
it's
like
a
show.
Stopper
right
like
I
could
be
wrong,
but
I
don't
think
that's
gonna
prevent
us
in
any
way
from.
Actually
we
can
solve
that.
I
feel
like.
A
A
C
I
could
see
the
a
couple
of
comments,
first
of
all,
having
a
default
text.
It
may
work
for
some
things
like
title,
but
for
other
fields
that
may
not
always
work
because
certain
rendering
engines
or
tools
or
whatever
may
interpret
different
fields
differently
like
we
can't
necessarily
predict
if,
if
we're
only
using,
you
know
supporting
a
subset
of
tools
to
start
with,
maybe
that's
okay,
but
going
forward.
C
That's
maybe
not
necessarily
the
the
description
of
the
field
like
often
and
even
in
existing
files
in
the
handbook.
That
may
be
some
comments
about
like
the
value,
like
some
specific
notes
about
the
implementation
of
that
value
or
why
they
used
it
so
long
term.
I
almost
see
that
evolving
into
a
separate
data
type,
which
is
like
a
comment
which
could
be
optional,
and
it's
about
that
particular
field.
C
A
A
A
B
A
Yes,
that
makes
a
lot
of
sense.
I
think
that
does
too
so
it's
almost
just
to
kind
of
do
a
quick
mini
recap.
Obviously
things
can
change.
Is
my
comment
around
option.
1,
which
is
the
comment
syntax
being
a
help
text?
Probably
we
don't
even
want
to
do.
That
is
what
it
sounds
like,
and
it
would
just
be
all
in
a
configuration
file
and
we'll
provide
a
default
and
we
can
provide
a
mechanism
again.
A
That's
we'll
leave
this
in
135
plus
to
solve
exactly
how
to
do
that,
but
we
have
a
rough
path
of
have
a
default
config
and
we'll
likely
provide
some
kind
of
overrideable
mechanism
for
them.
To
also
do
that.
I
think
that
makes
a
lot
of
sense
and
what
could
also
be
nice
about
that?
Naturally
right
is
it
could
feed
into.
A
We
actually
did
this
on
meltano.
Actually
we
had
a
our
yaml
file
was
kind
of
the
the
god
file.
If
you
will
that
informed,
what
types
of
controls
all
kinds
of
metadata
we
wanted
about
doing
this
exact
thing
about
automatically
generating
controls,
so
there's
definitely
a
it's
not
brand
new
to
do
that
type
of
thing
and
then
wonder,
go
for
it.
C
I'm
just
going
to
say
that
the
one
thought
I
had.
I
know
that
adding
the
configuration
file
may
not
be
in
the
first
iteration,
but
we
it
it's
not
going
to
be
that
hard
technically
like
on
the
back
or
the
front
end.
I
don't
think
so.
We
should
be
careful
about
making
decisions
that
might
end
up
being
as
much
or
more
work
or
lock
us
into
sub-optimal
approaches
just
because
we
don't
want
to
implement
a
config
file
in
their
first
iteration.
A
Yeah,
that's
a
great
great
point.
Well
since
enrique-
and
I
are
both
kind
of
like
probably
leading
this
thing
or
working
the
most
on
it
like
that'll-
be
kind
of
top
of
mind,
but
that's
a
great
point:
don't
make
any
decisions,
that'll
shoot
us
in
the
foot.
So
that's
part
of
this
process
is
kind
of
having
a
little
bit
of
foresight
into
where
we're
going.
So
we
don't
don't
do
that
anyway.
Did
your
second?
Did
this
question
get
answered
as
well.
B
Yes,
yes,
I
think
so
I
I
guess
that
the
answer
would
be
if
we
want
to
support
a
new
file,
a
new,
a
new
field.
Actually,
I
guess
that
what
we
do
is
I
imagine
that
the
way
that
we
are
delivering
the
configuration
file
or
the
configuration
of
a
site
to
the
service
aggregator
application
is
like
in
some
in
some
form
of
serialized
object
right.
The
vacant
will
take
that
java
file
from
the
repository
it
will
interpret
it.
B
B
A
Gut
would
be-
and
this
just
comes
directly
from
it's
a
little
bit
fresh
with
multanos.
We
just
basically
had
a
kind
of
a
base
baseline,
which
would
probably
just
default
to
like
an
input
field
right.
You
just
allow
some
kind
of
base
way
to
actually
do
the
editing,
so
it
would
be
lacking
compared
to
the
control
above
it
the
fourth
one,
as
you
mentioned,
that
would
have
all
the
metadata
to
be
a
particular
rich
type
of
control.
A
A
Yeah,
I'm
imagining
like,
basically
what
I'm
going
to
add.
I
think
unless
you
disagree
like
we
should
have,
we
shouldn't
not
prevent
them
most
likely
and
just
have
just
an
input
field,
and
it
still
has
to
go
through
approval
right.
So,
at
the
end
of
the
day,
you
know,
there's
a
there's
a
person
improving
this
edit
to
the
live
side.
I
think,
but.
C
C
Sure
I
just
said
that
I
I've
already
put
a
couple
of
questions
that
were
related
to
this
above
under
the
discussion.
Technical
solution,
validation
discussion,
so
I
just
said
to
refer
to
those,
for
example,
like
what
what,
if
you
don't
want
to
be
required
to
edit
a
config
file
to
have
a
new
field
or
what
what
will
new
or
unknown
fields,
be
handled
automatically,
or
are
you
required
to
edit
the
config
file
stuff,
like
that?
I
think
it's
related
to
this
question.
C
A
Would
be
kind
of
a
further
down
the
line
right
as
if
we
assumed
that
if
you're
adding
it
you
kind
of
know
what
you're
doing
we
could
potentially
automatically
update
the
source,
just
as
is
of
what
they
did
and
then,
in
addition,
kick
off
an
automatic
write
to
the
config
file
itself
to
update
it
to
handle
that
in
some
way
or
something
with
defaults.
I
don't
know,
maybe
that's
a
bad
idea,
but
that's
kind
of
an
extreme
thing.
We
could
do.
C
A
Editing
raw
or
being
a
developer,
or
something
like
that
is
probably
more
you
know,
that's
kind
of.
I
don't
want
to
say
gatekeeping
but,
like
you
know
what
I
mean
like
they
kind
of
know,
what
they're
doing
potentially
more
so
in
terms
of
that,
so
you
might
just
leave
that
type
of
edit
for
that
type
of
thing,.
A
C
A
There's
so
there's
to
answer
your
question.
The
plan
right
now
is
to
have
the
ui
component,
but
it's
just
going
to
iterate
through
the
object
that
gets
generated
and
simply
provide
just
labels
and
inputs
and
not
worry
at
anything
about
metadata,
not
worry
about
what
types
of
controls
they
actually
are,
and
that
would
be
a
simple
stopping
point
to
then
okay
iterate
on
right
and
handle
once
we
actually
get
to
13
5
and
actually
have
time
to
think
through.
A
A
A
Pretty
much
yeah
so
like
yeah,
the
kind
of
three
core,
mrs
that
I
envision
is
one,
is
the
proper
we're
already
extracting
markdown.
We
just
want
to.
You
know,
extend
on
that
to
do
different
types
of
markdown
and
actually
create
that
object,
and
then
the
second
piece
is
the
dummy
ui
that
consumes
that
object
or
a
dummy,
compo
or
a
component
that
consumes
that
object
and
just
spits
out
labels
and
input
fields
like
that's
the
gist
and
then
the
ui
is.
A
What
do
we
actually
want
it
to
look
like
we
can
then
that'll
be
maybe
the
next
iteration
or,
if
michael
actually
has
that
kind
of
solved.
That'll
inform
exactly
what
that
component
looks
like
stylistically
and
spatially
within
the
ui
and
then
then
resync
and
re-evaluate,
which
would
likely
be
within
13
4.
To
be
honest,
timing
wise,
I
would
expect
like.
I
don't
see,
that
being
a
whole
ton
of
work
could
be
wrong,
but
I
just
grouped
it
that
way,
so
that
13.5
is
more
about
okay.
A
C
A
And
again:
yeah
iteration!
That's
that's!
That's
what
it's
there
for
that's
a
good
natural
cutoff
point
which
is
nice,
so
that's
cool!
So
then
yeah
ui
wise
definitely
check
out
michael's
design,
which
we
have
here
like
we
can.
Actually
you
know
this
can
help
us
make
some
decisions
when
we
get
to
thirteen
five
right
now.
We're
just
gonna
do
exactly
this,
but
you
know
label
and
then
the
value
label
value
label
value.
That's
that's
what
we'll
do
for
for
this
13
floor.
A
A
Yep
again
yeah,
that's
that's
actually
one
I
just
saw
this
morning
of
I
didn't
even
know
that
was
an
option,
so
we
basically
yeah
thirteen
five.
So
we
can
skip
to
thirteen
five.
So
in
terms
of
looking
forward,
the
next
iteration
would
be.
How
do
we
do
the
config
file?
How
do
we
handle
all
the
like?
That's
where
we
had
actually
put
forth
the
effort
of
knowing
the
the
minimum
and
maximum
of
what's
all
actually
possible
in
in
front
matter,
and
how
do
we
want
to
handle
on
a
case-by-case
basis?
A
I
would
actually
anticipate
probably
when
we
do
that
we
would
kind
of
have
an
mr
per
type
like
mr
to
handle
boolean
switches.
You
know,
like
toggles,
an
mr
to
handle
images,
for
example,
that
one
actually
probably
is
going
to
be
a
little
bit
more
complicated
to
be
honest,
but
we'll
have
to
see
like.
Where
does
that
image
actually
go?
Where
do
we
temporarily
upload
it?
A
Is
it
a
base64
or
what
have
you
and
then
and
then
in
13.5,
yet
the
other,
mr
that
I
envisioned
so
that's
kind
of
I
put
back
in
here,
but
it's
you
know,
we'll.
Obviously,
all
work
together
to
figure
out
what
makes
the
most
sense.
Naturally,
as
that
configuration
payload,
hits
the
front
end
what
it
should
be.
It's
that
type
of
thing
and
then
another,
mr
anticipate,
being
the
fermata
controls
component
that
we
currently
have
in
134.
C
C
A
I
agree,
and
I
think
that's
why
at
least
one
outcome
of
this
is
discussion.
One
like,
I
think
it's
almost
unless,
unless
the
members
who
aren't
here
have
some
really
solid
pushback,
I
think
it
makes
a
whole
lot
of
sense
to
keep
raw.
There
really
is
no
reason
to
pluck
it
out
of
raw
in
our
opinions.
So
I
think
that's
a
good
outcome,
all
righty.
So
with
that,
I
think
that's
it.
I
don't
know
if
you
guys
have
any
closing
thoughts.