►
Description
Weekly sync call of the Static Site Editor group focused on engineering efforts.
A
A
We
won't
be
having
a
separate
product
and
design
one
this
week
as
michael
is
on
pto
I'll
quickly,
read
out
a
few
fyi,
so,
as
I
mentioned,
michael
is
ooo
of
the
meeting
house
and
he'll
be
out
wednesday
I'll
also
be
out
on
friday,
I'll
be
taking
that
in
lieu
of
public
holiday
that
we
have
on
monday
and
since
mondays
are
busy
days
for
me,
I'd
rather
work
that
they
take
friday
or
derek
is
also
taking
some
much
needed
vacation
next
week.
A
So
heads
up
that
is
out
and
that's
eric
added
here,
no
product
design
called
this
week.
All
right.
I
wanted
to
introduce
a
new
section
and
I'm
actually
gonna
share
my
screen
so
that
we
can
capture
this
in
the
recording.
But
you
know
like
what
I
want
to
try
and
introduce
is
a
highlight
from
last
week.
So,
first
of
all,
we
launched
the
static
site
editor
for
the
product
section
of
the
handbook.
A
Thank
you
very
much
eric
for
recording
that
that
introduction,
video
and
stuff,
I
thought
it
was
great
and
there
was
there
was
a
lot
of
kind
of
like
positive
vibes
in
slack
around
that.
So
that
was
great.
We
made
the
edit
links
in
the
handbook
more
accessible.
I
think
enrique.
A
You
had
an
image
here
for
earlier,
but
it
doesn't
seem
like
anymore,
but
I
will
quickly
show
it
anyway
on
the
screen.
So
you
know
previously,
you
had
to
go
all
the
way
to
the
bottom
of
the
page
to
find
edit
the
page
and
open
the
web
id,
and
now
we
actually
have
it
right
at
the
top
here
below
the
maintained
by
so
contribute
to
this
page
resources
and
then,
obviously,
if
you
are
in
the
product
section,
you
page,
let
me
just
go
to
product.
A
You
get
the
option
to
use
the
static
site
editor
as
well,
and
hopefully
we'll
be
opening
that
up
to
the
rest
of
the
handbook
soon
and
then
also
we,
we
refined
our
success
screen,
which
shows
up
after
creating
an
mr
go
to
the
memorial
to
see
so
we
used
to
have
it
looked
like
this
and
now
it
is
like
this
much
more
action
driven
in
terms
of
steps
that
you
need
to
take,
and
so
that's
a
good
enhancement,
especially
as
we
prepare
to
roll
out
to
the
rest
of
the
company.
A
All
right,
I
I'm
going
to
kind
of
like
keep
doing
the
highlights
from
last
week.
I
think
it's
good
for
us
to
recap
what
we
achieved
as
we
can
sometimes
get
lost
in
all
of
the
stuff,
we're
doing
and
forget
to
celebrate
the
the
good
things
that
that
happen
right
so
on
to
the
general
section,
so
we're
entering
the
the
second
half
of
the
milestone.
I
had
a
quick
scan
over
our
deliverables
for
for
13.3
and
they
look
to
be
doing
well.
A
They
all
seem
to
be
in
a
fairly
good
state,
and
so
I
want
to
suggest
that
we
we
push
to
to
get
our
issues
wrapped
up
as
soon
as
possible
to
provide
ourselves
a
bit
of
free
play
time
towards
the
end
of
the
milestone.
You
know
that
could
be
used.
You
know
to
take
on
an
issue
in
a
passion
project
that
you
have.
I
know
enrique
has
a
big
passion
for
gitlab.
B
A
And
we've,
you
know
derek
and
enrique
also
mentioned
that
they'd
like
to
tackle
some
of
the
performance
enhancement,
work
that
we're
attacking
in
dev.
So
you
know
if
we,
if
we
wrap
up
our
issues
early,
we
you
know
it
always
gives
a
little
bit
of
a
kind
of
like
capacity
for
that.
So
that's
just
an
idea.
A
The
second
point
I
want
to
highlight
is
so
last
week:
vasily
did
a
great
job
at
providing
a
status
update
comment
on
all
these
open
deliverables,
and
I
wanted
to
encourage
you
all
to
to
follow
suit,
as
it's
not
only
a
great
way
to
keep
the
team
informed
about
our
progress,
but
also
stakeholders,
and
that
can
prove
crucial.
You
know
there's
an
example
that
I've
linked
to
where
he
he
posted
an
update,
and
then
there
was
actually
a
response
to
to
to
that.
A
That
was
quite
important
context,
which
probably
would
not
have
come
out
if
you
didn't
post
that
update
or
it
might
have
come
out
too
late,
and
so
we
have
a
slack
reminder
that
goes
out
every
friday
for
you
to
to
update
your
open
deliverables.
So
I
want
to
encourage
you
all
to
do
that.
I
think
it
it's
it's
not
just
a
good
for
us
to
to
transparently
update
people
on
the
status
but
like
we
saw
there
can
actually
lead
to
some
invitational
information
coming
all
right.
A
Moving
on
to
the
github
product
for
the
static
site
editor.
So
enrique,
can
you
give
us
a
quick
update
on
the
the
integration
into
the
handbook.
B
Sure
so,
as
john
said,
we
released
a
lot
of
cool
stuff.
Last
week,
I
left
a
link
to
the
to
our
own
filter
website,
where
we
post
engineering
updates
with
some
screenshots
as
well.
B
I
want
to
highlight
that-
and
you
know
say
thanks
to
to
michael
for
designing
these
great
ux
improvements,
but
at
the
same
time
they
they
were
very
incremental
and
and
easy
to
implement.
So
that's
something
that
something
that
is
really
worth
highlighting.
B
Besides
that
direct
and
I
work
on
fixing
a
lot
of
formatting
issues
that
that
eric
found
last
week
on
you
know
they
are
very
small
and
they
were
just
like
preventing
the
formation
of
pages
things
like
a
bug
that
we
found
in
the
in
the
way
that
other
these
were
incrementing
these
markers
and
also
the
inconsistency.
B
Another
bug
with
the
with
formatting
bolt
and
an
italics
takes
a
good
indicator,
so
we
delivered
many
work,
fixes
related
to
that
and
now
the
next
step
is
opening
the
certified
editor
to
to
everyone
in
the
handbook
to
every
handbook
page.
For
that,
I
think
that
we
just
need
to
fix
first
complete,
complete
the
image
uploads
and
second,
we
have
to
finish
with
some
formatting
issues
in
your
big
syntax
within
markdown
documents.
A
Thank
you
very
much
and
since
you've
already
answered
point
three
where
I
asked
kind
of
like
how
close
are
we
to
resolving
the
blockers,
we
can
skip
that
one
derek.
You
have
point
two
there:
can
you
give
us
an
update
on
the
erb
cleanup
that
you've
been
working
on
and
the
concern
that
you
might
have
so.
C
Sure
yeah
so
just
kind
of
picking
up
after
what
enrique
just
mentioned,
so
at
a
high
level
we're
using
the
editor
in
a
unique
situation
where
we're
basically
have
code,
which
is
erb
syntax,
but
it's
not
in
code
blocks
or
inline
code.
It's
not
identified
as
such,
using
tick
marks,
which
is
what
a
markdown
editor
typically
expects
for
code.
C
So
this
is
basically
a
unique
exception
case
that
we
have
to
handle
and
the
initial
implementation
worked,
but
it
didn't
preserve
indentation
and
it
also
in
some
unique
cases,
strips
backslash
escape
characters
so
to
make
it
foolproof,
we
basically
have
to
take
a
few
more
steps.
So
that's
basically
what
that
comes
down
to
so
props
to
enrique,
for
I
was
a
little
bit
blinded
from
an.
C
I
went
down
this
approach
prior
to
having
a
converter
from
wysiwyg
back
to
markdown,
but
enrique
since
implemented
that
now
we
have
a
good
path
to
do
this.
So
thank
you
again
enrique
for
for
recommending
that,
because
I
was
kind
of
blinded
temporarily
because
of
that
so
long
story
short.
We
can
do
it
since
I'm
gonna
be
out
next
week,
and
I
just
don't
know.
I
basically
have
three,
mrs
queued
one
is
I
sent
enrique
this
morning,
so
I
can
get
those
done
then
all
as
well.
C
If
I
can't
that's
where
my
concern
is
about,
you
know
pushing
it.
For
you
know,
just
in
terms
of
iteration,
we
could
just
not
support
erb
files,
for
you
know
some
small
indefinite
amount
of
time
until
we
get
those
done.
C
So
that's
basically
what
that
comes
down
to
so
that's
kind
of
up
to
eric
and
if
how
we
want
to
do
that
and
again
that
kind
of
matches
against
how
quickly
I'm
able
to
get
it
done
and
how
quickly
those
mrs
get
through
so
and
just
for
context
based
off
my
initial
file,
audit
of
dot,
md,
dot,
html
dot,
md
and
then
also
the
data
html.md.erb.
C
You
know
how
what
percentage
of
files
that
wouldn't
be
editable
for
that
small
indefinite
period
of
time,
so
just
some
data
to
kind
of
roughly
throw
out
there
to
maybe
help
make
the
decision
but
yeah
and
just
maybe
a
kind
of
an
aside
like
longer
term.
If
we,
you
know
when
we
open
this
up,
not
just
within
the
handbook
and
there
are
other
static
sites
that
also
want
to
have
templating
syntax,
which
is
essentially
essentially
what
erb
is
from
other
languages.
C
We
would
you
know,
that's
is
that
a
use
case
we
want
to
really
handle
because
it
really,
it
would
be
easier
if
we
don't
again,
if
we
didn't
have
to
handle
erb,
our
problem
would
be
solved
already,
but
it's
something
to
think
about
again
if
we
want
to
support
other
templating
syntaxes
longer
term,
so
it's
just
worth
throwing
out
there
so
yeah,
that's
basically
it.
B
B
Supporting
supporting
others
and
playing
syntax
is
pretty
much
thinking
if
we
are
going
to
support
other
static
site
generators
right.
If
we
have
to
support
those
sites,
we
need
to
support
the
languages
that
they
use
for
contemplating.
D
I
think
we
absolutely
want
to
support
other
statistic
generators
and
I
think
we
would
want
to
support
their
templating
languages
too.
So
I'm
more
familiar
with
jekyll.
But
you
know
if
you're
writing,
liquid
templates
in
there
it's
or
liquid
tags
inside
your
markdown
is
pretty
common,
but
it's
not
like
you
know.
D
It's
not
back
ticks,
so
we're
going
to
need
a
way
to
identify
that
and
I
think
whether
that
ends
up
being
some
sort
of
upfront
configuration
where
we
say
you
know
you're
using
jekyll
or
using
hugo
you're
using
such
and
such,
and
we
have
just
custom
rules
written
for
each
one
or
if
we
can
find
something
more
generic.
I
think
I'll
leave
that
up
to.
B
C
Cool,
I
appreciate
that
and
just
again
add
a
little
bit
more
context.
There
is
enrique
has
done
a
really
good
job
about
kind
of
abstracting
things
for
configuration
already
like
you
know.
We
know
that
that's
kind
of
a
plan
essentially,
so
I
just
wanted
to
share
that.
Obviously
we
would
have
to
write
those
custom
renderers
and
then
we
also
have
to
do
the
custom
conversion
back.
So
that's
just
where
you
know
additional
work
needs
to
occur
per
templating
language
unless
that
exists
somewhere,
which
is
possible
too.
C
I
know
this
is
just
in
the
context
of
toast
ui
right
now,
like
there's
a
path
forward
for
this
type
of
thing.
We
just
need
to
do
custom
work
per
templating
language
type
and
then
again,
enrique's
done
some
good
research
on,
I
think
unified
is
the
the
live,
the
tool
basically
to
create
abstract,
abstract,
syntax
trees
from
any
document
which
is
pretty
cool,
so
that
also
might
help
us
again
there's
an
ecosystem
around
that,
so
that
might
solve
some
of
our
problems.
C
A
I
think,
in
terms
of
you
know,
just
going
back
to
your
progress
before
you
go
in
pto.
I
think,
let's
catch
up
you
and
me
on
thursday
morning
to
assess
kind
of
like
where
we
are,
what
the
likelihood
of
the
mrs
r
that
you've
created
for
landing
is,
and
we
can
then
make
a
call
on
the
way
forward
with
regards
to
supporting
erp
extension
or
not
in
the
short
term.
A
All
right
point:
four
is
just
a
quick
fyi,
so
milestone
searching
point.
Four's
main
theme
is
going
to
be
all
about
editing
front
matter.
I
chatted
to
derek
earlier
today
and
he's
gonna
be
leading
the
efforts
on
this
feature.
He's
shown
some
kind
of
like
interest
in
this
in
the
past
when
we
started
talking
about
this
and
since
enrique
had
the
the
privilege
of
leading
the
anvik
integration
know
time
to
relieve
him
of
some
leading
duties
that
derek
will
be
taking
on
on
that.
A
We've
got
some
architectural
decisions
to
make
on
this
one
yeah.
I
briefly
discussed
some
some
questions.
I
had
with
derek
and
there's
some
things
we
need
to
decide
on
around.
What
do
we
handle
via
the
back
end
in
terms
of
parsing
the
front
the
front
matter
you
know
with
what
things
did
we
might
want
to?
A
You
know
bring
into
configuration
in
terms
of
down
the
line,
might
not
be
for
our
first
iteration,
but
you
know
where
does
configuration
come
into
the
picture
and
is
it
better
to
pass
those
values
into
the
to
the
editor,
rather
than
have
the
editor
parse
the
front
matter
itself?
So
I'm
going
to
open
an
r
d
issue
on
this,
so
that
we
can
start
exploring
those
those
considerations
and
so
yeah
just
giving
you
a
heads
up
from
there
all
right.
A
Moving
on
to
git
club
handbook
chad,
can
you
give
us
an
update
on
the
monarch,
refactor.
E
Yes,
I
can
so
I
finished
all
of
the
tasks
that
I
had
identified
for
the
preliminary
separation
and
decoupling
tasks
and
refactoring
that
ended
up
being
29
hmrs
over
the
last
two
weeks
and
the
highlights
of
those
are
now
all
of
the
jobs
for
the
different
areas
of
the
site,
which
are
the
two
main
ones,
are
the
handbook
and
marketing,
as
well
as
the
various
image
and
assets
builds
that
they
share,
are
now
build
and
deploy
in
one
job
and
they're
completely
independent
of
each
other.
E
So
we
can
split
them
up
into
the
separate
monorepo
sites
without
having
to
worry
about
them,
coupled
be
a
partial,
build
or
a
monolithic
deploy,
as
a
result
of
that,
mainly
just
by
eliminating
the
single
in
deploy
step
and
its
need
to
spin
up
a
whole
dedicated
job
just
to
download
the
assets
which
the
other
jobs
already
had
and
deploy
them.
The
pipeline
should
be
about
two
to
five
minutes
faster,
I
think,
depending
on
whether
things
are
cached
or
not,
and
the
other
nice
thing
the
handbook
site.
E
So
if
you
cd
into
site's
handbook
and
just
run
middleman
now,
it
runs
fine
in
devmode,
including
all
of
the
assets
and
images
which
wasn't
the
case
before,
and
so
that
was
a
prerequisite
for
us
getting
rid
of
the
top
level
middleman
config
all
together
and
removing
it
as
a
its
development
mode,
support
and.
E
Several
passes
refactoring
to
get
lab
ci.
It's
it's
a
lot
cleaner.
It's
the
stages
have
been
renamed
appropriately
based
on
the
different
workflows,
all
the
needs
it's
all
now
and
based
on
needs
instead
of
dependencies,
not
using
the
deprecated
syntax
anymore,
and
all
of
the
sections
are
labeled.
E
So
that
sets
us
up
to
begin
thinking
about
moving
everything
that
is
still
under
the
top
level
source
directory
down
into
sites
marketing,
which
was
the
big
challenge.
There
is
what
do
we,
how
do
we
share
stuff
and
to
what
extent
do
we
try
to
drive
things
after
leave?
It
shared
versus
duplicate
things
and
what
is
the
best
decision
on
all
of
those
things
which
will
be
a
lot
of
little
decisions
and
seeing
what
breaks
and
how
we
want
to
do
it?
A
I've
got
a
question
on
that,
so
you
already
have
and
will
continue
to
to
work
closely
with
lauren
and
brandon
on
this.
But
would
it
make
sense
for
us
to
have
a
sync
chat
around
making
a
planning
how
we
approach
moving
the
marketing
files.
E
Out,
I
don't
know,
I
think
I
just
want
to
take
a
shot
at
it.
Okay,
and
one
thing
I
forgot
to
mention
that
the
dedicated
blog
build
plus
all
of
the
sim
links
that
were
related
to
that
are
now
gone,
so
there's
no
more
sim
links
in
the
repo.
E
D
E
I
just
need
to
take
a
a
first
pass
at
it
and
just
sort
of
get
an
idea
of
the
problems
we're
going
to
run
into
and
then
maybe
come
up
with
a
list
of
things
that
we
know.
We
need
to
talk
about
because
I
don't
think
there's
any
clarity
yet
on
what
we
would
even
need
to
talk
about.
A
Right
that
makes
sense
all
right
on
to
gitlab
docs
and
welcome
to
our
caller
game
season.
Good
to
have
you
here,
so
the
main
progress
we
made
last
week
I
was
outlastic,
but
I
followed
what
was
going
on
was
vaseli
had
a
chat
with
stephen
wilson
who's,
the
em
for
the
distribution
team
and
there
they
kind
of
like
deal
with
the
omnibus
package
and
they
discussed
the
the
requirements
and
limitations.
A
You
know
that
that
might
be
involved
with
we're,
bundling
gitlab
docs
with
omnibus,
because
we
want
to
provide
an
offline
version
for
a
gap
instances
there.
There
was
a
couple
of
concerns
that
came
out
so
the
increase
of
the
package
size.
You
know
the
omnibus
package
is
already
over
700
megabytes,
and
so
it
would,
you
know,
inflate
that
even
more
they're
testing
in
pipeline
durations.
You
know
jobs
can
take
several
hours
already
to
complete
for
for
that
build.
A
So
that's
a
consideration
and
alternative
options
that
they
discussed
was
providing
a
post
install
staple
documentation
on
how
to
include
the
the
the
docs
project
instead
of
bundling
it
in
omnibus,
as
well
so
potentially
essentially
getting
to
the
same
outcome,
but
maybe
having
it
as
a
as
a
process
outside
of
omnibus
not
in
on
with
us.
So
there's
still
some
exploration
to
be
done
there
just
in
terms
of
what
is
the
right
technical
execution
for,
allowing
you
know
a
user
to
to
have
a
local
copy
of
of
github
docs.
A
You
know
providing
an
outside
of
omnibus
installation
approach
so
we'll
once
we
see
it
back
from
pto
next
week,
we'll
explore
that
a
little
bit
further
and
come
to
a
more
concrete
recommendation
of
what
it
is
that
we
suggest
this
is
how
we
exec
execute,
bundling
github
docs
in
an
offline
environment
and
getting
it
up
and
running
there.
I
know
there
was
also
some
progress
on,
or
at
least
some
discussion
around,
the
approach
for
the
links
with
with
the
the
theater
name
in
them.
A
That
will
unfortunately
need
to
kind
of
carry
over
to
obviously
back
next
week,
but
other
than
that
we
susan
you'll,
be
happy
to
know.
We
we're
earmarking
putting
some
time,
aside
from
the
cv,
to
focus
on
specifically
those
two
issues
to
carry
on
focusing
on
that
in
13.4,
we'd
like
to
to
see
them
have
a
happy
conclusion
soon.
A
Perfect
all
right
over
to
eric
eastwood,
with
a
guitar
update.
F
On
gitter,
I've
been
working
on
the
user
data
exporters
tackling
the
harder
ones.
First,
I
refactored
the
exporter
a
bit
just
so
it's
instead
of
mongoose
cursors,
it's
native
iterables,
so
we
can
pass
in
mongoose
mango
stuff
or
just
plain
arrays
when
we
have
functions
that
already
fetch
all
the
data
for
us
already
and
that's
it
for
me,
eric.
D
Thanks
the
have
a
few
things
and
I
might
rattle
on
a
little
longer
since
I
don't
have
my
opportunity
to
talk
all
evening,
but
the
first
thing
I
wanted
to
do
is
I
was
talking
with.
B
D
Earlier
just
about
an
hour
ago-
and
I
think
my
intention
is
to
continue
to
move
forward
with
our
front
man
migration.
As
far
as
we
can-
and
I
guess
chad
you
can
stop
me
if,
if
I'm
overstepping,
but
I
think
the
the
next
step
should
be
to
create
an
epic
that
outlines
the
very
clear
benefits
that
we'll
get
from
moving
to
front
man
and
sort
of
justification
there.
And
that
way
we
can
track
implementation
issues
under
that
epic
and
yeah.
D
E
So,
if
that's
the
case,
we
can
maybe
we
can
discuss
it
just
because
of
splitting
my
attention
across
the
marketing
monorepo
move,
which
I
think
is
going
to
need
most
of
my
attention
and.