►
Description
Weekly sync call of the Static Site Editor group focused on engineering efforts.
A
Hello,
everybody:
this
is
the
static
side,
the
editor
weekly
synchronous
call.
This
is
the
engineering
favorite
edition
and
on
this
monday
the
24th
of
august
welcome
getting
straight
into
some
of
the
the
highlights
from
last
week.
So
company
group
call
was
a
big
success
and
was
well
received.
A
Thank
you
again
to
eric
for
hosting
that
and
the
effort
you
put
into
the
slides
and
we've
we
rolled
out
the
static
slider
to
the
to
the
rest
of
the
company
and
made
them
aware
of
it,
and
so
we
we
started
getting
very
valuable
feedback
already
on
that.
So
that's
that's
always
a
good
thing.
Then,
moving
on
to
to
fys
I've
got
it
in
general.
A
I've
got
a
couple
of
things
I
want
to
mention
this
week,
so
this
first
day
is
our
social
meeting,
but
we're
moving
we've
converted
that
into
a
pizza
virtual
pizza
party,
so
we're
gonna
take
a
moment
just
to
look
back
and
celebrate
the
last
eight
months.
A
What
we've
achieved
and
accomplished,
and
also
I
was
speaking
to
eric
just
now-
you
know
having
having
a
bit
of
a
talk
and
a
look
at
what's
next,
you
know:
what's
lying
ahead
for
us
in
the
next
six
months,
so
eric's
been
doing
a
lot
of
work
around
defining
what
the
future
looks
like
and
you
know:
we've
got
them
ambitious
and
and
interesting
things
lined
up,
but
we
also
have
some
very
tangible
things
that
we
that
we,
you
know,
is
clearly
there
for
us
to
achieve
in
the
next
three
to
six
months,
and
so
we
can
start
talking
about
those
things
a
little
bit,
but
mostly
it's
a
time
just
for
us
to
get
together
as
a
group
and
and
have
some
good
times
together.
A
So
I've
put
some
notes
in
there,
you
don't
have
to
eat
pizza,
you
can
you
don't
have
to
eat
on
the
call.
I
know
it's
going
to
be
like
6
a.m,
for
derek-
and
you
know,
and
in
midnight
almost
for
michael
if
he
joins
us,
so
you
know
eat
when
you
want
to
eat,
but
you
know
feel
free
to
expense.
It's
expensive
for
for
that
celebration.
A
Oh
definitely
not
and
there's
nothing
better
than
leftover
pizza
the
next
morning,
breakfast
of
champion.
So
then
a
little
fyi
that
gitlab
commits
is
happening
this
week.
I
I've
kind
of
like
I've
added
a
link
there
to
to
the
schedule.
I've
earmarked
a
couple
of
sessions
that
I
want
to
to
visit.
A
The
last
one
is
we
had
a
session
with
marcia
our
technical
writer
earlier
today,
just
talking
about
how
we
can
better
collaborate
on
working
with
the
technical
writing
team
and
and
there's
kind
of,
like
four
points
that
I
just
wanted
to
highlight
from
our
conversation
there.
So
the
first
one
is,
you
know:
let's
bring
the
technical
writer
into
the
picture
as
early
as
possible.
You
know
once
the
mr
is
there
and
you've
got
something
there.
A
You
know
like
add
a
couple
of
bullet
points
in
the
document
in
the
docs
and
and
yeah
start,
even
if
it's
just
a
an
fyi
to
marcia
to
say,
hey,
I'm,
I'm
just
giving
you
a
heads
up.
This
is
coming
but
make
them
aware
of
of
things
that's
coming
sooner
rather
than
later.
The
the
other
thing
is,
you
know,
assign
an
mr
to
the
technical
writer
when
they
need
to
action.
It
then
just
ping
them
in
the
in
the
in
the
mr.
A
They
get
a
lot
of
to
do
from
all
from
lots
of
groups.
So
if
you
can
make
it
more
explicit
when
they
need
to
action,
something
it's
better,
if
there's
a
delay,
you
know
feel
free
to
reach
out
in
slack
to
to
ask
them
and
or
remind
them
or
ask
them.
You
know
if
there's
anything
blocking
them
from
having
a
look
at
it
and
then.
A
Lastly,
you
know
avoid
requesting
mr
approvals,
one
or
two
days
before
the
release
post
title,
so
the
release
post
cutoff
was
on
the
17th
and
marshall
told
us,
since
she
had
like
30
mrs
to
to
review
at
one
stage
in
in
two
days,
causing
her
to
have
to
work
kind
of
like
11
hour
days
for
two
days.
So
that's
not
great.
So
let's
be
conscious
of
that
and
get
our
documentation
inanimate.
You
know.
Documentation
is
part
of
the
definition
of
done.
So,
let's
make
sure
we
we
don't
forget
that
I
will.
A
There
was
a
good
reminder
for
me
personally
and
I'll
be
looking
out
for
those
things
where,
where
possible,
to
help
out,
but
if
we
can
all
just
kind
of
like
be
aware
of
this
and
contribute
to
this,
we
can
work
better
together.
A
I
will
highlight
that
you
did
say
we
already
work
well
together,
so
this
is
all
about
just
let's
be
more
efficient
and,
let's
be
better,
all
right.
Moving
on
to
the
static
side
editor
in
the
product
enrique,
can
you
give
us
a
bit
of
an
update
on
the
work
you've
been
doing
as
well
as
the
feedback?
We've
received
so
far.
C
Sure
thing
we
receive
a
lot
of
awesome
feedback
of
people,
18
pages
with
the
in
the
handbook,
with
the
study
site
eight,
and
there
are
two
main
points
that
that
are
worth
highlighting.
So
the
first
problem
that
people
are
is
having
in
that
process
is
that
the
handbook
is
using
a
different
flavor
of
markdown
than
the
one
that
the
statistic
or
supports.
That
is
a
common
mark
out
of
the
github
flavor
markdown
as
a
consequence,
when
they
say
either
opens
a
handled
page.
C
It
interprets
the
that
markdown
in
a
different
way
that
the
handbook-
and
sometimes
that
means
that
the
markdown
is
broken
and
as
a
result,
when
that
reach
content
goes
back
to
markdown.
When
we
are
submitting
the
changes,
it
is
generating
markdown
that
brokens
the
100
page.
C
So
we
need
to
find
a
way
of
the
actually
thing
that
we
will
we
will
take.
Is
that
we'll
try
to
perform
at
the
handbook
pages
in
ways
that
they
complying
with
the
market
specification
and
that's
what
we
will
be
working
on
this
week?
The
second
bug
that
we
found
that,
I
think
is
also
critical,
is
about
interpreting
crown
dam
attributes.
So
crown
down
has
a
syntax
that
allows
attaching
metadata
to
to
mark
down
elements
like
headings
these
links,
everything
in
markdown
and
again.
C
The
series
editor
is
not
interpreting
that
correctly
and
in
the
case
of
the
table
of
contents.
What
the
the
convention
in
the
handbook
is
that
you
attach
a
class
to
hide
those
headings
from
the
table
of
contents,
and
that
is
broken
right
now,
when
the
user
submits
the
changes
using
their
data.
C
So
the
action
writing
is
that,
even
though
it
is
kind
of
difficult
to
handle
that
right
now
with
the
tools
that
we
are
using
for
parsing
markdown,
I
think
that
we
can
find
a
temporary
measure
anyways.
C
I
I
have
a
link
in
there
that
I
want
to
use
this
opportunity
to
to
to
share
this
with
you,
but
I
made
a
detailed
analysis
of
why
this
is
difficult,
because
we
have
limitations
with
the
marketing
partners
that
we
are
using
right
now,
so
it
is
worth
reading
in
my
opinion,
but
yeah
we
are
going
to
find
a
work
around
for
that,
then
we
are
going
to
work
on
out
of
that
this
week.
A
D
Yeah
so
pretty
straightforward,
we
just
finished
our
session
and
a
recording
link
there
on
the
dock
there
high
level,
the
planning
I
did
is
kind
of
on
par.
That's
the
direction
we're
going
to
take
it's
kind
of
broken
up
into
13.4
and
13.5,
so
we're
basically
going
to
kind
of
go
the
you
know
simple
route
and
then
naturally
iterate
on
it.
D
So
what
that
means
is
in
wysiwyg
mode,
we'll
have
a
kind
of
a
baseline
ui,
which
is
basically
just
going
to
be
input
fields,
and
then
our
next
iteration
is
when
we'll
actually
do
the
work
to
figure
out
what
the
config
file,
assuming
that's
the
route,
we
go.
What
that
should
actually
look
like
to
inform
that
front
matter,
widget,
essentially
to
provide
kind
of
more
first
class
controls
like
boolean,
would
be
a
checkbox.
D
For
example,
michael's
shared
a
an
image
design
that
actually
showed
an
image
uploading
scenario,
so
that's
actually
kind
of
a
unique
configuration
that
we'd
have
to
account
for
so
I
anticipated
mr
being
per
type
as
well
when
we
iterate,
so
that
should
keep
things
kind
of
small,
but
no
no
real,
show
stoppers
or
anything
like
that.
So
yeah
definitely
check
out
the
call
if
you're,
interested
or.
D
A
One
of
the
things
I
wanted
to
I
asked
derek
is
to
just
keep
this
thought
in
the
back
of
your
mind,
that
should
we
continue
using
this
planning
document
that
we
use
in
google
docs
as
a
as
an
interim
medium,
or
should
we
start
off
straight
in
in
the
issue,
I
think
initially,
when
we
started
with
this
process,
we
you
know
our
assumption
was
that
it
would
be
easier
to
collaborate
and
and
make
edits
and
stuff
while
we're
you
know,
in
the
rough
draft
phase
of
planning
and
then
transfer
the
information
to
to
the
epic
or
the
feature
issues.
A
A
At
the
moment
we
don't
have
to
answer
that,
but
if
you
do
have
some
thoughts
on
on
that,
you
know
feel
free
to
share
it.
Asynchronously
with
me,
I'm
just
curious.
If
we
can
skip
this
intermediary
step
forward
in
our
process,
if
it's
adding
value
great,
we
keep
it.
But
if
it's,
if
it's
not
owning
value-
and
we
can
go
straight
to
to
an
issue-
then
it
would
make
sense
to
do
that
all
right.
A
Moving
on
to
the
handbook,
so
I
just
wanted
to
mention
I
disabled
the
merge
train
on
the
gitlab
com
repo
on
saturday
morning.
At
my
time
it
you
know
there
was
numerous
amounts
of
time.
The
train
got
stuck
last
week.
A
I'm
I
have
a
suspicion.
It
relates
to
to
the
production
instance.
We
had
on
the
the
gitly
nodes
and
chad
you-
and
I
will
talk
about
that
later
today,
trying
to
see
if
we
can
look
at
that
pre-built
ci
script
to
to
cache
the
repo,
because
it's
it's
adding
a
lot
of
overhead
on
the
nodes
at
the
moment,
because
that
repo's
so
big
and
we
we
have
so
many.
Mrs
a
day
going
going
on
that
repo.
A
That
said,
there
is
an
issue
to
kind
of
like
automatically
recover
a
stuck
merge
train,
but
even
with
the
manual
kind
of
like
workarounds
that
we've
been
doing
last
week,
you
know
just
kept
getting
stuck,
and
so
I
made
the
decision
to
disable
it
for,
for
now
that
means
we
obviously
need
to
be
careful
that
we
don't
end
up
with
a
broken
master,
and
if
we
do,
we
need
to
be
responsive
in
handbook
escalation
channel.
So,
let's
watch
out
for
any
notifications.
There.
E
So,
based
on
our
last
experience,
doing
that
the
broken
master
is
it's
gonna
be
inevitable.
It
happened
multiple
times
within
a
day.
E
E
A
E
So
we've
made
a
lot
of
assumptions
for
optimization
like,
for
example,
not
running
tests
and
not
running
linters
on
master
for
speed.
So
currently,
if
you
just
turn
off
the
merge
train,
the
result
of
a
broken
master
is
people
don't
find
out
about
it
until
they're,
mrs
and
then
it's
affecting
multiple
people
and
then,
when
you
fix
it,
you
have
to
tell
them
to
rebase.
So
if
we
have
to
keep
it
turned
off
for
an
extended
amount
of
time,
we
should
consider
turning
some
of
the
tests
and
linting
back
on
our
master.
A
Yeah,
I
think
that's
a
good
idea
and
we
should
just
take
that
action
to
turn
it
on
until
we
turn
merge,
train
back
on
so
I'll.
Take
that
action
all
right.
Moving
on
to
the
next
point,
so
the
mono
refactor
is
for
moving
the
marketing
site
into
the
the
monorepo
structure
is
happening
today,
so
fingers
crossed
everything
goes
well
and
then,
if
chad
has
no
hair
tomorrow,
we
know
why
that
happened.
E
I
I
haven't
looked
at
anything
about
get
lab
for
a
week,
so
I'm
sure
it
will
go
smoothly
when
I
do.
F
E
A
What's
the
whole
idea,
you
come
back
refreshed,
you
know
not
overworked,
so
just
just
go
with
it.
What's
a
whipper
can
happen.
Am
I
I
just
remembered
that
it
was
being
recorded?
What
sort
of
that
can
happen?
This
might
come
back
to
want
me.
A
Know,
thank
you
for
listening
to
me.
Chad,
there's
always
a
first
of
all
something
eh
all
right.
The
last
point:
there
is
just
a
an
infi
that
messeli
created
a
linter
to
learn,
broken
links
and
anchors
in
the
handbook,
and
we
discussed
what
do
we
need
to
do
before
we
just
kind
of
like
merge
this
and
move
ahead
with
it,
and
we,
essentially
just
you,
know,
talked
about
when
something
goes
wrong
on
the
pipelines,
especially
when
it's
a
linting
thing.
Team
members
don't
always
know
what
to
do
about
it.
A
It's
not
always
clear
from
the
linting
areas
or
something,
and
so
we
see-
and
I
brainstormed
a
bit
and
we
eventually
settled
on.
We
need
to
create
a
page
in
the
handbook
that
we
can
direct
team
members
to
when
they
run
into
an
issue.
So
the
common
use
case
I
can
think
of
is
that
you
know
somebody
does
an
update
to
the
handbook
that
pipeline
breaks
because
of
the
linking
error
they
reach
out
to
the
immigration
channel.
A
The
approach
we've
taken
with
the
first
iteration
of
this
page,
and
you
know
the
idea-
is
that
we'll
build
out
this
page
over
time
with
all
the
kind
of
like
support
that
somebody
might
need
to
have
and
I'll
be
asking
the
mr
buddies
to
to
expand
on
it
as
well
as
they
get
common
requests
around
things
being
broken
all
right
and
then
on
to
bitlab
docs.
F
Sure
so
last
week
I
was
busy
mostly
with
product
years
and
so
a
bit
of
words
about
what
it
is
about.
We
have
lots
of
links
with
answers
that
lead
to
the
headers
that
contain
the
information
about
product
year,
for
example,
configuration
which
is
available
only
for
premium
and
in
case
when
the
product
year
changes.
We
need
to
update
all
of
the
links
and
it's
quite
error-prone
process
that
you
want
to
avoid.
F
So
the
goal
is
to
remove
all
of
the
information
about
product
years
from
edgers,
and
for
that
I
created
a
couple
of
merch
requests,
two
of
them
pointing
to
gitlab
main
project,
and
second
one
is
for
gitlab
docs.
So
in
this
merch
requests,
I
remove
all
of
the
information
about
product
years
and
there
is
a
third
one
that
can
basically
all
of
the
changes
to
the
existing
links.
So
I
went
through
all
of
the
docs.
G
So
we
finally
got
the
database
back
running
that
fell
over
last
week,
jumped
over
all
the
snakes
and
now
that's
running
smooth,
and
I
didn't
want
to
make
a
release
last
week
with
that
made
the
export
generally
available
for
everyone,
so
that
it
didn't
put
extra
strain
on
the
database
and
make
it
another
thing
fall
over.
So
now
that
that
one's
up
and
running
I
looked
at
data
dog,
it
was
going
smooth.
G
So
I
made
a
release
last
week
and
now
user
data
export
is
available
for
everyone,
and
I
see
some
stats
where
people
are
trying
out
a
bit.
So
that's
good
to
see
and
then
working
on
this
week
finishing
off
exporting
data
for
a
room,
so
messages
remembers
that
sort
of
stuff.
That's
more
domain,
specific
for
administrator
room
administrator
people.
A
Lauren
anything
relevant
in
growth,
marketing.
H
I
will
be
around
in
the
mr
buddies
and
handbook
escalation
channel
to
help
out
the
proof
of
concepts
for
our
cms
is
going
to
get
completed
this
week,
and
I
was
wondering
if
you
guys
have
a
handbook
page
or
any
issues
where
you've
gathered
like
requirements
for
the
static
site.
Editor
that
possibly
reused,
because
I
think
the
cms
and
the
aesthetics
editor
aligned.
A
Yeah,
so
I
know
we've
had
team
members
in
the
past
open
issues
when
they,
you
know,
I
know
rebecca,
opened
a
few
issues
around
features
that
she
would
like
to
see
when
we,
when
we
kind
of
showed
the
direction
of
the
static
side
editor,
but
I
don't
think
we
have
an
a
general.
B
Yeah,
nothing
that
we've
kept
up
to
date.
You
know
early
on,
we
had
a
lot
of
like
you
know,
big
brainstorming
documents
about
what
could
happen,
and
that
could
be
useful.
We
can.
We
can
share
those
again
and
then
just
our
just
general
maturity.
Epics
are
probably
the
only
thing
that
we
have
kept
up
to
date,
after
that
we
are
probably
gonna,
be
doing
a
little
more
of
that,
like
long-term
thinking
in
the
coming
weeks.
B
So
we
can
certainly
whip
you
in
on
that,
and
specifically
I've
been
working
on
the
jobs
to
be
done
more
formally
as
we
look
to
expand
into
complete
maturity
and
plan
for
that.
So
I'll
include
you
on
those
and
maybe
that'll,
be
a
good
place
to
start.
H
That's
great,
thank
you.
The
last
thing
that
I
noticed
popped
up
last
week
is
our
community
contributions
are
failing,
the
pipelines
are
so
I'm
gonna
look
into
that
and
see
if
we
can
get
those
fixed.
A
Can
you
give
us
a
quick
101
around
the
community
contribution
pipelines?
What
are
they
different.
H
They
I
mean
if
someone
goes
to
contribute
to
the
dub
dub
dub
repo
through
a
forked,
merge
request
the
pipeline
fails
and
then,
if
a
gitlab
team
member
then
pushes
a
commit
the
pipeline
succeeds.
So
that's.
E
E
I
guess
look
at
that,
mr
my
first
question
is
the
specific
requirements
of
middleman
like
how
it
pulls
in
partials
and
stuff,
so
whatever
about
that,
doesn't
work
where
we're
not
worrying
about
in
this
initial
pass
like
if
the
page
doesn't
actually
look
anything
in
the
headless
cms
like
it's
actually
going
to
look
due
to
middleman
specific
stuff.
H
Yeah
we'll
try
to
nail
those
down
on
the
proof
of
concepts.
That's
where.
C
H
Can
discover
where
some
of
those
issues
might
occur.
A
Yeah,
I
I
think
the
the
next
big
thing
after
the
marketing
site
migration
is
coming
up
with
the
plan
for
the
shared
assets
the
longer
we
we
delay
that
the
longer
it
will
be.
This
sword
that
hangs
over
our
head.
E
A
All
right,
the
the
last
point
I
have
there
is
just
an
f5
for
the
growth
marketing
team
lauren.
I
saw
you
you
you
commented
on
the
mr
already
is
we'll
be
moving
to
scoped
priority
and
severity
labels
in
the
gitlab
all
group,
and
we
want
to
replicate
that
on
gitlab.com,
so
that
we
have
consistency
with
that,
because
we're
doing
development
in
gitlab.com,
not
just
the
handbook
updates
right
and
then
last
but
not
least,
eric
with
an
update
on
product
thanks.
B
So
this
week,
I'll
be
focused
on
a
direction
page
update,
like
I
do
every
after
every
release,
and
this
one,
I
think,
will
be
a
little
more
significant
because,
depending
the
validation
from
our
our
survey,
I
think
we're
going
to
be
viable
in
this
release.
We've
shipped
a
lot
of
work
that
culminated
in
us
being
available
or
the
static
site
editor
being
available
on
the
handbook
and
that's
a
big
milestone,
so
I'm
going
to
be
taking
a
step
back
on
our
direction.
B
Page
thinking
through,
like
I
mentioned
before,
I've
been
thinking
a
lot
about
the
jobs
to
be
done.
Thinking
through
some
more
personas,
it's
going
to
be
a
more
meaningful
update
than
usual,
and
not
just
a
date
bump,
and
not
just
a
shifting
of
ethics
on
the
list
of
what's
next
so
expect
an
mr
in
the
next
couple
days
and
I'm
like
input
and
feedback.
If
I'm
misinterpreting
something
or
misstating
something.
If
something
stands
out
as
counter
to
what
we've
discussed
in
previous
meetings,
then
please
call
me
out
on
it.
B
I
think
codifying
our
are
not
necessarily
exactly
what
we're
going
to
do
to
get
to
complete,
but
our
next
phase
of
the
static
site
editor
will
be
important
in
this
direction.
Page
update
so
keep
an
eye
out
for
that,
and
then
I'd
like
to
start
the
discussion
about
supporting
more
static
site
generators.
B
I
think
that's
going
to
be
important
in
the
coming
months
and
over
the
next
year
to
drive
growth
for
the
future
and
support
for
people
outside
of
just
using
the
handbook,
not
as
many
people
use
middleman
as
something
like
hugo
or
even
gatsby.
Those
aren't
necessarily
what
we've
been
targeting.
So
my
assumption
is
that
we
need
to
make
a
decision
first
on
the
future
editor
architecture.
B
B
If
you
see
any
major
blockers
that
we
haven't
already
been
considering
now's
the
time
to
to
bring
them
up
as
we're
architecting
for
the
for
the
future.
B
E
F
E
Catch
up-
and
this
may
very
well
been
discussed,
but
the
one
thing
that
I'm
interested
in
is
the
discussion
that
was
going
on
about
decoupling,
the
the
parsing
of
the
markdown
and
that
part
of
it
from
the
rendering
and
the
fact
that
there
may
not
be
you
know
one
tool,
especially
toast
ui
or
any
tool
that
does
everything
we
want,
and
the
best
decision
going
forward
is
to
decouple
that.
So
I,
if
we
discussed
it,
don't
have
to
go
into
it
here,
but
that's
the
one
thing.
A
You
know
it's,
I
wouldn't
say
it's
a
done
deal
that
we're
going
to
have
to
re-architecture
our
editor
going
forward,
but
it
is
a
high
probability
of
that
and
I
think
as
we
as
we
kind
of
like
evolve
and
we
explore
and
understand
our
our
direction
and
requirements
going
forward.
A
It
does
kind
of
like
start
to
seem
like
we
want
a
little
bit
more
low-level
control
of
things
to
to
be
able
to
be
more
responsive
to
to
the
needs
of
what
we
want
our
product
to
do,
but
yeah
enrique
can
tell
you
all
about
that
and
he's
documented
a
whole
bunch
of
stuff
in
in
the
issues
already.
So
it's
definitely
good
to
catch
up
and
all
of
that.
E
Great
and
the
reason
I
bring
that
up
is
because
this
like,
if
that's
the
direction,
that
the
less
work
we
do
making
toast
ui
work
in
in
the
front
in
the
near
term
is
the
better,
which
I
think,
that's
probably
a
reason
why
we
schedule
the
front
matter,
because
it's
less
dependent
upon
that.
While
we
sort
that
out
right
exactly.
A
Yeah
yeah,
I'm
not
I'm
not
going
to
spoil
my
my
speech
on
thursday,
but
suffice
to
say,
you'll
hear
more
about
that
on
thursday
about
the
future.
A
Just
one
last
thing
before
we
sign
off,
I
remember
now,
eric
there
was
paul
slaughter
created
a
website,
conventional
comments
which
is
done
with
higo,
and
I
actually
opened
an
issue
asking
me
if
he
would
be
okay
if
we
integrated
the
static
slide,
editor
with
that,
and
I
was
going
to
do
it
as
soon
as
we
had
the
handbook
integration
done
and
now
since
we
have
that
done.
I
think
I
just
need
to
take
that
up,
because
it
will
be
a
good
kind
of
like
exploration,
to
see
what
is
needed
to
to
adapt.
A
You
know
is
it
as
simple
as
adding
the
edit
link
to
the
site
and
and
it
works,
or
is
there
more
to
it
that
we
need
to
be
aware
of
so
I'll
it'll
be
a
good
one
to
explore
with
great
all
right
with
that
said,
is
there
any
other
thoughts
that
you
want
to
share
before
we
all
sign
off
anybody.
E
Okay,
right
I
mean
technically
I
need
to
rebase
them
r.
Hopefully,
there's
no
big
conflicts,
the
scripts.
I
wrote
automate
most
all
of
that
and
make
sure
it
passes
and
probably
do
one
final
pass
to
make
sure
I
didn't
forget
anything
and
then
pull
the
trigger.
Like
john
said,
sometimes
this
evening,
my
time.
A
So
the
one
thing
I
will
say
lauren-
and
you
might
kind
of
like
maybe
just
reach
out
to
the
marketing
side
is-
I
did
on
friday,
send
a
message
to
say
if
anybody
has
any
open,
mrs
that
they
would
like
us
to
help
them
out
proactively
to
rebase
it
that
they
should
just
add
a
link
to
the
mre
now
on
our
rollout
issue,
so
that
once
we've
done
the
the
move,
we
can
go
and
help
sort
their
emails
out
for
them.
A
Otherwise
I
guess
it'll
be
you
know
tomorrow,
we'll
get
a
bunch
of
requests
and
mr
buddies
or
handbook
or
whatever
it's
like
and
we'll
just
respond
to
them
as
they
come
in.
But
I
you
know
we
did
double
communication
on
this
already,
so
I'm
not
too
yeah.
I
don't
think
you
have
to
be
online
and
waiting
for
this
to
happen.
I
don't
think
it's
that
needed
and
we're
specifically
doing
it
after
hours.
A
E
And
our
past
experience
and
hope
is
that
git
seems
to
be
pretty
smart
about
being
able
to
handle
files
which
have
been
moved
like
before,
after
the
edit
and
during
rebases.
So
we're
hoping
this
is
minimal
disruption,
but
it's
obviously
a
lot
more
files
in
the
handbook.
So
we'll
see
famous
last
words.