►
Description
A discussion around how we proceed with dealing with the shared files between the marketing and handbook sites as we move to separating these sites into a monorepo structure.
A
Hello,
everybody.
So
this
is
a
joint
conversation
between
the
static
site,
editor
and
marketing
website
teams
to
discuss
the
mono
reaper
effect,
which
that
will
ultimately
lead
to
the
handbook
and
marketing
sites
being
their
own
independent
sites
in
the
gitlab
con
repo
we've
got
some
decisions
to
make
and
refactoring
to
do
with
regards
to
shared
assets
between
the
two
sites
and
how
we
deal
with
that,
and
this
conversation
is
to
recap
the
situation
and
then
discuss
the
approach
that
we
want
to
take
going
forward.
B
Sure,
hello,
everybody
so
I'll
paste
in
the
whoops,
the
epic
which
we
still
need
to
reorganize
things,
but
that
will
contain
most
of
it
and
the
the
topics
today
are
going
to
be
primarily
what
we're
we
still
need
to
reorganize
these,
but
primarily
what
we're
calling
phase
one.
And
then
I
wanted
to
also
talk
a
little
bit
about
this
issue,
which
has
a
lot
of
tasks
in
it
that
I'm
going
to
be
working
on
could
probably
be
split
up
into
an
epic.
We
may
or
may
not
do
that.
B
Different
areas
of
ownership,
because
we're
going
to
be
going
different
directions
with
the
handbook
versus
the
various
parts
of
the
marketing
site,
the
blog
and
everything
else-
that's
become
even
more
clear
and
urgent.
Lately
we
know
marketing
wants
to
go
to
cms
and
the
handbook
is
is
going
to
do
its
things
and
the
monorepo
approach
is
a
good
one
and
we've
covered.
C
C
B
B
And
you
can
look
at
the
description
of
it
for
a
lot
more
detail,
but
that's
the
crux
of
it
and
that
will
make
everything
else
a
lot
easier
going
forward.
So
those
should
really
and
then
the
rest
of
the
phase,
one,
which
is
the
main
purpose
of
this
discussion,
is
sort
of
talking
about
these
difficult
discussions,
and
that
is
the
that
note
that
I
pasted
in
the
other
link
to
that
note,
quick
john,
that
you
could
paste
in.
B
Are
we
either
duplicate
a
bunch
of
stuff
which
is
still
really
used
and
shared,
because
it's
all
one
site
and
there's
definitely
downsides
to
that,
like
we
change
keys
or
third-party
services
or
there's
actual
layouts,
that
we
want
to
look
the
same
like
that?
Is
something
marketing-ish
or
some
marketing
copy
that
we
show
both
on
the
marketing
side
in
the
handbook.
If
we
duplicate
that
it's
gonna
get
evolve
out
of
sync
or
there's
a
a
key,
an
adwords
key
or
something
along
those
lines
that
would
be
duplicated.
B
B
It's
not
nearly
as
quick
and
easy
as
just
duplicating
everything
and
then
in
some
cases
like
we
just
really
definitely
shouldn't
duplicate
them,
so
that
was
sort
of
what
that
brain
template
was
about,
and
apologies
it's
it's
really
hard
to
distill
this
into
any
sort
of
cohesive
and
simple
point,
because
there's
so
much
to
it.
But
I
guess
the
crux
of
this
meeting
when
I
wanted
to
get
to
is
a
on
that
issue
with
the
preliminary
stuff.
B
Just
do
a
quick
walk
through
on
that
make
sure
everybody
is
okay
with
the
direction
I'm
going
on
that
with
the
build,
because
it's
going
to
pretty
drastically
change
the
build
and
then
b
talk
through
these,
at
least
to
the
high
level
and
maybe
a
placeholder
for
another
meeting
of
what
we
want
to
do
about
the
the
split
up
and
what
our
general
opinions
and
stances
are
on
the
various
risks
and
trade-offs.
There.
A
I
I
want
to
get
to
point
two,
which
is
kind
of
like
the
what
seems
like
the
most
and
I'm
making
the
assumption
that
everybody
everybody's
had
a
chance
to
to
at
least
scan
the
stuff,
but
I
think
for
me
the
there's
gonna
be
like
for
me.
The
obvious
solution
here
is:
is
the
middle
ground,
one
where
we
have
some
things
that
we
can
duplicate,
because
it's
low
risk
and
it's
likely
going
to
change
either
on
the
marketing
or
the
handbook
side
in
the
near
term?
A
And
then,
if
I'm
talking,
near-term,
probably
talking
next
one
to
three
months,
then
there's
things
that
will
continue
to
be
shared
lightly,
potentially
even
with
the
new
marketing
website.
I'm
thinking
like
things
that,
like
compliance
things
like
cookiebot,
you
know
like
whether
we
you
know
what
it
whatever
solution
we
use
on
the
website.
You
know
we're
going
to
need
a
similar
solution
for
the
handbook
and
it
doesn't
make
sense
to
to
have
separate
things
on
there.
A
So
I
think
there's
going
to
be
this.
This
scenario,
where
there's
certain
things
we're
going
to
want
to
keep
sharing
for
a
long.
Let's
call
it
medium
term
and
longer
term
and
in
the
short
term,
there's
things
that
we
that
are
lower
risk
and
that
we're
happy
to
duplicate
and
let
it
deviate
in
its
own
kind
of,
like
course,
of
action.
A
B
And
just
just
to
jump
in
that's
sort
of
the
point
I
made
in
that
note
like
that's.
Definitely
what
we're
going
to
do
some
combination
of
the
two,
but
that's
also
not
the
easiest
way
forward,
and
it's
still
a
lot
of
individual
calls
to
be
made
on
what
is
important
and
what's
not
what
should
be
shared
and
what
should
be
duplicated
and
I'm
definitely
not
the
person
to
make
that
call
in
every
case.
So
it's
just
a
lot
of
there's
a
lot
of
minor
decisions
implied
by
taking
that
middle
ground.
A
How
do
we
determine
what
what
and
so
on
my,
I
think
the
the
obvious
kind
of
like
choice
would
would
be,
for
instance,
initially
for
michael
myself
to
make
those
calls,
but
I
am
cognizant
that
michael
is
going
on
parental
leave
soon,
so
we
need
to
we're
probably
going
to
need
you
to
delegate
your
decision
making
powers
to
to
one
of
your
team
to
standing
in
for
you
during
that
time.
Yeah.
C
A
All
right,
so
I
think
then,
let's
what
I
would
also
suggest
is
that
we
there's
this
precedent
for
setting
up
project
channels
in
slack
and
I'm
going
to
suggest
we
create
like
a
project
monoreaper
refactor
channel,
just
for
for
quick
conversations
and
bringing
things
to
each
other's
attention
and
it's
an
easy
way
to
ensure
that
everybody
gets
informed
about
the
issues
and
comments
or
whatever,
and
we
can.
You
know
like
when,
there's
a
decision
to
be
made.
We
can
slack
it
in
there
and
quickly
get
a
a
call
on
it
with.
A
A
C
Could
have
a
loose
loose
agreement
around
like
time
if
there's
like,
if
we're
putting
out
something
that
needs
an
answer
like
we
can
sort
this
out
in
that
slack
channel
or
in
a
later
conversation.
But
I
always
just
get
worried
about
bottlenecks
or
you
know
there
sometimes
just
add
decision
is
better
than
indecision
so
which
is
a
line
from
sopranos
randomly.
C
But
you
know
it's
it's
better
to
keep
moving
forward,
especially
with
something
so
complicated,
and
I
can
only
imagine
chad
if,
like
something
gets,
missed
you're
just
kind
of
sitting
there
spinning
your
wheels.
So
if
we
have
a
loose
kind
of
working
agreement
that
you
know,
I
asked
the
question
I
didn't
hear
from
it
like
an
answer
from
a
day
and
a
half
my
intuition
says
this
way.
I
went
this
way.
I
think
keeping
our
velocity
up
with
this
is
pretty
important.
C
B
B
C
E
E
It's
a
very
automated
process
that
product
has
put
together
for
themselves
over
time
and
they've
spent
a
lot
of
effort
in
it.
So
I
wouldn't
necessarily
move
that
to
the
cms.
It
may
share
certain
things
like
styles
or
whatever,
depending
on,
if
they
ask
us
to
update
it,
but
I
imagine
that
is
kind
of
even
though
it's
currently
built
using
blog
technology
like
it
might
become
its
own
thing
as
well.
E
A
That,
as
far
as
as
far
as
I
understand
just
sorry,
try
to
interrupt
they're
working
towards
building
a
feature
in
gitlab
the
product
to
handle
release
posts
and
stuff.
So
I
would
how
it
kind
of
like
ends
up
on
the
website.
I
don't
know
yet,
but
the
from
a
data
management
and
an
input
point
of
view,
they're
they're,
looking
to
build
that
into
the
product
and,
for
instance,
read
that
data
from
issues
and
and
so
on.
B
You
have
to
find
those
and
get
rid
of
them
or
and
isolate
them
only
to
with
under
the
blog
path
and
everywhere
else
do
something
different,
whether
it's
an
iframe
or
just
linking
to
the
page,
or
something
like
that.
So
we
can,
as
an
action
item
coming
out
of
this
meeting,
definitely
say
that's
a
part
of
this.
That
y'all
can
tackle
and
and
start
helping
with
whenever
you're
ready,
because
you
definitely
have
to
do
it
for
the
cms
move.
C
Yeah-
and
I
think
just
just
to
be
clear-
I
I'm
not
100
super
clear
on
this,
but
the
way
I'm
holding
it
is
that
blog
will
be
cms,
as
will
the
about
dot
pages.
So
whether
that's
the
same
cms
or
it's
broken
into
two
for
build
purposes,
totally
open,
but
just
want
to
make
sure
I
don't
even
know
which
order
we're
going
to
go
after
them
yet,
but
that
probably
would
make
sense
to
phase
it.
But
both.
B
D
B
B
E
B
Sure-
and
it's
mainly
just
to
make
sure
you're
there's
nothing
in
there
that
I'm
because
I'm
planning
on
cranking
through
that
as
fast
I
can
over
the
next
week
or
so
without
very
many
reviews.
So
if
there's
anything
in
there,
that's
like
no
that's
a
bad
idea.
Don't
do
that!
You
should
let
me
know
one
thing
at
the
bottom
of
that
list,
which
we
we
can
even
make
another
point
here,
I'm
just
going
to
insert
it.
B
A
C
E
That's
the
only
use,
I'm
aware
of
the
only
thing
I
can
think
of
moving
forward
as
we
may,
when
we're
building
out
a
cms
needs
something
similar,
but
we
can
evaluate
at
the
time
you
know
I
don't
know
that
it
needs
to
be
that
stage.
It
wouldn't
be
that
staging
environment.
I
don't
think
it
would
be
like
some
other
environment
but
yeah.
The
only
other
use
I'm
aware
of
is
the
redirects
like
lawrence.
B
So
the
one
of
the
two
times
that
I
tried
to
do
redirect
and
it
was
when
sid
was
waiting
on
it.
It
was
an
emergency,
it
actually
didn't
work.
It
worked
on
the
staging
site
and
did
not
work
when
I
deployed
it
to
prod
so
there's
I
don't
think
they're
configured
the
same
and
do
they
does?
Is
it
used
that
often
or
can
you
just
say
you
know
you
test
them
on
pride
and
if
they're
not
right,
you
try
to
get
them
right
again
like
is
it
providing
that
much
value?
B
E
Yeah,
I
think
that
makes
sense,
at
least
from
my
perspective,
I've
kind
of
wondered
since
I
got
here
because
my
previous
company,
we
would
always
run
into
issues
where
you
know
the
test
environment
was
never
configured
exactly
the
same
as
production.
So
like
it's
good
to
have
that
parity
for
sure
and
yeah,
I
don't
know
how
it
like.
You
said
it's
configured
right
now,.
B
Because
it
it
is
going
to
add
extra
work
and
complexity
to
the
the
cleanup
that
I'm
trying
to
do.
What
I'm
trying
to
do
is
make
the
deploy
step
just
go
away,
so
the
review
app
will
definitely
go
away,
but
all
that
will
be
left
and
and
making
things
more
complex
and
take
more
time
as
the
room
is
staging.
B
D
B
D
D
B
A
D
Yeah
this
is,
I
was
just
wondering
if
there's
an
issue
or
epic
created
for
moving
the
marketing
site
into
its
own
subsite,
since
we've
done
the
blog,
but
we
need
to
put
it
all
together
and
I
would
love
to
work
with
chad
on
doing
that.
Just
so,
I
can
really
understand
all
the
code
that
went
into
the
monorepo
and.
D
A
So
my
my
assumption,
and
and
chad
you
can
correct
me
from
wrong-
was
that
the
blog
would
essentially
just
become
marketing
right
now
and
contain
everything-
that's
not
handbook,
so
we
wouldn't
create
a
third
site
at
this
point.
It
would
all
just
be
what
two
got
two
sites.
Essentially,
we
do
need
to
clean
up
some
of
these
issues
and
ethics,
but
things
have
changed
quite
rapidly
over
the
last
while
and
and
they're
not
all
reflect
reflecting
the
reality
of
what
we're
planning.
A
So
we
do
need
to
clean
up
and-
and
I
think
in
terms
of
you
being
involved
in
the
process-
I'm
definitely
for
that.
I
obviously
have
a
key
man
dependency
on
chad
at
this
stage,
so
the
bus
hits
him
like
it's,
not
great
and
so
having
a
second
pair
of
eyes
following
him
along
would
be
would
be
great
and
I'll.
Leave
that
up
to
the
two
of
you
to
figure
out
how
best
to
to
work
on
this
together,
you
know
whether
it's
through
reviews
or
pairing
or
whatever.
B
So
this
the
step
back
and
reapproach
of
it
is
this
new
phased
approach
which
we
haven't
reflected
in
the
epics
yet
because
I
just
we
just
talked
about
it
in
the
middle
of
last
week
and
the
the
crisis
at
the
beginning
of
that
is
what
lives
in
that
issue.
The
ad302,
and
one
of
the
main
points
of
that,
in
addition
to
splitting
up
into
separate,
builds,
is
at
the
end
of
that
we'll
be
able
to
just
delete
all
of
the
blog,
siblings
and
it'll
no
longer
be
a
monorepo
site.
A
B
B
E
Yeah
so
just
kind
of
at
the
bottom
of
that
refactor
separation,
decoupling
issue,
it
says,
remove,
review
and
deploy
jobs,
and
I
know
there's
a
lot
of
stuff
gone
over
above
that,
but
I'm
just
kind
of
wondering
what
exactly
that
entails
like
what.
Why
are
they
no
longer
needed
at
that
point,
like
I'm
just
kind
of
not
getting
that
part
of
the
flow,
I
guess.
B
Sure
the
crux
of
it
is
like
every
part
of
the
site.
You
build
whether
it's
like
everything
under
handbook
for
everything
under
blog,
which
you
do
via
cms
or
everything
else,
everything
under
releases
everything
else.
That's
not
under
those
those
are
going
to
be
independent
jobs
in
ci,
and
now
they
all
the
way
it
works.
All
of
those
independent
jobs
build
their
stuff.
They
pass
it
along
to
the
artifacts
to
this
deploy
job.
B
The
new
approach
which
is
in
this
issue
is
each
of
those
jobs
when
they're
done
building
it
they're
just
going
to
deploy
that
part,
and
the
crux
of
that
is
instead
of
the
main
deploy
like
deleting
everything
that
doesn't
need
to
be
there.
That's
sort
of
going
to
get
moved
out
to
this
scheduled
job,
that
does
it
cleans
up
old
files
out
of
band
and
each
part
of
the
site
that
you
build
will
also
just
incrementally,
deploy
that
and
so
that
that
approach
also
is
intended
to.
B
B
B
Each
job
is
going
to
build
and
deploy
the
part
of
the
site
that
it
needs,
and
then
that
lets
you
move
those
around
like
legos,
you
can
move
to
a
different
site.
You
can
make
him
build
something
differently.
You
can
make
him
deploy
differently
as
long
as
the
end
result
of
that
is
those
files
end
up
in
the
bucket
in
the
right
place.
B
B
And
this
also
lets
us
in
some
cases,
not
all
of
them,
but,
for
example
like
in
the
images
we
can
say,
if
none
of
the
images
change
we
don't
need
to
build
them,
which
is
one
of
the
slowest
ones
for
other
things.
As
long
as
everything
is
still
using
middleman,
it's
more
like
I
don't
know
you
still
have
to
build
it.
If
anything
changed,
because
you
don't
know
what
you
could
have
been
sharing
cool.
E
D
B
B
B
A
All
right
recapping,
so
we've
decided
our
decision
making
pro
on
our
decision
making
process
when
it
comes
to
technical
implementation.
Matters
we'll
take
a
bias
to
action
and
implement
as
base
determined
but
share
changes
made
with
the
broader
group
so
that
everybody
stays
informed
if
anything
impacts
functionality,
content
or
is
here
it
needs.
Oh.