►
Description
Weekly sync call of the Static Site Editor group focused on engineering efforts.
A
Hello,
everybody:
this
is
the
static
cited
group
sync.
This
is
the
engineering
focus
edition.
Today
is
the
17th
of
august
and
happy
monday
to
everybody
on
the
call,
as
usual
I'll
start
with
a
few
quick
fyi.
So
chad
is
out
this
week
and
we'll
be
back
next
week.
Monday
and
derek
is
out
this
week,
monday
and
tuesday
and
we'll
be
back
on
wednesday.
A
A
Thank
you
silly
for
jumping
in
and
adding
the
feature
flag
for
us
as
an
extra
safety
net
for
those
that
didn't
see,
obviously
enabled
the
feature
flag
action
a
few
minutes
ago.
So
that's
all
good
now
and
then
also
on
the
handbrake
side,
we
see
we
added
a
custom
helper
that
enabled
us
to
split
the
performance
indicator
yaml
file
into
smaller
files,
which
will
definitely
which
made
a
lot
of
people
very
happy,
because
that's
probably
the
one
file
that
receives
the
most
conflicts
from
edits
and
so
on.
A
So
that
was
a
nice
win
advice
as
well
on
the
general
front,
so
this
week
we're
starting
with
milestone.
13.4,
our
main
focus
should
be
getting
momentum
with
our
our
deliverables.
A
I
I
reviewed
the
priorities
with
enrique
and
vasily
today
and
I
think
we've
got
a
good
milestone
plan
and
ambitions,
one,
but
also
a
very
nice
one
that
I
think
we.
If
we
we
can
land
most
of
what
we
we
talked
about.
It
will
be
a
really
great
milestone,
with
lots
of
newest
release,
notes
to
go
into
the
release
post.
A
A
reminder
also
tomorrow,
is
tomorrow's
company
group
call
is
going
to
be
run
by
eric
and
features
the
static
site
editor.
So
please,
let's
make
sure
we're
present
and
support
eric
and
make
ourselves
available
to
help
field
any
questions
that
might
arise
right,
I'm
going
to
change
a
tradition
and
skip
the
static
slide
data,
the
product
updates
from
engineering,
because
I
want
to
keep
that
one
for
last.
We
don't
have
a
long
agenda
today,
so
I
want
us
to
to
finish
the
race
and
then
come
back
to
that.
A
So
our
main
focus
is
editing
front
matter
in
13.4
and
we're
doing
some
planning
on
that
this
week.
So
I
wanted
to
just
kind
of
like
have
a
discussion.
While
we
have
so
many
people
synchronizing
the
fall
that
we
can
use
the
time
for
that
on
the
handbook
side,
so
the
monorepo
refactor
workers
is
done
and
ready.
A
We
discussed
last
week,
chad,
lauren
myself,
and
we
made
the
the
single
call
not
to
try
and
rush
it
in
last
week,
but
we're
going
to
wait
for
chad
to
be
back
from
this
video
and
so
on
next
week,
monday
after
6
p.m,
pst
we'll
pull
the
trigger
and
migrate
the
files,
and
then
we
will
have
a
theme
repo
with
two
isolated
sites
from
a
code
point
of
view
more
or
less.
A
There
is
some
shared
files
that
we
need
to
work
on
over
time,
but
considering
where
we
were
back
in
january,
when
we
took
over
kind
of
like
technical
support
for
the
handbook
and
stuff
there's
been
so
much
cleanup,
that's
happened
and
yeah
it's
exciting
to
see,
see
it
progress
through
that,
so
I've
linked
to
the
rollout
plan.
So
you
can
have
a
look
there
gitbapdog,
so
I
haven't
updated
this
section
yet,
but
I'll
quickly
give
an
update
here.
A
Hopefully
he'll
start,
firstly
on
the
the
tier
status
badge
in
the
header
to
wrap
that
work
up
and
following
that
we'll
be
working
on
the
issue
around
switching
the
internal
help
links
in
gitlab
to
to
the
external
gitlab
docs
url
with
that
will
come
an
admin
setting
for
for
people
to
to
choose
which
documentation
source
to
use
either
the
internal
help
or
or
an
external
site
which
will
default
to
the
gitlab
docs
website,
and
that's
so
that
people
that
are
in
airgap
instances
can
at
least
still
use
forward.
Slash
help.
A
And
then
once
we
get
to
the
point
where,
where
you
can
host
your
own
doc
site
and
we
deprecate
help,
that's
where
you
will
put
in
your
your
url
for
your
external
posted
or
internal
hosted
docs
as
well.
So
we
that
issues
a
bit
of
a
kind
of
like
a
precursor
to
to
being
able
to
to
role
or
find
support
for
dogs
all
right.
B
Okay,
so
finally,
user
data
export
is
complete,
been
working
on
that
for
a
couple
weeks
and
now
working
on
some
room
export
endpoints,
but
those
will
probably
go
fast.
Now
that
I
have
the
format
down
and
everything's
working,
I
fixed
the
sidecar
login,
so
there
were
some
cookie
issues
with
the
sort
of
new
flag
where
they
don't
share
across
domains.
B
A
B
It's
the
one
thing
that
happened
before
that
we
encountered
with
it
is
our
old
desktop
site
that
that
attribute
breaks
old
chrome
instances
so
that
the
cookie
just
doesn't
work
and
that
doesn't
affect
a
lot
of
people,
because
chrome,
auto
updates
for
everyone.
But
in
our
old
desktop
site
we
used
an
old
nwjs
version
which
pulled
in
old
chromium
and
so
that
we
had
also
login
problems
there.
B
A
Right
over
to
lauren
for
an
update
on
what's
happening
in
growth
marketing
world.
C
Pretty
short
update
this
week,
hoping
to
get
redirect
testing
re-enabled
before
we
had
a
staging
environment
where
you
test
redirects
and
we're
going
to
get
those
applied
to
review.
Apps
and
that'll
be
cool
for
the
handbook,
also
and
then
still
working
on
the
proof
of
concepts
for
our
cms
integration,
and
that
project
will
be
ongoing
over
the
next
couple
of
weeks.
A
All
right,
looking
forward
to
seeing
the
outcome
of
those
concepts
onto
product
update
eric
shooter.
D
Yeah,
so
you
already
mentioned
this,
I'm
getting
excited
for
the
group
conversation.
It
is
going
to
be
our
first
one,
which
is
so.
I
don't
know
what
to
expect.
I
don't
know
who's
going
to
show
up
who's
going
to
be
interested
in
what
kind
of
questions
there
will
be,
but
I'm
excited
to
field
them
all.
It
would
be
great
if
you
could
join,
but
it's
certainly
not
required.
I
know
time
zones
and
other
meetings
could
come
up.
I
I
hope
we
get
some
good
questions.
D
That's
really
all
I
have
if
you
could
look
at
the
slides,
if,
if
you
feel
like
you
want
to
review
them
for
accuracy
and
whether
they
make
sense
john
was
nice
enough
to
provide
some
context
and
add
some
links
late
last
week,
because
I
procrastinated
on
making
the
slides,
but
I
think
they're,
pretty
much
complete,
so
some
last
minute
eyes
would
be.
D
I
will
be
posting
in
the
next
hour,
most
likely
the
slides
to
the
team.
I
will
also
be
combining
that,
with
an
announcement
about
the
static
site
editor
being
available
on
the
whole
handbook,
so
that'll
be
a
big
celebration.
I
don't
want
to
gloss
over
that
too
much,
because
that's
what
we've
been
working
towards
for
six
months
now.
D
D
Yeah,
it's
just
a
big
moment.
I
think
we
should
all
kind
of
celebrate
in
our
own
ways
today.
If
you
can
and
hopefully
we'll
get
a
ton
of
users
and
a
ton
of
great
feedback
and
we'll
we'll
be
able
to
keep
iterating,
I
don't
think
it.
You
know
it's
hard
to
it's
hard
to
celebrate
shipping
remotely
and
it's
hard
to
celebrate
shipping
when
you're
already
moving
on
like
two
releases
past
what
you
you
know
what
you're
about
to
announce,
but
it's
it's
a
big
moment.
D
So
thank
you,
everybody
and
I
will
leave
the
rest
of
the
time
for
our
engineering
conversation.
A
Carrick
yeah,
it
feels
like
we
should
do
a
pizza,
pizza,
social
call
or
something
next
week
to
celebrate
properly
all
right.
So
I'm
going
to
share
my
screen
so
that
it's
easier
for
you
all
to
follow.
A
Okay
and
you'll
see
my
screen
file,
I'm
using
in
one
or
two
levels.
All
right
so,
as
mentioned
editing
front
matter
is
the
is
the
main
feature
that
we're
targeting
in
13.4.
A
My
hope
is
that
we
can
land
an
initial
kind
of
like
feature
iteration.
That
would
essentially
pretty
much
just
be
the
you
know,
showing
what
what
the
front
matter
field
and
values
are.
He
put
boxes
along
so
much
to
edit
it
from
my
initial
conversations
with
derek
it's
it's
fit
in
nicely
with
the
the
way
he
already
has
ripping
out
a
front
matter
and
stitching
it
back
together
when
we
create
the
mr
and
so
I'm
hopeful
that
we
should
have
a
fairly
smooth
conflict
first
iteration.
A
That
said,
we
don't
know
until
we
know,
and
this
week
when
there
is
pacquiao
focusing
on
on
the
planning.
What
I
wanted
to
talk
about,
and
I'm
just
looking
for
the
design
that
michael
did
a
there.
We
go.
A
So
I
wanted
to
just
quickly
bring
this
up,
so
this
is
the
initial
concept
that
michael
worked
on,
and
you
know,
he's
currently
working
on
a
solution,
validation,
prototype
and
we'll
be
doing
some
testing
with
users
on
this.
But
I
wanted
to
just
provide
this
for
some
context
for
this
discussion.
A
So
essentially,
you
you'll
see
a
contract
settings
icon
here
whether
this
kind
of
like
icon
is
sufficient
in
terms
of
knowing
what
to
do
is
things
that
will
come
out
of
the
solution
validation,
but
when
you
kind
of
click
on
it,
the
initial
idea
was
that
it
would
open
like
a
drawer
that
essentially
just
displays
the
the
key
value
pairs
of
of
the
front
matter
of
the
file
and-
and
this
would
simply
be
plain
text
to
start
off
with
down
the
line.
A
A
Maybe
you
have
a
bunch
of
layouts
that
that
users
can
choose
from,
and
so
you
might
want
to
have
a
drop
down
with
the
layouts,
instead
of
them
having
to
try
and
remember
what
the
values
are
so
anyway,
when
you
have
predefined
values,
you
might
want
to
consider
that
and
that's
something
that
we
need
to
figure
out
how
we're
going
to
do
still.
You
know
our
initial
thoughts
around
that
was
around
providing
a
configuration
file
for
the
statics
type
editor.
A
We
you
could
define,
for
instance
the.
Maybe
you
don't
want
certain
front
matter,
fields
to
be
editable
even,
and
so
you
might
want
to
define
which
fields
are
editable
or
not
editable,
and
you
might
want
to
define
predetermined
values
for
them.
So
those
those
are
things
that
that
will
come
in
probably
in
the
second
iteration,
but
things
that
we
will
keep
in
mind
when
we
do
the
planning
so
that
we
contract
architect
a
solution
that
can
cover
for
all
of
those
things.
A
What
I
wanted
to
to
really
talk
about
in
today's
session
and
get
some
some
opinions
on
is
one
of
the
key
decisions
we
we
need
to
make.
In
my
mind,
anyway,
is
where
we
deal
with
the
parsing
processing
of
the
front
matter
and
when
I,
when
I
refer
to,
that
is
think,
let's,
let's
take
the
handbook
page
means
instance.
So
as
soon
as
I
click
on
this
link
here,
it
takes
me
to
the
static
site
editor
and
by
the
time
it
lands
here.
A
You
know
this
editing
by
the
time
it
shows
things
needs
to
needs
to
know
what
those
key
value
pairs
are
that's
in
the
front
matter,
so
currently
it
just
strips
it
out
and
it
stitches
it
back
together
when
you,
when
you
go
to
when
you
submit
your
changes,
one
one
question
that
I
have
is:
should
we
be
doing
the
parsing
of
the
the
front
method
values
in
the
key
value
pairs
in
the
front
end,
or
should
we
be
parsing
those
values
by
the
back
end
and
having
having
it
passed
to
the
static
site
editor
to
as
as
parameters?
A
A
A
If
so,
what
type
of
processing
should
we
have
there,
or
should
we
have
it
all
in
the
front
end,
and
if,
if
the
consideration
is
to
have
it
in
the
front
end,
you
know
what
are
the
type
of
things
that
we
expect
the
backing
to
handle
for
us
in
terms
of
the
static
site,
editor,
and
so
that's,
that's
the
the
kind
of
like
setup
question
that
and
context
that
I'm
giving
you
and
I'd
like
to
hear
some
thoughts
on
this.
If
you
please,.
A
As
far
as
I
know,
it
loads
a
lot
of
things
you
know
like,
for
instance,
this
is
an
a
is
a
it
uses.
I
believe
they
use
graphql
on
the
way
by
you
already,
I'm
not
100
sure
actually,
but
I
believe
most
of
it
is
actually
done
with
with
api
calls
on
the
front
end.
D
A
A
E
E
Oh
no,
please
finish
your
your
thoughts.
A
No,
I
I
I
was
just
going
to
say
to
eric's
point
I
think,
looking
at
how
the
web
ide
approaches.
This
is
definitely
a
good
starting
point,
and
then
you
know
if,
if
they
do
it
in
whichever
way,
which
I'm
hoping
enrique
has
an
answer,
it
would
be
good
to
reach
out
to
paul
and
dennis
and
hear
what
their
experience
has
been
so
far
with
that
approach
and
whether,
if
they,
if
they
had
a
blank
canvas
today,
whether
they
would
approach
it
differently.
E
E
I
think
that
the
advantage
that
we
get
when
we
do
parsing
in
the
front
end
is
control
mostly,
so
you
have
the
the
raw
source
and
then
you
do
the
parsing
in
the
client.
You
get
the
abstract
syntax
tree.
That
is
like
taking
raw
information
and
converting
it
into
extra
and
a
structure
that
has
structured
data.
You
know
that
structure
and
then
you
can
make
transformations
on
it.
E
So
that's
probably
the
that
is
that
we
get
from
there,
but
I
think
from
a
high
level
point
of
view,
we
should
go
a
little
bit
deeper
and
and
try
to
evaluate
and
investigate
what
advantage
we
get
from
doing
it
on
each
side
or
the
other.
A
I
would,
I
would
say
one
of
one
of
the
potential
benefits
of
doing
parsing
by
the
backing
could
potentially
be
performance.
So
I
think
we
need
to
keep
in
mind
that
one
one
of
our
objectives,
long
term,
is
to
to
have
the
static
site.
Editor
be
usable
on
mobile
phones
and
while
we,
while
we
currently
not
focusing
too
much
on
that
you
know,
the
more
processing
will
flow
to
the
front
end.
A
The
more
cpu
usage
will
will
be
needed
on
the
on
the
mobile
device
and
that
in
itself
I
think
in
this
specific
instance,
because
the
the
front
matter
is
is
not
visible
immediately.
We
could,
we
could
potentially
delay
the
processing
of
that
to
after
the
the
editor
is
extract
to
not
kind
of
like
delay,
the
rendering
of
it,
but
other
things
that
we
that
we
might
like
say
say.
For
instance,
we
talk
a
little
bit
more
generic,
so
it's
a
configuration
file.
A
Would
we
want
to
to
parse
that
configuration
purely
on
the
on
the
client
because
and
we
maybe
maybe
we
can-
and
maybe
it's
funny?
Maybe
we
can
use
web
workers
to
to
help
us
with
performance
like
that,
but
I
think
performance
is
probably
the
the
one
consideration
you
would
have
not
so
much
from
it
from
a
desktop
to
a
laptop
computer
point
of
view,
but
mostly
from
devops,
the
less
less
processing
you
have
to
do
in
the
mobile
device,
the
better
from
actual
performance,
but
also
from
a
power
consumption.
Point
of
view.
D
I
don't
know
if
this
would
help
steer
the
conversation,
but
if
I
could
just
share
maybe
a
little
bit
of
the
strategy
or
long-term
vision
I
had
in
this
and
you
kind
of
mentioned
in
the
beginning.
I
think
it'd
be
great
for
the
end
users
down
the
road
to
be
able
to
configure
this
in
a
more
upfront
and
sort
of
line
by
line
manner.
So
if
I
have
front
matter
that
is
an.
E
E
D
Might
want,
it
might
support,
say
like
different
templates.
That
might
be
something
we
can
infer
and
build.
It
might
be
something
that
somebody
wants
to
provide.
It
might
be
great
to
say
this
is
like
a
you
know.
This
is
a
binary.
True
fall,
so
I
want
it
to
be
a
switch.
It
might
also
be
really
important
for
some
of
them
to
be
required
versus
optional
or
have
pre-filled
values
versus
free
form.
D
I
don't
know
if
that
would
inform
at
what
point
we
set
up
that
configuration,
whether
it
needs
to
be
more
upfront
and
done
in
the
back
end
and
handled
in
a
configuration
file
versus
parsing
it
and
inferring
a
lot
of
this
from
from
the
values
we
can,
maybe
obviously
we're
going
to
iterate
towards
that
step,
but
if
it
informs
the
architecture,
I
think
that's
the
the
direction
we
should
be
heading
is
is
allowing
people
to
say
allowing
our
users
to
say
this
front
matter
is
required.
D
F
F
Yeah,
I
want
to
share
some
thoughts
about
it.
I
think
there
is
like
two
questions.
First,
one
is
about
front
matter,
and
second
one
is
about
the
configuration
for
front
matter
and
for
other
parts
in
case
of
front
matter.
I
think
we
already
parsing
the
file
and
we
get
this
front
meter
kind
of
for
free
unless
I'm
wrong.
F
So
from
this
perspective,
I
think
it
doesn't
really
matter
like
if
it's
on
the
back
inside
or
if
it's
on
the
front
side,
because
we
on
the
front-end
side,
currently
we
parse
a
whole
file
and
we
parse
the
front
matter
from
it.
So
unless
there
are
some
kind
of
like
obstacles,
we
is
dealing
with
the
front
matter.
On
the
frontal
side,
I
think
we
can
keep
it
there,
at
least
for
now,
and
we
can
also
evaluate
how
much
performance
we
can
get
if
we
move
it
to
the
back
end
for
the
configuration.
F
I
think
it's
a
bit
different
because
the
configuration
file
first
of
all,
we
need
to
validate
it,
and
probably
we
don't
want
to
have
this
logic
on
the
front
and
it
might
be
transformed
to
from
the
like
configuration
file
to
some
kind
of
like
intermediate
like
variant
with
some
kind
of
like
options
and
keys.
That
can
be
useful
for
the
front
end
not
to
deal
with
the
raw
file
which
need
to
be
like
separately
loaded,
parsed
validated,
and
I
added
all
of
this
configuration
to
the
static
site
editor.
E
Yes,
my
thoughts
go
in
the
in
the
same
line.
We
don't
want
to
provide
a
raw
configuration
file
to
a
project.
E
I
imagine
that
we
are
going
to
make
a
version
that
perhaps
transforms
the
the
array
of
options
that
we
will
provide
for
the
layout
field
into
into
something
that
is
like
clean,
something
that
that
transformed
those
paths
to
something
that
is
a
label
plus
the
the
actual
time
of
the
path,
the
actual
path
of
the
file
yeah.
I
think
I
agree
with
that
with
those
thoughts
of
possible.
D
C
In
here
and
just
add,
I
really
like
the
idea
of
a
configuration
file
and
being
able
to
apply
uniform
front
matter
across
the
site.
Even
our
dub-dub-dub
repo,
our
front
matter.
It's
crazy
amongst
the
marketing
site.
It
varies
tremendously,
so
being
able
to
make
that
consistent
would
be
awesome.
A
Yeah,
so
having
listened
to
this
philly's
argument,
I
I
think
it
makes
sense.
It
also,
if
I
recall,
aligns
with
my
initial
conversations
with
derek
where
he's
his
opinion
was
also
to
to
keep
the
the
parsing
of
the
front
matter
on
the
on
the
front
end,
because
it's
already
there
like
you
see,
he
said
you
get
it
for
free.
You
don't
need
to
make
a
separate
request
and
so
on
and
as
far
as
the
the
conflict
go.
A
Definitely,
I
can
see
it
going
that
way,
so
I
think
making
making
that
distinction
between
contract
on
the
back
end
and
parsing
the
backing
pass
through
the
editor
and
anything
sorcery.
That's
it
part
of
the
source
gets
processed
by
the
by
the
front
end,
because
that's
already
where
we
have
that
logic
going.
I
think
that
makes
a
lot
of
sense
and
seems
like
a
nice
clean
divider
as
well
for
us
to
use
as
a
kind
of
like
a
I'm
going
to
call
it
a
rule,
but
a
guide
going
forward.
As
well,.
A
All
right,
thank
you
very
much,
everybody
with
that.
We
we
are
at
prime,
I'm
very
glad
that
we
got
to
discuss
that
point,
because
that
pictures
are
planning
a
little
bit
forward
on
on
that
issue
already
so
have
a
great
rest
of
your
monday
and
see
you
all
on
the
group
call
tomorrow
where
we
will
watch
eric.