►
From YouTube: Recap sprint 5 marketing design system
Description
Related epics, issues, and merge requests :
Related OKR: https://gitlab.com/groups/gitlab-com/marketing/growth-marketing/-/epics/92
Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/
A
A
B
Yeah,
so
I
think
we
did
a
good
job
of
picking
up
new
tasks
quickly.
So
thank
you,
everyone
for
that.
There's
kind
of
a
lot
of
chaos
going
on
previous
week
in
this
coming
week
and
so
kind
of
the
second
item
to
that
is
thanks.
Everyone
for
volunteering
to
help
out.
B
You
know
sammy
for
helping
with
cms
and
picking
up
the
the
banner
and
tyler
for
you
know,
jumping
in
and
helping
hobby
with
setting
up
the
review
apps
for
the
slippers,
repo
and
stuff
like
that
and
laura
for
you
know
she
saw
a
couple
bugs
mentioned
in
slack,
and
you
know
other
things
so
and
jess
and
everyone
for
you
know,
jumping
on
the
design
files
kind
of
last
minute
requests.
B
So
I
just
wanted
to
thank
everyone
for
being
flexible
this
time
and
I
think
we
did
a
good
job
of
that.
C
Thank
you
brandon,
so
this
week
has
been
very,
very
interesting.
I
was
able
to
use
my
to-do
list
very
smart,
very
much
more
smarter,
so
I
was
going
through
all
my
lists
to
clean
out
a
lot
of
tasks
that
was
assigned
to
me
this
week.
Tina
was
on
another
level.
She
just
kept
assigning
stuff
to
me,
like
almost
eight
of
them
in
a
day,
so
that
was
awesome.
It
really
improved
my
speed
and
leading
to
work
much
more
smarter
and
secondly,
I
had
a
very
good
collaboration
on
the
ibm
announcement.
C
I
really
loved
that
I
pushed
something
live
earlier
than
the
for
first
time
and
everybody
came
around
to
quickly
help
me
out
so
that
we
can
correct
things.
So
I
really
want
to
send
a
big
shout
out
to
tina
and
lauren
yeah.
She
was
super
helpful
this
morning.
I
like
that
and
brandon
also
jumped
on
immediately
when
we
noticed
that
I
pushed
something
much
more
earlier
and
we
quickly
fixed
that
that's
amazing
thank
you,
everybody
and
also
to
danielle
and
danielle
and
sarah.
They
were
very,
very
helpful.
C
I
love
the
way
we
collaborate
together.
It's
highly
very
productive.
The
next
thing
I
want
to
discuss
about
is
the
storybook.
C
So
since
last
week
we've
been
trying
to
integrate
how
we
can
use
readme
files
directly
in
storyboard,
but
because
I
was
doing
a
lot
of
different
stuff
and
I'm
going
through
a
learning
curve
of
storybook
because
there's
actually
limited
documentation,
but
right
now
I'm
happy
that
at
least
we
can
get
it.
I
don't
want
to
walk.
I
can
test.
I
know
that
it's
working,
but
now
I
need
to
just
spend
some
time
to
flesh
it
out
a
little
bit
so
that
it's
going
to
be
easier
for
everybody
to
use
in
the
future.
A
Yeah,
I'm
up
next,
so
a
couple
things
I
thought
went
really
well
this
week.
On
my
end,
I
felt
like
we
had
an
improved
handoff
from
design
to
development
regarding
the
pricing
page
versus
like
the
home
page
working
on
before.
Obviously,
that's
a
two-way
street,
so
brandon
doesn't
feel
that
way.
Let
me
know,
but
I
felt
like
it
was
a
little
bit
easier
kind
of
more
controlled,
more
versioning
going
on,
which
was,
I
think,
will
be
helpful
in
actually
getting
it
implemented.
A
I'm
also
pretty
psyched,
because
this
is
really
the
first
full
page
that
our
team
is
going
to
own
from
top
to
bottom.
We
aren't
really
relying
on
the
old
way.
It
was
so
much
or
the
old
system
and
it's
kind
of
exciting
to
actually
get
something
out
there,
that's
fully
ours
and
I'm
stoked
about
that
also
finally
got
access
to
user
testing.
A
Just
yesterday
I
got
the
go
ahead,
so
we'll
hopefully
launch
something
today.
I
also
want
to
shout
out
some
really
quick
turnarounds.
We
have
the
ibm
announcement
that
sanji
was
just
talking
about
great
job
there.
A
We
also
have
another
global
notification
coming
up
it's
confidential,
so
we
can't
talk
about
what
it
is,
but
I
just
really
want
to
shout
out
laura
because
she
did
it
super
quickly
and
it
was
perfect.
I
had
no
feedback
for
her
whatsoever,
so
great
job
there,
and
we
also
have
a
couple
team
issue
templates
now,
which
is
kind
of
cool,
also
shout
out
to
becky.
She
made
one
of
those
for
us
and
brandon
and
tyler
were
really
helpful
on
those
tyler
helped
me
do
my
first
ever
commit
so
thank
you
yeah.
A
Those
are
my
things
that
went
well
and
I
think
javi
are
you
up
next.
B
D
So
I
just
wanted
to
say
I
wanted
to
shout
out
the
people
that
worked
while
we
were
supposed
to
be
like
on
holiday.
So
like
that
time
where
everyone
else
was
away
and
people
were
so
around,
I
just
wanted
to
cut
that
out.
D
Something
that
I
thought
also
went
well
in
regards
specifically
to
storybook
is
that
storybook
was
designed
for
kind
of
like
a
component
library,
so
I
ended
up
using
a
view
render,
instead
of
using
what
I
was
using
originally
was
html,
and
I
think
that
not
only
is
the
community
like
bigger
in
that
the
documentation
is
like
starting
to
get
a
little
better.
It's
a
little
more
clear,
which
I
think
helps
a
lot
yeah,
because
it's
a
little
closer
to
react,
which
is
what
I
would
say
what
storybook
felt
like
it
was
designed
for.
D
First,
because
all
the
documentation
is
react
first
and
so
the
transition
from
going
from
view
like
to
making
that,
like
mental
jump
from
a
react
like
react,
dock
to
a
view,
dock
is
like
a
little
easier
and
a
lot
more
readable
than
just
trying
to
see
how
a
native
browser
would
render
some
of
those
things.
So
all
of
that
stuff,
I
think,
is
helping
us
out
laura
you're
up
next.
A
Yeah,
I
just
wanted
to
shout
out
to
you
javi
for
the
slippers
repo
existing
in
its
own
world
now,
which
is
a
dream
for
me
to
come
in
and
spin
up
my
own
local
environment
with
it.
So
that's
awesome
to
see,
and
I'm
excited
to
to
contribute
to
that
and
other
than
that.
I
was
able
to
pick
up
some
smaller
tickets
and
kind
of
get
to
know
my
way
around
the
the
website
and
where
all
the
file
files
are
located
with
plenty
of
help
from
brandon.
A
So
thank
you
for
answering
all
of
my
questions
and
hopping
on
calls
to
to
guide
me
through
some
of
the
where
things
exist
and
guiding
my
way
through
the
project.
A
No,
there
are
no
other
things
that
went
well
this
week
and
we'll
move
on
to
things
to
improve
on.
So
we
just
have
a
couple
so
tyler.
I
think
you
have
the
first
one
there
you
want
to
talk
about.
What's
going
on.
E
Yeah,
I
think
that
since
so
much
of
our
sprint
work
is
going
to
be
working
around
slippers
and
the
slippers
repository,
I
think,
there's
I'd
like.
I
still
have
a
few
outstanding
questions
about
just
the
workflow
stuff.
E
We
have
so
many
issue
templates
and
merge
request,
templates
and
processes
in
place
in
the
existing,
like
www
repo,
that
we
don't
have
in
slippers,
and
just
you
had
some
suggestions
last
time
we
talked
about
this,
so
I'm
hoping
we
can
tackle
a
few
of
those
moving
forward,
but
I
just
want
to
get
us
to
process
parity
as
quickly
as
possible,
because
I
know
that's
really
important
here
and
I
think
that's
just
a
it'll
be
an
investment
in
our
future
success
with
this.
E
Yeah
yeah
for
sure,
did
you
want
me
to
jump
to
those
or.
A
Yeah
I
mean
yeah
they're
related
just
to
make
sure
if
we
have
a
something
that
went
wrong.
We
kind
of
try
and
make
an
action
item
for
it,
but
looks
like.
E
Yeah,
thank
you
yeah,
so
that
second
action
item
for
me
is:
you
had
suggested
that
we
can
do
like
epics
in
the
main
project
and
then
do
sub
epics
through
slippers
and
then
track
slippers
issues
up
to
okrs
or
whatever
other
metrics
make
sense
to
be
tracking
for
the
team.
So
I
think
in
this
upcoming
iteration
I
will
take
a
look
at
that
and
kind
of
we
have.
B
I
just
want
to
say
I
like
the
tyler's
thinking
about
that,
because
I
think
that'll
be
helpful
and
it's
something
you
know
these
communication
things
we
just
kind
of
get
into
the
flow
of
doing
what
we've
been
doing
and
not
really
thinking
about
what
we
should
be
doing
and
also
you
know
kind
of
relates
to
jess's
earlier
mention
of
you
know
things
that
went
well
building
new
templates,
so
yeah
just
keep
on
thinking
about
how
we
want
to
organize
our.
A
Work
and
sami:
do
you
want
to
talk
about
this
number
two
here.
C
Yes,
so
about
things
we
can
improve
on
what
I
notice
is
that
we
need
to
find
time.
I
may
propose
that
maybe
we
should
schedule
like
a
workshop
between
all
the
front-end
developers
and
people
on
the
ux
so
that
we
can
discuss
how
we
want
to
name
some
of
the
things
that
we
use.
For
example,
if
random
is
working
on
the
pricing
page.
Is
writing
some
classes
that,
if
I
am,
if
I
don't
work
on
the
pricing
page
I'll,
be
writing
another
set
of
classes
for
the
same
thing.
C
So
if
we
can
all
come
together,
we
can
have
that
small
transition
and
transparency
between
all
the
things
that
we
are
using,
and
I
think
brandon
also
raised
the
same
discussion
of
slack
earlier
today.
So
those
I
think
we
need
to
improve
on
that
area,
and
we
can.
We
need
to
do
it
as
soon
as
possible.
A
Yeah-
and
I
we
have
sorry
do
we
have
a
point
for
that
yet
for
interaction
items.
I.
B
I
was
just
going
to
say
I
made
one
as
while
you
and
sami
were
talking
so
number
six.
You
know
to
codify
the
figma
files
into
css
kind
of
starting
with
the
font
stack,
I
should
say
reusable
css,
so
one
of
the
things
we've
been
doing
is
you
know,
just
kind
of
taking
the
figma
files
and
and
translating
them
to
a
page
and
not
really
integrating
that
into
a
design
system.
B
Even
though
we
have
you
know
a
section
of
modifiable
chunk
of
css
that
we
could
reuse
right,
it's
not
really
built
that
way,
yet
so
we're
kind
of
slowly
transitioning
into
reusable
modules
that
everyone
can
share,
and
so
that
was
kind
of
the
you
know
like
three
minutes
before
this
video.
On
slack
I,
as
I'm
working
on
the
the
pricing
page
update,
I
looked
and
noticed
you
know,
there's
a
delta
between
the
original
enterprise
design
and
the
current
state
of
the
figma
files
and
the
current
state
of
the
code.
B
A
A
Okay,
I
think
that
was
it
for
the
things
that
didn't
go
well,
so
we
have
some
other
action
items
here.
Tyler.
Do
you
want
to
talk
about
number
one.
E
Yeah
we
got
some
work
done
on
our
gitlab
pages
for
slippers
and
the
review
app
and
brandon
had
mentioned
doing
a
little
write-up
about
that.
Excuse
me,
so
I
think
I'm
gonna
and
I
had
a
few
other
things
this
week
that
were
kind
of
interesting
and
like
a
couple
like
deep
dives
into
just
like
playing
around
with
some
internals
of
our
tools.
So
I'm
going
to
do
a
couple,
quick
write-ups
and
I.
B
E
Push
it
to
unfiltered
seems
to
be
the
place
to
do
that
so
yeah,
that's
my
that's
something
on
my
list.
I'm
excited
about!
I'm
also
happy.
If
anyone
else
wants
to
like
either
jump
in
or
like
volunteer
to
do
like
a
first-round
edit
or
something
so.
B
A
C
Sorry
yeah
so
this
week,
I'm
planning
to
add
in
the
migration
of
topic
pages,
so
I
was
expecting
the
video
that
tyler
promised
and
he
made
a
comment
recently
that
the
video
should
be
ready
very
very
soon,
so
that
we
can
have
an
idea
of
what
they
are
doing
behind
the
scenes.
So
I
can
be
able
to
opt
in
and
help
them
out
to
migrate.
Some
of
these
topic
videos,
and
secondly,
during
this
week
I'll
also
be
working
with
javi
on
the
storybook.
C
E
Yeah
see
we
recorded
that
video
right
before
this
call,
so
when
it's
up
I'll
make
sure
it's
shared,
and
I
also
I
did
some
netlify
cms
documentation
in
the
repo
so
I'll
drop
that
link
there
too.
So
it's
easy
to
get
to
when
you're
doing
that
work.
A
Right,
javi
you're
up
next
number,
four.
D
Yeah
I
wanted
to
talk
about
using
the
prefix
of
the
at
gitlab
for
npm,
because
the
way
that
like
official
packages
forget
lab
work,
is
that
they're
prefixed
with
like
that
in
front
of
it,
essentially
to
show
that
it's
like
legitimate
and
not
just
like
some
random
person,
because
it
doesn't
take
much
to
publish
an
npm
module.
D
So
I
just
wanted
to
make
sure
that
we
call
out,
like
figuring
out,
how
to
get
that
set
up
and
then
on
a
related
note,
because
we're
going
to
be
doing
this
at
some
point
eventually
is
how
to
integrate
that
project
with
about.getlab.
D
And
how
should
we
go
about
it
in
terms
and
what
I
mean
by
this
is
like:
should
we
introduce
it
to
a
page
at
a
time?
Are
we
going
to
do
more
of
a
switch
where
we
just
like
you
know,
just
switch
everything
over
I'm
kind
of
curious
that
that
would
make
sense.
I
guess
maybe
even
to
the
point
of
where
it
is
right.
Now,
it's
mostly
just
buttons
right
now.
So
it's
like.
D
E
Okay,
I'll
give
sort
of
what's
in
my
head
and
what
I've
done
in
the
past
with
like
or
tried
to
do,
I
feel
like
it
doesn't
shake
out
quite
as
well
as
this.
This
vision
right
but
like
I
think
this
is
in
my
mind,
like
the
ideal
path,
is
that
it
there's
like
a
virtuous
cycle
right,
so
we
field
requests
for
the
marketing
site
or
related
projects
that
slippery
like
that
are
in
the
slippers
domain
or
like
can
be
helpful
from
slippers
and
then,
where
there's
appropriate
fits.
E
So
if
we
get
let's
say
we're
working
on
a
figma
file
that
has
new
stuff
in
the
design
system,
we
use
that
to
drive
like.
What's
the
next
thing
we
build
in
slippers
right,
so
the
slippers
repository
has
that
storybook
and
it's
like
you've
got
the
sigma
file
and
it's
got
a
bunch
of
these
slippers
elements.
We
haven't
yet
created
them.
We
build
what
we
need
out
of
there
and
I
think
that
fits
really
nicely
with
the
sort
of
you
know:
minimum
viable
change
strategy
and
then
and
then
like.
E
We
pull
that
into
the
original
request.
So
up
front.
It's
like
a
little
extra
lead
time
for
the
first
couple
ones
of
these
that
happen,
but
then,
once
we
get
into
the
swing
of
things
and
we've
handled,
you
know
two
or
three
larger
updates.
We
should
have
more
of
those
utilities
like
ready
to
go
and
there
should
be
less
of
that
upfront
work
and
then
slippers,
like
the
progress
we
make
on
the
slippers
repository,
will
reflect
sort
of
like
the
the
most
critical
requirements
at
the
moment.
E
Right
and
it'll
keep
it
sort
of
that
like
living
design
system.
So
that's
that's
kind
of
what
I
have
in
my
head.
I
haven't
really
done.
I
don't
think
I've
done
any
actual,
like
visual
changes
to
the
marketing
site.
So
I
don't
know
enough
about
what
that
workflow
looks
like
to
know
if
that's
a
realistic
expectation,
but
in
my
ideal
world.
That
is
how
I
would
do
that
work.
B
Yeah,
I
think
once
we
get
to
a
solid
point
with
slippers
in
terms
of
you
know,
having
all
the
infrastructure
in
place.
I
think
that
workflow
makes
sense,
and
you
know,
while
it
would
be
nice
to
say,
replace
all
the
buttons
at
once
based
on
my
experience
in
my
previous
company.
It
doesn't
really
work
that
way,
it's
more
of
a
page
at
a
time
kind
of
thing.
Unfortunately,
without
a
larger,
you
know
kind
of
company-wide
systemic
driver,
it
usually
ends
up
being.
I
need
this
project
worked
on,
and
so
you
say:
okay.
B
Well,
I
want
to
build
this
project
with
the
new
system
rather
than
the
old
one,
because
the
idea
is
that
we're
going
to
start
doing
that.
So
it's
you
know
more
piecemeal
where
we
can
do
it
more
of
a
system
at
a
time
is
like
the
cms
and
templates
saying
like
we're
building
this
new
template.
All
of
these
pages
are
going
to
be
built
with
it.
That
button
is
going
to
be
applied
to
maybe
100
pages,
because
they're
all
built
with
that
template
so
yeah.
D
Yeah,
it's
perfect.
Thank
you
all
right
and-
and
I
also
have
the
next
one-
and
I
just
wanted
to
briefly
talk
about
how
developers
are
using
slippers.
D
So
back
when
I
was
first
starting
to
get
integrated
to
this
team,
I
created
an
issue
to
talk
about
kind
of
just
guess
what
you
call
developer
experience
and
what
it
is
that
people
go
through
in
order
to
make
changes
to
about,
and
I'm
making
like
the
assumption
here
that
people
are
just
copy
copy-pasting
code
snippets
in
terms
of
like
what
would
happen,
especially
for
people
that
aren't
as
codeliver.
I
don't
know.
D
I
guess
this
is
just
like
my
way
of
like
what
do
we
know
about
the
people
that
push
to
the
repo.
Obviously,
there's
lots
of
merge
requests
and,
like
I'm,
just
wondering
what
these
people
go
through.
What
is
the
experience
level
like
things
like
that,
like
in
my
head?
I
don't.
I
haven't
even
considered
that,
like
other
people
will
have
to
use.
D
That's
like
really
the
power
of
it
is
not
when
we
use
it,
but
it's
like
when
everyone
else
that
is
pushing
to
the
repo
is
also
using
it,
not
just
like
our
team
so
trying
to
figure
out.
Like
all
of
that
stuff,
I
think
is
like
something
that
I'm
thinking
about.
There's
also
like
the
related
discussion,
if
like
camel
in
particular
of
like
is
that
is
that,
like
what
we've
decided?
That's
like
our
approved
way
of
templating
going
forward
and.
E
D
B
I
would
say
my
gut
would
be
that
for
the
less
code
interested
people,
they
would
probably
more
likely
be
using
the
cms
or
you
know
not
creating
new
pages
or
creating
issues
for
us
to
create
new
pages.
B
But
for
you
know
some
of
our
more
seasoned,
coders
or
people
who
know
how
to
code
like
they
would
probably
look
at
examples.
We
have
posted
in
the
design
system
in
slippers
in
storybook
and
you
know
be
able
to
copy
paste
the
code
in
terms
of
hamel
versus
not
haml.
I
mean
since
we're
so
integrated
with
ruby
and
hamel.
B
At
the
moment
I
don't
see
us
moving
away
short
term
and
I
know
that
the
cms
is
being
built
with
you
know:
templates
are
being
built
with
haml
and
stuff
like
that,
so
you
know
I
think
it
makes
sense
to
explore.
Can
we
use
hamel
in
storybook,
but
also
you
know
who
knows
what?
A
year
from
now
we
may
be
going
to
view
or
whatever
else
but
yeah
I'd,
say
short
term.
That
makes
sense
if
it's
possible,
but
yeah.
These
are
all
the
things
to
think
about
and
we
don't
have
to
decide
today.
Yeah.
E
I
would
throw
my
hat
in
the
ring
for
not
doing
hamel
for
the
output,
because
hamel
has
like
such
a
one
to
one
with
html
and
like
ht
like
we
might
change
haml
like
we
might
not
use
hamel,
we
might
not
use
it
in
some
places
and
use
it
other
places.
Hamel
might
change.
Html
won't,
and
I
think
that
if
the
code
snippets
spit
out
html
and
you've
got
people
who
are
working
in
hamel,
I
think
it's
a
reasonable
ask
to
have
them.
E
Do
the
translation
in
their
at
least
keep
that
out
of
the
storybook
itself?
Perhaps
we
build
some
helpers
that
are
like
external
to
this,
so
if
you
want
to
like
maybe
there's
like
a
nice
little
node
script,
that
like
says,
hey
like
hamilthi
this
output
or
something
like
that,
but
I
think
storybook
like
when
I
think
about
storybook
and
tools
like
that.
I
want
it
to
be
sort
of
a
canonical
reference.
E
B
Yeah,
no
sorry
that
that
totally
makes
sense.
I
wasn't
thinking
about
it.
In
terms
of
that
perspective,
the
outputted
examples
it
would
be
great
to
have
an
html
but
anytime
we're
giving
them
an
example.
That
says
you
need
business
logic
in
it.
You
know
our
business
logic
comes
from
hamel
at
the
moment,
so
you
know
if
we
had
an
example
that
needed
that
sort
of
thing
then
maybe
have
it
in
hamel
but
yeah.
D
I
think
that
would
be
really
cool
if
we
could
get
it
to
work,
and
I
don't
think
it
would
be
that
complicated
to
be
honest,
because
just
all
you're
doing
is
taking
html,
that's
rendered
and
then
switching
it
to
hamel.
So
it's
just
finding
a
way
to
do
that
and
then
showing
it
on
a
page.
So
that's
something
that,
like
is
probably
not
super
high
priority,
but
like
at
some
point.
D
B
Yeah
so
one
of
the
things
number
six
we
we
talked
about
earlier
already,
which
is
the
the
figma
and
the
css
but
number
seven.
B
We
ran
into
you,
know
something
this
morning
where
the
timing
of
ruby
code
versus
gmt-
and
you
know
so
that
kind
of
thing
ended
up
having
a
bug
released,
live
which
is
totally
fine.
You
know
bugs
happen
and
mvc
and
all
that
kind
of
stuff,
and
it's
not
the
only
instance
of
qa
related
stuff.
So
in
the
past
it's
been
like,
oh
you
know,
I
I'm
trying
to
think
of
the
example
that
happened
to
me
recently
and
I'm
totally
blanking
on
it.
B
But
from
time
to
time
we
do
get
qa
things
that
are.
We
do
get
bugs
where
it
would
be
great
to
have
that
extra
layer
of
qa
testing
to
catch
it,
and
you
know
there's
a
little.
We
can
do
internal
right,
but
ultimately
we
don't
want
a
developer
to
be
responsible
for
reviewing
their
own
code,
and
you
know
I've
mentioned
this
to
michael
and
I
don't
have
an
answer
at
the
moment,
but
it's
just
something
to
think
about,
like
I
feel
like
we're
in
a
pretty
decent
spot.
B
All
things
considered
in
terms
of
you
know
we
do
pure
code
review.
We
have
the
designers
look
at
things.
We
have
copy
editors
looking
at
things,
so
so
all
the
eyes
on
the
page
do
tend
to
improve
the
qa
of
it,
but
like
I'm
totally
open
to
suggestions,
if
anyone
has
any
ideas
on
how
we
can
improve
our
qa
and
testing
for
the
you
know
releases
that
we
do
to
the
website.
B
That
would
be
great
and
then
kind
of
a
sub
bullet.
Of
that
point,
is
you
know,
sort
of
a
long
term
question
of
as
we're
building
out
slippers,
and
you
know
tools
like
storybook
and
node
modules
and
whatever
long
term,
we
might
want
to
consider.
How
are
we
going
to
test
these?
Do
we
need
to
test
them
automated
automatically?
You
know
when
and
where
do
we
want
to
do
that?
B
So
again,
I
don't
have
the
answer
right
now,
but
it's
something
to
keep
thinking
about
in
the
back
your
mind
and
then
to
the
next
bullet.
Point
tyler's
question
about
you
know:
what
tools
are
we
already
using?
There
are
a
few
integration
tests.
B
They
tend
to
be
with
more
business
logic,
oriented
stuff
that
needs
to
work
like
our
integration
with
job
boards
that
we
don't
really
use
anymore,
but
we
did
for
a
while
handbook
tests
to
make
sure
that
you
don't
point
to
invalid
jobs
or
countries
or
things
like
that,
so
there's
minimal
stuff-
and
you
mentioned
that
you're
familiar
with
cyprus.
I
am
too,
I
love
cyprus,
I'd
love
to
get
it
in
there.
B
I
think
at
some
point
I
asked:
how
can
we
get
this
integrated
with
our
ci
file
and
ultimately
it's
not
something
that
has
been
explored,
but
you
know
it's
it's
something
we
can
consider,
maybe
someday.
We
want
to
do
visual,
automated
regression,
testing
right
part
of
the
considerations
we
have
to
think
about
are:
where
do
we
want
the
coverage
and
will
this
impact
productivity?
B
So,
like
you
know
anytime,
for
example,
right
and
where
are
the
warnings
and
where
are
the
errors
right
so
like
right
now
any
we
get
hundreds
of
people
editing
the
handbook
a
day.
If
we
introduce
a
test,
maybe
it
starts
impacting
the
deliverables
for
the
handbook
and
maybe
we're
causing
extra
trouble
so
probably
not
applying
things
across
the
board.
But
it
is
good
to
think
about
testing
in
qa
and
automation
and
stuff,
like
that.
So
yeah.
E
B
Yeah
or
that,
thank
you
that
that
reminds
me
of
the
part
that
my
mind
wandered
off
in
the
past.
We've
had
people
update
pages
without
our
knowing
and
they
totally
break
styles
or
javascript,
or
something-
and
you
don't
find
out
for
a
month
and
then
it's
like
well,
you
know
we
lost
all
that
traffic
or
whatever
so
so
yeah.
But
I
think
that
is
an
excellent
point.
If
we
introduce
that
kind
of
stuff
into
storybook,
it'd
be
much
easier
to
do.
Visual
regression,
testing
and
things
like
that,
so
cool.
D
Yeah
there's
some
add-ons
that
come
with
it
that'll.
You
know
I
haven't
looked
into
a
whole
ton
but
stuff,
that's
literally
like
it'll,
take
a
snapshot
and
then
it'll
compare
the
snapshot
against
another
snapshot,
so
you
can
literally
see
like
oh,
like
or
internet
browser
like
for
the
this
type.
This
happens
with
this
code
change
like
and
it'll
like
pass
or
fail
a
test.
So
it's
really
interesting.
I
haven't
looked
too
much
into
it
or
how
it
works,
but
that's
just
something
I
thought
I'd
call
out.
A
Yeah,
the
the
snapshot,
testing
that
you
were
mentioning
would
be
something
that
would
be
ideal
to
have
kind
of
one
more.
A
more
finished
state
like
a
v1
release
of
slippers
when
we're
done
messing
around
with
it,
and
it's
in
a
pretty
ready
state
to
use
that'd
be
great,
because
until
then
we're
going
to
be
changing
it
constantly
and
then
yeah
using
percy
or
using
any
other
kind
of
test
like
stateless
testing.
A
So
being,
I
guess,
void
of
any
state
in
an
application,
especially
if
we're
using
something
like
view
doing
basic
checks
to
make
sure
that,
like
oh,
if
I
click
on
a
button
for
a
tool
tip,
does
that
tooltip
appear
in
the
dom.
You
know
just
like
really
basic
kind
of
functional
testing,
but
but
not
actually
relying
on
any
state
in
the
application,
but
we
can
implement
all
of
that.
B
Sorry,
just
one
more
thing
I
thought
of
for
the
testing
too.
We
also
want
to
make
sure
that
it
doesn't
become
a
time
time
sink
for
resources
right
like
theoretically,
it
would
be
awesome
to
get
all
that
stuff,
but
maybe
we
don't
do
it
until
we
have
a
full-time
automation
engineer
who
can
you
know
maintain
these
things
right?
It's
one
thing
to
build
it,
it's
another
thing
to
keep
it
running,
it's
kind
of
similar
to
design
system
right.
B
D
D
Quickly,
because
I
see
that
I'm
the
next
one
is
that
there's
like
the
static
site,
generator
discussion
that
like
needs
to
happen
like
at
some
point,
and
so
we
should
like
plan
to
have
it,
because
it's
like
a
lot
to
talk
about
and
it's
stuff
that
it's
not
like
super
pertinent
right
now,
but
at
some
point
it's
just
it's
good
to
have
that
discussion,
especially
because
there's
a
lot
of
implications
longer
longer
term.
So
I
just
wanted
to
call
that
out.
D
I
would
suggest
that,
like
kind
of
similar
to
what
we
did
for
god,
what
was
the
other
thing?
I
can
I'm
completely
completely
blanking,
but
I
let
another
workshop
where
we
did
something
similar
or
like
something
that
was
also
blocking
us
like
this
like
longer
term
vision,
type
stuff,
so
it'd
be
awesome
to
get
that
yeah
and
I
see
tyler
just
typing
some
stuff
up
so.
E
Yeah,
this
is
just
still
me
being
new.
This
has
been
something
that,
like
I
see
mentioned
often
and
like
I
have
a
handful
of
times
like
conflated
with
other
like
okrs
or
projects,
and
so
I
think
like
I
just
want
clarity
on
like
what
the
plan
is,
and
I
think
there
was
like
danielle
asked
me
what
asked
michael
a
question
you
asked
me
a
question
about.
E
Like
was
a
decision
made
and
I
was
looking
through
the
threads
there
and
I
felt
like
I
felt
still
very
unclear
about
what
problems
we're
actually
solving.
I'm
sure
we
could
all
list
many
like
challenges
that
need
solving,
but
I
don't
know
what
the
priority
is,
and
I
also
don't
know
where
to
like,
where
I
would
begin
with,
like
an
epic
or
some
sort
of
project
plan,
to
like
look
for
the
status
of
this
and
for
deadlines
and
other
things
around.
D
Well
I
mean
we
do
have
our
our
weekly
or
like
our
bi-monthly
working
group
sessions,
so
I
was
thinking
that
would
probably
be
a
good
time.
We
can
also
set
up
other
time
too
just
because
that
call
also
is
we're
inviting
everyone
in
the
team
and
not
everyone
in
the
team
needs
to
be
in
that
discussion.
So
I
don't
know
I'm
open
to
a
couple
different
ideas.
Also,
like
timing,
wise,
I
don't
know
in
terms
of
like
what
your
discussion
about
priorities.
I
don't
know
how
much
of
a
priority
is
it.
D
A
All
right
last
thing:
here
somebody
wrote
an
fyi,
I
don't
know
who
who
wrote
this
dude?
Do
you
want
to
talk
about
it
at
all
or
just
kind
of.
E
No
sorry
that
was
me
I
just
I
was
responding
to
sami's
comment.
I
didn't
want
it
to
get
lost
if
comments
got
resolved,
but
that's
the
video
for
the
cms
migration
and
lauren
has
posted
that
as
well.
A
A
No
all
good
awesome,
all
right!
Well,
that's
it
for
us,
then,
thanks
for
coming
to
our
retro.