►
Description
Weekly sync call of the Static Site Editor group focused on engineering efforts.
A
Hello,
everybody.
This
is
monday,
the
27th
of
july
and
you're,
watching
the
static
site,
editor
group,
weekly
sinkhole.
This
is
the
engineering
focused
one
and,
as
usual,
I'll
start
off
by
reading
some
fyis
and
before
we
get
into
our
engineering
topics.
A
Just
a
reminder:
we
have
our
cycle
call
coming
up
this
thursday
lauren
as
an
honorary
team
member
you're.
More
than
welcome
to
join
our
social
call.
I
will
I'll
add
you
as
a
as
an
optional
member
of
to
the
invite.
We
do
some
random
things.
We
talk
about
sports
last
time
we
played
some
drawsaurus,
but
you
know
feel
free
to
join
you
you're
you're
you've
got
a
long-term
membership
to
the
team.
A
I
wanted
to
just
highlight
that
I've
opened
the
epic
to
reevaluate
our
wizardwick
editor
and
the
first
issue
specifically
around
defining
the
usix
ux
and
technical
requirements,
so
those
issues
aren't
scheduled
for
we'll
focus
on
them
in
13.4
and
I'll
assign
a
dri
to
it,
but
I
want
to
to
kind
of
like
just
mention
it
and
allow
team
members
to
to
have
a
look
at
it
and
add
some
feedback
in
the
meantime.
A
You
know
nothing
stops
us
from
from
pushing
it
a
little
bit
forward
asynchronously
for
now,
and
then
please
take
note
of
all
the
osos
coming
up.
We've
got
quite
a
bit
of
pto
coming
up
in
the
team
over
the
next
two
weeks,
which
is
great
by
the
way.
It's
not
a
bad
thing,
it's
a
great
thing,
and
I
encourage
you
all
to
make
sure
that
you
take
the
time
off
and
use
it
to
the
best
of
your
ability.
B
A
I
will
definitely
not
say
no
and
yeah,
we
don't
just
to
recap
for
everybody,
we
don't
have
a
formal
schedule
of
who's
on
call
wing.
We
provide
on-call.
Basically
from
a
certain
time
of
the
day
in
in
to
to
win,
I
think
chad
end
of
day
was
in
pst.
You
know,
I
think
it's
like
six
o'clock
pst,
that
we
try
and
cover.
A
If
somebody
isn't
available,
you
know,
like
you
know,
if
chad
is
not
going
to
be
around,
you
know
like,
and
we
know
specifically
if
it's
the
right,
you
know,
release
post
deployment
date
or
whatever
and
you're
like
we
try
and
be
aware
of
of
issues
that
can
come
up
if
there
are
time
sensitive,
blog
deployments
like,
for
instance,
when
it
was
like
a
response
to
github's
pricing
change
or
whatever
we
try
and
be
proactively
aware
of
those
situations
and
respond,
but
otherwise
it's
at
this
stage.
A
It's
mostly
about
monitoring
and
and
responding
to
to
incident
and
escalating
it
up
to
the
reliability
engineering
team
if
it's
not
related
to
configuration
of
our
pipelines
or
our
code.
So
if
it's
gitlab
product
or
infrastructure
related,
we
escalate
it
up.
We
don't
deal
with
those
ourselves
directly,
and
so
the
handbook
on
full
page
has
been
updating.
It's
got
the
latest
and
greatest
information
so
just
be
on
the
in
the
channel
and
be
responsive
when
there's
an
issue.
That's
all
that's
as
good
as
it
gets.
A
Well,
thank
you
very
much.
All
right,
so
primary
focus
for
this
week
is,
is
definitely
launching
the
editing
of
the
handbook
through
the
static
site
editor
with
the
product
team.
So
we
were
a
little
bit
delayed
last
week
and
getting
the
the
last
few,
mrs
in
as
well
as
some
discrepancies
that
eric
picked
up
with
the
the
formatting
of
the
content,
some
edge
cases.
A
So
the
focus
this
week
is
on
on
trying
to
iron
out
those
last
few
ones
and
then
getting
it
out
to
the
product
team
so
that
we
can
get
some
initial
feedback
before
opening
this
baby
up
to
the
whole
company,
so
that
should
definitely
be
our
primary
focus
and
having
caught
up
with
enrique
and
derek
already
earlier
today,
I
know
they're
honored
and
focusing
on
on
that.
So
then.
A
My
last
point
on
the
general
that
I
wanted
to
touch
up
on
was
just
the
upcoming
pto
and
on
those
going
on
pto.
You
know
my
request
is:
please
make
sure
that
you
add
a
status
update
on
your
deliverables
before
you
go
off.
I
know
we've
got
the
reminder
in
slacknow,
but
it
only
goes
off
on
a
friday
and
if
you
don't
go,
you
might
be
out
before
then
or
whatever.
So
please
just
make
sure
that
all
your
deliverables
have
proper
status
added
to
them.
A
Going
once
twice
sold
all
right,
then
we
don't
have
to
discuss
any
specific
dependencies.
I
didn't
expect
there
to
be
any
considering
where
we
are
in
the
milestone
and
the
way
the
work
has
been
signed,
but
in
case
there
are
anything,
please
make
sure
you
you
bring
it
up
and
that
we
can
afford
them
to
have
a
peaceful,
uninterrupted
pto
so
that
they
can
enjoy
their
time
off
and
then
to
those
going
on
to
pto
like
right
down
here,
please
switch
off
and
race
and
recover
enjoy
that
all
right.
A
D
Sure
I
think
that
you
said
it
all.
Last
week
we
formatted
most
of
the
pages
in
the
handbooks
products
section
and
thanks
eric
sure
for
for
doing
that,
but
at
the
same
time
we
also
found
some
formatting
inconsistencies
very
small
things,
but
they
actually
disrupt
the
user
experience.
D
This
week
we
are
gonna
focus
on
on
fixing
those-
I
didn't
put
it
in
the
document,
but
in
the
work
that
I'm
doing
individually,
I'm
gonna
deliver
some
small
ux
improvements
to
later,
for
example,
something
that
is
very
close
to
get
out
is
the
the
improvement
in
the
in
the
success
screen
after
the
user
saves
the
changes
that's
very
close
to
to
get
merged
and
the
other
one
is
displaying
the
edit
the
edit
links
in
the
top
of
the
handbook
page.
A
Oh
alrighty,
on
to
the
handbook,
chad,
can
you
give
us
a
bit
of
an
update
on
the
monorepo
reflector.
C
Sure
and
lauren
this
this
is
relevant
to
some
of
the
stuff.
We
discussed
a
little
bit
of
change
of
plans,
so
we
should
probably
touch
base
sometime
early
this
week,
but
I
tried
to
put
some
content
in
here
this
time.
C
So
if
you
look
at
this
issue,
that's
what
the
stuff
that
I've
been
working
through
and
that
I've
discussed
with
lauren
and
some
other
people-
and
you
can
see
several
other
things
checked
off.
I
made
good
progress
on
them,
but,
as
is
normal
with
with
all
of
this
modern
repo
stuff,
I
tend
to
run
into
blockers
that
don't
work
out
exactly
the
way
I
plan
them
or
not
necessarily
blockers,
but
I
have
to
think
about
them
and
come
up
with
different
plans
and
really
on
this
one.
C
So
the
two
main
things
that
I
ran
into
is
really
each
one
has
to
have
three
jobs,
because
there's
like
one
that
deploys
that
part,
only
one
that
deploys
that
to
the
one
that
only
builds
it
one
that
deploys
it
to
the
review
site
and
one
that
deploys
it
to
the
prod
site
and
not
to
get
too
much
into
it.
But
the
main
reason
for
that
is
because
we
still
have
to
have
something
at
the
end
that
cleans
up
all
of
the
files
that
have
been
deleted
off
of
the
prod
site.
C
Each
of
these
individual
things
that
I
envisioned
for
the
parts
of
the
build
which
the
company,
the
handbook,
all
of
the
other
various
parts,
would
be
three
jobs
in
the
ci
file,
which
would
just
really
explode.
So
stepping
back
from
that,
I
said
you
know,
let's
just
leave
everything
as
the
existing
partial
build
job.
That
is
this
one
monolithic
thing
that's
responsible
for
handling.
C
A
Cool
we
see,
can
you
on
git
laptop?
Can
you
give
us
a
brief
update
just
on
the
the
two
r
d
issues
that
you've
worked
on
recently.
E
So
I
was
working
on
two
issues.
The
first
one
is
related
to
offline
documentation.
I
did
some
research
and
I
created
a
proposal
like
how
to
move
forward
with
this
approach.
E
So
it's
also
related
to
the
dogs
right
now.
What
we
have
is
a
badge
for
the
headers
in
the
documentation
which
states
this
feature
belongs
to,
let's
say
premium
and
higher
tiers
of
the
gitlab
product,
and
these
patches
are
displayed
differently
like
in
a
gitlab
docs.
It's
like
a
nice
icon
with
the
explanation.
What
is
it
about
in
our
main
help
pages?
It's
just
a
text
which
is
not
rendered,
and
there
is
also
one
specific
problem
with
that
is
the
way
how
we
generate
answers
for
these
headers.
E
We
use
the
text
of
the
tier.
It's
like
it's
added
to
the
enter.
If
you
have
let's
say
like
header
configuration
which
is
available
for
premium,
then
the
answer
will
be
configuration
dash
premium
and
if
something
happens-
and
we
change
this
feature-
and
let's
say
it's
available
not
for
premium-
but
for
everybody
we'll
need
to
change
all
of
the
answers
in
the
code.
We
need
to
find
them
in
the
documentation,
links
and
we
need
to
update
them,
which
is
yeah
not
so
convenient.
E
E
It's
based
on
some
crumb
down
specific
feature.
It's
like
an
extension
of
cram
chromedown
that
allows
to
modify
the
content
that
goes
below
this
definition,
so
we
basically
can
assign
a
specific
classes
for
the
headers
where
we
can
define
that.
We
want
to
present
the
patch,
for
example,
so
yeah
and
I
did
some
tests
and
it
seems
to
work
for
me.
So
I'm
gonna
create
implementation
issues
for
that
and
we
can
proceed
with
the
development.
A
Yeah
and
then
just
also
on
the
the
offline
documentation,
I'm
meeting
with
the
the
em
of
the
distribution
team
tomorrow
to
to
start
a
conversation
about
how
we
can
collaborate
with
their
team
up
by
getting
the
docs,
bundled
with
the
the
omnibus
package
for
people
that
self-install
and
out
of
that.
A
Hopefully,
we
will
have
somebody
that
we
can
collaborate
with
from
their
side
to
to
drive
this
forward,
and
you
know
understand
a
little
bit
more
about
any
requirements
or
restrictions
that
there
might
be
with
regards
to
bundling
docks
with
with
the
gitlab
installer
all
right.
Eric
eastwood,
the
investigator
update.
F
Okay,
on
getter's
side,
we
had
some
exporters
for
user
messages
in
the
user
object
itself.
I
tested
out
the
performance
with
the
messages
because
there's
a
lot
of
them
for
like
each
user,
I
have
a
26
000
messages,
even
for
myself
and
on
the
secondaries
which
handle
this
load.
It's
looking
good,
I
don't
see
like
I,
I
mean
big
difference
when
I
just
pound
it
with
five
requests
at
once.
F
So
I
think
that
solution
is
good
to
go
where
we
just
stream
objects
directly
from
the
database
to
an
nd
json
file
to
the
user,
but
I'll
be
working
on
more
exports
later
in
this
week
as
well,
and
then
on
the
opr
for
adding
more
pwa
features
to
the
web
app
and
making
it
installable.
I
added
the
web
app
manifest
and
a
service
worker
fetch
handler
and
testing
it
out
just
like
locally,
and
it's
a
really
cool
like
standalone,
desktop
site.
Now,
that's
definitely
could
replace
our
existing
desktop
application.
A
A
All
right
lauren:
can
you
give
us
a
marking
update
please.
B
Yeah,
so
I'm
going
to
finish
or
help
with
chad
moving
the
marketing
site
into
the
monorepo
getting
those
set
up
and
after
that
the
general
plan
is
I
really
want
to
get
the
external
asset
pipeline
in
so
we're
processing
all
of
our
css
javascript
images
using
webpack
or
gold
that'll
be
a
big
win
and
then
we're
going
to
work
on
getting
the
headless
cms
in
seems
like
that's,
going
to
be
in
q3
q4
as
general
timeline
and
from
there
looking
out,
we
might
look
at
the
static
site
generator
whether
or
not
we're
going
to
keep
using
middleman.
B
We
haven't
really
dove
into
that
topic
yet,
and
we're
going
to
implement
a
design
system.
B
There
is
not
a
timeline
at
this
point,
we'd
like
to
do
it.
You
know
piece
by
piece
like
one
component
get
in
once
we
get
the
external
asset
pipeline.
We
can
start
to
lay
out
our
components
and
make
them
available
to
the
site,
but
we
haven't
built
out
an
epic
board
or
a
timeline.
A
Still,
okay,
because
I
think
that
that's
one
that
we
definitely
want
to
keep
close
tabs
on
in
terms
of
how
we
can
leverage
it
for
the
handbook.
A
Con
my
conversations
with
with
various
marketing
managers
so
far
have
been
that,
while
the
handbook
is
essentially,
you
know
like
not
directly
in
you
know,
scope
of
influence
or
concern
right
now.
You
know
it
makes
total
sense
for
the
handbook
to
have
a
representative
look
and
feel
of
the
overall
gitlab
branding
and
marketing,
and
so,
if
there's
any
changes
that
come
through
through
this,
it
would
be
good
to
to
carry
that
through
to
the
handbook.
C
And
that
has
worked
on
and
as
far
as
the
assets,
that's
we.
We
should
touch
base
on
that
too,
because
that's
really
part
of
the
the
difficulty
I'm
running
into
because
there's
three
main
categories.
There's
like
some
stuff,
like
the
highlight
tool
tip
and
the
you
know,
salary
calculator.
Things
like
that
that
are
handled
by
rollup
right,
which
is
like
a
different
version
of
webpack.
C
That
which
is
that
slack
thread
I
linked
to
before
so
the
first
part,
the
ones
that
were
handled
by
rollup
like
I
already
got
those
to
move,
because
those
were
pretty
simple
and
the
others
I'm
just
going
to
like
pull
them
out
and
have
them
one
job
that
handles
the
images
one
job
that
handles
the
javascripts
and
style
sheets,
because
they're,
but
still
built
by
middleman,
because
it's
minifying
them.
I
don't
want
to
try
to
minify
them
a
different
way.
C
Maybe
that
breaks
things
and
just
get
them
separate
and
then
we'll
think
about
what
we
want
to
do
with
them
going
forward
but
which
we'll
have
to
be
very
careful
about,
and
the
team
and
the
pet
images
I'm
just
going
to.
Let
y'all
handle
that
because
it's
a
whole
different
ball
game,
aft
and
we'll
move
them
all
down.
C
A
All
right,
thanks
for
lauren,
so
before
I
hand
over
to
eric
in
my
status,
update
for
what
I'm
focusing
on,
you
would
have
seen
13.4
kind
of
like
issue
planning,
but
eric
and
I
had
a
quick
discussion
earlier
and
it
might
it
we
we're.
You
know
it's
up
for
for
re-evaluation,
but
we
might
consider
the
editing
of
front
matter
via
the
ui
as
our
our
primary
scene
for
for
feature
development
in
13.4.
A
So
if
any
of
you
are
really
interested
in
that
topic,
let
me
know
probably
start
kicking
the
can
that,
in
terms
of
you
know
what
our
requirements
are
and-
and
we
know
we-
we
did
some
initial
thinking
about
about
that
earlier
on
and
revisiting
a
lot
of
that.
So,
if
you're,
if
that's
an
area
that
you're
quite
interested
in,
let
me
know
and
I'll
keep
you
informed
on
the
conversation
as
it
goes,
and
with
that
over
to
you
eric.
G
Thanks
yeah,
so
my
my
intention
there
is
to
promote
that
issue
into
an
epic
if
it's
not
already
and
then
start
the
conversation
in
there,
so
that
everybody
can
be
involved
and
we
can
collaborate
on
an
approach
as
as
people
want
to
contribute
I'll
share
a
link
with
that
in
the
slack
channel.
Probably
I
just
have
a
few
fyis
this
shouldn't
take
long,
but
I
did
want
to
clarify
that
I
don't
feel
like
we
missed
anything
as
far
as
making
the
static
site
editor
available
in
the
product
handbook.
G
I
didn't
video
and
that
was
entirely
my
decision
and
not
the
not
due
to
the
bugs
that
we
discovered.
I
think
my
intention
is
to
record
it
today.
I
got
to
the
point
where
friday
and
I
didn't
feel
like
there
would
be
as
many
people
engaged
on
friday
with
a
video
that
I
posted
and
I
wanted
to
start
the
week
off
with
a
recording
in
the
product
channel.
So
I'm
going
to
record
something
today,
you
know
even
with
those
bugs
that
are
still
outstanding.
G
The
one
thing
that
also
will
be
delayed
is
the
story,
mapping
and
think
big
exercise.
We
had
talked
about
using
our
social
call
time,
for
a
few
reasons,
some
logistical,
some
practical
reasons.
I
think
we
should
just
keep
that
social
call
and
I'll
find
time
the
the
following
week
or
potentially
early
the
next
week
and
some
more
on
that
as
the
invite
gets
created,
you'll
all
be
invited
and
it's
considered
optional.
G
You
can
watch
the
recording
if
you
can't
make
it,
but
I
encourage
participation
if
you
can
make
it
a
little
bit
of
housekeeping.
G
I
had
an
mr
at
the
end
of
last
week
because
I
am
bad
at
dates
and
calendars
and
when
I
had
created
our
categories.yaml
projection
for
being
viable,
our
viable
maturity
date
was
was
set
to
be
the
end
of
the
quarter.
But
in
my
head
I
thought
we
had
all
of
the
next
release:
13
3,
to
get
there
and
we
don't,
because
I
don't
look
at
calendars
like
that
yeah.
G
So
I
learned
how
to
do
that
and
now
it
is
correctly
set
to
quarterly
for
us
being
viable,
but
it
is
set
to
early
quarter
three,
not
that
our
website
makes
a
distinction,
but
we
are
still
correctly
set
to
be
at
the
end
of
13.3,
viable
and
in
the
handbook.
So
there's
nothing
new
there,
except
to
point
out
that
if
you're
paying
really
close
attention
to
the
product
maturity
graphs
on
our
website,
it
did
get
delayed.
G
G
We've
already
gotten
that
we
will
fail
to
meet
the
requirements
to
to
be
considered
viable.
I
think
we're
going
gonna
do
pretty
well
on
that,
but
anything
can
happen
so
we'll
have
all
of
quarter
three
to
to
make
up
for
it
and
at
john's
nudging.
I
signed
us
up
for
the
group
conversation
I
post
about
this
in
slack,
but
on
august
18th
I'll
be
hosting
a
ama
group
conversation
style,
roundtable
discussion.
G
Hopefully
some
of
you
can
join
and
bail
me
out
if
I
get
in
over
my
head,
but
if
we
had
any
chance
to
to
be
in
front
of
the
whole
company,
this
would
probably
be
the
best
one
to
take.
So
I
went
ahead
and
signed
us
up
we'll
be
able
to
discuss
any
outstanding
questions
that
people
have
about
the
static
site
editor
and
hopefully,
we'll
get
some
opportunities
to
to
hype
it
up
right
before
we
go
live
to
the
whole
handbook,
so
I
think
it
should
be
good,
hopefully
well
attended.
G
A
We'll
we'll
do
one
of
those
there's
hype
reveals
that
leads
up
to
a
to
a
launch
date
or
something
yeah,
there's
partially
revealing
and
part
of
an
image.
Every
few
days.
G
I
believe
that
there
are
slides
that
should
go
with
it
and
I
haven't
attended
as
many
of
the
like
individual
group
conversations,
as
I
probably
should
have
so.
I'm
gonna
go
back
to
what
the
typical
format
is
and
how
much
I
should
prep,
but
I
might
might
need
a
little
bit
of
proofreading
and
stuff
on
those
slides
before
the
18th.
A
All
right
and
with
that
we're
right
on
time,
and
so
I'm
gonna
end
the
call
and
wish
you
all
a
happy
rest
of
your
monday
cheers
everybody.